Re: Exercising Version Negotiation

[Subodh Iyengar <[e-mail]>]

Oh sorry i completely misunderstood what you're saying, ignore my previous email.


Subodh

________________________________
From: QUIC <[e-mail]> on behalf of Subodh Iyengar <[e-mail]>
Sent: Thursday, March 22, 2018 9:49:53 AM
To: Eric Rescorla
Cc: IETF QUIC WG; Roberto Peon
Subject: [Potential Spoof] Re: Exercising Version Negotiation


My understanding is that your proposal says that the interpretation of a particular bit in the public header is determined by the version, i.e. the server and client will negotiate a particular version if they need a spin bit. What I was saying is that if that is true, the middlebox needs to look at the negotiated version and hence creates the aforementioned concerns.


Subodh

________________________________
From: Eric Rescorla <[e-mail]>
Sent: Thursday, March 22, 2018 9:45:14 AM
To: Subodh Iyengar
Cc: Roberto Peon; IETF QUIC WG
Subject: Re: Exercising Version Negotiation

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]<mailto:[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]<mailto:[e-mail]>> on behalf of Roberto Peon <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[e-mail]<mailto:[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.