Subject: Re: Invariants draft

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Dec 2017 11:49:50 +1100

Thanks for the comments Christian.  I think that this is one of the
most important points to reach agreement on, mainly because we get
stuck with the outcome for a long time.

On Fri, Dec 1, 2017 at 3:46 PM, Christian Huitema <[email-masked]> wrote:
> As far as the general approach is concerned, your draft leaves me
> somewhat uneasy. I understand the concern to beat ossification, and to
> ensure that future developers can easily define and use extended
> versions of QUIC. But at the same time, I am concerned with the tension
> between "focusing on extensibility" and "ensuring interoperability".

I don't think that this dichotomy is - as you make it - as serious as
that.  It's a reflection of a design philosophy.

The philosophy reads like this: It's easier to design a protocol
without extensibility points.  Designing good and usable extensibility
is really hard.  So you invest your effort into designing a
replacement strategy and only add the extensibility you know that you
need.  No matter how much of the protocol you mess up, as long as you
can replace the entire protocol, you are never stuck.

When we did HTTP/2, we had ALPN.  We could have added a *lot* more
extensibility to HTTP/2 than we did, but we didn't because we knew
that HTTP/3 was always a possibility.  That raised the bar for
extensibility mechanisms, and I think we produced a better result,
more quickly for it.

For QUIC, this doc attempts to define that pivotal mechanism.  That
doesn't mean that QUIC version 2 will be substantially different.  On
the contrary, I expect that we'll make new versions with only modest
changes.  But those changes might *appear* to be significant.  The
hope is that significant changes will be possible because the protocol
won't be so ossified as to make them impossible.

You might think that this is familiar to Adam Langley's views on
extensibility.  That is "have one joint and keep it well oiled" --
<https://www.imperialviolet.org/2016/05/16/agility.html>.  That's not
coincidental.  I happen to agree, see
<https://datatracker.ietf.org/doc/html/draft-thomson-use-it-or-lose-it>.

This is part of the defense against ossification, but it's not
complete.  As Brian will point out, the actual wire image of a
protocol is what ossifies, not what we say that the wire image is.
But as you observed, we're working on improving that too.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Dec 2017 11:53:10 +1100

On Fri, Dec 1, 2017 at 5:26 PM, Mikkel Fahnøe Jørgensen
<[email-masked]> wrote:
> Thanks for writing up.
> Some input:
> Appendix A, incorrect assumptions:
> - A 5-tuple is unique to a single connection.
> - A client uses ephemeral ports.
>
> More generally: I find it unfortunate that UDP is made an invariant, anf
> possibly even IP.

That's intentional.  For instance, QUIC over DCCP would be something
else entirely and not covered by this promise.  The same applies to
layering QUIC directly on top of IP, or any imaginable substrate (like
your embedded device bus example).  Nothing we do here would prevent
those things.  Though each - as an entirely new thing - would have to
overcome its own challenges.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 4 Dec 2017 03:17:56 -0500

That is a fair point. For example it might make sense to remove UDP but
extend the type field with a routing class identifier for some networks or
use cases and such a change could still build on the UDP invariants by
stating where it differs. The same could be said about multiplexing.
Perhaps my concern is more monopolising QUIC, the name, for UDP. Thus one
could say QUIC/UDP invariants. But I also see you have to make some
boundaries for a protocol.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 4 Dec 2017 10:06:39 +0000

Well, the Transport doc is titled “QUIC: A UDP-Based Multiplexed and Secure Transport” but QUIC isn’t an anagram for Quick UDP Internet Connections anymore right? It’s more of an all-caps identifier like KFC.

From: QUIC [mailto:[email-masked]] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: 04 December 2017 08:18
To: Martin Thomson <[email-masked]>
Cc: [email-masked]; Christian Huitema <[email-masked]>
Subject: Re: Invariants draft

That is a fair point. For example it might make sense to remove UDP but extend the type field with a routing class identifier for some networks or use cases and such a change could still build on the UDP invariants by stating where it differs. The same could be said about multiplexing. Perhaps my concern is more monopolising QUIC, the name, for UDP. Thus one could say QUIC/UDP invariants. But I also see you have to make some boundaries for a protocol.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 4 Dec 2017 14:59:39 +0100

