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

2401bis protocol selector

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