Re: Increasing QUIC connection ID size

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

This was also my intention. That the server and router share the key. But
also that multiple connection ID’s are encrypted with the same key and a
unique identifier.

Igor says the key can be matched to the connection. This is true, each
connection can have a unique derived key. But it is largely the same as
using a single key with different IV since we are only encrypting a single
block. Details may very on how insecure the solution is if the unique value
is not unique. But the challenge remains that there needs to be a unique
identifier and packet number and 4-tuple is not it.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 12 January 2018 at 02.05.18, Roberto Peon ([e-mail]) wrote:

Correct/agreed. The L4 ‘router’ must be able to decrypt/interpret the data
in order to act upon it. This requires sharing of some key material.

-=R



*From: *QUIC <[e-mail]> on behalf of "Lubashev, Igor" <
[e-mail]>
*Date: *Thursday, January 11, 2018 at 4:55 PM
*To: *Mikkel Fahnøe Jørgensen <[e-mail]>, Victor Vasiliev <
[e-mail]>, IETF QUIC WG <[e-mail]>
*Subject: *RE: Increasing QUIC connection ID size



I think the idea is that the key used to encrypt connection ID is known to
both the server and the router.  That key would need to be rotated
periodically, and the router would need to understand which key was used
for this particular connection, but that can be solved.



*From:* Mikkel Fahnøe Jørgensen [mailto:[e-mail]]
*Sent:* Thursday, January 11, 2018 7:25 PM
*To:* Lubashev, Igor <[e-mail]>; Victor Vasiliev <
[e-mail]>; IETF QUIC WG <[e-mail]>
*Subject:* RE: Increasing QUIC connection ID size



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.