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

[Fernando Gont <[e-mail]>]

Hi, Ran,

As always, thanks so much for your feedback and elaborated comments.
Please find my response in-line...

On 07/19/2012 07:33 PM, RJ Atkinson wrote:
> I think the requirement that a packet that violates the
> proposed oversized-heacer-chain rule be dropped "silently" 
> is too strong and lacks operational flexibility.

FWIW, when I said "silently", I didn't meant to stress it. My point was
about including a requirement to drop such packets, than whether they
should be silently dropped, a counter incremented, etc.


> A device ought to be allowed, but not required, to send 
> an ICMPv6 Parameter Problem message if/when it drops 
> such a packet.
> 
> In some situations, it might be desirable for a device
> to drop the packet AND also generate an ICMPv6 
> "Parameter Problem" message for the packet originator. 

Agreed.



> 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?



> 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")



> 3) I'd also suggest a sentence or two clarifying that the
>    ICMPv6 "Parameter Problem" with the new Reason Code
>    is the appropriate message to send -- if the device dropping
>    the packet with oversized-header-chain sends an ICMPv6
>    message.  One would hope this would be obvious, but being
>    very clear is good.

Ok.


> 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?

Thanks so much,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492