Re: [QUIC] Network Path Requirements for QUIC

[Brian Trammell <[e-mail]>]

hi Joe, Christian, all,

(hatless, inline reply...)

> On 16 Jun 2016, at 19:40, Joe Hildebrand (jhildebr) <[e-mail]> wrote:
> 
> On 6/16/16, 11:14 AM, "Christian Huitema" <[e-mail]> wrote:
> 
>> Joe, I think that we need state the requirements precisely. I heard a wide range of potential requirements in the MARNEW workshop, and then on the SPUD and PLUS mailing list, and then in your draft. I am concerned that general goals like "make QUIC friendly to firewalls" can derive into an endless list of feature requirements. If we write anything at all in the charter, it has to cut to the core of the issue.
> 
> We can enumerate these if you wish, but if we come up with another one that the working group wants to tackle, I’d prefer not to have to recharter.  A little bit of language saying “and similar issues” would be enough for me.

It seems to me that a lot of what we're talking about here goes to aligning the operation of QUIC with the expectations of people who actually run networks. We've got lots of running code out there that assumes that "connection-oriented Internet transport protocol" and "TCP" are synonymous. There's the code on firewalls, but that's relatively easy to patch compared to the "code" in the heads of network and system administrators. The closer the control points and network-level information available are equivalent to those available in TCP, the less friction with this existing practice. There are obvious tradeoffs in visibility and exploitability that must be evaulated, but this is engineering the WG should do. In any event, reusing people's intuition about TCP to the extent it fits with QUIC seems useful to me.

Given that, would the following change to the charter (adding one sentence to the paragraph for focus area one) be acceptable?

OLD:

The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, version negotiation, and options negotiation. Work on congestion control will describe use of an existing congestion controller as a default scheme for QUIC. QUIC is expected to support rapid iterability and experimentation, and this work will describe a versioning process that enables distributed experimentation with QUIC.

NEW:

The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, version negotiation, and options negotiation. This work will consider deployability, manageability and diagnosability of the wire format, including how the wire format will be processed by devices on path. Work on congestion control will describe use of an existing congestion controller as a default scheme for QUIC. QUIC is expected to support rapid iterability and experimentation, and this work will describe a versioning process that enables distributed experimentation with QUIC.

Indeed, I would hope that manageability and diagnosability -- which includes enabling firewalls to keep state, and making it possible to differentiate attack traffic -- are requirements for any IETF transport protocol going forward.

The discussion below, I think, needs to happen in the WG. General guidance here can come from PLUS (and indeed, I see a lot of points raised in the SPUD-derived requirements document draft-trammell-spud-req in Joe's list below), but the detailed evaluation of these aspects of how the protocol will interact with devices on path in the specific case of QUIC are a matter for QUIC. I believe the suggestion above allows that work to happen.


Cheers,

Brian


>> I heard two common requirements, "marking the beginning and end of a flow," because that helps firewalls and load balancers manage resource, and "assessing consent," because that helps differentiating between regular traffic and attack traffic. Is there more?
> 
> If you want the processing to be efficient (and not ossify something unintended), being able to separate QUIC traffic from non-QUIC UDP traffic easily would be useful.  Otherwise, path devices are likely to grab whatever version number they see as the discriminant.
> 
> If “marking the beginning of a flow” also includes being able to tell easily which side intended to initiate the conversation, then that’s fine.
> 
> The protocol needs to ensure that a path element can associate further traffic on a QUIC connection with the beginning of the flow.
> 
> There probably needs to be recommendations for time-outs, particularly around the end of the flow.
> 
> The protocol doc needs to describe what happens with associated ICMP.
> 
> The protocol needs to say what happens when a network or host receives a QUIC packet it wasn’t expecting.
> 
> We need to think about return routability.
> 
> The protocol needs to keep in mind that state will be generated in the network, so that as we add multi-path extensions (for example), we don’t just start sending traffic on a new path without first starting a new flow.
> 
> It is possible that we might want to describe what a load balancer should do when it drops QUIC state due to a timeout (or when it is *about* to drop state).  We might want it to send a hint to one or both of the endpoints, to avoid having to diagnose mid-stream black holes.  Some load TCP load balancers send RSTs in both directions in this case, for example.
> 
> We should analyze the known attacks on TCP (at least) to ensure that QUIC is not immediately vulnerable to the sorts of things we’ve already fixed over the last 40 years.
> 
> There are probably a couple of others, and I’m open to modifying the list as people see fit.  Alternately, if we can find a way to describe these kind of discussions in a way that does not bring in the explicit path communication bits that we explored in SPUD, I think the charter would be easier to understand.
> 
>>> QUIC will not be able to be deployed on some networks, such as the
>>> one I'm on right now, unless we describe the changes that are necessary
>>> for the network devices that are currently blocking it.
>> 
>> There are such networks. But there also are networks today that block outgoing TCP connections, because of some policy considerations. We don't change TCP for that. We simply accept that these networks are making a tradeoff. They care so much about some of their policies that they are willing to forego some of the value of the Internet. That's probably fine. Over time, the cost/advantage balance of the tradeoff will change, and the policies will probably evolve.
> 
> Are you saying that people will want QUIC so much that they will open their firewalls up to all UDP traffic in both directions?  Or that the terrible timing-based heuristics we have for generic UDP will be enough for a large enterprise?  Or that the current protocol description, without discussion and analysis, should be presumed to be perfect in this regard?
> 
> For once, we have a chance to do some thoughtful engineering before a protocol is fully specified to consider how it will be deployed, baking decades of learning into the design.  I think the approach that the TLS working group has been doing on TLS 1.3 to consider attack vectors, backward-compatibility, etc. is a model for what is needed from a protocol of QUIC’s potential impact.
> 
> --
> Joe Hildebrand
> 
> _______________________________________________
> QUIC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/quic