Subject: Atomic fragments: converging on something?

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 20:14:26 -0300

Folks,

The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered
some (unintended) discussion about the usefulness/legitimacy of IPv6
"atomic fragments" (IPv6 packets that contain a Fragmentation Header,
but that have the "More Fragments" bit set to zero).

My understanding is that is quite clear that such packets have been
found in the wild and that a number of things would break if they were
blocked or banned.

That said, I'd like some feedback on the actual proposal in
draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned
"atomic fragments" as if they were non-fragmented packets. This would
basically eliminate all the security issues and problems normally
associated with framgentation, while still allowing their legitimate use.

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: Mohacsi Janos <[email-masked]>
Date: Wed, 4 Jan 2012 09:28:33 +0100 (CET)

> associated with framgentation, while still allowing their legitimate use.

I support your proposal. I will do a more thorough review of your draft.

 	Best Regards,
 		Janos Mohacsi

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

---

From: Timothy Hartrick <[email-masked]>
Date: Wed, 4 Jan 2012 09:51:37 -0800

Fernando,

> but that have the "More Fragments" bit set to zero).
Just to clarify what you mean by an atomic fragment; you mean fragments
with an offset of 0 and the "More Fragments" flag set to zero.  That is,
this is the beginning and there is no more.

> found in the wild and that a number of things would break if they were
They are essential to translation systems.  Firewalls that block them are
broken since "atomic fragments" represent no security risk and are a legal
part of the protocol.

> associated with framgentation, while still allowing their legitimate use.
On the one hand I would prefer that this document not be necessary.  That
is, treating "atomic fragments" as not being fragmented at all is the way
that any competent software engineer would treat them.  The idea of
allocating reassembly state and timers for datagrams of this sort and then
executing anything like the normal reassembly logic on them is absurd.  It
is difficult to imagine that there are implementations that would do so.

That said, if we need to spell that out in great and gory detail to get
implementors to do the obvious thing, then I guess we need to.  I
grudgingly support the proposal to document how implementations should
treat "atomic fragments".

Tim Hartrick

---

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 16:36:38 -0300

> this is the beginning and there is no more.

Yes, exactly. (Sorry for the confusion! -- 24-hours working on code
without any sleep (literally) did have their effect on me, it seems... :-( )

> They are essential to translation systems.  Firewalls that block them
> are broken since "atomic fragments" represent no security risk and are a
> legal part of the protocol.

That's my take, too.

> On the one hand I would prefer that this document not be necessary. 
> That is, treating "atomic fragments" as not being fragmented at all is
> the way that any competent software engineer would treat them.  The idea
> of allocating reassembly state and timers for datagrams of this sort and
> then executing anything like the normal reassembly logic on them is
> absurd.  It is difficult to imagine that there are implementations that
> would do so.

Test some of them, and you'll see. :-)

> treat "atomic fragments".

Thanks, for your support. My experience with this sort of corner cases
is that unless you explicitly say what should be done, you cannot assume
that implementers will follow your own logic (even if it's supposed to
be obvious).

Sometimes it takes time and discussion (such as that in this thread) for
us (protocol types :-) ) to converge on something.. so it shouldn't be
surprising that someone working on tons of patches doesn't spend some
time trying to get every detail right.

Thanks!

Best regards,

---

From: Rémi Després <[email-masked]>
Date: Thu, 5 Jan 2012 18:02:53 +0100

Hi Fernando,

Full agreement on the substance of your draft, and support for an RFC based on it.

However, I believe it should rather be a BCP than a Standard-track RFC.
(I don't see any need to standardize anything beyond what already exists.)

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Jan 2012 03:48:51 -0300

Hi, Rémi,

> (I don't see any need to standardize anything beyond what already exists.)

How is this different from, e.g. standardizing that hosts should discard
overlapping fragments on Std Track?

Thanks,

---

From: Rémi Després <[email-masked]>
Date: Mon, 9 Jan 2012 10:27:52 +0100

> overlapping fragments on Std Track?

 Discarding receiving fragments that overlap (RFC is IMHO something that might ALSO have been treated as BCP: it doesn't change the protocol. (Implementations that don't comply with the new provision still interwork with those that do.) 
 An ambiguity however exists in RFC 2460 because it describes a specific reassembly algorithm without saying it isn't part of the standard. This algorithm, which could have been left to implementors to choose based on how sources do fragmentation, doesn't include the consistency check that fragments don't overlap. It it then worth specifying that the described algorithm isn't as complete as it could be.

I have to agree that the logic of what you propose, although less important IMHO, is similar. 

Therefore, and despite my comment, I don't really care whether it ends up as a standard rather than a BCP if others so prefer.

Regards,
RD

> Thanks,

Sec 4.5

   The following conditions are not expected to occur, but are not
   considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.