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