Subject: Re: [QUIC] Welcome to QUIC

From: "Mishra, Sanjay" <[email-masked]>
Date: Fri, 14 Oct 2016 14:43:54 -0400

I have a question on the clarity of text around network management practices as stated in the charter:

Text from the QUIC charter:

Current practices for network management of transport protocols
include the ability to apply access control lists (ACLs), hashing of
flows for equal-cost multipath routing (ECMP), directional signaling
of flows, signaling of flow setup and teardown, and the ability to
export information about flows for accounting purposes. The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions
described in RFC 7258.

The efficacy of WG's consideration on  striving to achieve a balance consistent with tension described in RFC 7258 may find that its hands are tied given the charter text "The QUIC protocol need not be defined to enable each of these abilities...". I may be missing, but what other mechanisms in the charter help ensure working group can guide to an outcome consistent RFC 7258? Specifically, the statement from RFC 7258 that says "Making  networks unmanageable to mitigate PM is not an acceptable outcome,  but ignoring PM would go against the consensus documented here."

Thanks
Sanjay

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Eggert, Lars
Sent: Monday, October 10, 2016 4:46 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [E] [QUIC] Welcome to QUIC

As some of you have no doubt seen, QUIC is now chartered as am IETF Working Group:

https://datatracker.ietf.org/wg/quic/charter/

Welcome!

As a reminder, as an IETF list, activity here is covered by the NOTE WELL terms; for more information, see:

https://www.ietf.org/about/note-well.html

This WG *will* be meeting at the Seoul IETF; we'll have a draft agenda out for comments soon, but we expect to go over the charter and the input documents there. If you have not already, please familiarise yourself with all of them beforehand.

Our milestones are on an aggressive schedule, so we will be having a number of Interim meetings (as highlighted in the charter). Details will be forthcoming soon, but at this point we anticipate having at least three standalone Interims in 2017, roughly half-way between the IETF meetings (with the first in the mid-January to mid-Feburary timeframe), with the potential for Interims held adjacent to the three IETF meetings as well (in addition to meeting during the Plenary weeks, of course).

As many other WGs have, we plan on using Github <https://github.com/> as the repository for our documents and issues list(s). Best practices for using Github in IETF work are still evolving, but we will take appropriate steps to assure that a) no information is "locked" into Github, and b) it is possible to participate without disadvantage if you choose not to create a Github account. If this causes you concern, please contact the chairs.

We'll be in touch soon with more information, but in the meantime, please continue to discuss the documents and implementation of them on the list. We look forward to working with all of you.

Regards,

Lars Eggert and Mark Nottingham, QUIC Working Group Chairs
_______________________________________________
QUIC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/quic

---

From: Brian Trammell <[email-masked]>
Date: Fri, 14 Oct 2016 23:08:17 +0200

hi Sanjay,

> On 14 Oct 2016, at 20:43, Mishra, Sanjay <[email-masked]> wrote:
> 
> The efficacy of WG’s consideration on  striving to achieve a balance consistent with tension described in RFC 7258 may find that its hands are tied given the charter text “The QUIC protocol need not be defined to enable each of these abilities…”. I may be missing, but what other mechanisms in the charter help ensure working group can guide to an outcome consistent RFC 7258? Specifically, the statement from RFC 7258 that says “Making  networks unmanageable to mitigate PM is not an acceptable outcome,  but ignoring PM would go against the consensus documented here."

Since many of the words you seek to clarify come from language helped write to be added to the charter, let me try to clarify the intent, and explain what I see as the way to ensure an outcome consistent with 7258's recognition that realization of the extent of large-scale pervasive surveillance does not change the fact that manageability is a first-order requirement of network protocols.

Since much of the controversy on this point at the BoF was that "network management and operations" was too vague, we wanted to be concrete about what kinds of network management practices should be considered in designing a new transport protocol. The five chosen are widely deployed, well understood, and relatively uncontroversial.

A requirement to support every one of these operations exactly as they are presently supported by TCP would constrain the QUIC design space too tightly: it would have to look and behave exactly like vanilla TCP on the wire. We already have a transport protocol that does that. It's called TCP.