hi Martin, all,

> On 4 Dec 2017, at 01:49, Martin Thomson <[email-masked]> wrote:

<snip>

> But as you observed, we're working on improving that too.

Thanks for saying this so I don't have to. :)

This document is (1) a very clear description of (2) what seem to be to be the right set of prescriptive invariants. Thanks for putting it together! On "it's the actual wire image that ossifies", I was divided on whether or not this document should attempt to discuss "descriptive" invariants, i.e. those parts of the Version 1 wire image that are less likely to be deployably changeable in Version 2. Having read it, though, I don't think they belong here, and I think we'll actually need some deployment experience with Version 2 before we'll be smart enough to say anything definitive about what's more or less ossifiable. I'm not sure that our experience with TCP will translate very well here, especially if we can turn the crank on a Version 2 by, say, late 2019.

Indeed, I'm still a bit of a pessimist that invariants and greasing will actually work as well as we (the WG) think they will. We don't really have an experiment at Internet scale to demonstrate that greasing works at the level that QUIC proposes to use it, and the threat model it supposes for middlebox deployment behavior is ad-hoc and implicit. IMO the best way to prove all this works quickly would be to define and deploy versions 1 and 2 simultaneously, but I suspect that wouldn't have the impact on the version 1 milestones that the WG and the chairs would like to see. Might I suggest, though, that defining Version 2 milestones now (I'd suggest that "whatever is shippable in late 2019", whether that includes MP, PR, both, or neither, is a good target from a preventing ossification PoV) might make sense in terms of committing the WG publicly to exercising these mechanisms in a useful way?

Cheers,

Brian

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 4 Dec 2017 15:45:25 +0100

Hi,

> On 1. Dec 2017, at 05:09, Martin Thomson <[email-masked]> wrote:
> 
> I've just submitted a personal draft that describes the invariants
> that I think we agreed to in Singapore.
> 
> https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants <https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants>

Reading the draft, I wondered whether we should put some rudimentary amplification attack mitigation in the invariant version negation description.

Something alongside: “Don’t send a version negotiation packet in replay to a smaller packet”.

AVE!
  Philipp S. Tiesel / phils…

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 4 Dec 2017 10:10:00 -0500

Something alongside: “Don’t send a version negotiation packet in replay to
a smaller packet”.

You could imagine a QUIC version that is behind a DoS protected network
where resources are highly constrained, such as battery powered sensor
networks. They might want define a QUIC version that allows for a small
initial packet size in order to save power and to reduce latency.

Invariants should be rather conservative and only ensure that changes are
consistently possible, not reduce the design space of new versions, IMHO.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 4 December 2017 at 15.46.24, Philipp S. Tiesel ([email-masked]) wrote:

Hi,

https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants

Reading the draft, I wondered whether we should put some rudimentary
amplification attack mitigation in the invariant version negation
description.

Something alongside: “Don’t send a version negotiation packet in replay to
a smaller packet”.

AVE!

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Dec 2017 09:45:22 +1100

