Re: Conflicting requirements for sending ICMPv6 and EH scan?

[Tom Herbert <[e-mail]>]

On Fri, May 24, 2019 at 11:57 PM Mikael Abrahamsson <[e-mail]> wrote:
>
> On Fri, 24 May 2019, Tom Herbert wrote:
>
> > Hello,
> >
> > I am updating the references in Linux stack from RFC2460 to RFC8200. I
> > came across the ipv6_skip_exthdr function which contains a long, and
> > somewhat apologetic, comment that this function is purposely walking
> > over all the IPv6 extension headers for the purpose of locating the
> > transport layer protocol and hence violates RFC2460 (RFC8200):
> >
> > "Therefore, extension headers must be processed strictly in the order
> > they appear in the packet; a receiver must not, for example, scan
> > through a packet looking for a particular kind of extension header and
> > process that header prior to processing all preceding ones."
> >
> > The need for this function arises from the requirement of RFC4443:
> >
> > "(e) An ICMPv6 error message MUST NOT be originated as a result of
> >       receiving the following:
> >
> >       (e.1) An ICMPv6 error message."
> >
> > So, for instance, if we are sending an ICMP error because of a problem
> > with an extension header, we need to walk (process) the  other
> > extension headers to determine if the transport is ICMPv6 and if it is
> > then not send the error.
> >
> > The comment is over fourteen years old! I would like to resolve
> > somehow as not being a violation of standard. Any ideas how to do
> > that?
>
> Is this ipv6_skip_exthdr only used as a sanity check when having decided
> to send an ICMP6v6 error message, or is it used in other cases as well?
>
Mikael,

Good question! Yes, it seems to be called in a few cases. We also skip
over extension headers when trying to determine the flow of packet
(for firewall or hash for ECMP, etc.). The commonality amongst all
these cases seems to be that they are doing passive DPI with the
purpose of extacting higher protocol layer information about a packet
to make decisions or to fulfil requirements when processing lowering
layers (as in the case of the ICMPv6). So I think it might be
reasonable to say that these conform with the spirit of RFC8200
requirements since this is only parsing headers beyong the current
header being processed, not actually performing the specified
processing of deeper protocol headers out of order.

The also implies another subtle issue. ESP might be used in transport
mode with ICMP, so it would is impossible to determine in that case
whether an ESP packet contains an ICMP error. That's probably a
pathological issue.

Tom

> --
> Mikael Abrahamsson    email: [e-mail]