[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.

[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].".

[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.

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.

The following Last Call announcement was sent out:

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.

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