[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ip address datatype & matching function proposal
i was pondering our ip address match function (looking for the best way to represent a range) and began wondering if we shouldn't qualify addresses as ipv4 or ipv6 when invoking this function. after spending two hours hashing through this it reinforces my belief that this is one of those things that *looks* easy, but is a tough nut to crack! to begin, since the fundamental composition of ipv6 URLs (rfc2732) are significantly different than that for ipv4 URLs (rfc2396) i suggest that we first make a few changes to the spec: 1. remove datatype urn:oasis:names:tc:xacml:2.0:data-type:ipAddress 2. add datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address For purposes of policy writing XACML IP addresses follow rfc2396: A four byte octet (32 bit) written as decimal values separated by ".". Example: 192.168.254.252. 3. add datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv4AddressMask A four byte octet (32 bit) written as decimal values separated by "." used to define the boundary of an IP address range when applied to an urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address. Example: 255.255.255.0 specifies as 24 bit subnet mask; when applied to an IP address such as 192.168.254.0 it refers to all IP addresses from 192.168.254.0 through 192.168.254.254 4. add datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address For purposes of policy writing XACML IP addresses follow rfc2732: A 128 bit number written in hex, bracketed with "[]". Example: [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] 3. add datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv6AddressMask A 128 bit number written in hex, separated by ":" and used to define the boundary of an IP address range when applied to an urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address. Example: ffff:ffff:ffff:ffff:0000:0000:0000:0000 specifies a 64 bit subnet mask; when applied to 3ffe:ffff:0100:f101:0210:a4ff:fee3:9566 defines a range from 3ffe:ffff:0100:f101:0000:0000:0000:0000 through ffe:ffff:0100:f101:ffff:ffff:ffff:ffff. then we correct a problem with the current ip address matching function (it allows for a mask but provides no mechanism to pass it, nor does it provide port range syntax). A. remove function urn:oasis:names:tc:xacml:2.0:function:ipAddress-match B. create function urn:oasis:names:tc:xacml:2.0:function:ipv4Address-match This function SHALL take two arguments of data-type urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address and one argument of datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv4AddressMask. Applying the ipv4AddressMask to the first ipv4Address argument specifies the set of addresses that are acceptable for the match to be "True". The second ipv4Address argument specifies a particular address to be tested against the set of acceptable values. This function SHALL return "True" if, after each address and mask are converted to their byte sequence equivalents, a) the second ipv4Address argument falls within the address range defined by the application of the ipv4AddressMask to the first ipv4Address argument. Otherwise, this function SHALL return "False". C. create function urn:oasis:names:tc:xacml:2.0:function:ipv6Address-match This function SHALL take two arguments of data-type urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address and one argument of datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv6AddressMask. Applying the ipv6AddressMask to the first ipv6Address argument specifies the set of addresses that are acceptable for the match to be "True". The second ipv6Address argument specifies a particular address to be tested against the set of acceptable values. This function SHALL return "True" if, after each address and mask are converted to their byte sequence equivalents, a) the second ipv6Address argument falls within the address range defined by the application of the ipv6AddressMask to the first ipv6Address argument. Otherwise, this function SHALL return "False". NOTES: this solution requires that ALL ip address matching have a mask on the bounding address (a 32/128 bit mask for v4 and v6 respectively will yield a single address if desired). port numbers are not part of the ip addressing matching function. in keeping with my proposal that uri matches are broken into two components (host & resource), and the port number being a subset of the 'resource' portion, it is matched using regex (with the rest of the resource notation). personally i think this is a lot easier than creating yet another datatype (ipPortrange or something) and adding yet another argument to the matching function. anyway, this is what i came up with... b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]