Re: draft-duke-quic-load-balancers-05.txt

[Martin Duke <[e-mail]>]

Hi Sowmini,

Thanks for the review. I'll file a PR for your editorial changes.

Responses inline:

On Mon, Oct 28, 2019 at 12:50 PM Sowmini Varadhan <[e-mail]>
wrote:

>
> <snip>
> - Section 3.2: Config rotation is one octet (per Section 3.3) and
>   there are 2 bits for config rotation, so it is confusing when Section 3.2
>   says
>  361    received these, it MUST generate connection IDs with the config
>  362    rotation bits set to '0b11' and MUST use the "disable_migration"
>   (0b11 is 2 bytes? In general, it would help to provide more context about
>   what/when/how this can happen, and why it is needed)
>

0b11 is 2 bits. The '0b' notation indicates each digit is a bit; '0x' would
be hexadecimal, where 2 characters = 1 Bytes.


>
> - Section 4 ("Routing Algorithms"). The 0-RTT can have application data.
>   Given that Section 4 discusses an "alternate algorithm" for 0-RTT,
>   is it possible that the data from 0-RTT gets routed differently than
>   the remainder of the packet?
>

In section 4, it says: " The load balancer SHOULD route Initial and 0-RTT
packets from the client using an alternate algorithm". The point here is
that the destination CID for these packets is chosen by the client. It may
not be long enough to apply the chosen algorithm, so something else should
be done. However, " This algorithm SHOULD generate consistent results for
Initial and 0RTT packets that arrive with the same source and destination
connection ID" so they all end up at the same place. If the LB doesn't do
this, then the 0RTT packets will be lost. This is suboptimal but doesn't
break the protocol.

<snip>

>
>
> - Section 4.3.1 refers to "token". Is this the token from the Initial?
>   From the Retry? The LB is just a service in the middle, between the
>   2 quic endpoints, so it would help to explain which token to use.
>   To be clear, I am referring to:
>  604    The load balancer decrypts the server ID using 128-bit AES
> Electronic
>  605    Codebook (ECB) mode, much like QUIC header protection.  The nonce
>  606    octets are padded to 16 octets using the as many of the first
> octets
>  607    of the token as necessary.  AES-ECB encrypts this nonce using its
> key
>  608    to generate a mask which it applies to the encrypted server id.
>
>
This is the QUIC-LB authentication token, which I should clarify. In any
case, I don't believe that servers get this token if there's out-of-band
configuration, so I need to fix this.


>
> - Editorial: s/decrypts/encrypts in second paragraph of Section 4.3.2:
>  631 4.3.2.  Server Actions
>   :
>  640    The server decrypts the server ID using 128-bit AES Electronic
>  641    Codebook (ECB) mode, much like QUIC header protection.  The nonce
>
> - Section 5: this one was particularly hard for me to read. I think it
>   would help if this section of the draft hsd a top-level discussion on
>   why this is needed (i.e., what are the sort of things that can go
>   wrong if it is not there? Also, in Figure 5, why do we need to encode
>   ODCIL and ODCID in the Retry token, given that they are already there
>   in the Retry packet itself?)
>

This is for the benefit of the QUIC server. When the server gets an Initial
Packet with a Retry token in it, it needs to extract the ODCID from that
token so that it can send it back in a transport parameter. If the client
got a Retry but then doesn't get the ODCID transport parameter, it means
there's an unauthorized man in the middle and the client should terminate
the connection.



>
> --Sowmini
>