QUIC has one advantage that TCP doesn't: it can fall back to TLS over TCP. Indeed, it is defined in such a way that applications that cannot handle a fall back to TLS over TCP cannot run over it. We have to do this to handle UDP blocking (relatively common, about 5%) and other performance impairment (much rarer, still present). I personally think that this should be seen as the starting point of an indefinite transition, as opposed to a permanent convenience; the latter risks stalling the deployment of the protocol. (Fallbacks are great for reliability but terrible for ensuring deployment. Case in point, I'm a huge fan of Happy Eyeballs, but last time I looked about 10% of the sites in the Alexa top million that bothered to publish AAAA records had them point to nonsensical places, or weren't listening where they thought they were. Happy Eyeballs means nobody notices, so these problems never get fixed.)

But IETF-standard QUIC doesn't exist yet, in-network devices that support these management functions in probably-somewhat-TCP-like but not-TCP-wire-compatible don't either. They'll have to be developed in tandem with the protocol. And if the working group finds that there is a tradeoff -- for example, the working group may find that either flow directionality or flow setup and teardown signaling needs to be impaired or removed to meet some other more important requirement. Indeed, either directionality signaling or end signaling is probably enough to do most of what most firewalls need at layer 3/4. This text gives the working group the flexibility to do that without rechartering.

So I would interpret the text to mean that the working group must consider operations and management functions in the design of the protocol, especially how the protocol interacts with devices other than the endpoints for these five management functions, and needs good reasons to trade off against supporting them in the final protocol design. I would not interpret this text to mean "QUIC may be defined to enable *none* of these abilities".

Hope this helps, cheers,

Brian

> To: [email-masked]
> [email-masked]
> [email-masked]

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Mon, 17 Oct 2016 14:15:12 -0400

Hi Brian --

Thanks for the detailed response and clarification to the charter text. 

-Sanjay

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Friday, October 14, 2016 5:08 PM
To: Mishra, Sanjay
Cc: Eggert, Lars; [email-masked]
Subject: [E] Re: [QUIC] Welcome to QUIC

hi Sanjay,

> enable them in the same way as they are enabled by TCP when used with 
> TLS 1.3, but the working group must consider the impact of the 

Hope this helps, cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 20 Oct 2016 00:26:14 +0200

Hi, all,

A couple of days ago, in a thread on the network management paragraph in the charter, I wrote:

> Indeed, either directionality signaling or end signaling is probably enough to do most of what most firewalls need at layer 3/4.

We've just posted a short draft on the signaling required to drive a generic, transport-independent state machine for flow-state-keeping network devices, as part of the PLUS effort:

https://tools.ietf.org/html/draft-trammell-plus-statefulness

Aside from the ability to associate packets to flows (generally via their five-tuple), this approach requires only an association signal (to indicate a receiving endpoint is interested in keeping a connection open) and a stop signal (to indicate either endpoint is shutting the connection down, and that state should be freed). Depending on how the association signal is encoded, it might also provide information about the directionality of a flow.

We note that QUIC in its current state would need only very small changes to support this state machine: the Connection ID already works as an association signal (albeit without directionality), and the Public Reset facility could be repurposed as a stop signal, if exposed on every association shutdown, as opposed to just abnormal ones.

This would be a first step toward the fulfillment of the charter goal to ensure that QUIC is manageable; especially as "flow setup and teardown" signaling is one of the example functions mentioned directly in the charter.

Cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Oct 2016 13:36:54 +1100

You say:

   QUIC's cryptographic protocol, to be based on TLS
   [I-D.thomson-quic-tls], will provide the necessary integrity
   protection to drive the state machine.

This isn't currently true.  Any signal that you create will
necessarily be outside of the confidentiality protection envelope.  We
would have to change the packet protection structure so that was added
to the AAD.  We currently do not use the AAD, so it's a kinda big
change.

I like the formulation of the association signal idea.  This means
that you only need to include a connection ID in packet 0.  This
covers the current mechanism (connection ID in initial packets and the
combination of shorter or absent connection IDs and the 5-tuple in
later packets).  It also suggests the possibility that you might do
other things that make things easier or harder depending on where you
sit.

