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 123.123.123.123/24 as the pattern, then 123.123.124.4
will not match because it is a different segment than what the
pattern designates. However, if the pattern would have been
123.123.123.123/16, then it would match because it's within the
123.123.*.* segment, if I may use a made up notation.
Best regards,
Erik
On 2014-03-20 16:23, Hal Lockhart
wrote:
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:]
Sent: Thursday, March 20, 2014 7:22 AM
To:
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
Document
Name:
DLP-NAC
profile
Description
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
