Skip to main content

Processing of IPv6 "Atomic" Fragments
RFC 6946

Revision differences

Document history

Date Rev. By Action
2020-07-29
04 (System) Received changes through RFC Editor sync (removed Errata tag (all errata rejected))
2015-12-31
04 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2015-10-14
04 (System) Notify list changed from 6man-chairs@ietf.org, draft-ietf-6man-ipv6-atomic-fragments@ietf.org, "Robert M. Hinden" <bob.hinden@gmail.com> to (None)
2014-12-22
04 Bob Hinden Notification list changed to 6man-chairs@tools.ietf.org, draft-ietf-6man-ipv6-atomic-fragments@tools.ietf.org, "Robert M. Hinden" <bob.hinden@gmail.com> from 6man-chairs@tools.ietf.org, draft-ietf-6man-ipv6-atomic-fragments@tools.ietf.org
2014-12-22
04 Bob Hinden Document shepherd changed to Robert M. Hinden
2013-05-14
04 (System) RFC published
2013-05-10
04 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc6946">AUTH48-DONE</a> from AUTH48
2013-05-06
04 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc6946">AUTH48</a> from RFC-EDITOR
2013-04-05
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-03-22
04 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-03-22
04 (System) RFC Editor state changed to EDIT
2013-03-22
04 (System) Announcement was received by RFC Editor
2013-03-21
04 (System) IANA Action state changed to No IC
2013-03-21
04 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2013-03-21
04 Amy Vezza IESG has approved the document
2013-03-21
04 Amy Vezza Closed "Approve" ballot
2013-03-21
04 Amy Vezza Ballot approval text was generated
2013-03-21
04 Brian Haberman Ballot writeup was changed
2013-03-21
04 Brian Haberman Ballot approval text was generated
2013-03-21
04 Brian Haberman Ballot writeup was changed
2013-03-20
04 Fernando Gont New version available: draft-ietf-6man-ipv6-atomic-fragments-04.txt
2013-02-28
03 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2013-02-28
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-02-28
03 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-02-27
03 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Abstain
2013-02-27
03 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Abstain from No Objection
2013-02-27
03 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2013-02-26
03 Sean Turner
[Ballot comment]
1) I tend to agree with Stephen's suggestion wrt the abstract.

2) s4: I think it would be clearer if you said:

  …
[Ballot comment]
1) I tend to agree with Stephen's suggestion wrt the abstract.

2) s4: I think it would be clearer if you said:

  Section 4.5 of [RFC2460] and Section 4 of [RFC5722] are updated to include
  the following new checks:

This draft is just adding new checks right ;)


From Simon's secdir review (https://www.ietf.org/mail-archive/web/secdir/current/msg03710.html):

3) Section 2:
      Offset set to 0 and the M bit set to 0.
                                ^^^
RFC 2460 uses the term "M flag", not "M bit".

4) s3, 2nd bullet: is it's the "Destination's Cache" or is just the queue?

