QUIC connection and flooding attacks

[Christian Huitema]

As part of a prototype implementation of QUIC, I am looking at the "SYN Attack resilience" mechanisms built in the protocol. The server can respond to "Client Hello" by a "REJECT" message that includes a cookie (IP Token), which the client will then repeat in a new "Client Hello". These synchronization messages are sent through stream number 1. The decision to use the stream mechanism to convey negotiation messages makes sense, but it also creates interesting issues.

1) Can the initial Client Hello be spread over several packets?  If it can, then the server has to create a full connection context to receive the message, and that opens the door to various abuses.

2) If the server "Rejects" a Client Hello, will the new "Client Hello" be sent in the same connection context, or in a new context? I would like to keep no memory of a failed attempt on the server side, and that implies deleting the context, but I am not sure that I read the spec correctly on that point.

3) If the client believed that the connection will be accepted, it might send some data immediately after the CHLO, using the intermediate encryption key derived from the server config. Upon reception of a REJ, is the client supposed to reset the encryption context to "unencrypted?" What happens to the "immediate data?"

-- Christian Huitema

[Ryan Hamilton]

On Mon, Jun 1, 2015 at 12:08 PM, Christian Huitema <huit...@gmail.com> wrote:

As part of a prototype implementation of QUIC, I am looking at the "SYN Attack resilience" mechanisms built in the protocol. The server can respond to "Client Hello" by a "REJECT" message that includes a cookie (IP Token), which the client will then repeat in a new "Client Hello". These synchronization messages are sent through stream number 1. The decision to use the stream mechanism to convey negotiation messages makes sense, but it also creates interesting issues.

1) Can the initial Client Hello be spread over several packets?  If it can, then the server has to create a full connection context to receive the message, and that opens the door to various abuses.

​Currently, the CHLO will fit into a single packet, but the answer to the next question makes that less important.

2) If the server "Rejects" a Client Hello, will the new "Client Hello" be sent in the same connection context, or in a new context? I would like to keep no memory of a failed attempt on the server side, and that implies deleting the context, but I am not sure that I read the spec correctly on that point.

​Currently, the same context so even if the CHLO fits into a single packet, the server still needs to maintain connection state.

 

3) If the client believed that the connection will be accepted, it might send some data immediately after the CHLO, using the intermediate encryption key derived from the server config. Upon reception of a REJ, is the client supposed to reset the encryption context to "unencrypted?" What happens to the "immediate data?"

​It is lost and needs to be retransmitted with the new" initial encryption key, derived after processing the REJ.

I said, "currently" in my first two responses because we are actively working to make the QUIC handshake stateless on the server side. The crypto handshake was originally envisioned​ to be stateless, with the reject cause the existing connection to be closed and a new connection created to continue the handshake. For a number of reasons, we didn't implement this initially and instead the server continues to hold state across rounds. But we're actively working on this and you should expect to see updates to the docs, and to the code soon-ish.

Cheers,

Ryan

[Christian Huitema]

On Monday, June 1, 2015 at 2:22:18 PM UTC-7, r...@chromium.org wrote:

... 

I said, "currently" in my first two responses because we are actively working to make the QUIC handshake stateless on the server side. The crypto handshake was originally envisioned​ to be stateless, with the reject cause the existing connection to be closed and a new connection created to continue the handshake. For a number of reasons, we didn't implement this initially and instead the server continues to hold state across rounds. But we're actively working on this and you should expect to see updates to the docs, and to the code soon-ish.

Can we do that and at the same time look at the initial sequence number? It is currently hard-coded to zero, but doesn't have to. It could be defined as "the sequence number of the packet that carried the (non rejected) CHLO." With that, we could have a stateless server implementation, without requiring clients to churn new contexts.

-- Christian Huitema

[Ryan Hamilton]

​Thats a clever idea! I like it, but I think it's unfortunately problematic. I think that the client still has to churn a new context. The reason is that handshake messages are delivered as the payload of the sequence of bytes on the crypto stream. So if a client sends CHLO at, say, bytes 0-512 on the crypto stream, then if it does not "reset" state, it'll send the second CHLO ​at bytes 513-1024. But the server will see this frame and will wait for bytes 0-512, which will never arrive. In addition, there are flow-control considerations to think about here as well. You could imagine just resetting some of this state, but I fear there might be dragons there.

Based on our discussions, I think it's simpler to reason about if the client simply comes back with a completely new connection ID and context.

​Cheers,

Ryan​

[Christian Huitema]

Based on our discussions, I think it's simpler to reason about if the client simply comes back with a completely new connection ID and context.

I agree that is simpler, and easier to get right.

-- Christian Huitema