Subject: [quicwg/base-drafts] Server responses to multiple Initial packets (#1115)

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Feb 2018 00:34:00 +0000 (UTC)

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.

-- 
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/1115

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Feb 2018 17:05:59 -0800

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 therefor be different 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 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 an way 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).

-- 
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/1115#issuecomment-366115246

---

From: Christian Huitema <[email-masked]>
Date: Sat, 17 Feb 2018 18:12:30 +0000 (UTC)

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? 

-- 
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/1115#issuecomment-366460303