I touched on this and other issues I consider open in this email last November:
https://lists.oasis-open.org/archives/xacml/201311/msg00011.html
I left the mask as an option in the –value mostly because it is allowed in the current 3.0 datatype and also because I thought it was just possible that somebody would want to insist that two identical values with different masks not be considered equal. I don’t know if there is any legitimate way for this to occur. Clearly you could have a case where the subnet had been reconfigured and there was some old data around.
Note also that the ipAddress-network-match function needs a mask as input. Clearly two identical addresses with different masks may not match using this function.
As I said in the referenced email, I am open to making changes related to any of the 8 issues I identified.
Hal
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, March 20, 2014 7:22 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Groups - DLP-NAC profile uploaded
Hi,
Why does the ipAddress-value data type have a network mask?
Maybe it was discussed on a call when I was not present, and I am not a networking expert and might not understand what the intention was, but I tried to retrace the discussion on the list. If ipAddress-value is intended to represent a specific network endpoint, then it should not contain a mask, since masks are used to represent IP address ranges, right?
Likewise, the matching functions which use a pattern, they should not be comparing the mask for straight equality, right? I read the intent of the matching functions to be used for checking whether an ipAddress-value is within the network segment denoted by the ipAddress-pattern. The value should be within the range of the pattern, so there should not be a check to see that the mask is equal, or actually, the value should not have a mask in the first place.
Also, regarding the network match function, now it is defined as a strict equality function, but it could be useful to separate between an "equals" and a "match", where the latter allows for one argument to be a subset of the other.
And, did you consider the need of an ipAddress value equal function which also checks the port? BTW, the definition of ipAddress-value-equal says that "Any portrange values in either argument SHALL be ignored", but an ipAddress-value does not have a portrange, it has a port.
Best regards,
Erik
On 2014-03-19 20:54, John Tolbert wrote:
Submitter's message
All feedback received thus far has been incorporated. Please review. Volunteers needed to generate sample XACML policies for examples 4.1.2 to 4.2.2. Thanks
-- Mr. John Tolbert