[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2401bis protocol selector

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