Subject: [Technical Errata Reported] RFC5722 (3089)

From: RFC Errata System <[email-masked]>
Date: Fri, 13 Jan 2012 12:05:22 -0800 (PST)

The following errata report has been submitted for RFC5722,
"Handling of Overlapping IPv6 Fragments".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5722&eid=3089

--------------------------------------
Type: Technical
Reported by: Simon Perreault <[email-masked]>

Section: 4

Original Text
-------------
   IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
   create overlapping fragments.  When reassembling an IPv6 datagram, if
   one or more its constituent fragments is determined to be an
   overlapping fragment, the entire datagram (and any constituent
   fragments, including those not yet received) MUST be silently
   discarded.

Corrected Text
--------------
   IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
   create overlapping fragments.  When reassembling an IPv6 datagram, if
   one or more its constituent fragments is determined to be an
   overlapping fragment, the entire datagram (and any constituent
   fragments) MUST be silently discarded.

Notes
-----
Discarding fragments "including those not yet received" is not implementable. You'd have to keep state about the (source, destination, protocol, id) 4-tuple for MSL (120 seconds). If you do this you create two bugs:
- A new attack vector: an attacker could eat your resources. And if you just limit the number of such state entries then you fail to implement RFC 5722 correctly.
- It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update.

The proposal is simply to remove the "including those not yet received" bit. Normal host stacks do not keep state once a fragment has been reassembled. You reassemble the full packet and clear the fragment table. So this corrected text would align the RFC with actual practice.

This errata report results from an implementation attempt by OpenBSD.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5722 (draft-ietf-6man-overlap-fragment-03)
--------------------------------------
Title               : Handling of Overlapping IPv6 Fragments
Publication Date    : December 2009
Author(s)           : S. Krishnan
Category            : PROPOSED STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Jan 2012 15:42:23 -0500

> - It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update.

I was confusing IPv6 with IPv4 (they do look similar!). You can ignore this argument.

The other argument still stands.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Jan 2012 10:31:14 -0300

On 01/13/2012 05:05 PM, RFC Errata System wrote:
> Notes ----- Discarding fragments "including those not yet received"
> is not implementable. You'd have to keep state about the (source,
> destination, protocol, id) 4-tuple for MSL (120 seconds). If you do
> this you create two bugs: - A new attack vector: an attacker could
> eat your resources. And if you just limit the number of such state
> entries then you fail to implement RFC 5722 correctly. 
[...]
> 
> The proposal is simply to remove the "including those not yet
> received" bit. Normal host stacks do not keep state once a fragment
> has been reassembled. You reassemble the full packet and clear the
> fragment table. So this corrected text would align the RFC with
> actual practice.
> 

FWIW, this follows the general principle that "you don't add more state
for malicious traffic".

That aside, at least not spending too much time on it I couldn't come up
with a scenario in which "not dropping future fragments" would enable
the attack discussed in the aforementioned RFC.

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

---

From: [email-masked]
Date: Mon, 16 Jan 2012 08:15:11 -0000

I noticed this Errata.

I'm OK with removing the requirement (MUST), but I think the
recommendation is not entirely bad to discard fragments that may follow -
albeit for a limited time and subject to finding a way to implement. MSL
As presently defined could also be regarded as too harsh, that's a
different topic.

The note mentions "normal" stacks: Normal stacks do not keep state when
the IP packet has been resembled (forwarded), but do keep it while the IP
packet is not complete. Hence, if the packet did not reassemble, the
"overlap" state would be kept.

Gorry

> Discarding fragments "including those not yet received" is not
> implementable. You'd have to keep state about the (source, destination,
> protocol, id) 4-tuple for MSL (120 seconds). If you do this you create two
> bugs:
> - A new attack vector: an attacker could eat your resources. And if you
> just limit the number of such state entries then you fail to implement RFC
> 5722 correctly.
> The proposal is simply to remove the "including those not yet received"
> bit. Normal host stacks do not keep state once a fragment has been
> reassembled. You reassemble the full packet and clear the fragment table.
> So this corrected text would align the RFC with actual practice.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Jan 2012 07:17:12 -0300

Hi, Gorry,

On 01/16/2012 05:15 AM, [email-masked] wrote:
> albeit for a limited time and subject to finding a way to implement. 

It's not that it's "bad". It's that if it is assumed that overlapping
fragment are malicious traffic (i.e., it cannot originate from
legitimate sources), then there's not much motivoation to do more work
(e.g., first prun the fragments, then the "state") or tie system
resources (such as those needed to keep state for "future fragments" of
that packet).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1