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

[Fernando Gont <[e-mail]>]

Hi, Jinmei,

On 12/08/2014 06:40 PM, 神明達哉 wrote:
> - 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.

FWIW, RFC6056 (port randomization) says:

   Ephemeral port selection algorithms SHOULD obfuscate the selection of
   their ephemeral ports, since this helps to mitigate a number of
   attacks that depend on the attacker's ability to guess or know the
   five-tuple that identifies the transport-protocol instance to be
   attacked.


OTOH, RFC6528 (TCP SEQ randomization) says:

   F() MUST NOT be computable from
   the outside, or an attacker could still guess at sequence numbers
   from the ISN used for some other connection.

where F() is essentially the TCP SEQ generator..




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

Good grief! -- Will do.



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

FWIW, the rationale for including it as a normative reference (rather
than in order to understand the attack description in Section 3 (pages
5-6), you need to read RFC6946.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1