search

martinduke / draft-duke-quic-load-balancers

An internet draft to standardize the way that QUIC servers and load balancers can support routable, unlinkable connection IDs
Other
2 stars 4 forks source link

Adding a text that explains how to generate CID. #37

Open huitema opened 5 years ago

huitema commented 5 years ago

I tried to read the current spec, with an idea of implementing it in Picoquic. I quickly grew frustrated, because I found the discussions of CID format somewhat hard to follow. So I wrote a new section explaining the proposed CID structure.

martinduke commented 5 years ago

Hi Christian, thanks for reading and contributing.

Was your intention to summarize the rest of the draft in this section, or propose a new algorithm? If the former, I have indeed done a terrible job of making it clear.

huitema commented 5 years ago

@martinduke a little bit of both. I had a hard time understanding what you were trying to specify. I also don't get the discussion about the divider -- for me, it has the hallmarks of homemade crypto.

martinduke commented 5 years ago

Ah, that makes sense.

There are three different CID algorithms in the draft that involve different tradeoffs. The "homemade crypto" one is an obfuscation design for load balancers that cannot accept per-packet decryption costs. We have discussed the pros and cons of this a lot in the design team, and expect that it will be a point of contention in the WG.

Judging from your PR, you are probably going to like the "Stream CID" algorithm the best. I suggest you read that over and ignore the rest of the draft. I'll prioritize adding a diagram. If there are partcular sentences/paragraphs in there that are awful, I would appreciate that feedback. Likewise, if there are problems with that design, we should talk about that too.

Would you like to be on the design team mailing list?

huitema commented 5 years ago

Sure, add me to the mailing list.

By the way, there was a long debate on homemade crypto in one of the IETF lists, dnsop I believe, about the IPCrypt proposal for 32 bit "encryption". One of the point I heard loud and clear is that instead of using homemade stuff, people should be using FFX, which relies on proven algorithms like ChaCha20 or AES, is proven safe, and allows for variable bloc sizes. It would support any size between 32 and 144 bits.

In particular, FFX could be use to make a unique mapping between an N bit integer and an N bit "random number" of the same size, avoiding the birthday paradox issues when generating the "server" part of a CID. It has a cost -- either 4 times AES or 10 times AES depending on how paranoid you are. But in the design that I developed in the PR, that cost is only borne by the servers at generation time, not by packet by the load balancers or the servers.