Re: Asymmetric CIDs

[Eric Rescorla <[e-mail]>]

On Fri, Feb 16, 2018 at 11:08 AM, Martin Duke <[e-mail]>
wrote:

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

The server knows it's CID (from the offending packet) but doesn't know the
client's CID (because it's statelsss), so when it sends SR, there's a
chance it gets misrouted at the client.

-Ekr


>
> 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.
>>>>>
>>>>>
>>>>
>>>
>>
>