Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

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