Re: 2401bis protocol selector

[Stephen Kent <kent@bbn.com>]

At 14:47 -0500 11/24/03, Mark Duffy wrote:
>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?

the intent is to treat most protocols as next layer protocols. For 
IPv4 this is not an issue. Only in IPv6 do we encounter complexity 
due to the extension headers. we can reword the text to minimize 
confusion.  there is no need to skip any protocol headers, under the 
new processing model, except the IPv6 extension headers. because the 
new model calls for external forwarding to route a packet through the 
IPsec processing, if more than one pass is needed, we should be able 
to simplify the description.

>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.

yes, it has caused confusion in the past and we hope to avoid that in 2401bis.

>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.

we'll revise the text and, expect for IPv6 extension headers, I think 
it will be pretty simple.

>
>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.

I think we can make the "next header" selection discussion simpler.

Steve