Re: Exercising Version Negotiation

[Eric Rescorla <[e-mail]>]

Hi Subodh,

I'm sorry, I'm not following you. I'm not talking about the spin bit here,
just about exercising the regular negotiation function.

-Ekr


On Thu, Mar 22, 2018 at 4:26 PM, Subodh Iyengar <[e-mail]> wrote:

> I don't think using version negotiation is as simple as it seems:
>
>
>    1. My understanding is that the current draft and the data that was
>    shown doesn't even look at the handshake negotiation and only looks at
>    short headers.
>    2. Short headers have no version. So to use version negotiation
>    correctly as a signal of the spin bit, the middlebox MUST intercept the
>    handshake negotiation.
>    3. Each 5 tuple could potentially have multiple connections and we are
>    apparently designing for that use case, so the middlebox needs to use
>    connection id
>    4. Some implementations are thinking of changing connection ids very
>    frequently, maybe in each RTT.
>
>
> Given these are we saying that when using the spin version you must not
> change the conn id per RTT so that the middlebox can observe the spin?
>
>
> Subodh
>
> ------------------------------
> *From:* QUIC <[e-mail]> on behalf of Roberto Peon <
> [e-mail]>
> *Sent:* Thursday, March 22, 2018 9:19:57 AM
> *To:* Eric Rescorla; IETF QUIC WG
> *Subject:* [Potential Spoof] Re: Exercising Version Negotiation
>
> Love it. This is a great idea!
>
> I'd suggest being more agressive with deployment,  e.g. recommend that
> servers negotiate speaking version +1 to more like 50% of the clients, and
> swap guid/ip mappings to have clients formerly using +1 switch  to -1 and
> vice versa weekly or so.
>
> -=R
>
>
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Eric Rescorla <[e-mail]>
> Date: 3/22/18 5:05 AM (GMT-08:00)
> To: IETF QUIC WG <[e-mail]>
> Subject: Exercising Version Negotiation
>
> Following up on the discussion at the mic, I do think it is useful to
> exercise the VN function, but I don't think it's useful to have those
> versions be different, because that creates perverse incentives.
>
> Here's what I suggest instead: create two versions (we can call them QUIC
> v1+i  and QUIC v1-i), each with its own code point [0]. They should be
> essentially identical except for two trivial differences, intended to
> ensure that if you screw up version negotiation, you get failed interop.
>
> - The constant in the handshake salt (5.2.2)
> - The HKDF expansion constants
>
> I suggest we handle each of these by just inverting the bits.
>
> We would then suggest to people that they somewhat randomize their
> preferences (e.g., 99% of the time prefer v1+i, 1% of the time prefer
> v1-i). This will almost always result in matching versions, but will
> occasionally result in a mismatch, thus forcing us to test VN.
>
> -Ekr
>
> [0] Obviously we can do this for draft versions. We just say that the two
> versions are
> ff0000XX and ffffffXX.
>
>
>
>
>
>
>