Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

["C. M. Heard" <[e-mail]>]

On Wed, 01 Nov 2017, Michael Richardson wrote:
> Yet we skip other extension headers in order to find the ULP.

Not so. An end node that encounters an unrecognized extension header is
not supposed to skip the unrecognized extension header; it is supposed
to discard the packet. See Section 4 of RFC 8200:

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.

Substantially the same language appears in Section 4 of RFC 2460.

It is, in fact, impossible to reliably tell the difference between an unknown
extension header and an unknown upper layer protocol because they are drawn
from the same numbering space. That fact has been discussed here on more than
one occasion.

> In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
> header....  Because we got this wrong, we couldn't use AH to secure ND or any
> other multicast (like OSPF) without causing of a flag day.  AH became totally
> USELESS.  It was sad.

There may be problems with AH, but that is not one of them.

Mike Heard