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

[Gorry Fairhurst <[e-mail]>]

On 16/02/2017 15:59, Joe Touch wrote:
> Hi, Gorry,
>
>
> On 2/16/2017 6:08 AM, Gorry Fairhurst wrote:
>>
>> The text below is not about tunnels - this is about  the operation of
>> transport, and the quoted text is from the new UDP Guidelines ID.
> Oh - I was distracted by some of the text then - see below...
>
>>
>> On 15/02/2017 21:26, Joe Touch wrote:
>>> Hi, Gorry (et al.),
>>>
>>> Again, the following text should not drift into discussing how tunnels
>>> are handled IMO. That should be addressed in a different document (and I
>>> don't think it's troublesome at all if viewed correctly).
>>>
>>> Joe
>>>
>>>
>>> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote:
>>>> - Introduces a significant vulnerability.  A rogue PTB message that
>>>> reduces the PMTU to a minimum, can result in a path too small to carry
>>>> an encapsulated packet. (Recently noted by Fernando Gont). .
>
> The issue is the IPv6 limit. Issues of "encapsulated packets" not
> fitting in this limit are already handled by transport protocols using
> IPv6 (if this is about layering encapsulation) and tunneling (if this is
> about tunneling, which is how I inferred "encapsulated packets").
>
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).

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

>>
>>>> - clearly handling this in IP-layer tunnels can be troublesome, but
>>>> that's a problem that should be described, not obscured.
>>>
>>
>> Gorry
>
Gorry