Subject: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Apr 2016 21:24:55 -0400

I am an assigned INT directorate reviewer for
draft-ietf-6man-deprecate-atomfrag-generation-06.txt

These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments
just like they would treat comments from any other IETF contributors and
resolve them along with any other Last Call comments that have been
received. For more details on the INT Directorate, see
http://www.ietf.org/iesg/directorate.html.

This document doesn’t appear to actually recommend a course of action other
than in the Abstract.   It seems to me that this document is arguing
(perhaps?) that firewalls should drop atomic fragments, or perhaps that
hosts should.   But it never gives any actual advice.

It seems to me that the document could be substantially improved by
explicitly saying what behaviors are being recommended here.   Otherwise,
the statement in the Abstract that this is intended to motivate changes to
the core IPv6 protocol specifications seems to leave whoever does that with
the task of reading this document, thinking through the problem the authors
have already thought through, and trying to come up with the right changes
to the base spec.

While doable, this seems unnecessary given that the authors have put a lot
of thought into this.  Even if the document were to recommend a course of
action that wasn’t ultimately followed, walking through the reasoning
behind those recommendations would likely be helpful.   Given that the
document is informational, this advice could be described as a
recommendation for future work, and not as advice to implementors.

It might also be useful, and would likely render any worries about this
document being treated as normative, if the authors were to talk about what
to do to clean up existing implementations if the decision is taken to
retain the atomic fragment functionality.

That said, the document is mature, and useful as written.   I do not see
any reason to hold up publication if the working group is unwilling or
unable to make the changes I’ve suggested.

Some minor detailed suggestions follow:

OLD:
  Once the attack
  packet has been sent, it will be the aforementioned routers
  themselves the ones dropping their own traffic.
NEW:
  Once the attack
  packet has been sent, the aforementioned routers
  will themselves be the ones dropping their own traffic.

  o  As noted in Section 3, SIIT [RFC6145] (including derivative

Expand SIIT acronym?

  2.  The IPv4 node is located behind an IPv4 link with an MTU smaller
      than 1260 bytes

It would be helpful to talk about when this might happen.   It’s not clear
to me that this is a plausible real-world scenario in these modern times,
but if it is it would be good to identify the situations in which the
proposed change will create operational problems.  I don't think that any
use case you might list here would lead the reader to conclude that
therefore we need to keep atomic fragments, but such use cases should be
discussed, or the lack of any known such use cases should be discussed, for
completeness.