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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Gorry,


On 2/16/2017 8:47 AM, Gorry Fairhurst wrote:

The point was that according to this spec (as currently written), an off-path attacker can trivially inject an ICMPv6 message into the traffic, which then causes a host to accept a different PathMTU. Normally a transport design would expect ICMP messages to be at least checked against the list of known connections, so that successfully mounting this attack required the  packet to correspond to ports that are in use. (Usually unknown to an off-path attacker).

Agreed - but IMO this has nothing to do with "encapsulation" or tunneling, AFAICT.



Moreover, other layers view ICMP messages with suspicion and have long
noted the need to check ICMP payload and match only packets that
relate to actual 5-tuples in use (effectively reducing vulnerability
to off-path attacks). For example, the Guidelines for UDP, rfc5405bis,
state:

" Applications SHOULD appropriately validate the payload of ICMP
   messages to ensure these are received in response to transmitted
   traffic (i.e., a reported error condition that corresponds to a UDP
   datagram actually sent by the application). …“

The comment below could easily be handled by something that clearly
indicates the problem and points to the tunnel draft for guidance, I
agree no need to go into algorithms/methods here.

The problem isn't unique to tunnels - it happens on any link whose MTU
can vary, and IMO the solution is the same. React to the change in
subsequent traffic, rather than attempting to rely in ICMP relaying from
signaling inside the link layer -- regardless of that link layer.

Joe

I'd be fine with recommending that way of working - but if the host reacts to ICMP, it is important to try to verify ICMPv6 messages before accepting them.

I think that's a fine punchline. The key is what "verification" means - as you note, a transport connection might not want to react to conflicting information and no entity (transport, OS, etc.) ought to react to nonsensical info (attempts to push MTU below required minimums).

Joe


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]