Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01

[神明達哉 <[e-mail]>]

At Thu, 4 Dec 2014 09:07:18 +0100,
Ole Troan <[e-mail]> wrote:

> This message starts a two week 6MAN Working Group Last Call on advancing:
>
>      Title           : Security Implications of Predictable Fragment Identification Values
>      Authors     : Fernando Gont
>      Filename   : draft-ietf-6man-predictable-fragment-id-01.txt
>      Pages        : 16
>      Date           : 2014-04-30
>
>       http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id-01
>
> as a Best Current Practice Document.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on December 18, 2014.

I wouldn't be opposed to publishing this document; it certainly
contains useful information and I've not found anything obviously
wrong.  But I also think Ole made some valid point.  If I were to
choose, I'm a bit inclined to NOT publish it as a separate document at
this time. (But, again, if many others want to see it published, I
have no problem with it either).

I have some comments on the latest versions of the draft, all pretty
minor and mostly editorial:

- Abstract: s/simple a/a smple/

   Address.  Some implementations use simple a global counter for

- Section 3: s/the the/the/
   learn the the Identification value currently in use by Host A,

- Section 3: s/ICCPMv6/ICMPv6/
   response (e.g., an ICCPMv6 echo request with a large payload).  The

- Section 4:

   The Identification value of the Fragment Header MUST NOT be
   predictable by an off-path attacker.

  'MUST NOT be predictable' sounds vague to me, especially with the
  RFC2119 keyword.  I'm not sure if there's a precedent of the use of
  this word with a normative keyword, but even if there's, I would
  personally still like to see a clearer term here.  (If, of course,
  we'd like to publish it as an RFC in the end).

- Section 6.3:
   secret1:
      Secret data unknown to the attacker
  (The latter one: this should be "secret2")

- Section 10.1: Not a big deal, but I'm not sure why this has to be a
  "normative reference".

   [RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
              6946, May 2013.

--
JINMEI, Tatuya