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

From: Tore Anderson <[email-masked]>
Date: Sat, 11 Jun 2016 11:16:07 +0200

Hello Ted, thank you for your review, and apologies for the much
belated reply.

* Ted Lemon

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

I see your point.

The document used to normatively recommend a course of action, by
updating specific problematic text in the existing standards.

However, later on all of its recommendations were incorporated in
1981bis, 2460bis and 6145bis. They were therefore removed from this
draft. The remaining purpose of this draft is thus to document the
reasoning behind the change, which it does not need to be normative to
do.

This might have been self-evident for those of us involved in the
developement of this draft, but I can see that this isn't so for a new
reader.

To remedy that, I suggest inserting a new section like this:

  4. Conclusion

  Taking all of the above considerations into account, we recommend
  that IPv6 atomic fragments are deprecated.

  In particular:

  o IPv4/IPv6 translators should be updated to not generate ICMPv6
    Packet Too Big errors containing a Path MTU value smaller than the
    minimum IPv6 MTU of 1280 bytes. This will ensure that current IPv6
    nodes will never have a legitimate need to start generating IPv6
    atomic fragments.

  o The recommendation in the previous bullet ensures there no longer
    are any valid reasons for ICMPv6 Packet Too Big errors containing
    a Path MTU value smaller than the minimum IPv6 MTU to exist. IPv6
    nodes should therefore be updated to ignore them as invalid.

  We note that these recommendations have been incorporated in
  [RFC1981bis], [RFC2460bis] and [RFC6145bis].

How does that read to you?

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

Agree. Your NEW text reads better.

>   o  As noted in Section 3, SIIT [RFC6145] (including derivative
> 
> Expand SIIT acronym?

Yep, agreed.

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

I am not aware of any significant deployment of <1260-byte MTU links in
the IPv4 Internet today (which makes all of this complicated and
insecure atomic fragment stuff oh so much more pointless to begin with).
But the IPv4 standard does allow them, and the Internet is a large
place, so I'm sure there are some of these links to be found somewhere.

Anyway, how about adding a new paragraph at the end (and rewriting the
current last paragraph to not suggest it's the last one):

   [RFC6145] is the only "consumer" of IPv6 atomic fragments, and it
   correctly and diligently notes (in Section 6) the possible
   interoperability problems of relying on IPv6 atomic fragments,
   proposing as a workaround that leads to more robust behavior and
   simplified code.

   Finally, we believe that IPv4 links with an MTU smaller than 1260
   bytes are very uncommonly found in the modern Internet. At the same
   time, we note that the sole purpose of IPv6 atomic fragments is to
   make such links compatible with IPv4/IPv6 translation. We surmise,
   therefore, that IPv6 atomic fragments are useful in only a miniscule
   number of "real world" situations.

How does that read to you?

Tore

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Jun 2016 07:36:32 -0400

Tore, thanks, your proposed changes address all the issues I raised.   It
hadn't crossed my mind that this document might already have had its
intended effect!   :)