Prime client with connection ID for 0-RTT

[igorlord]

The draft requires the client to use client's Connection ID, even if the server's Connection ID is available. This is an artifact of having just one packet type and wanting to be unambiguous whose connection ID this packet features.

I propose using assigning an extra packet type for "0-RTT packets with Server Connection ID" to make handling connections more reliable.

This is related to #577.

[igorlord]

The original issue description is about switching to Server Connection ID for 0-RTT packets. This may be a rare race condition when Server Connection ID is available, so it is not very important.

The more important case is when Server Connection ID is available for the client before the very first 0-RTT packet is sent. It is important than for the server (load balancer) to know that Server Connection ID is being used. This also make this a very similar issue to #577.

[martinthomson]

@igorlord, Can we repurpose this issue to talk about priming the client with a connection ID that will improve their chances of having 0-RTT accepted by a server?

[igorlord]

@martinthomson Yes, with my last comment, I've already started down that road. Please, use this issue to be about priming the client with a connection ID for 0-RTT and the 0-RTT packet explicitly identifying itself as primed.

[ianswett]

Are you indicating the client would use a different packet type(ie: Client Initial) to indicate it was not client chosen?

[igorlord]

Yes, a different packet type would do it.

I want my load balancer to be very simple like:
forward_to_server_id = has_server_id(packet) ? extract_server_id(packet) : pick_server_id_for(packet, policies);

[martinthomson]

Well, I'm not inclined to suggest a new packet type. We could require that a client use a connection ID if the server picked one. In that way, the server could be sure (to the extent that it can be) that when it accepts 0-RTT, the connection ID is correct.

[igorlord]

Ok, server/load-balancer would just need to treat this case like it would treat Client Initial. I can live with this, I think.

[ianswett]

The editors discussed this and especially with the new varlen connection IDs, we don't believe a new packet type is necessary.

We can imagine this being useful to limit the scope of resumption for the purpose of preventing replay.

After discussing the mechanisms, bundling the ID in the transport params is one approach, since implementations are expected to be able to store transport params for future 0RTTs.

The supplied connection ID(s) in the transport params could be used with any session ticket.

[hardie]

It seems like supplying the connection ID with the session ticket allows you to both use the same one for all session tickets supplied (the same as this proposal) or to vary them with session ticket supplied which might be useful in some routing contexts. Could we consider that approach as well?

[ekr]

I think it's a reasonable idea in concept, but I'm not super-enthusiastic about the proposed newSessionTicket frame. As a practical matter, you're going to need your TLS stack to process the NST, so I'd rather just send it in stream/cream 0 and then have the TLS stack eat it. At that point you have two options:

1. Internal session cache, in which you interrogate the TLS stack after it has emitted CH (but before you send the packet) for its properties (whether 0-RTT is available, ALPN, etc.)
2. External session cache, in which the TLS stack tells you when a new ticket is available and its properties and you store it.

[martinthomson]

I'm putting this one on the v2 list. The basic idea that Igor raised here is sound, but it has evolved into a means of priming 0-RTT using external means. That's definitely something that I'm interested in, but I think that this is sufficiently non-trivial that it deserves its own effort. As ekr says, it's hard. And we clearly don't have time for that in version 1.