I admit to being a little rusty, but consulting my copy of Stevens, I believe the following is true. This discussion only considers IP v4. A specific IP address is assigned to an adapter on a host. From the value of the address you can determine whether it is of Class A, B or C. However, a network administrator can configure any network to treat part of the hostid field of the address (as defined by the Class) to be used as the subnet. The subnet can fall on a byte boundary or not. There is no way to tell what subnetting is being used merely by inspecting the IP address value. In principle it is possible to reconfigure the subnetting without changing the assigned IP addresses of the hosts on the network. (Nowadays clients use DHCP which provides the mask as well as the IP address at connection time, so admins only have to worry about the servers.) In general, end (non-routing) nodes do not need to know what subnetting is in effect to send and receive messages, since everything comes and goes on the same adapter. However to determine if two hosts are on the same network you need to know the subnetting in use. An IP address assigned to a real adaptor on a real network will be subject to some particular subnet scheme, but an address which has merely been allocated for use by some organization may not. I guess my view was to be conservative and allow all constructs which are not actually impossible, even though I can’t necessarily think of a usecase. The main justification I can see for what I have proposed is that in might detect certain configuration errors resulting from out of date information. However, I do think users will expect IP v4 addresses values to be able to contain an optional mask value even if we were to drop the network match function and otherwise ignore the mask. Hal From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, March 20, 2014 11:53 AM
To: Hal Lockhart; xacml@lists.oasis-open.org
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 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 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
|