On Tue, Dec 5, 2017 at 12:59 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> Might I suggest, though, that defining Version 2 milestones now (I'd suggest that "whatever is shippable in late 2019", whether that includes MP, PR, both, or neither, is a good target from a preventing ossification PoV) might make sense in terms of committing the WG publicly to exercising these mechanisms in a useful way?

I'm on board for that.  Separately, it would be nice if the solution
to the QUIC/realtime multiplexing problem was to define a version of
QUIC specific to that application.  That wouldn't be as good as two
versions of QUIC-for-HTTP, but it would help.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 4 Dec 2017 14:57:10 -0800

On Mon, Dec 4, 2017 at 2:45 PM, Martin Thomson <[email-masked]>
wrote:

> > Might I suggest, though, that defining Version 2 milestones now (I'd
> suggest that "whatever is shippable in late 2019", whether that includes
> MP, PR, both, or neither, is a good target from a preventing ossification
> PoV) might make sense in terms of committing the WG publicly to exercising
> these mechanisms in a useful way?
>
> Not that the cast of characters is all that different, but do you
anticipate that being the job of this group or RTCWebBis?

Ted

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Dec 2017 09:59:58 +1100

On Tue, Dec 5, 2017 at 9:57 AM, Ted Hardie <[email-masked]> wrote:
> Not that the cast of characters is all that different, but do you anticipate
> that being the job of this group or RTCWebBis?

Much of the discussion here has happened in avtcore, who look after
SRTP (I think).  That would be a fine place, as would this group
assuming that the effort is cheap (as it should be), but that's just a
DISPATCH-style question.

---

From: Roni Even <[email-masked]>
Date: Wed, 6 Dec 2017 10:44:54 +0000

Hi,
I think that the document needs some more information about why these fields are invariants.
For example, we can have a new version with a message type that will mean that the header format from the next message changes and the connection ID will be in a different position from the next message with higher packet number.  I assume that this is not something we want if there is a need to support routing based on connection ID by intermediary who will not support this new version. So if routing support is mandatory it will be good to mention it in this document.

Roni

> -----Original Message-----
> From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: יום ו 01 דצמבר 2017 06:10
> To: QUIC WG
> Subject: Invariants draft
> 
> I've just submitted a personal draft that describes the invariants that I think
> we agreed to in Singapore.
> 
> This is just me for the moment (though Jana and Mike were very helpful in
> reviewing an even draftier draft).  It also assumes a few things about the
> current drafts that aren't yet true, and may not even become true.  Don't
> focus too much on the specific content of what is in or out, because that sort
> of detail is easy to fix.
> 
> More than content, I'd like to concentrate on the general approach and
> scope.  My hope is that we can agree that those are more or less correct.
> And then adopt the draft.  A draft like this should help address questions
> people have been asking about what can and cannot change between QUIC
> versions.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 6 Dec 2017 13:56:51 -0600

Speaking with no hats ...

On Wed, Dec 6, 2017 at 4:44 AM, Roni Even <[email-masked]> wrote:

> For example, we can have a new version with a message type that will mean
> that the header format from the next message changes and the connection ID
> will be in a different position from the next message with higher packet
> number.  I assume that this is not something we want if there is a need to
> support routing based on connection ID by intermediary who will not support
> this new version. So if routing support is mandatory it will be good to
> mention it in this document.
>

I want to thank Martin for putting together version -00 of this draft. It's
already very helpful.

When I made the suggestion to progress work on invariants as a separate
draft, I was thinking that the problem that solves, is making it easier to
update QUIC specifications without simultaneously reopening the list of
invariants and/or arguing about adding to that list.

IIUC Roni's suggestion, I'm thinking that it's also worth adding
information about why these invariants are invariant, in case we ever start
arguing about taking an invariant away.

I can easily imagine that some creative security person will, some day,
think of some way that one of these invariants can be exploited to tell a
third party something that the two endpoints didn't intend to share. If
(when?) that happens, it would be good to have a clear understanding of the
value of any invariant that's questioned, so we don't have to agree on that
while we're trying to decide what to do, after an exploit is identified.

Again, wearing no hats.

Spencer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Dec 2017 08:01:54 +1100

On Thu, Dec 7, 2017 at 6:56 AM, Spencer Dawkins at IETF
<[email-masked]> wrote:
> IIUC Roni's suggestion, I'm thinking that it's also worth adding information
> about why these invariants are invariant, in case we ever start arguing
> about taking an invariant away.

I can appreciate the desire for more detail, though the headline is
already there: we want to preserve the ability to deploy a new version
of QUIC.  The piece that is perhaps missing is one that Jana convinced
me to remove, namely the reasons for connection ID being in the draft.
Some of that is in the section on connection ID.

> while we're trying to decide what to do, after an exploit is identified.

I worry less about exploitation of the invariants, but of the
not-invariants that we inadvertently expose by virtue of only
deploying a limited number of versions.  All the stuff in the
appendix, basically.  And that is a list that I wish were shorter.