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