Re: Conflicting requirements for sending ICMPv6 and EH scan?

[Tom Herbert <[e-mail]>]

On Tue, May 28, 2019 at 3:23 AM Ole Troan <[e-mail]> wrote:
>
> Tom,
>
> > The rfc4443 text you are quoting is from section 2.4. That deals with processing rules for ICMP messages. That is, you already know you have received an ICMP at that point.
> >
> > If you are looking at the corner case where someone sends you an ICMP message with an unparsable extension header chain, then you have to treat that as any other packet with unknown headers.
> >
> > Ole, here is an example scenario:
> >
> > A host receives a packet with a destination option whose type is unrecognized by the host. The high order bits of the option type indicate that an ICMP error should be sent in response to receiving an unknown option. But, per the text quoted from RFC4443, we are not permitted to send the ICMP error if the received packet was itself an ICMP error packet. At this point, we're only processing the destination options, so we don't know yet whether or not the received packet is ICMP-- the only way to determine that is to parse the packet beyond the destination options EH to find the transport protocol.
>
> But in the general case you cannot. And probably shouldn't either.

Ole,

Unless there's an unknown EH or the ICMP message is in ESP, this
algorithm should work pretty well. The only downside really is the
potential for a false negative where we couldn't determine the ICMP
message and send an error contrary to RFC4443. Conceptually, we could
eliminate the false negatives by parsing to find if the packet
contains a recognizable end transport protocol (TCP, UDP, SCTP, etc.)
and if we can't find one withhold the ICMP error. That would be closer
to conformance with RF4443 at the cost of more implementation
complexity and now false positives where we could have sent the ICMP
error but didn't.

> In this case the stack cannot know that it has received an ICMP message and the provisions in RFC4443 do not apply.

Strictly reading RFC4443, if we don't know rather the packet in error
is ICMP we can't send an ICMP error. So if we can't parse beyond an
extension header to determine if the packet is ICMP, we can never send
an ICMP error because of an extension header problem!

>
> Is there any case where an ICMP error message can include extension headers before the ICMP header?

Sure. There's no restrictions for using extension header headers with
ICMP. For example, when a host sends an ICMP error to some peer the
destination address is routed and the route lookup for that
destination may provide a routing header, hop-by-hop options, etc. We
don't typically do special routing for ICMP.

>
> If we allow that, you could indeed imagine a (very constructed) case, where host A sends host B an unparsable header chain ICMP, and host B responds with a different unparsable header chain ICMP.

Yep, that is a problem and presumably why RFC4443 mandates to not send
ICMP in response to ICMP errors.

Tom

>
> Best regards,
> Ole
>