Re: Asymmetric CIDs

[Martin Duke <[e-mail]>]

That sounds workable to me. Thanks for clarifying. However, if this is the
case then how is Stateless Reset broken?

If a load balancer is encoding different lengths in the CID, that
introduces additional overhead to a LB/Server communication protocol as
I've drafted. It's solvable but annoying.


On Fri, Feb 16, 2018 at 10:38 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Feb 16, 2018 at 9:52 AM, Martin Duke <[e-mail]>
> wrote:
>
>> Thanks for writing this up, ekr. This incorporates many of the
>> suggestions I made in objection to this project (perhaps coincidentally)
>> and I like it a lot.
>>
>> Advantages of this:
>> - In the common case where most of the data is server->client, clients
>> can get away with shorter Conn IDs to reduce overhead.
>> - Omit-conn-id just becomes a case where length = 0. Does this sidestep
>> some of Google's transition issues?
>> - If a client sends NEW_CONNECTION_ID, that indicates an intention to
>> migrate, and is a good cue for the server to send the same. We should add a
>> SHOULD to specify this behavior.
>>
>> I must be missing something, however, regarding implicit CIDs.
>>
>> If there's a NAT rebinding, how is the server supposed to extract the
>> CID?
>>
>
> The assumption is that the server either:
>
> (a) always uses the same CID length
> (b) has a structured CID which starts with the length.
>
> But that we don't need to mandate which one in the protoocl
>
>
>> Furthermore, this obviates the entire concept of using Connection ID for
>> routing; it's not obviously a savings to store CID length in a table vs.
>> just storing the destination server.
>>
>
> I don't think you hae to do this, but maybe I am confused. See above and
> tell me if you think I'm wrong
>
> -Ekr
>
>
>> Lastly, if we encode the length somewhere that seems to solve the
>> Stateless Reset issue.
>>
>>
>> On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett <[e-mail]> wrote:
>>
>>> Thanks for the excellent summary EKR.  I like this design and think the
>>> breakage of stateless reset in certain cases is acceptable, since it only
>>> applies if both sides must have their preferred connection ID present in
>>> order to route correctly, which is a use case that's impossible in the
>>> status quo.  I have not come up with any other downsides.
>>>
>>> On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla <[e-mail]> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> After a bunch of discussion, the CID task force came down to rough
>>>> consensus that asymmetric conn IDs were probably the right
>>>> direction (CID task force members, please feel free to voice dissent
>>>> here). Here's a complete writeup of what I think would be needed
>>>> for asymmetric connection IDs. It's not a PR, because I think
>>>> something self-contained is cleaner.
>>>>
>>>> Note that if we adopt this direction, we would be sacrificing
>>>> public reset under some conditions (see previous emails to the
>>>> list) and we would need to decide if it was worth keeping at all.
>>>>
>>>>
>>>> OVERVIEW
>>>> The basic idea is that each side gets to dictate the connection IDs
>>>> that are used to send to it. During the handshake, you establish those
>>>> CIDs and then each side can issue new CIDs during the connection.  The
>>>> main advantage of this is that it allows for symmetric topologies in
>>>> which
>>>> the client is also behind some kind of stateless LB/router rather than
>>>> just the server. See Issue #1091 for more info on this.
>>>>
>>>>
>>>> The overall handshake looks something like this:
>>>>
>>>> Client                                      Server
>>>>
>>>> Initial [CID=XXX] {recv-CID=YYY} ---------------->
>>>> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ}
>>>> Cleartext [CID=ZZZ], {recv-CID=YYY} ------------->
>>>> <-------------------------- Short header [CID=YYY]
>>>> Short header [CID=ZZZ] -------------------------->
>>>>
>>>>
>>>> The client's initial CID (XXX) is special, and either consists of
>>>>
>>>>     (a) a randomly chosen dummy CID. Proposal: require this to be
>>>>         8 bytes or at least a minimum. This should be the same
>>>>         for all Initial packets in a connection (unless a stateless
>>>>         reject is received, as below).
>>>>     (b) a CID which it received from the server in a stateless reject
>>>>
>>>> All the server's packets are sent with the client's receive CID (YYY)
>>>> and all subsequent client packets are sent with the server's receive
>>>> CID (ZZZ). The general rule is that you should send with the
>>>> connection ID that you most recently received (where recently
>>>> is defined as highest PN).
>>>>
>>>> Note: I believe it's safe to just use the sending CID as the mixin
>>>> for the KDF, but I haven't thought this entirely through yet.
>>>>
>>>> Finally, you can send NEW_CONNECTION_ID in either direction to provide
>>>> a new connection ID for the other side to use. The general assumption
>>>> is that you can do this at any time, just as with current QUIC, and
>>>> that any time you send to a new remote 3-tuple you should change CIDs
>>>> if you can. Note that this means that endpoints should try to make
>>>> sure that the other side has spare CIDs in case they need to migrate.
>>>>
>>>>
>>>> WIRE ENCODING
>>>> As we discussed in the meeting the short header should just have
>>>> an implicit length CID. This gives us the following short header:
>>>>
>>>>    +-+-+-+-+-+-+-+-+
>>>>    |0|C|K| Type (5)|
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                                                               |
>>>>    +                     [Connection ID (*)]                       +
>>>> <- change from 64
>>>>    |                                                               |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                      Packet Number (8/16/32)                ...
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                     Protected Payload (*)                   ...
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>> Note that we may also be able to dispense with the C bit, if each
>>>> side just gets to say "send me this CID exactly", why do we want
>>>> to say "here is my CID but you can omit it".
>>>>
>>>>
>>>> We have several options about the long header. The first question
>>>> is where recv-CIDs go. In previous versions I suggested putting
>>>> them in transport parameters, or elsewhere in the TLS handshake,
>>>> and that might still be viable, though it has some drawbacks [0],
>>>> so the other alternative is to put both CIDs in in the long header.
>>>> This would look something like:
>>>>
>>>>    +-+-+-+-+-+-+-+-+
>>>>    |1|   Type (7)  |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |  DCID-Length  |                                               |
>>>>    +-+-+-+-+-+-+-+-+   Dst Connection ID (*)                       +
>>>>    |                                                               |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |  SCID-Length  |                                               |
>>>>    +-+-+-+-+-+-+-+-+   Src Connection ID (*)                       +
>>>>    |                                                               |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                         Version (32)                          |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                       Packet Number (32)                      |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                          Payload (*)                        ...
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>> The semantics here are that the first value is the CID you want to
>>>> send to and the second one is the value you want used to send to you
>>>> (I've inverted these to keep the order the same as short header).
>>>>
>>>> Two notes about this encoding:
>>>>
>>>> 1. I think we agreed that we didn't want arbitrary length CIDs up to
>>>> 255 bytes, and yet we have room in this length byte. I propose we
>>>> limit it to 31 bytes and then grease the remaining 3 bits [1].
>>>>
>>>> 2. Because the client sends its CID first, there's no way to get the
>>>> current QUIC semantics of the server just dictates the CID.  I propose
>>>> we fix that by defining a special sentinel CID (all 1s, all 0s,
>>>> whatever) of whatever our maximum length is that means "just use your
>>>> own CID".
>>>>
>>>> We can endlessly bikeshed on this structure.
>>>>
>>>>
>>>> Finally, we will need to update NEW_CONNECTION_ID to allow a variable
>>>> length CID. This would look like this:
>>>>
>>>>     0                   1                   2                   3
>>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                          Sequence (i)                       ...
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |  CID-Length   |                                               |
>>>>    +-+-+-+-+-+-+-+-+       Connection ID (*)                       +
>>>>    |                                                               |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    |                                                               |
>>>>    +                                                               +
>>>>    |                                                               |
>>>>    +                   Stateless Reset Token (128)                 +
>>>>    |                                                               |
>>>>    +                                                               +
>>>>    |                                                               |
>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>>
>>>>
>>>> [0] However, in the transport parameters design, if the server's
>>>> handshake gets reordered, the client might need to send some ACKs with
>>>> the initial CID. However, we've agreed that the client's IP address
>>>> has to be stable, so this isn't a problem. Alternately, you could
>>>> change C->S CIDs in the short header if that was easier.
>>>>
>>>> [1] An alternative would be to have a sparse range (e.g., you can
>>>> express 0-7 and then 8-22 by 2s, assuming I have counted correctly)
>>>> and then we could pack both lengths into a single byte. As I said,
>>>> lots of opportunities for bikeshedding here.
>>>>
>>>>
>>>
>>
>