Re: How does a server identify a new connection?

[Christian Huitema <[e-mail]>]

 

> On Nov 30, 2018, at 7:37 AM, Dmitri Tikhonov <[e-mail]> wrote:
> 
>> On Thu, Nov 29, 2018 at 11:41:32AM +0900, Kazuho Oku wrote:
>> The question is what happens if a man-on-the-side attacker races an
>> Initial packet with the same 5-tuple, same SCID / DCID, but having
>> different values in other fields.
> 
> Is such attack feasible?  By definition, the man-on-the-side cannot
> delay the original packet.  For the spoofed packet to reach the
> server first, the man-on-the-side would have to have access to a
> different, faster path to that server.

Non only feasible, but in actual use now. Do for example a search for "Quantum Insert".


> 
> How do other transport protocols mitigate such attacks, if at all?

The only plausible defense now is to run over IPSEC or a VPN. TLS over TCP is vulnerable to TCP level attacks.

> 
> I am asking these questions a) out of ignorance and b) as the
> implications of the proposed change (PR 2076) begin to dawn on me.

Defending against inserts after the handshake is relatively easy and everybody should do it. Defending the initial handshake involves speculative initiation of many connection copies, and then rolling back the bad ones once a good one was verified. So, yes, it is costly.

Kazuho's PR changes the equation from very costly to doable. In particular, the idea of tying the initial CID to the Client Hello greatly reduces the cost of the defense on the server side, and does not burden clients much. There is still some heavy work to do to client side to fully complete the defense, but the cost is only borne by those clients who want the defense.

-- Christian Huitema