Folks,
I just read through this document and it looks ready to move forward,
modulo this:
* In the Security Considerations section, it says:
" In the first attack, the false message indicates a PMTU much smaller
than reality. This should not entirely stop data flow, since the
victim node should never set its PMTU estimate below the IPv6 minimum
link MTU. It will, however, result in suboptimal performance."
This is not really correct. If the node was employing extension headers
(e.g., lots of Destionation Options), then this actually could actually
stop the data flow. -- Yes, such a scenario doesn't happen in practice,
but, according to the specs is possible.
* In the same section, this paragraph:
" In the second attack, the false message indicates a PMTU larger than
reality. If believed, this could cause temporary blockage as the
victim sends packets that will be dropped by some router. Within one
round-trip time, the node would discover its mistake (receiving
Packet Too Big messages from that router), but frequent repetition of
this attack could cause lots of packets to be dropped. A node,
however, should never raise its estimate of the PMTU based on a
Packet Too Big message, so should not be vulnerable to this attack."
Should probably be simplified to:
" In the second attack, the false message indicates a PMTU larger than
reality. If believed, this could cause temporary blockage as the
victim sends packets that will be dropped by some router. A node,
however, should never raise its estimate of the PMTU based on a
Packet Too Big message, so should not be vulnerable to this attack."
* In the same section, a reference to RFC5927 might be useful, since it
expands on PMTU attacks and also describes what some implementations do
to mitigate these attacks.
* Finally, given the work in RFC8021, RFC7915, and rfc2460bis, I think
it would be sensible for this document to note, somewhere, that ICMPv6
PTB messages advertising an MTU smaller than 1280 bytes should be
silently dropped.
Thanks!
Best regards,
Fernando
On 02/01/2017 08:52 PM, The IESG wrote:
The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Path MTU Discovery for IP version 6'
<draft-ietf-6man-rfc1981bis-04.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 describes Path MTU Discovery for IP version 6. It is
largely derived from RFC 1191, which describes Path MTU Discovery for
IP version 4. It obsoletes RFC1981.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/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)
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