Specify DCID of 0-RTT packets

[mikkelfj]

This has been discussed before, but after reorg. of text, I can't find any clear statement in Transport Draft about how to create DCID for 0-RTT. The DCID field is not mentioned for 0-RTT packets in transport draft.

#1513
#1721

Note: I got the think about this in the context of replay attack prevention which would be simpler of the 0-RTT DCID is not random. But that discussion was already closed in the above issue.

[martinthomson]

We previously discussed this and the conclusion was to change to the server-selected connection ID once a packet has been received from the server. Until then, the random value would be used. If this is missing, then we just need some text in the 0-RTT packet section to cover this. This probably just needs to reference Section 7.2, which says:

Upon receiving a packet, each endpoint sets the Destination Connection ID it sends to match the value of the Source Connection ID that they receive.

[mikkelfj]

Based on proposed 0-RTT routing to single instance for replay protection, discussed on the mailing list, it would be helpful if the server can assign a DCID for use in 0-RTT that is potentially longer than normal CID's. This is because CID routing lifetime may shorter than 0-RTT session tickets, and a longer DCID could make it easier for a server farm to route 0-RTT packets correctly.

[MikeBishop]

Are you proposing that the client should get a CID along with the NewSessionTicket (or the NEW_TOKEN)? That's been discussed before, and while it makes sense to me, it means that load balancers need to be able to differentiate the two types (and potentially sizes) of CID.

On the whole, I think this is a promising direction, but perhaps not needed for v1.

[mikkelfj]

Yes, along with the session ticket. The ticket transfer is a bit of a black box so I can only propose the high level concept. (I'm wondering if Retry and 0-RTT could be made more similar, but whatever).

That's been discussed before, and while it makes sense to me, it means that load balancers need to be able to differentiate the two types (and potentially sizes) of CID.

At least such that they have an option to do so if they are so inclined. I.e. there is no immediate downside since you can also just provide a standard CID if that is better for a particular infrastructure.

As to sizes, that was a bigger problem a while ago when the CID size was implicit. Also, since the CID is only used for 0-RTT, it can be large without significant cost - it should/could be changed immediately upon 0-RTT server acceptance.

As to v1, I agree that might be stretching it a bit.

[martinthomson]

The point that keeps coming up in this context (I'm sure I've typed the same response elsewhere...) is that the timescales over which connection IDs are stable is likely far less than the timescale over which attempting 0-RTT is possible. That is, you might attempt 0-RTT up to a week later, but the server cluster you hit might be in a configuration so different that the connection ID you got 5 or 6 days ago doesn't route to the same node.

That said, for those server configurations that are more stable, this isn't a terrible idea. If this were discretionary, say as an extension, then it might be useful for ensuring that 0-RTT attempts are routed to the right destination.

But anything that does this sort of targeting could also create a nice targeted DoS vector. Connect to the same server multiple times over the course of a week. Then, when it's go time, send that server 0-RTT using all the collected connection IDs that route directly to it.

Marking v2, not editorial.

[mikkelfj]

It's fine to move to v2 on the larger issue, but the text is still unclear in transport v1.