Subject: RFC5722 and network packet duplication

From: Dennis Ferguson <[email-masked]>
Date: Thu, 27 Aug 2015 15:27:42 -0700

IP should be tolerant of packet duplication in the network since this
is sometimes hard to avoid with certain link layer technologies and
can apparently also be caused in others by misconfiguration (I have
seen this happening without knowing the cause).  RFC5722 seems to
spend no text on the distinction between "overlapping fragments"
and "duplicate fragment packets" even though being able to differentiate
between the two is essential to keeping the fragmentation protocol robust
when the network is duplicating packets (there is a reason why the basic
reassembly procedures accept fragments carrying duplicate data...).

I was wondering if adding a definition of "overlapping fragments"
at the start of Section 2. to explicitly exclude duplicated packets
would make this better, maybe like:

   Two fragments of the same packet having different Fragment Offsets
   or different lengths of data after the fragment header are
   overlapping fragments if the offset ranges of the fragment data
   they carry overlap.   Duplicate fragment packets with the same
   Fragment Offset and length are not overlapping fragments and may
   be the result of packet duplication in the network rather than being
   intentionally constructed by the sender.

This unfortunately implies that reassembly implementations might need
to record the original packet boundaries, while the ones I've looked
at only track the data they've received and the holes they need to fill
to complete the packet.  I think, however, that the latter is sufficient
to avoid the attack 5722 imagines if the following rules are observed(?)

- if an incoming packet fragment only carries data that has already
  been received discard that packet fragment but continue the reassembly.

- if an incoming packet fragment includes both new data and data already
  received discard everything.

but this would be too big a change to make to the existing text.  I am
assuming RFC5722 did not intend to make the fragmentation protocol
intolerant of network packet duplication, but the fact that there is
clearly some implementation complexity involved with this that 5722
gives no attention to is making it hard to see exactly how this is
supposed to work.

Dennis Ferguson

---

From: Bob Hinden <[email-masked]>
Date: Thu, 27 Aug 2015 16:11:27 -0700

Dennis,

Since IPv6 fragmentation can only occur at the source (that is, not in the network), wouldn’t any packet duplication result in exact copies of any fragment?  The duplicates would either overlap, or not overlap.

Bob

> On Aug 27, 2015, at 3:27 PM, Dennis Ferguson <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Dennis Ferguson <[email-masked]>
Date: Thu, 27 Aug 2015 17:06:55 -0700

Bob,

I think that's exactly right.  For IPv6 fragments that carry all
the same data are duplicates, while fragments that only carry some
of the same data are overlapping.  The receipt of a duplicate
shouldn't cause the reassembly to be abandoned, only overlapping
fragments should.  The only problem with 5722 is that it never
points this distinction out, but rather leaves it as an exercise
for the reader to deduce.

As a practical issue separating duplicates from overlaps is trivial
if your reassembly queue recalls where the original packet boundaries
are.  As at least some reassembly implementations (the ones I'm looking
at now) don't keep that information I kind of wish someone who understood
the attack well had worked through what was necessary to avoid it while
keeping minimum reassembly state, but I guess that's a different issue.

Dennis Ferguson

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Aug 2015 21:10:36 -0300

Hi, Bob,

On 08/27/2015 08:11 PM, Bob Hinden wrote:
> 
> Since IPv6 fragmentation can only occur at the source (that is, not
> in the network), wouldn’t any packet duplication result in exact
> copies of any fragment?  The duplicates would either overlap, or not
> overlap.

I believe the point Dennis is raising (which seems valid to me) is that
RFC5722 only wants to tackle the case of partial overlaps (see e.g., the
cases we test in
<http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html>).

Full overlaps (resulting from packet duplication) shouldn't really be an
issue. (Me thinking out loud) It would seem that RFC5722 is
underspecified in this respect.

Thanks!

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

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Aug 2015 12:58:54 -0700

Dennis,

> On Aug 27, 2015, at 5:06 PM, Dennis Ferguson <[email-masked]> wrote:
> 
> Bob,
> 

I am currently working on RFC5722 update in RFC2460bis.  I think it would be straight forward to also include this clarification.  That is, an exact duplicate fragment is not considered overlapping and all of the related fragments should not be discarded.  Though, I need to see how to say it in the new draft.

I would appreciate feedback from the author of RFC5722 and others in the working group.  I think this is clarification, more than a change as I don’t think the intent of RFC5722 was to treat this as an the case to discard the fragments.

Thanks,
Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Aug 2015 14:16:31 -0400

Hi Dennis/Bob,

> I would appreciate feedback from the author of RFC5722 and others in the working group.  I think this is clarification, more than a change as I don’t think the intent of RFC5722 was to treat this a…

When I wrote the initial text, my intention was certainly not to discard 
based on duplicates. I agree that this will be a worthwhile thing to 
clarify in 2460bis.

One thing I would like to point out though is that depending on the 
implementation of the reassembly (specifically the context retained 
about the fragments) it might be difficult or impossible to 
differentiate between duplicates and overlaps.

Another thing that might complicate issues is that calling something a 
duplicate requires checking whether the contents of the fragment are 
actually duplicate. This may also require additional processing.

Thanks
Suresh