ietf
[Top] [All Lists]

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

2017-02-26 01:01:36
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(_at_)ietf(_dot_)org mailing lists by 2017-03-01. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



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




<Prev in Thread] Current Thread [Next in Thread>