Going back to the start, it seems like there is an implied problem with the draft in that connections with the identifier are hard to distinguish from connections without. Is that the main problem?
I can't see how an explicit marking helps. If we admit the possibility that some connections will not support this new feature, then the recipient of packets is forced to identify those connections by 5-tuple. That's invariant. Mixed deployments have some challenges, but it's not completely unworkable. My conclusion is that peers without connection ID support monopolize the 5-tuple that they use, so that other connections can't migrate to that 5-tuple. They also cannot migrate to another 5-tuple. Otherwise, things work out. To reach that point, you have to realize that a mixed deployment has to use 5-tuple as a primary key. Packets that come in on a new 5-tuple are matched to connections opportunistically on what might or might not be a connection ID. If it is, then great (better make sure you ask for the same length ID from all peers, or match on prefixes...). If it isn't, then the ciphertext will be read as a connection ID, but even if it does identify a connection it will fail to decrypt. Thomas mentioned a heuristic, but I don't think that we need that. The only case that is difficult, and it's one that you might not care about, is one where a connection migrates to the same 5-tuple as an another connection. There, you will match to an existing connection and find that the packet doesn't decrypt. If the connection that you have associated with the 5-tuple supports and uses a connection ID, you can recover without trial decryption. Otherwise, you just have to drop the packet when it doesn't decrypt. (You could look up all the connections without connection IDs and use trial decryption, but why bother spending the effort and undermine the strength of your ciphers in that way.) You can only truly dispense with the 5-tuple mapping if you can guarantee that all of your clients support connection ID; at which point you can drop that table and route on connection ID alone. Packet inspection boxes will have maintain state, I don't see a way around that. The point here being that you need state to know how long the connection ID is, as well as how long it is. The middlebox issue is somewhat more interesting. If it is *your* middlebox, then there might be a case for routing connections with a connection ID differently. Based on the above, I would have said that it might be better to only deploy that sort of configuration when you can insist on receiving a connection ID. An explicit marking helps, but the cost is pretty high if we care about saving bits. My suggestion for the middlebox is to use a longer connection ID and include a MAC inside the connection ID. It ends up being a longer connection ID than the one QUIC uses, but it would allow the stateless routing middlebox to identify packets with and without a connection ID without any explicit marking. That doesn't require any change to the design. On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla <e...@rtfm.com> wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > Comments welcome. > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
