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

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Jul 2012 14:33:55 -0400

OPINION/BELIEF:

I concur with Fred Baker's analysis of "SHOULD" versus "MUST".

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.

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.  

ACTIONABLE SUGGESTIONS:

So....

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.

and

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.

and

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.

and

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]

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jul 2012 20:20:08 +0100

Hi, Ran,

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

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

> "Parameter Problem" message for the packet originator. 

Agreed.

>    the sending of the ICMPv6 message configurable also would be 

Should we make this latter bit (about this being configurable) a MAY, or
would you prefer to have non-RFC2119 language?

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

>    message.  One would hope this would be obvious, but being

Ok.

>    in the Source IPv6 Address field of the illegal packet.

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 19 Jul 2012 16:04:10 -0400

On 19  Jul 2012, at 15:20 , Fernando Gont wrote:
> 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".

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

> 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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Jul 2012 00:46:13 +0100

Hi, Ran,

> setting as part of supporting "local operational policy".

Ok. I will craft some text, and post it to the list for review...

> by making illegal a previously-valid, if very odd, 

Ok. As with the above, I will craft some text and send it to the list
for review.

Cheers,