2401bis protocol selector

[Mark Duffy <mduffy@quarrytech.com>]

Hi,

rfc2401bis-00 in sect. 4.4.2 has the following text:


>   - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
>     IPv6 "Next Header" fields.  This may be an individual protocol
>     number.  These packet fields may not contain the Next Layer
>     Protocol due to the presence of IP extension headers, e.g., a
>     Routing Header, AH, ESP, Fragmentation Header, Destination
>     Options, Hop-by-hop options, etc.  Note that the Next Layer
>     Protocol may not be available in the case of receipt of a packet
>     with an ESP header, thus a value of "OPAQUE" SHOULD be
>     supported..br [REQUIRED for all implementations]
>
>
>     NOTE: To locate the Next Layer Protocol, a system has to chain
>     through the packet headers checking the "Protocol" or "Next
>     Header" field until it encounters either one it recognizes as a
>     Next Layer Protocol, or until it reaches one that isn't on its
>     list of extension headers, or until it encounters an ESP header
>     that renders the Next Layer Protocol opaque. Note: The IPv6
>     mobility header is a possible next layer protocol.

The text above is almost identical to that in RFC 2401.
My comment following is focused mainly on IPv4; v6 may be similar.

The above text has always struck me as an undesirable way of working.   Why 
should certain protocols carried in IP be considered "next layer" protocols 
(for which the SPD should be evaluated) while other protocols (e.g. AH) are 
considered to be things one should look inside to find a deeper header to 
evaluate against the SPD?  Shouldn't the IPsec policy just be evaluated 
against the outermost "plaintext" packet presented to IPsec, regardless of 
the protocol indicated?  I believe this has caused quite a bit of confusion 
in the past e.g. for protocols such as AH, ESP, IP(4) and GRE.

Can we please change this in 2401bis to remove any special cases and just 
treat every IP packet the same?  This could be accomplished (for IPv4 
anyway) by removing all of the quoted text above except for the first two 
sentences.  I believe we could also remove the confusing table about next 
header and derived port selectors and its descriptive text two paragraphs 
further down in the document.

If we don't make such a change, then the document should clearly enumerate 
which values of the IP header protocol field are "next layer protocols" and 
which are 
non-next-layer-protocols-that-you-look-inside-for-a-next-layer-protocol.

Thanks, Mark