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

Hi Hal,

Yes, I saw this email, but I did not understand the reasoning behind point 3, which is the motivation that the value will also contain a mask.

It could be that I don't understand networking well enough, but it looks to me that the proposal (and the existing data types) mixes a few separate concepts.

An IP address designates a network interface, which the network will route packets to.

Some protocols over IP use ports. Examples of these are TCP and UDP. A combination of an IP address and a port designates a communication endpoint using one of these protocols.

Network masks are used by routers to decide network segment boundaries, so they can forward a packet in the right direction.

I guess these could be combined in different ways. For instance the IP and port could be separate attributes, or combined, like now in the profile.

As I read the profile, I read the ipAddress-value the be intended to designate either a IP address, or a TCP/UDP (or other protocols which uses ports) endpoint. This should not contain a mask since it is a single designated IP. I think the old data type has the mask because it has served as both the "value" and "pattern" in one data type.

The "pattern" type does need the mask, since the pattern type conceptually corresponds to a network segment. (BTW, the pattern type could potentially be generalized to not be limited to a single network segment like this. You could have bunch of network segments separated by commas, but I am not sure if that is needed for the intended use of this profile.)

So, if I have as the pattern, then will not match because it is a different segment than what the pattern designates. However, if the pattern would have been, then it would match because it's within the 123.123.*.* segment, if I may use a made up notation.

Best regards,

On 2014-03-20 16:23, Hal Lockhart wrote:

I touched on this and other issues I consider open in this email last November:




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.




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



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,

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

Document Name: DLP-NAC profile

Working draft 05.
Download Latest Revision
Public Download Link

Submitter: Mr. John Tolbert
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2014-03-19 12:54:23


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