OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Groups - DLP-NAC profile uploaded



On 2014-03-20 17:24, Bill Parducci wrote:
On Mar 20, 2014, at 8:59 AM, Erik Rissanen <erik@axiomatics.com> wrote:

Thanks Bill,

That clarifies things. So what you are saying is that what we usually type in as single IP, say 123.123.123.123, is actually shorthand for the actual meaning, 123.123.123.123/32?
Pretty much. Every routing device/firewall I have been exposed to is rather picky about this :)

Does that mean that all instances of the ipAddress-value data type must have a mask of 32 (for IPv4), if they have the mask specified?
That is my understanding. Given the sensitive nature of our space I believe that we should be as unambiguous as possible with this notation. While the two of us can agree upon what "192.168.1.1" means casually, there are literally millions of instances of that IP address out there and the only way to precisely define it is via a route from the current context (network). "/32" tells the router: "look for 192.168.1.1 HERE, do NOT explore beyond this subnet (make an arp request ONLY)". Your workstation thinks of its IP address the same way, it will not reach out to the router if [IP Address] is bound to its card because it considers locally bound IPs as /32 "routes" (and its local stack is a "network", but I digress :).

Ok, but then there is something else which is wrong because the ipAddress-endpoint-match function says "If the first argument contains a mask, the second SHALL also contain a mask with the same value". This implies that if this function is to be useful, then masks must always be /32, even for the pattern data type. I doubt that was what intended. I guess it's the match function definition which is wrong. Presumably it should say that the mask must be equal or greater in value.



Regarding when I said "... but an ipAddress-value does not have a portrange, it has a port", I was referring to a simple typo in the spec. It should say "Any _port_ values in either argument SHALL be ignored"
Ah, got it. I still like your idea of port range inclusion and matching :)

b



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]