On Thu, Sep 10, 2020 at 2:21 PM Mike Bishop <mbis...@evequefou.be> wrote:
> Certainly it’s better for the server if it can be consistent, especially > if it expects multi-packet first flights. If the same back-end sees both, > it can discard the second, and that’s what I’d expect most of the time. > But here’s what I think is possible: > > > > The client sends an Initial packet (randomly selected Destination CID), > PTOs, then sends another Initial packet to the same Destination CID. On > the server side, the infrastructure assumes that Initial packets whose CIDs > aren’t issued by them can be routed to a random back-end, and that back-end > will set a new DCID that routes to it in the future. > > > > The client will receive either of the Server Initial packets, switch to > the new DCID, and will reject the other because attempts to change the > server’s CID a second time. The connection succeeds because whichever > server’s ServerHello is used also has its DCID used, so all subsequent > packets go to that back-end. > OK, this can't happen in DTLS because the CID management works differently. While it's not clear to me that QUIC explicitly prohibits this (it would be prohibited if CRYPTO frames were STREAM frames because of draft-ietf-tls-quic-transport S 2.2, it seems like it's quite bad practice because the result will be that the losing server has a pending handshake which it continues to retransmit on until the client times out. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
