Subject: Greasing the QUIC Bit

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Jul 2020 21:01:08 +1000

The QUIC Bit (aka. the bit in the first byte that is fixed to 1) is one of the few things that doesn't change in QUIC.

That's a shame, so I wrote a draft explaining how that might not need to be true forever.  This might be a little too optimistic for some, but I thought that it was worth the time needed to write it up:

https://tools.ietf.org/html/draft-thomson-quic-bit-grease-00

Mostly this is so I had something to work with while I was working out GitHub Actions.  But I am considering implementing it still.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 2 Jul 2020 08:26:44 -0400

+1 -- I like it.

  - Dmitri.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jul 2020 14:57:35 +0200

On Thu, Jul 02, 2020 at 09:01:08PM +1000,
 Martin Thomson <[email-masked]> wrote 
 a message of 7 lines which said:

> That's a shame, so I wrote a draft explaining how that might not
> need to be true forever.

Isn't it the point of draft-ietf-quic-invariants? If it is not an
invariant, it may change.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 2 Jul 2020 15:18:59 +0200

> On 2 Jul 2020, at 14:57, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Invariants is a normative declaration of what we won't change in the future. This draft is a proof of concept showing that we can keep the "QUIC bit" from being an accidental invariant (i.e., a practical invariant not normatively declared as such).

I continue to fear that the demand for on-path discrimination of QUIC traffic will remain such that if:

- there is no intentional invariant for distinguishing QUIC traffic from non-QUIC traffic by arbitrary on-path devices; AND
- there is a trivially deployable method for blocking QUIC traffic which will result in negligible end-to-end availability risk and low impact on quality of experience, i.e. that blocking will come at no cost to access networks that choose to do so (which given TCP fallback is indeed the case in the majority of networks, unless things have changed since I last looked)

then we remain at risk of a rapid reversal of fortune on deployment. Sorry, hadn't said that at a mic for about a year now, felt a need to repeat it for the record. :)

As this view is incapable of gaining consensus within this working group, I'm fully in support of this approach to greasing the QUIC bit: we should be intentional about our invariants, and back them up with running code. And this appears to be a perfectly reasonable way to do that.

Cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Jul 2020 08:35:48 -0500

Hi, Brian,

On Thu, Jul 2, 2020 at 8:21 AM Brian Trammell (IETF) <[email-masked]>
wrote:

> Invariants is a normative declaration of what we won't change in the
> future. This draft is a proof of concept showing that we can keep the "QUIC
> bit" from being an accidental invariant (i.e., a practical invariant not
> normatively declared as such).
>
> - there is no intentional invariant for distinguishing QUIC traffic from
> non-QUIC traffic by arbitrary on-path devices; AND
> - there is a trivially deployable method for blocking QUIC traffic which
> will result in negligible end-to-end availability risk and low impact on
> quality of experience, i.e. that blocking will come at no cost to access
> networks that choose to do so (which given TCP fallback is indeed the case
> in the majority of networks, unless things have changed since I last looked)
>
> then we remain at risk of a rapid reversal of fortune on deployment.
> Sorry, hadn't said that at a mic for about a year now, felt a need to
> repeat it for the record. :)
>

Thank you for the important reminder.

> As this view is incapable of gaining consensus within this working group,
> I'm fully in support of this approach to greasing the QUIC bit: we should
> be intentional about our invariants, and back them up with running code.
> And this appears to be a perfectly reasonable way to do that.
>

Before I read this ^ paragraph, I was planning to ask you whether "blocking
QUIC" merited a mention in
https://tools.ietf.org/html/draft-ietf-quic-manageability-06, because we
are in the awkward position with HTTP/3 that operators will face less
blowback blocking HTTP/3-QUIC and forcing a fallback to HTTP/2-TCP than
they will face blocking almost any non-HTTP/3 QUIC protocol (with less
clearly defined fallbacks) (see: MASQUE).

