Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)

[Kazuho Oku <[e-mail]>]

@ianswett 
> I think there are two obvious designs here, though there may be more:
> 
> 1. Change the CID routing based on packet type (Nick's suggestion above)

I do not think that this is a viable design.

An attacker controls both the client tuple and the initial CID. A stateless load balancer has to have the capability to change the CID, otherwise, it cannot balance the load between the servers running behind.

> 2. Use 5-tuple routing for all long header packets(Because 5-tuple can't change during the handshake) and CID routing after that.

Actually, there's a third design, that is possible under the current specification (and IIRC that multiple stacks already implement).

As @marten-seemann points out, a server can use authenticate the CID, to tell at a very high probability if a CID was generated by the server. Initial / 0-RTT packets that contain an authenticated CID is passed to the corresponding backend server (or the corresponding pthread). Initial / 0-RTT packets that do not are considered as new connections.

When not under attack, packets with CIDs that do not authenticate are routing using the 5-tuple. Servers will generate authenticated CIDs that route to themselves. Therefore, all the Initial and 0-RTT packets reach the correct backend.

When under attack, 0-RTT is disabled / dropped. Initial packets carrying CIDs that do not authenticate are distributed to the backends using an algorithm that the load balancer selects. Initial packets that carry CIDs that authenticate are routed to the corresponding servers. While it is true that routing of a tiny portion of Initial packets is not controlled by the load balancer, it is fine assuming that the CID encryption key is unknown to the attacker.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2834#issuecomment-504827612