Re: Is "Version Greasing" a new benfit or a new obstacle?

[G Fairhurst <[e-mail]>]

Bringing this thread back - to me it seems there has been lots of 
discussion about how "version greasing" can be added in various ways, 
and very little on what makes this necessary and worth the impact on the 
network.

I still don't do not see that the side effects are worse when the 
protocol requires the version to be unobfusticated (as in most other 
IETF transport protocols).

Gorry


On 12/04/2019, 17:41, Roberto Peon wrote:
>
> I’m not sure that I agree there—there is no need to have it 
> standardized so long as the LB is involved in picking it. Each LB 
> system can choose whatever it wants. Thus, every LB **deployment** 
> could use a different scheme with different grease. Every LB 
> deployment could change the scheme it uses pseudo-randomly or 
> according to the lunar calendar, etc.
>
> Because there is a dynamic (and controlling) component (namely the 
> part of the LB system which vends and then later routes CIDs), there 
> is no need for anything else.
>
> -=R
>
> *From: *Praveen Balasubramanian <[e-mail]>
> *Date: *Friday, April 12, 2019 at 9:28 AM
> *To: *Roberto Peon <[e-mail]>, Christian Huitema 
> <[e-mail]>, Ian Swett <[e-mail]>
> *Cc: *"Gorry (erg)" <[e-mail]>, Mirja Kuehlewind 
> <[e-mail]>, Mikkel Fahnøe Jørgensen 
> <[e-mail]>, "[e-mail]" <[e-mail]>, "Border, John" 
> <[e-mail]>
> *Subject: *RE: Is "Version Greasing" a new benfit or a new obstacle?
>
> Re. Encoding in CID. Then it needs to be standardized and if it is 
> standardized what’s the point in greasing? Let’s not ignore the 
> smaller services who use the cloud i.e. people deploying say NGINX web 
> servers in AWS, Azure or GCP. Not every QUIC deployment is a large 
> first party service which controls all aspects how LB and DDoS are 
> done. In public clouds LB and DDoS protection are network functions 
> (services) and are middleboxes under a completely different 
> administrative domain.
>
> Christian, this is about source address validation by the middlebox. 
> This is how it works for TCP (think SYN cookies) and we need to have 
> parity for QUIC. When under attack, short header packets will be 
> dropped for addresses that have not been validated, but this is the 
> same for non-SYN packets for TCP. I don’t understand how invariants 
> can be used here. If we don’t have parity for DoS protection in 
> network then QUIC traffic will be rate limited which is going to be 
> really bad for performance. FWIW there is already DoS traffic that 
> looks like QUIC.
>
> *From:* Roberto Peon <[e-mail]>
> *Sent:* Friday, April 12, 2019 9:16 AM
> *To:* Christian Huitema <[e-mail]>; Ian Swett 
> <[e-mail]>; Praveen Balasubramanian <[e-mail]>
> *Cc:* Gorry (erg) <[e-mail]>; Mirja Kuehlewind 
> <[e-mail]>; Mikkel Fahnøe Jørgensen 
> <[e-mail]>; [e-mail]; Border, John <[e-mail]>
> *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle?
>
> For any large deployment, I suspect they’ll need LB.
>
> For most kinds of LB-ing, I’d expect the LB system to either directly 
> or indirectly be involved in choosing/vending connection IDs.
>
> If it is involved in vending/choosing connection IDs, it can encode 
> version information into the CID.
>
> -=R
>
> *From: *Christian Huitema <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Friday, April 12, 2019 at 9:13 AM
> *To: *Ian Swett <ianswett=[e-mail] 
> <mailto:ianswett=[e-mail]>>, Praveen 
> Balasubramanian <pravb=[e-mail] 
> <mailto:pravb=[e-mail]>>
> *Cc: *"Gorry (erg)" <[e-mail] 
> <mailto:[e-mail]>>, Roberto Peon <[e-mail] 
> <mailto:[e-mail]>>, Mirja Kuehlewind 
> <[e-mail] 
> <mailto:[e-mail]>>, Mikkel Fahnøe Jørgensen 
> <[e-mail] <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, 
> "Border, John" <[e-mail] <mailto:[e-mail]>>
> *Subject: *Re: Is "Version Greasing" a new benfit or a new obstacle?
>
> On 4/12/2019 8:57 AM, Ian Swett wrote:
>
>     *From:* Praveen Balasubramanian
>     *...*
>
>     Version greasing will create problems for DDoS protection. The
>     DDoS protection middlebox will have to treat all traffic with
>     unknown version numbers as plain old QUIC and rate limit it. Any
>     solution that requires per connection state to track version
>     numbers doesn’t scale. Especially in the cloud scenario customers
>     bring their own web servers so this makes any opt-out solution not
>     good enough. So I do think this is an obstacle for many deployments.
>
> Don't we have an example of middle-box ossification just there?
>
> Praveen's example points to the perils of the "shortest path" approach 
> to middle-box design. Taking the shortest path means finding something 
> that works now, and once you have found it deploy it without worry 
> about consequences -- which very often include ossification. If the 
> DDOS protection box looks for "QUIC versions that it knows" and just 
> rate limits the other types of packets, then the box will by design 
> prevent deployment of versions that it does not know.
>
> I assume that big organizations like Azure will update their 
> protections once a new version is out, but the experience shows that 
> many other organizations don't. And even when they do, the focus on 
> published versions will block experimenting with new versions, not to 
> mention interfering with other features like connection migration. I 
> take Praveen's example as an argument why we should in fact 
> standardize version greasing, precisely to avoid this "shortest path 
> middle-box design".
>
> In the case of DDOS protection, I will point out that DDOS protection 
> also needs to work with short header packets, which do not carry any 
> version number. In order to avoid DDOS by short header packets, the 
> boxes have to be able to distinguish between packets that belong to 
> authorized connections and packets that don't. And if you do that, 
> then you don't really need to look at the version numbers, you can 
> simply rely on the invariants.
>
> -- Christian Huitema
>