DLP/NAC Profile wd4

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

I added the IP Address and DNS Name datatypes and functions to the DLP profile as I described on the call last week.

To avoid forward references, I put the new stuff at the beginning of section 2, which forced the renumbering of that section. I hope that didn't break anything.

Please everybody take a close look at what I wrote, especially the function descriptions. (I am already considering some wording changes for clarity.) If anyone knows of someone actually working with IP v6 networks, it would be very useful to found out about current practices in notation and subnetting.

I had to make a number of fairly arbitrary decisions which I don't feel strongly about. I would be glad to change them if there is a consensus to do so.

1. I introduced generalized, non-contiguous port ranges. However I chose not to prohibit various odd but harmless forms, such as out of order and redundant ranges. The following is legal, but IMHO not best practice.

192.1.1.1:3000-4000, 123-200, 3333, 150-500

2. I chose to use CIDR format only for the mask. It seems more efficient, less error prone and most importantly, more popular.

3. I decided that for the match functions, if the -pattern contains a mask, you probably care about the mask and the -value must also contain a mask with the same value. For consistency I defined the equal functions to treat the first and second arguments the same way even though both arguments are value types. 

4. It is my understanding that IP v6 networks use 64 bits for network and 64 bits for host as a default. For consistency with #3 I defined the network-match function for IP v6 to require that either both inputs have a mask or neither does, rather than treat 64 bits as the default for a missing mask. I don't feel strongly about this. I understand currently only about 2% of all deployed hosts are on v6 networks, (You can't have mixed networks.) so it is hard to find any info on subnetting schemes other that 64 bits for v6. The Internet of things will probably be the main driver for v6 deployment.

5. Portranges are ignored by all the functions except the endpoint-match ones.

6. I chose to define DNS wildcarding very strictly. The names must have exactly the same number of components and only the leftmost one can be wildcarded. For example: *.example.com matches www.example.com but not foo.bar.example.com or example.com. This was mostly to preserve my perception of the intent of the stuff in core and of course the avoid all the messiness which surrounds the mysterious http same origin policy enforcement.

7. I tried to change all the relevant attribute definitions, eliminating the core datatypes in favor of the new -value ones. Please check to see if I missed any. Should I have kept both the old and new? That would help backward compatibility between PEPs which support the Profile and PDPs that do not. (Using roll your own comparison functions.)

8. I changed one of the examples to use ipAddress-value instead of ipAddress. I noticed that the examples have embedded comments stating they were generated using ALPHA. Obviously the changes I made broke that, since ALPHA does not support the datatypes I just made up. I think as a matter of good standards practice we should remove the comments and insert a footnote or inline comment acknowledging the use of Axiomatic's tool. I don't want to imply to anyone that you have to use ALPHA to use the Profile. What do others think?

9. I added a new section at the beginning of the conformance chapter, again forcing renumbering. I made everything mandatory.

While I am at it, I noticed that Section 1.7 Disclaimer is empty. Is there an intention to put something there?

Hal