One possibility is that we could make it difficult to trace backwards
along a flow.  We could even make it impossible to trace a flow
without packet 0..n.  Of course, I can't imagine a use case for
either.  It does suggest that there's a trade-off here though.

One thing I'd like to see made a lot clearer is that you are talking
about a single flow.  There is no requirement for the network to be
able to identify packets across disparate flows as belonging to the
same connection (for multipath or even just for mobility).  I can
imagine no good reason to have on-path adversaries being able to
correlate flows on different paths (yep, that's a challenge folks, let
the counterarguments fly).  The main reason being that correlation
across flows would defeat some of the traffic analysis defenses we are
considering.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 20 Oct 2016 12:19:20 +0200

hi Martin, all,

> On 20 Oct 2016, at 04:36, Martin Thomson <[email-masked]> wrote:
> 
> You say:
> 

Right, but aren't all the QUIC header bits also integrity-protected?

> that you only need to include a connection ID in packet 0.

You *could* do this, at the expense of having to do a fast-reset (resending the connection ID, to cause a connection ID echo) if you detect connection disruption due to state loss (restart) of a device on path. This is no better than the behavior of TCP with stateful firewalls that need to see a SYN.

> This

Yep. We tried to define association signals in the abstract to carry the *minimum* possible information. If a protocol piggybacks association on other information it radiates, there are of course tradeoffs in the other things you want to do with that information.

> either.  It does suggest that there's a trade-off here though.

Yep.

> about a single flow.

Hm, I was pretty sure that was already pretty clear, what with leading off the terminology section with the definition of a Flow cribbed from 7011. Text suggestions welcome :)

> There is no requirement for the network to be

Agreed completely, noting that traffic analysis defense is extremely hard to do if you have latency and bandwidth efficiency requirements too. That's not a reason to make it easier for no reason, though.

Cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Oct 2016 21:43:16 +1100

Lifting a choice piece.

> Right, but aren't all the QUIC header bits also integrity-protected?

Let's quickly assess these:
1. connection ID - routing critical, so I didn't see a need for
protection (though we would roll it into the handshake if it was
needed - most fall into this category)
2. version - rolled into the handshake
3. sequence number - forms the nonce (see TLS for analysis of this)
4. public reset etc...  - can't

I realize now that I didn't write down the analysis of the first, so
that could be wrong.

Just thinking about this, if you signal end-of-flow in the clear and
use the same techique for integrity as the version (corroboration
rather than a cryptographic device), you can watch for a close_notify
alert in the TLS to corroborate the cleartext signal.

But that leads me to ask: how do you signal end-of-flow here?  The
close_notify will be reliable and therefore subject to repair.  But if
the middlebox sees the first close_notify with the cleartext
end-of-flow marker, your model has it transition immediately to the
zero state.  I don't think that's a good outcome.

If the close_notify is actually lost we don't have an authenticated
end to communications.  Sure, that's much less of a problem from a
robustness perspective with the solid stream semantics in h2/quic, but
it might lead to clients attempting to repair a connection that is
unwanted.

Enter TIME_WAIT.

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 20 Oct 2016 07:11:22 -0700

> Right, but aren't all the QUIC header bits also integrity-protected?

Yes indeed. All of the public QUIC header bits are integrity protected with
the current code. I believe the plan with TLS is to provide the same
integrity protect, just using the key derived during the TLS handshake. Of
course, this only applies to post-handshake packets. ​

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 24 Oct 2016 19:15:59 -0400

> I realize now that I didn't write down the analysis of the first, so

Cryptographically binding QUIC connection ID would be nice as an extra
protection
against possible confusion attacks.

I agree with you that for the most of the values in the public header
altering
them would result in either routing or decryption failure.  In the future,
we
might want to add values which we want everyone to read but want to
authenticate between endpoints too (like the connection close signal).  I
feel
like setting the AAD to the bytes of the public header is a fairly robust
construction that solves this problem for any of the potential changes we
make.
It should be easy to implement, and most of the implementations already
have to
do AAD in TLS 1.2, so presumably there should not be any extra crypto code
to
write here.