ISTM that at a minimum, the "accidental invariants" might be mentioned in
https://tools.ietf.org/html/draft-ietf-quic-manageability-06, which targets
operators.

Does any of that make sense?

Best,

Spencer

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2020 15:16:08 +0000

On Thursday, 2 July 2020 13:18:59 UTC Brian Trammell (IETF) wrote:
> ...
> non-QUIC traffic by arbitrary on-path devices; AND - there is a trivially
> deployable method for blocking QUIC traffic which will result in negligible
> end-to-end availability risk and low impact on quality of experience, i.e.
> that blocking will come at no cost to access networks that choose to do so
> (which given TCP fallback is indeed the case in the majority of networks,
> unless things have changed since I last looked)
> 
> then we remain at risk of a rapid reversal of fortune on deployment. Sorry,
> hadn't said that at a mic for about a year now, felt a need to repeat it
> for the record. :)
> 

among the SASE (secure access service edge), such as enterprise, home, and 
other privately operated networks, QUIC is going to face accidental reverse 
discrimination. UDP is privileged here, only permitted if it is recognizably 
permitted. if QUIC offers no way to be recognized, then the fortunes of its 
deployment will be moderate.

when i say privileged, i mean default-deny in both host-based firewalls and 
perimeter gateways. i hope to be able to use QUIC on such networks, but i 
won't do so if it's an all or nothing proposition-- allow any unknown traffic 
or disallow QUIC, means to me, disallow QUIC. my position will be typical 
among CISO's. if QUIC is intended only for public (ISP or mobile IP), then i 
withdraw my concern.

the QUIC bit isn't enough to hook onto, so greasing that doesn't hurt the SASE 
use case. but i think we'll all be better off if we don't have SASE networks 
using destination UDP port number as the hook for "allow this traffic".

see also:

https://techspective.net/2020/06/23/the-four-horsemen-of-sase-secure-access-service-edge/

-- 
Paul

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 2 Jul 2020 18:37:07 +0200

hi Spencer,

> On 2 Jul 2020, at 15:35, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Brian, 
> 
> On Thu, Jul 2, 2020 at 8:21 AM Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Before I read this ^ paragraph, I was planning to ask you whether "blocking QUIC" merited a mention in https://tools.ietf.org/html/draft-ietf-quic-manageability-06, because we are in the awkward position with HTTP/3 that operators will face less blowback blocking HTTP/3-QUIC and forcing a fallback to HTTP/2-TCP than they will face blocking almost any non-HTTP/3 QUIC protocol (with less clearly defined fallbacks) (see: MASQUE). 
> 
> ISTM that at a minimum, the "accidental invariants" might be mentioned in https://tools.ietf.org/html/draft-ietf-quic-manageability-06, which targets operators. 
> 

Yep; have had limited cycles of late to devote to things IETF, but Mirja and I are picking up applicability and manageability again next week (to finally sync with the core documents which I presume will not change that much in WGLC).

This is tracked in https://github.com/quicwg/ops-drafts/issues/96

Cheers,

Brian

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 2 Jul 2020 16:20:27 -0400

Martin,

Why don't you pick a TP number -- let's interop on it during the
upcoming Interop.

  - Dmitri.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 2 Jul 2020 20:38:40 +0000

Seems like the most straightforward way to grease it to be extending header protection to cover that bit as well.  It's always set to 1, but you change the mask you're using on the first byte of header protection and get instant variability, just like the reserved bits.  I'm surprised the document doesn't mention that way of implementing it, even if it's hardly the only way to achieve an "unpredictable value."

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 03 Jul 2020 10:41:08 +1000

Multi-reply, inline...

> invariant, it may change.

Indeed it is the point of that document, and we do not promise that the value is constant.  But actions are louder than words and QUIC version 1 fixes the bit, so there is the concern that the words in -invariants won't have an effect.

