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 Mar 20, 2014, at 4:21 AM, Erik Rissanen <erik@axiomatics.com> wrote:

> Hi,
> 
> Why does the ipAddress-value data type have a network mask?

A mask of /32 represents an "end point" using CIDR notation. This is commonly used in router or firewall rule/policy expression.

> 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?

Using CIDR notation on an IP address is the more formal expression. 

> 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.

Yes. I was not successful in making the case for it sufficiently. I believe this is a very useful extension of this logic.

I don't think there is a definitive reference for how port/portranges are described with respect to IP addresses. There are some notational conventions (which we adopted in the Profile), but I don't think anyone was able to identify an RFC specification on how it is to officially be expressed. Based on that, a portrange was also deemed "valid" an extension to IP address for our purposes. 

If we were to pursue the port matching concept I would offer that the best way to do it is via portrange matching, extending your equals vs. match concept. All ports references would be a range. Therefore a single port would be expressed as a range of one port (e.g. "8000-8000"). Personally, I would express this as upperPort and lowerPort attributes in XML, pulling port notation away from the IP address value completely, thus keeping the matching function logic in tact (sans the need to pare port off). I would further suggest that we make port mandatory and allow for a wildcard/keyword value to represent ports 1-65535 for completeness.

b


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