Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Folks,

Page 15 of the document says:

    For every packet that is to be fragmented, the source node generates
    an Identification value.  The Identification must be different than
    that of any other fragmented packet sent recently* with the same
    Source Address and Destination Address.  If a Routing header is
    present, the Destination Address of concern is that of the final
    destination.

      *  "recently" means within the maximum likely lifetime of a
          packet, including transit time from source to destination and
          time spent awaiting reassembly with other fragments of the same
          packet.  However, it is not required that a source node know
          the maximum packet lifetime.  Rather, it is assumed that the
          requirement can be met by implementing an algorithm that
          results in a low identification reuse frequency.  Examples of
          algorithms that can meet this requirement are described in
          [RFC7739].

This is certainly an improvement over RFC2460, which suggested the use
of a simple counter to achieve this requirement. While the algorithms in
RFC7739 are meant to result in non-predictable (by off-path attackers)
Identification values, I believe that this spec should clarify that
Identification values should not be predictable by off-path attackers.

The survey in Appendix B of RFC7739
(<https://tools.ietf.org/html/rfc7739#appendix-B>) shows some sample
popular implementations that, unfortunately, still employ predictable
Identification values.

Given too-frequent pattern of protocol implementations employing
improper numeric-identifier generators (see
<https://tools.ietf.org/html/draft-gont-predictable-numeric-ids>) and
<https://tools.ietf.org/html/draft-gont-numeric-ids-history>), I think
an explicit requirement is warranted.

Thanks,
Fernando

On 02/01/2017 08:49 PM, The IESG wrote:
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'Internet Protocol, Version 6 (IPv6) Specification'
>   <draft-ietf-6man-rfc2460bis-08.txt> as Internet 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 2017-03-01. 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
> 
> 
>    This document specifies version 6 of the Internet Protocol (IPv6).
>    It obsoletes RFC2460
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information: 
>     rfc4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft Standard - IETF stream)
>     rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492