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

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

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




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