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

[Fernando Gont <[e-mail]>]

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)

etc.

Much of this is covered in RFC5927.

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