Re: Proposed changes to cleartext packets

[Jana Iyengar <[e-mail]>]

There are two issues that are I brought up; for clarity's sake, I'll limit
this discussion to the immediate one. I'm summarizing the two proposals,
because it helped clarify my thinking, so I hope it helps others as well.
Please correct / add anything you think is incorrect / missing. I'm back in
favor of the newer proposal, FWIW, see below.

*Proposal #1 (first proposal):*
Client sends Client Initial
Server sends ServerHello/Stateless Retry/Version Negotiation with new
connection ID

If server sends SHLO:
Client continues with connection, uses server-supplied connection ID
Server continues using same connection ID

If server sends SR / VN:
Client resets connection
Client sends Client Cleartext with server-supplied connection ID
Server continues using same connection ID.

Load balancer rules: Complicated; 0-RTT packets from client following
Client Initial carry client-chosen connection ID and those following the
Client Cleartext carry server-chosen connection ID.

Issues:
- no rules specified for the server to verify that the client is indeed
using the server's supplied connection ID.
- no rules specified for client to verify that the server saw its Client
Initial before sending SR/VN. (I see now that the packet number is echoed,
but we should turn this into a requirement for the client to verify. This
is what I meant by a "correlator" for the client to use to tie the
client-chosen ID to the server-chosen one.)

*Proposal #2 (newer proposal):*
Client sends Client Initial
Server sends ServerHello/Stateless Retry/Version Negotiation with new
connection ID

If server sends SHLO:
Client continues with connection, uses server-supplied connection ID
Server continues using same connection ID

If server sends SR / VN:
Client resets connection
Client sends Client Initial with server-supplied connection ID #1 (SCID1)
Server sends SHLO with new server-chosen connection ID #2 (SCID2).
Client continues sending Client Cleartext and 0-RTT packets with SCID1
When SHLO is fully received, client switches to 1-RTT packets and SCID2

Load balancer rules: Simple; 1-RTT packets use server-chosen connection
IDs, everything else uses client-chosen IDs (from the load-balancer's point
of view, even though SCID1 is actually server-chosen.)

Issue (repeating for clarity):
- no rules specified for client to verify that the server saw its Client
Initial before sending SR/VN. (I see now that the packet number is echoed,
but we should turn this into a requirement for the client to verify. This
is what I meant by a "correlator" for the client to use to tie the
client-chosen ID to the server-chosen one.)

Proposal #2 additionally has the value that no rules are required for the
server to verify that the client is indeed using the server's supplied
connection ID, since the load balancer treats SCID1 as client-chosen
anyways.

If my understanding is correct, I am back in favor of Proposal #2, because
I cannot resolve the load balancer question of 0-RTT packets with Proposal
#1. Laying it out like this makes it clearer, and I wonder if some of it
can make it into the draft. Currently, the draft does not really specify
how a server might use this degree of freedom of specifying server-chosen
connection ID in SR packets (especially with load balancing rules the way
they are intended to be), and I think it may be valuable to lay out what a
server might want to do. Should this go in the applicability draft perhaps?

- jana



On Sun, May 7, 2017 at 4:31 PM, Martin Thomson <[e-mail]>
wrote:

> On 6 May 2017 at 11:06, Jana Iyengar <[e-mail]> wrote:
> > I don't think we should add complexity to optimize an RTT for super rare
> > cases. If we could do it for no cost, that's fine.
>
> I guess that it's a matter of perspective. I consider the less complex
> case to be where the server's connection ID is always correct and the
> server can respond with a new connection ID if the client sends Client
> Initial.  That means that having Version Negotiation contain a
> server-selected connection ID is the cheap option.
>
> >> I'm not sure that I understand the advantages that this design has.
> >> You claim that it reduces the number of mechanisms to two, but I think
> >> that you end up with three because you need to use a transport
> >> parameter.  (FWIW, the current writeup essentially only has two
> >> mechanisms: NEW_CONNECTION_ID and server handshake packets, though
> >> I'll concede that there might be three of those).  It has essentially
> >> the same properties as what I've written up, but it's more complicated
> >> in several ways.
> >>
> >>
> >>
> >> The NEW_CONNECTION_ID frame implies a packet number gap.  With client
> >> authentication, the server might receive encrypted packets before the
> >> handshake completes.  If we take ekr's pull request for
> >> NEW_CONNECTION_ID, the server can't know what the gap is without
> >> receiving the handshake packets.
> >
> >
> > That's a single bit of information we can add to the frame.
>
> Yep, more complexity.
>
> >> You would instead have us switch the test to packet[0] & 0x80 == 0x80>>
> and packet[0] != 0x87 and packet[0] != 0x88, that is every long form
> >> packet except the 1-RTT ones.  I don't see any advantage there.
> >
> >
> > That's not right. Your logical expression reduces to:
> > if packet[0] != 0x87 and packet[0] != 0x88:
> >   routing = client_selected
> > else:
> >   routing = server_selected
>
> Read it again, it's not the same.  It says everything with long form
> except those two.  Though the point was poorly made: the logic isn't
> particularly relevant.
>
> > ... which is the same complexity, but it isn't the correct filter
> anyways.
> > There's a related problem that I realized with this most recent scheme:
> > Connection ID in 0-RTT packets are ambiguous. If they follow a Client
> > Initial, they're client-chosen, but if they follow a Client Cleartext,
> > they're server-chosen. I think this is a problem in your earlier version
> > too. So that's a bummer.
> >
> > You say you see no advantages. I wrote out the advantages in my previous
> > email, but perhaps you didn't see them?
> >
> > 1. Explicitly indicating the new connection ID gives the client an
> explicit
> > correlator from the client's ID to the new server one, which is better
> than
> > assuming that the 4-tuple will only carry packets for this connection.
> > Currently, the client will receive the first server packet with an
> unknown
> > Connection ID and the only correlator is the fact that it was received on
> > the same 4-tuple that the Client Initial was sent on. If you have
> multiple
> > connections on the same 4-tuple, there's no explicit correlator.
>
> OK, that didn't seem like a real advantage to me, just a rearrangement
> of the furniture.  Packets reach the client based on port/IP pairs.
>
> > 2. This mechanism (and the previous one in the current spec) have both
> the
> > server and the client changing connection IDs -- the server does it
> during
> > handshake and the client does it after it receives one or more
> > NEW_CONNECTION_ID frames. I think we can make this simpler (both in
> protocol
> > and impl) with only the client initiating this change by sending a packet
> > with a server-chosen connection ID first. If the client were the only one
> > initiating the change, this would allow the server to not care about
> doing
> > any changes mid-connection, and it could simply use the connection ID in
> the
> > largest received packet as the outgoing one.
>
> Yes, my assertion was that this isn't in fact simpler due to the need
> for special rules during the handshake.
>
> If you wanted to talk about how we might, for example, use a different
> connection ID in each direction, then I might concede that there are
> advantages in using the frame type.
>