Re: Increasing QUIC connection ID size

[Ian Swett <[e-mail]>]

I would like to leave QUIC open for longer connection IDs in future
versions, so I'd like to specify the invariants in such a way that longer
connection Ids wouldn't violate them(ie: Victor's suggestion
of “middleboxes always get first 64 bits and they have useful entropy to
distinguish connections”.) but I'm reluctant to include 128 bit connection
IDs in v1 at this point.

I would also echo Christian's sentiment that the incremental overhead
starts becoming fairly large.

On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <[e-mail]>
wrote:

> We have a prototype implementation in Picoquic in which the connection ID
> can be split so some bits are random and some bits are used for routing to
> a specific server -- thanks Igor for that. It makes for nice experiments,
> but it is a denial of service waiting to happen. For example, attackers
> could set the bits in such a way as to target a specific server in a pool,
> or they could learn which connections are on the same server and use that
> later for some kind of same server attack. It would be better if that
> information was not in clear text. In fact, the picoquic implementation use
> a callback to ask for the new value -- presumably from the router. That
> callback could return anything, including an encrypted value.
>
> On the other hand, it is not clear to me that we need full encryption. For
> example, assume that the server that needs a connection ID can ask it from
> the router. The router could pick one at random, make sure that it is
> properly documented in the routing tables and that there is no collision,
> and then pass it back to the server. No encryption needed, but of course
> lots of state.
>
> If the router does not want to keep the state, it can indeed create a
> connection ID by encrypting a <nonce, server-ID> tuple. But it does not
> follow that the encryption needs to be 128 bits. For example, it could use
> a 64 bit algorithm like Blowfish.
>
> So I am not sure that we actually need to change the length. And I am a
> bit concerned by the incremental overhead if the connection ID suddenly
> becomes very large.
>
>
>
> On 1/11/2018 2:25 PM, Mikkel Fahnøe Jørgensen wrote:
>
> Actually, on encryption of connection ID, this is not so simple.
>
> We must assume there is only a single key for many connections because the
> router is not part of a key exchange. This unique value or counter used for
> encrypting a single block cannot be the same for two different connections
> ID’s, but it can be public. This means that it must be stored in the packet
> header. And, as it turns out, random connection ID chosen by a trusted
> source, can be used for such a unique value. But then it must be used to
> encrypt and/or authenticate something else carrying the actual routing
> information. So now you start to really need some extra payload.
>
> Alternatively the routing information is entirely random such as content
> hashed routing. Then you only need to authenticate the routing data. You
> can do that with a HMAC, and CMAC could probably also work. The additional
> benefit is that you can probably get away with 64-bits for all routing
> information possibly including the auth tag. Say 48 bits of routing data
> and 16 bits of auth tag.
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 12 January 2018 at 00.57.21, Lubashev, Igor ([e-mail])
> wrote:
>
> I am interested in exploring this proposal, since it allows for more
> flexible schemes of encoding routing metadata and a checksum.  I would also
> like to be explicit about the connection ID size in a packet header,
> though, since it greatly simplifies the implementation.
>
>
>
>    - Igor
>
> *From:* Victor Vasiliev [mailto:[e-mail]]
> *Sent:* Thursday, January 11, 2018 6:16 PM
> *To:* IETF QUIC WG <[e-mail]>
> *Subject:* Increasing QUIC connection ID size
>
>
>
> Hi everyone,
>
>
>
> In the current version of QUIC, the connection ID size is fixed to be a
> 64-bit opaque blob, and that is set as an invariant in the protocol.
>
>
>
> I’ve looked into possibility of using a connection ID to encode the
> specific server details into it (to provide stability of the connection in
> case of load balancing changes, especially BGP flaps for anycast IPs), and
> have chatted about this with other people I knew were interested in this.
> It seems like 64 bits might be too small for this purpose, and we might
> want to leave an opportunity to extend the connection ID size.
>
>
>
> The basic idea is that you want to be able to:
>
>    1. Store some routing metadata in the connection ID.
>    2. Have some entropy that allows distinguish users with identical
>    routing metadata.
>    3. Have a checksum to ensure the validity of routing information
>    4. Encrypt the information above to prevent disclosing the route
>    information and allow generating uncorrelatable connection IDs.
>
> There are two underlying issues here.  The first problem is that all of
> this does not fit well into 64 bits, and you have to seriously compromise
> on the strength of the checksum (which is bad especially if you want it to
> be a MAC rather than a checksum).  The second problem is that encrypting
> 64-bit values fast is actually fairly hard since the block ciphers easily
> available in hardware have 128-bit block size, and the performance
> requirements on load balancers are tighter than on servers.
>
>
>
> In other words, having a 128-bit connection ID provides for an easy secure
> way to generate unlinkable connection IDs on migration.
>
>
>
> So, the problem we’re trying to solve is that the connection ID is too
> small.  There are two questions I believe the working group should answer
> at this point:
>
>    1. Do we want to address this problem at this point in standardization
>    process?
>    2. If we don’t address this problem right now, how do we structure the
>    standard in a way that we can extend the connection ID in the future?
>
> There are multiple ways to solve the problem of making connection ID
> larger.  One is to just add extra bit to the “omit connection ID” field to
> allow 128-bit connection IDs.  Another approach is to allow connection ID
> size to be explicitly specified by the server, and then assume that the
> load balancer knows that size and no one else on the path needs to read it.
>
>
>
> There’s also a question of how much of connection IDs do middleboxes
> (excluding load balancers and other boxes owned by the same entity as
> either client or server) need to know.  We could go for both “middleboxes
> should be always able to read the entire ID” and “middleboxes should not
> read connection IDs at all options”, but I think there’s also a room for
> more flexible formulations like “middleboxes always get first 64 bits and
> they have useful entropy to distinguish connections”.
>
>
>
>   -- Victor.
>
>
>