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 Bill,

Yes, it makes sense to me.

But it opens the question, if subnets cannot be reliably known, and most people in fact want to base their policies on arbitrary IP ranges, which are unrelated to physical subnets, should the ipAddress-pattern data type be based on subnets like it is now? Shouldn't it instead be some other form of pattern matching, allowing arbitrary ranges? Like "10.123.123.[10-14,19]"?

Best regards,
Erik


On 2014-03-21 20:40, Bill Parducci wrote:
Yes, this looks correct to me. I personally do not like the idea of writing a policy that uses the concept of the "same subnet" because there are some interesting artifacts associated with private addressing, but if we wish to allow for that sort of thing then I support your proposal with a small tweak (after a long winded rumination--I would like to capture this should we revisit in the future)...

As we touched on during the call, when private addresses are involved an address such as

subject-ip-address = 10.123.123.123/32
subject-subnet = 10.123.0.0/16

...it may describe any number of different and unrelated devices that match both the subnet and ip address. The case could be make that this is true for IP address so policy generation/evaluation needs to mindful of this. My concern is that the IP address is known by the PEP by inspecting the packet *anywhere*, while the subnet that the device is bound to is only known by the sending device (or at best a device residing on the same subnet as that device).

the device bound to 10.10.123.123.123 may be configured to be part of the 10.0.0.0/8, 10.123.0.0/16, 10.123.123.0/24... subnets in reality, but the value represented in the policy is representational only; it doesn't necessarily reflect how that device interacts with the world. This is not necessarily a bad thing--policies are likely to be based upon ranges of IPs defined within an organization--we just need to be aware of this divergence.

Stated another way, there is no way to know the true subnet a device is bound to by inspecting a packet that is not on a network local to the device (shared subnet). Therefore, the value represented in the policy is not truly the subnet the device is bound to but rather an address range that it is a part of by definition. One possible way to work through this is to consider the following syntax:

subject-ip-address = 10.123.123.123/32
subject-ip-address-range = 10.123.0.0/16

Assuming we are talking about a server, the policy thinks of the server as 10.123.123.123/32. The policy also thinks of the server as being a part of 10.123.0.0/16. However, the server may actually be bound to the network (TCP/IP) as 10.123.123.123/24 for routing purposes. For the purposes of the policy evaluation we frankly don't care that the server is physically bound to the 10.123.123.0/24 network. Evaluation ONLY occurs against those values that are in the policy, one as a Subject and one as a "Subject group" (for lack of a better term). Or, to think of it one other way, subject-ip-address-range is just a bag of contiguous IPs and has nothing to do with the routing behavior of the subject device (which is what I really think we should aim for here. Routing concepts are what I think have been confusing the conversation. I think we can separate them out to our benefit ;) This same logic should apply resources.

Does this make sense?

b

On Mar 21, 2014, at 1:00 AM, Erik Rissanen <erik@axiomatics.com> wrote:

Based on what I heard on the call yesterday, and Bill's comments in this thread, there are two concepts which matter to the use cases we are talking about in the profile:

1. The ip endpoint of a some entity (like the subject or the resource)
2. The subnet of the said entity.

The former is an IP address with a netmask of /32 (which is commonly not spelled out in consumer/office grade user interfaces).

The latter is an IP address with a netmask which is less than /32.

Shouldn't these be different XACML attributes? That would solve the ambiguity regarding the meaning of the netmask.

For instance, you could have a request like this:

Subject
  subject-ip-address = 123.123.123.123/32
  subject-subnet = 123.123.0.0/16
Resource
  resource-ip-address = 123.123.124.54/32
  resource-subnet = 123.123.0.0/16

To write a policy which permits the access if the subject and resource are on the same subnet, you would match the subject-subnet and resource-subnet attributes. Or perhaps the subject-ip-address against the resource-subnet.

You would not be matching the subject-ip-address with the resource-ip-address because they don't contain the required information. (Unless we change the meaning of the netmask in the ipAddress-value data type to mean the netmask of the subnet the ip is part of, but that is not consistent with the use of netmask /32 in firewalls, etc, as described by Bill.)

Bill, do I understand this correctly?

Best regards,
Erik



On 2014-03-20 21:35, Bill Parducci wrote:
On Mar 20, 2014, at 1:25 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

First of all, I don't believe a non-routing host needs to know the mask to send messages. It just puts them out on the adapter (LAN). The Gateway (router) on the LAN is supposed to forward the message if required, based on its knowledge of the subnetting.
The "gateway" is the first hop in the route. Do `netstat -nr` on your workstation (or whatever Windows uses if you have that) to verify. This is why the "gateway" is also referred to as the "Default Route". The workstation will not converse with the Gateway if the destination IP address is within the range of the bound IP's netmask. In that case it will issue an arp request and craft a packet using the MAC address of the responding device.

b



Hal

-----Original Message-----
From: Bill Parducci [mailto:bill@parducci.net]
Sent: Thursday, March 20, 2014 12:24 PM
To: Erik Rissanen
Cc: XACML TC
Subject: Re: [xacml] Groups - DLP-NAC profile uploaded

On Mar 20, 2014, at 8:59 AM, Erik Rissanen <erik@axiomatics.com> wrote:

Thanks Bill,

That clarifies things. So what you are saying is that what we usually
type in as single IP, say 123.123.123.123, is actually shorthand for
the actual meaning, 123.123.123.123/32?

Pretty much. Every routing device/firewall I have been exposed to is
rather picky about this :)

Does that mean that all instances of the ipAddress-value data type
must have a mask of 32 (for IPv4), if they have the mask specified?

That is my understanding. Given the sensitive nature of our space I
believe that we should be as unambiguous as possible with this
notation. While the two of us can agree upon what "192.168.1.1" means
casually, there are literally millions of instances of that IP address
out there and the only way to precisely define it is via a route from
the current context (network). "/32" tells the router: "look for
192.168.1.1 HERE, do NOT explore beyond this subnet (make an arp
request ONLY)". Your workstation thinks of its IP address the same way,
it will not reach out to the router if [IP Address] is bound to its
card because it considers locally bound IPs as /32 "routes" (and its
local stack is a "network", but I digress :).

Regarding when I said "... but an ipAddress-value does not have a
portrange, it has a port", I was referring to a simple typo in the
spec. It should say "Any _port_ values in either argument SHALL be
ignored"

Ah, got it. I still like your idea of port range inclusion and matching
:)

b
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





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