Re: oversized-header-chains: Receipt of illegal first-fragments

[RJ Atkinson <[e-mail]>]

On 19  Jul 2012, at 15:20 , Fernando Gont wrote:
>> 1) I'd prefer this draft say that such illegal packets MUST 
>>   be dropped, but then also say that the device dropping the 
>>   packet MAY send an ICMPv6 Parameter Problem control message 
>>   back to the (alleged) sending node.  A brief sentence 
>>   suggesting, but not requiring, that implementations make 
>>   the sending of the ICMPv6 message configurable also would be 
>>   sensible.
> 
> Should we make this latter bit (about this being configurable)
> a MAY, or would you prefer to have non-RFC2119 language?

I believe this configurability is really desirable.
It isn't a big burden for an implementer, as it is
simply an on/off flag, but we don't want to require it.

So I would suggest either use "SHOULD support configuration of
whether an ICMPv6 error/diagnostic message is sent" (edit to preference) 
OR (more simply) avoid using RFC21109 ALL-CAPS wording and
still urge that implementers support this as a configurable 
setting as part of supporting "local operational policy".

> 2) For the situation where an IPv6 packet is dropped for this
>>   specific reason, I'd suggest that the "Reason Code" registry 
>>   for an ICMPv6 "Type 4 - Parameter Problem" message be updated
>>   with a new focused reason code defined.  As a straw man, 
>>   I'd propose adding this new entry to that registry, 
>>   as part of this proposal:
>> 
>>   CODE     NAME/DESCRIPTION
>>     3      IPv6 Initial Fragment missing upper-layer protocol header
>> 
>>    Of course, this means an "IANA Considerations" section
>>    update for the I-D would be in order.
> 
> I find your suggestion acceptable. Can others please weigh in?
> 
> Minor note: May be the description for the error code should be along
> the lines of "IPv6 First Fragment missing entire IPv6 header chain"?
> (I'm just thinking of IPv6 packets with no upper layer protocol, which
> would remain legal, but would not have an "upper layer protocol header")

I don't object to the rephrasing of the name/description.
Ideally the name/description field is relatively short.

>> 4) Security Considerations ought to note the importance of
>>   deploying Source Address Forgery Prevention filters, in
>>   order to reduce the threat of an adversary forging an
>>   illegal packet with contains a victim/target's IP address
>>   in the Source IPv6 Address field of the illegal packet.
>>   [RFC-2827, RFC-3704]
> 
> I have no problem with this.
> However, should we really elaborate on this topic,
> since it applies to all ICMPv6 error messages and
> hence is probably a topic belonging to e.g. RFC 4443?

I think a brief reminder here is appropriate, in part 
because this draft increases the attack surface a bit,
by making illegal a previously-valid, if very odd, 
IPv6 packet construct.

I would not object to including the phrase "...as with
all ICMPv6 error/diagnostic messages..." as part of that
brief description of the concern.

Cheers,

Ran