Re: Conflicting requirements for sending ICMPv6 and EH scan?

[Ole Troan <[e-mail]>]

Tom,

>>> (Trimmed.)
>>> If you don't check for ICMP in the received message, couldn't one easily get two misbehaving boxes (each trying to use an option the other doesn't understand) bouncing ICMPs back and forth?  Preventing that is the reason for the rule.
>> 
>> Right.
>> If host A includes in it's ICMP error messages an unknown to host B EH _ and_ host B includes an unknown to host A EH in it's ICMP error messages, you would get a loop.
>> That I don't think we can fix, apart from stating though shalt not do that.
>> 
>> Now, for the case where host A includes in it's ICMP error message an known EH, but with a problematic option inside, and host B would do the same, then Tom's "skip to the end if I can" approach would work.
>> And thinking some more about it, I think that behaviour is the correct one. And as I think was pointed out earlier, you are not "processing headers" any longer, you are just peaking at the upper layer protocol type.
>> 
> Ole,
> 
> Yes, I think the approach is reasonable (and we've been doing it for
> fourteen years anyway!).

Agree, and at the same time I do not agree it is mandated by RFC.
(and we can of course discuss if it should have been. ;-))

> Assuming we do continue to perform the deep parse, then what should be
> done if we can't conclusively determine whether or not the packet
> contains an ICMP error (for instance we hit something like an
> unrecognized next header or ESP)? Right now the ICMP error is sent
> anyway, but strict adherence to RFC4443 might imply we shoudn't send.

That's equivalent to my first example above.
You encounter a parameter problem in a header chain that cannot be walked to the end, you should send the ICMP.
Of course at that point it would be unwise to likely known or likely unknown EHs before the ICMP header, in the ICMP error response...

Cheers,
Ole