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: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492