Subject: On path attack by address rewriting

From: Christian Huitema <[email-masked]>
Date: Tue, 29 Jan 2019 18:52:52 -1000

EKR,

During the interim session this morning we had a discussion of issue
#2143. The concern is that either man-on-the-side or man-on-the-middle
can rewrite the IP headers and play games with the address. This is
possible because the IP header is outside the encryption and
authentication envelope, yet we play games with it. It is very hard to
get a full defense against such attacks, as they are very close to the
"NAT rebinding" scenario that we actually want to support.

We actually discussed this attack before, and that's the reason why the
spec ask for servers to probe both the old and the new address. I
verified that defense by adding a test in the Picoquic test suite. It
works like that:

1) Client and server are connected by a simulated 10 Mbps link.

2) Client starts a long download.

3) After the handshake, the simulation mimics an attack. 75% the packet
headers are rewritten, 25% of them pointing to an attacker controlled
address, 50% pointing to random addresses that go nowhere. The packets
sent to the attacker address are relayed to the actual source.

4) After some time, the attacker stops relaying packets to the source,
in an attempt to break the connection.

5) After some more time, the attack ceases.

The test verifies that the connection completes in a reasonable time,
without breaking. The test was failing with the original spec, but with
the new requirement to "probe both paths" the test passes. This makes me
believe that the spec is doing something right.

-- Christian Huitema