IP Address types and functions, was: RE: [xacml] Groups - DLP-NAC profile uploaded

[Hal Lockhart <hal.lockhart@oracle.com>]

This thread has a lot of good discussion, but it is not clear to me exactly what the consensus is. Before I update the DLP-NAC Profile, let me try to state what I think is agreed and what I think is missing.

1. Fix typo in definition of the ipAddress-value-equal function (2.1.3):

Change: (Any portrange values in either argument SHALL be ignored.)
To:     (Any port values in either argument SHALL be ignored.)

2. Because network mask cannot reliably determined and/or may not be that useful we should drop the network-match function.

Comment: My original idea here was that it is common to limit actions to the same subnet (or rarely to different subnets). The reasoning is that routing subnets frequently correspond to physical divisions of the network, such as a building or a floor. Obviously this can be done by specifying ranges, but I was hoping that getting the mask from the network would be a way to make a policy remain valid in spite of minor minor network reconfigurations in a way that hardwiring the address range into a policy would not. In principle, I have no problem with dropping network-match.

3. I am not sure what to do about the mask. If we don't use it, and can't depend on its value. Perhaps we should drop it entirely. I know it may be required by some hardware or software components, but that doesn't mean we have to carry it in our IP Address Value. (or pattern).

If that is not acceptable, should I say: it can appear or not, but if it appears it is ignored?

4. With regard to Bill's proposed matching scheme, is this the proposed syntax or just a functional example?

> Example 1 (range):
> 
> IpAddressRangeStart = 10.10.0.0
> IpAddressRangeEnd = 10.10.10.255
> IpPortRangeStart =
> IpPortRangeEnd =
> 
> match: All addresses between and including 10.10.0.0 and 10.10.10.255.
> Port is not evaluated so ALL ports "match".

Note that we already have a syntax for port range defined in core Appendix A2. It looks like: 

Portrange =- portnumber | "-"portnumber | portnumber"-"[portnumber]

I generalized this to:

portrange = portnumber | "-"portnumber | portnumber"-"[portnumber]
portrangelist = portrange ["," portrange]

Is one of these ok for syntax or do you want to have IP Address Pattern be a complex XML attribute with 4 fields (sub elements)?

If you like the portlist syntax, can we define something similar for ip address:

Either: 10.123.1.1-10.123.1.200,10.123.2.0-10.123.2.255 or 10.123.1.[1-200],10.123.2.[255] or something similar?

Thoughts, suggestions?

Hal


> -----Original Message-----
> From: Bill Parducci [mailto:bill@parducci.net]
> Sent: Tuesday, March 25, 2014 11:39 AM
> To: Hal Lockhart
> Cc: Erik Rissanen; XACML TC
> Subject: Re: [xacml] Groups - DLP-NAC profile uploaded
> 
> If the goal here is to make things as simple as possible then I suggest
> we simply limit it to the following for *ranges* (the use of the term
> "subnet" I think is the root of some of our confusion) and ports:
> 
> IpAddressRangeStart
> IpAddressRangeEnd
> IpPortRangeStart
> IpPortRangeEnd
> 
> I suggest IpAddressRangeStart and IpAddressRangeEnd are mandatory,
> while IpPortRangeStart and IpPortRangeEnd are optional as a pair. The
> syntax is the same for ranges and single IPs ("range of 1").
> 
> Netmask is unknowable outside of the subnet local to the requesting
> device (even then it is only a decent assumption). One hop over a
> router and there is nothing to work with beyond IP address, port and
> previous hops (which requires a lookup). The netmask use case then
> pretty much distills down to code running on the machine bound to the
> network, evaluating other processes on that same machine. Maybe some
> can point to it, but I can't think of any other situation where the
> netmask is truly known.
> 
> Ranges on the other hand make perfect sense and are generally what you
> see in practice for things like webservers, etc.
> 
> Here are some examples of what I think will meet most of our needs.
> Netmask could always be added as an optional value should we determine
> there is a need for it.
> 
> Example 1 (range):
> 
> IpAddressRangeStart = 10.10.0.0
> IpAddressRangeEnd = 10.10.10.255
> IpPortRangeStart =
> IpPortRangeEnd =
> 
> match: All addresses between and including 10.10.0.0 and 10.10.10.255.
> Port is not evaluated so ALL ports "match".
> 
> Example 2 (single IP):
> 
> IpAddressRangeStart = 10.10.0.1
> IpAddressRangeEnd = 10.10.0.1
> IpPortRangeStart =
> IpPortRangeEnd =
> 
> match: only 10.0.0.1
> 
> Example 3 (range, with port):
> 
> IpAddressRangeStart = 10.10.0.0
> IpAddressRangeEnd = 10.10.10.255
> IpPortRangeStart = 8000
> IpPortRangeEnd = 8000
> 
> match: All addresses between and including 10.10.0.0 and 10.10.10.255,
> using port 8000
> 
> Example 4 (range, with port INVALID):
> 
> IpAddressRangeStart = 10.10.0.0
> IpAddressRangeEnd = 10.10.10.255
> IpPortRangeStart = 8000
> IpPortRangeEnd =
> 
> IF either port value is provided, BOTH must be stated. This is what I
> meant by "optional pair".
> 
> The mechanics for evaluating this are consistent and could be handled
> by a single matching function.
> 
> b
> 
> On Mar 25, 2014, at 7:19 AM, Hal Lockhart <hal.lockhart@oracle.com>
> wrote:
> 
> > All of this more complex matching can be done using existing
> functions by converting the address to a string and using a regex (or
> other string functions) against it. I suggest we stick to the most
> basic and clearly useful functions.
> >
> > I still want to look a use cases in terms of 1) location of PEP and
> 2) type of attribute the IP address is and 3) source of the address
> information, particularly the mask.
> >
> > Here is my list:
> >
> > 1. Web or App Server, Firewall, Network access point 2. Subject,
> > Resource, Environment (is this really just subject?) 3. Packet
> > Inspection, Various containers (Servlet, JSP, EE, .Net), OS
> Primitives
> >
> > What Have I missed?
> >
> > Hal
> >
> >> -----Original Message-----
> >> From: Bill Parducci [mailto:bill@parducci.net]
> >> Sent: Monday, March 24, 2014 12:54 PM
> >> To: Erik Rissanen
> >> Cc: Hal Lockhart; XACML TC
> >> Subject: Re: [xacml] Groups - DLP-NAC profile uploaded
> >>
> >> That is a more flexible option, although it will take a fair amount
> >> of wording to describe how to match multi-octet ranges I suspect.
> >> Multi- octet would be expressed similarly I assume? (e.g.
> >> 10.123.[19-20].[10-
> >> 14,19])
> >>
> >> b
> >>
> >> On Mar 24, 2014, at 12:39 AM, Erik Rissanen <erik@axiomatics.com>
> >> wrote:
> >>
> >>> 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_workgroup
> >>>>>>>> s.php
> >>>>>>>>
> >>>
> >>>
> >>
> 
> 
> ---------------------------------------------------------------------
> 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
>