On Thu, Jul 2, 2020, at 23:18, Brian Trammell (IETF) wrote:
> I continue to fear that the demand for on-path discrimination of QUIC 
> traffic will remain [...]

Ack.  The question for me is how much this bit was ever likely to sufficient for that purpose.

> Why don't you pick a TP number -- let's interop on it during the

As the rules for the registries allow, the draft has a number in it.  I'll see about implementation.  It shouldn't take too long :)

On Fri, Jul 3, 2020, at 06:38, Mike Bishop wrote:
> Seems like the most straightforward way to grease it to be extending 
> header protection to cover that bit as well.  It's always set to 1, but 
> you change the mask you're using on the first byte of header protection 
> and get instant variability, just like the reserved bits.  I'm 
> surprised the document doesn't mention that way of implementing it, 
> even if it's hardly the only way to achieve an "unpredictable value."

This remains the most difficult question for me.  I spent a good amount of time thinking about this and never really reached a conclusion I was happy with.

The use of the masking to generate an unpredictable value might sound good, but it isn't good.  Unless you can meet some very particular constraints - and you disassemble your AEAD - the value of the mask depends on the value of the bit, so you can't use masking bits to decide the value.  You might save bits from the last packet for the next one, I guess, but that's just an RNG.

It's this that makes the question of masking difficult.

If you mask the bit, then you need to be sure that recipients know when it is masked.  That means you can't apply the new rule for generating the bit prior to negotiating the extension.  In practice, that means you can only realistically affect 1-RTT packets (and maybe 0-RTT packets).

If you don't mask the bit, then you can toggle the value of bit any time you think your peer might be OK with it, including for new connections.  The value you send is what is authenticated.  But that prevents you from masking the value of the bit.  Or at least it makes it much more difficult to use the bit to carry a value for which you require end-to-end confidentiality.  I can think of a couple of tricks, but they require some crypto-juju to avoid some fairly nasty costs.

In the end, not masking is easier to specify and implement, so that was the decider :)  The effect is that this is better suited to path signals than end-to-end signals.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Jul 2020 19:02:55 -0700

I am almost done implementing this in picoquic, I just have a question
about to set the quic bit if the option is negotiated

The spec says "use an unpredictable value", and I am hesitating between
three options:

1) flip a coin upon negotiation of the TP, and set all Quic Bits for the
connection to the selected value.

2) flip the bit at every packet.

3) run a random number generator for each packet.

The problem is that it has to be both unpredictable and testable.
Testable would mean "run a test connection, and check that the Quic bit
is zero some of the time". This kind of rules out the "one coin per
connection" option, because then some connections will never set the bit
to zero. Flip on every packet is testable, but is hardly unpredictable.
The RNG is a statistical test. It can still statistically fail, unless I
run the test for long connections. Also, it is hard to make it
repetitive. I will probably end up with some RNG variant, but this does
not make me too happy...

-- Christian Huitema

---

From: Dmitri Tikhonov <[email-masked]>
Date: Sun, 5 Jul 2020 16:26:53 -0400

> 3) run a random number generator for each packet.

The draft does not make it clear whether the "unpredicable value" is
per connection or per packet:

 " Endpoints that receive the grease_quic_bit transport parameter from a
 " peer MAY set the QUIC Bit to any value in packets they sent to that
 " peer.  Endpoints SHOULD set the QUIC Bit to an unpredictable value
 " unless another extension assigns specific meaning to the value of the
 " bit.

When I read it the first time around, I interpreted it as "per packet."
If one interprets it as "per connection," it makes for the most efficient
method, which would be my preference.

  - Dmitri.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 Jul 2020 10:25:32 +1000

> method, which would be my preference.

I had intended per packet, but I see how how you might interpret that differently.  I think that you achieve the desired outcome if you make it "per connection ID".  Using per connection adds a bit of entropy that can be used to link activity across paths.  Whatever scope you choose it needs to be based on something everyone knows.  Changing daily across all connections would also likely work (and would produce some interesting stats).