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