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

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Jul 2012 21:36:36 +0100

Folks,

There's one issue that came up during my recent exchange with Suresh on
which I'd like others (including Suresh) to weigh in:

Since first-fragments that fail to include the entire header chain will
be illegal, I think it would be appropriate to include an additional
requirement in draft-ietf-6man-oversized-header-chain along the lines of:

"A host that receives a first-fragment that fails to include the entire
IPv6 header chain MUST silently drop the aforementioned fragment".

Clearly, since such packets are illegal, they shouldn't exist in the
first place... so dropping them makes sense.

Thoughts?

Thanks!

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

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 18 Jul 2012 13:51:16 -0700

Hi Fernando,

I think this is an essential message that needs to be added as part of the
draft.

Thanks,
Vishwas

On Wed, Jul 18, 2012 at 1:36 PM, Fernando Gont <[email-masked]>wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 18 Jul 2012 21:03:27 +0000

> first place... so dropping them makes sense.

I would say "SHOULD", but I'm OK with the fundamental statement. The Robustness Principle has some built-in tension: "be liberal in what you accept and conservative in what you send" often works out to mean "accept a technically-illegal message if you can work out an unambiguous intent"; what you are saying is to "be strict in what you accept", which in this case is (as you suggest) probably the right thing to do.

The distinction between "SHOULD" and "MUST" is a little of a chinese wall. The rule I use, which is neither specified nor universal, is that I say something "MUST" be obeyed if failing to obey results in an identifiable failure (fragmenting a DNF packet, for example, fails in that if a recipient of DNF fragments will refuse to reassemble them, this prevents communication that was intended to be supported, so a packet marked DNF "MUST" not be fragmented), and I use "SHOULD" when I would like to say "MUST" but can't identify the failure mode and therefore might have a case in which it is inappropriate. The argument for "MUST" in this case would be that there will be a reasonable chance that the recommendations of the draft will not be given teeth apart from being "strict"; the argument for "SHOULD" is that this could be handled as an exception case operationally.

> Best regards,

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Jul 2012 22:48:22 +0100

Hi, Fred,

Thanks so much for your prompt response. Please find my comments in-line...

On 07/18/2012 10:03 PM, Fred Baker (fred) wrote:
>> "A host that receives a first-fragment that fails to include the
>> entire IPv6 header chain MUST silently drop the aforementioned
>> fragment".
>> 
>> Clearly, since such packets are illegal, they shouldn't exist in
>> the first place... so dropping them makes sense.
>> 
>> Thoughts?
> 
> I would say "SHOULD", but I'm OK with the fundamental statement. The
> Robustness Principle has some built-in tension: "be liberal in what
> you accept and conservative in what you send" often works out to mean
> "accept a technically-illegal message if you can work out an
> unambiguous intent"; what you are saying is to "be strict in what you
> accept", which in this case is (as you suggest) probably the right
> thing to do.

Agreed.

> The distinction between "SHOULD" and "MUST" is a little of a chinese
> wall. The rule I use, which is neither specified nor universal, is
> that I say something "MUST" be obeyed if failing to obey results in
> an identifiable failure

I've always used the same rule, but ended up reconsidering it upon
suggestion of S. Braden when he noted that, as per RFC2119, a "SHOULD"
implies that

  "there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

So I guess that, from that perspective, to make it a "SHOULD" (rather
than a "MUST") one should be able to come up with a good reason to
accept such packets...

(I should say that I've authored documents that include SHOULDs/MUSTs
with your rationale, rather than the one I've just quoted)

> (fragmenting a DNF packet, for example, fails
> in that if a recipient of DNF fragments will refuse to reassemble
> them, this prevents communication that was intended to be supported,
> so a packet marked DNF "MUST" not be fragmented), 

(Side discussion, but just for the fun of it): Actually, I'd argue that
the motivation for "MUST NOT" fragment would probably be that the
Identification field is most-likely 0, and the node fragmenting the DNF
packet is in no good position of selecting a good Fragment ID.

Thanks!

Cheers,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Jul 2012 06:21:31 +0000

Fernando,

Adding this text has the merit of being clear.

Two comments:
1) for the transition period (when we could perhaps see those packets -- even if I have yet to see one!), 'silently' is perhaps too strong, I would suggest at the bare minimum a dropped packet counter (else operators would be blind)
2) RFC1858 (the IPv4 equivalent of your I-D) specifies that routers with an ACL must also drop those packets and I would think that this should also be the case here but with a SHOULD for router implementing layer-4 ACL (not for plain forwarding routers or layer-3 ACL)

Hope it helps

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: mercredi 18 juillet 2012 22:37
> To: [email-masked]
> Subject: oversized-header-chains: Receipt of illegal first-fragments
> 
> Folks,
> 
> Since first-fragments that fail to include the entire header chain will be
> illegal, I think it would be appropriate to include an additional
> Clearly, since such packets are illegal, they shouldn't exist in the first
> place... so dropping them makes sense.
> 
> Thoughts?
> 
> Thanks!
> 
> Best regards,
> --
> Fernando Gont
> SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jul 2012 14:59:47 +0100

Hi, Eric,

On 07/19/2012 07:21 AM, Eric Vyncke (evyncke) wrote:
> Two comments: 1) for the transition period (when we could perhaps see
> those packets -- even if I have yet to see one!), 'silently' is
> perhaps too strong, I would suggest at the bare minimum a dropped
> packet counter (else operators would be blind) 

Ok. What about the counter? SHOULD?

> 2) RFC1858 (the IPv4
> equivalent of your I-D) specifies that routers with an ACL must also
> drop those packets and I would think that this should also be the
> case here but with a SHOULD for router implementing layer-4 ACL (not
> for plain forwarding routers or layer-3 ACL)

The caveat here is that it's trivial for a v4 router to figure out
whether the upper layer protocol's header is fragmented, but it may be
not so trivial for a v6 router to do so (i.e., it would require them to
follow the entire IPv6 header chain, which could possibly be a large
number of headers.

That said, I guess that including the aforementioned requirement for
routers, with the granularity you mention ("routers implementing layer-4
ACLs" or some equivalent wording) might work for the wg?

Can others please weigh in?

Thanks!

Best regards,