Re: Increasing QUIC connection ID size

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I can also see a need for larger connection ID’s for routing purposes in
overlay networks, but I decided it was probably better to prefix the QUIC
header in that case.

It is worth noting that if you have a non-unique tuple of port-address
pairs, you need the connection ID in every packet, and that can be a lot of
overhead. So a large ID would likely isolate that version to a dedicated
purpose, and then you might as well add a packet prefix.

An alternative solution is to use the connection ID as an index into a
routing table that has the real details, but this requires that early
packets of the connection carry those details in a way that routers can
pick up which probably isn’t practical.

A more practical solution is to keep the connection ID as is to serve its
primary purpose. A given protocol version could negotiate an extension the
the clear text header. Even if those data are not directly following the
connection ID, they can easily be picked up by router. This is essentially
the same as a packet prefix, except that the QUIC invariants are now
maintained.

As to encryption: block encryption generally works by xor’ing a “random”
value to the clear text. AES produces such a value from a counter or
similar unique value per block but does not need the clear text data at
all. The output of AES is simply XOR’ed with the clear text data (this can
be different when encrypting multiple blocks). This means that if the block
size is 128 bit you can easily encrypt 64 bytes by XOR’ing with the first
64-bits of the AES output. But you likely want to zero extend instead due
to auth tag:

It is not safe to use block encryption alone. It must nearly always be
associated with an authentication tag as with AES-GCM. Otherwise an
attacker will quickly learn that, say, bit 53 and bit 32 affects routing
and can trivially cause at least 1/4 packets to land somewhere else just be
flipping either bit. A compact auth tag does not have to be very long for
such a short message but it adds to the overall size requirement and
complexity of the solution.It could be generated with CMAC that are two AES
encryption rounds. (CMAC on connection ID could, BTW, also be used to very
quickly reject invalid QUIC packets, which I have proposed earlier). The
CMAC output will be one AES block, but it can be truncated depending on the
security level required.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 12 January 2018 at 00.16.21, Victor Vasiliev ([e-mail]) wrote:

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.