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

Fernando Gont <> Wed, 08 February 2017 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA3241296F0; Tue, 7 Feb 2017 16:56:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nX10ZA7xyeG8; Tue, 7 Feb 2017 16:56:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67C7C12971E; Tue, 7 Feb 2017 16:56:38 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EDD39828F9; Wed, 8 Feb 2017 01:56:33 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
To: Joe Touch <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 7 Feb 2017 21:52:32 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, 6man WG <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Feb 2017 00:56:42 -0000

Hi, Joe,

On 02/07/2017 06:35 PM, Joe Touch wrote:
> IMO it's worth including a sentence that highlights these things
> elsewhere in the doc.
> But if others disagree, the existing text is sufficient.

The text is actually incorrect (see below).

>>> I'd add one sentence about Fred's observation too:
>>> In addition, spoofed ICMP messages can also affect the correct operation
>>> of PMTUD.
>> You don't think that's covered by the existing security considerations:
>>    This Path MTU Discovery mechanism makes possible two denial-of-
>>    service attacks, both based on a malicious party sending false Packet
>>    Too Big messages to a node.
>>    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.

If you are employing EHs this could indeed stop the data flow.

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

This one is probably not worth elaborating: at the end of the day, it
doesn't work.

There are many other things to note here, e.g.:
*  many stacks don't even check that the ICMPv6 PTB referes to e.g. an
ongoing TCP connection

* Some stacks cache the PMTU for all packets sent to the target IPv6
address (i.e., the attack might affect multiple flows)


Much of this is covered in RFC5927.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492