Server responses to multiple Initial packets

[martinthomson]

There is an odd case where a client sends two Initial packets. The server accepts one and sends Retry in response to the other. If the client processes the first, the Retry will likely cause the client some problems if it tries to handle it. We should explain this in the description of Retry and recommend that the client just drop the Retry.

Separately, if there are two differing server Handshake packets, we need rules about those too. In this case, is possible if the two Initial packets end up at different back end servers. The really perverse case is where the server Handshake is mixed: Handshake[0] from server 1 is followed by Handshake[1] from server 2. I don't see any easy answer here, other than to note that servers are likely to be consistent with their packet sizes. As long as Handshake packets from one server arrive before Handshake packets from the other server, they will be seen as duplicate data and discarded. The second server will just eventually time out. If the client gets a mix of data from different servers, then the handshake will just have to fail.

A recommendation/requirement to route Initial packets with the same connection ID consistently is probably the best solution for this second case. A server that accepts 0-RTT has to do this anyway.

[mikkelfj]

As I have said a few times before, I really think the initial client CID should be included in any early handshake, VNEG, or RETRY message along with the a separate server CID. For handshake the AEAD handles this case, although an explicitly reflected CCID would be helpful in the single port case we do not support.

If we further require the SCID to include a random element and therefore be different from the CCID, the ambiguities ought to be sorted:
A client that does not see its own CCID (or cannot verify AEAD) can just drop the packet.
A client that has accepted any early server response should lock on to that unique SCID and ignore others.
A client MAY reset state and prefer another later arriving server SCID, for example preferring a handshake over a VNEG (an attack from a path observer recently discussed on the mailing list).

This avoids the consistent early routing requirement. It may be helpful to avoid this requirement because it is a way to DoS a single server and because it balances load even if the CCID is not random (as it should be).

If we look further out to asymmetric CID's the initial packet sent by client after a retry would be different from an ordinary initial packet because it would route by a SCID and not a CCID. A router would be able to tell the difference and consistently route SCID but possibly randomly route a CCID (to prevent DoS and to balance load).

EDIT: it is still possible to have conflicts because the random SCID might accidentally be the same as another. The client needs to be robust against this - also because an attacker could otherwise exploit it. I'm not sure how it would ensure robustness, but closing the connection is acceptable if it can figure that out.

[huitema]

The initial CID is "virtually" included in any handshake -- the handshake key depends on it. I too would prefer that it be actually present, because then the clients could demux by CID instead of just by IP address and port. But explicitly adding the CCID to the handshake packet will not change the state machine. It will also not prevent repeat of Client Initial Message on time out, and thus the corner case that Martin points out.

The root cause of that corner state is that the sent a stateless reset in response to the first message, and then shortly after that stated a handshake in response to the second message. This is a mildly inconsistent behavior, but it could happen if the server state changed between the two messages, for example if the retry was sent because of a temporary congestion. And it will only cause a problem if the restart is delivered to the client out of order, after the handshake reply. But then, yes, that could happen, especially at times of congestion.

Ignoring restart packets after the handshake has started. That sounds like an appropriate response to a mild error, and will work well in most cases. But there is another angle. What if the handshake response was a fake, something sent by a man on the side?

[MikeBishop]

Discussed at editors' meeting: Proposal is to assume this is broken server infrastructure. Different client source CIDs would fix this, but doesn't solve anything in the common zero-length case. In that case, we'll accept the handshake failure here. If there's a good suggestion on how to close these holes, we can reopen and consider.

[martinthomson]

Creating multiple connections from the client (with different randomized Destination Connection ID and new Source Connection ID fields) might work, but complicates the client. It also doesn't work if the client uses a zero-length connection ID because the server packets don't properly identify which of the cryptographic contexts the client used.