5) s4: For consistency: r/{IPV6/{IPv6

6) s4: This is actually more of a question about the new rule text.  I'm having trouble understanding what should happen in the following situation:

* A host has a fragment with fragment identification X in its cache,
  with fragment offset 42 and M=1 indicating there are other
  outstanding fragments.

* A host has received an atomic fragment (i.e, fragment offset 0 and
  M=0) with the same fragment identification X.

* A host never receives any more fragments with the fragment
  identification X.

RFC 2460 says:

      If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment.

Now given the following updated text in section 4:

      A host that receives an IPv6 packet which includes a Fragment
      Header with the "Fragment Offset" equal to 0 and the "M" bit equal
      to 0 MUST process such packet in isolation from any other packets/
      fragments, even if such packets/fragments contain the same set
      {IPv6 Source Address, IPv6 Destination Address, Fragment
      Identification}.

The atomic fragment should be dealt with in isolation, so it is reassembled immediately.  Now, after 60 seconds, what should the host do?  Should it send an ICMP Time Exceeded or not?  It has already completed assembly but it is also waiting for more fragments.
2013-02-26
03 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-02-26
03 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-02-26
03 Martin Stiemerling [Ballot comment]
My DISCUSS is solved by the RFC editor note. Thank you.
2013-02-26
03 Martin Stiemerling [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss
2013-02-26
03 Brian Haberman Ballot writeup was changed
2013-02-26
03 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-02-26
03 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2013-02-26
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-02-26
03 Martin Stiemerling
[Ballot discuss]
I have no objection to publish this draft, but there is one important edit that has been lost and I will clear as …
[Ballot discuss]
I have no objection to publish this draft, but there is one important edit that has been lost and I will clear as soon as the change is applied, either as an update to the draft or as an RFC editor note:

Section 3., paragraph 5:

>    o  Many implementations fail to perform validation checks on the
>      received ICMPv6 error messages, as recommended in Section 5.2 of
>      [RFC4443] and [RFC5927].  It should be noted that in some cases,

  RFC 5927 does not recommend, but solely document. The text below was
  agreed during the TSVDIR review discussions, but the draft has not
  been updated. Here is the agreed text: "...Section 5.2 of [RFC4443]
  and documented in [RFC5927].".
2013-02-26
03 Martin Stiemerling [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling
2013-02-26
03 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-02-25
03 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2013-02-25
03 Stephen Farrell
[Ballot comment]

- The abstract tries, but fails, to explain how some attacks
are enabled via atomic fragments. I mean the "Thus..."
sentence, which cannot …
[Ballot comment]

- The abstract tries, but fails, to explain how some attacks
are enabled via atomic fragments. I mean the "Thus..."
sentence, which cannot be understood by itself and is not a
good thing to have in an abstract

- Section 4 here is not clear as to what changes in 2460 and
5722.

- Section 6 says "this document describes..." but it doesn't;
you have to read 5722 or other references to actually
understand the threat.

- In the light of the above I would suggest rewording the
abstract to something more like this:

The IPv6 specification allows packets to contain a Fragment
Header without the packet actually being fragmented into
multiple pieces (we refer to such packets as "atomic
fragments"). Atomic fragments are typically sent by hosts that
have received an ICMPv6 "Packet Too Big" error message that
advertises a "Next-Hop MTU" smaller than 1280 bytes.  Atomic
fragments are processed by some implementations as "fragmented
traffic" whereas they ought properly be processed
independently of all other fragments since handling these as
non-atomic fragments can allow for expoitation of unrelated
vulnerabilities related to improper fragment handling.  This
document formally updates RFC 2460 and RFC 5722 such that
Atomic fragments are handled independently, thus avoiding
pitfalls related to fragment handling that can be set up via
"Packet Too Big" messages.
2013-02-25
03 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-02-24
03 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2013-02-13
03 Martin Stiemerling Request for Last Call review by TSVDIR Completed: Ready. Reviewer: Matt Mathis.
2013-02-06
03 Brian Haberman State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-02-06
03 Brian Haberman Ballot has been issued
2013-02-06
03 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2013-02-06
03 Brian Haberman Created "Approve" ballot
2013-02-06
03 Brian Haberman Ballot writeup was changed
2013-02-06
03 Brian Haberman Placed on agenda for telechat - 2013-02-28
2013-01-17
03 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Simon Josefsson.
2013-01-16
03 Wesley Eddy Request for Last Call review by TSVDIR is assigned to Matt Mathis
2013-01-16
03 Wesley Eddy Request for Last Call review by TSVDIR is assigned to Matt Mathis
2013-01-16
03 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-01-11
03 Pearl Liang
IANA has reviewed draft-ietf-6man-ipv6-atomic-fragments-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there …
IANA has reviewed draft-ietf-6man-ipv6-atomic-fragments-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.
2013-01-03
03 Jean Mahoney Request for Last Call review by GENART is assigned to Mary Barnes
2013-01-03
03 Jean Mahoney Request for Last Call review by GENART is assigned to Mary Barnes
2013-01-03
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Simon Josefsson
2013-01-03
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Simon Josefsson
2013-01-02
03 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ipv6@ietf.org>
Reply-To: ietf@ietf.org
Subject: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ipv6@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-6man-ipv6-atomic-fragments-03.txt> (Processing of IPv6 "atomic" fragments) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Processing of IPv6 "atomic" fragments'
  <draft-ietf-6man-ipv6-atomic-fragments-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IPv6 specification allows packets to contain a Fragment Header
  without the packet being actually fragmented into multiple pieces (we
  refer to these packets as "atomic fragments").  Such packets
  typically result from hosts that have received an ICMPv6 "Packet Too
  Big" error message that advertises a "Next-Hop MTU" smaller than 1280
  bytes, and are currently processed by some implementations as
  "fragmented traffic".  Thus, by forging ICMPv6 "Packet Too Big" error
  messages an attacker can cause hosts to employ "atomic fragments",
  and then launch any fragmentation-based attacks against such traffic.
  This document discusses the generation of the aforementioned "atomic
  fragments", the corresponding security implications, and formally
  updates RFC 2460 and RFC 5722 such that fragmentation-based attack
  vectors against traffic employing "atomic fragments" are completely
  eliminated.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-01-02
03 Amy Vezza State changed to In Last Call from Last Call Requested
2013-01-02
03 Brian Haberman Last call was requested
2013-01-02
03 Brian Haberman Last call announcement was generated
2013-01-02
03 Brian Haberman Ballot approval text was generated
2013-01-02
03 Brian Haberman Ballot writeup was generated
2013-01-02
03 Brian Haberman State changed to Last Call Requested from AD Evaluation::AD Followup
2012-12-29
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-12-29
03 Fernando Gont New version available: draft-ietf-6man-ipv6-atomic-fragments-03.txt
2012-12-13
02 Brian Haberman State changed to AD Evaluation::Revised ID Needed from AD Evaluation
2012-12-13
02 Brian Haberman
AD Review comments:

Substantive
----------------

* It would be quite useful to explicitly define "atomic fragment" prior to using it in
the document.  This could …
AD Review comments:

Substantive
----------------

* It would be quite useful to explicitly define "atomic fragment" prior to using it in
the document.  This could be done in the Introduction in a formal manner and the
use of "atomic fragments" in the Abstract can be re-worded.

* The Introduction needs to provide more motivation as to why we should allow these
atomic fragments to exist.  Please provide the rationale discussed on the mailing list
about how v4/v6 translators use the fragmentation information.

* The core source of this attack is that some implementations have predictable algorithms
for generating the Fragmentation ID, allowing attackers to launch these types of attacks.
It would be good to reference that work in this draft as well.

* What is the purpose of the indented paragraph within the first bullet of the list in section 2?
Is it a quote from one of the two referenced RFCs?

* It is not clear to me why the document spends much time on discussing ICMP-based attacks
on the source of traffic, especially ones that ignore existing RFCs, when the issue is really with
devices that don't do the right thing on the receiving end.

* I am rather disappointed with the Security Considerations section given that this draft is addressing
a perceived security vulnerability.  In fact, I would like to ask the WG if the solution actually creates
an attack vector on receiving hosts.  An on-device path could modify packets with Fragmentation
headers by setting Offset=0 and M=0.  This would cause the receiver to blindly treat the packet as
an atomic and pass it up to the upper-layer protocol.  Is this an acceptable risk?  Obviously, packets
protected by IPsec would be immune to this attack.  At a minimum, the Security Considerations should
spend some time discussing the potential new attacks based on these rules.

Editorial
------------

- Abstract
    * s/IPv6 specification allows/IPv6 specifications allow/

- Introduction
    * s/[RFC2460] allowed/[RFC2460] allows/
    * s/[RFC5722] forbid/[RFC5722] forbids/
    * Provide a forward pointer to Appendix A in paragraph 4
2012-12-12
02 Brian Haberman State changed to AD Evaluation from Publication Requested
2012-12-10
02 Brian Haberman IESG process started in state Publication Requested
2012-12-10
02 Brian Haberman Intended Status changed to Proposed Standard from None
2012-12-07
02 Bob Hinden IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2012-12-07
02 Bob Hinden Changed protocol writeup
2012-12-04
02 Bob Hinden Changed shepherd to Robert Hinden
2012-11-06
02 Fernando Gont New version available: draft-ietf-6man-ipv6-atomic-fragments-02.txt
2012-09-11
01 Ole Trøan IETF state changed to WG Consensus: Waiting for Write-Up from WG Document
2012-09-11
01 Ole Trøan Passed WGLC.
2012-09-11
01 Ole Trøan Changed shepherd to Ole Troan
2012-08-10
01 Fernando Gont New version available: draft-ietf-6man-ipv6-atomic-fragments-01.txt
2012-02-01
00 (System) New version available: draft-ietf-6man-ipv6-atomic-fragments-00.txt