Re: [QUIC] Network Path Requirements for QUIC

["Matt Miller (mamille2)" <[e-mail]>]

To me it's clear this discussion needs to continue to happen, and needs to be in scope for the proposed WG.  To that end, I think Brian's suggested text does that and ought to be adopted.


--
- m&m

Matt Miller
Cisco Systems, Inc.

> On Jun 19, 2016, at 06:16, Brian Trammell <[e-mail]> wrote:
> 
> hi Jana,
> 
> (hatless, inline)
> 
>> On 18 Jun 2016, at 05:11, Jana Iyengar <[e-mail]> wrote:
>> 
>> 
>> 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.
>> 
>> I'm fine with adding this text. That said, I don't think this requirement that you mention for any IETF transport is clear. What state are we talking about?
> 
> The *bare minimum* here is perhaps best called "connection establishable": (1) what current practice (ab)uses SYN/ACK to mean (the server decided a given connection request was OK enough to continue) and (2) some indication that the entity that sent the first packet on an n-tuple can actually receive traffic on the source address it gave, roughly equivalent to the third ACK leg of the TCP 3WHS.
> 
> We should have a longer discussion about how much more state might be useful in the WG; that's what I hope to accomplish with my charter text proposal. But without at least this much being visible to on-path devices, QUIC will be largely incompatible with TCP-centric network management practice, which I'm afraid will come with negative consequences for deployment.
> 
>> I don't know of a clear definition of "attack traffic",
> 
> Heh. If I knew of one of *those*, that was always network visible and didn't rely on the evil bit, I'd be in a different business. :) But I think there are some basic signals a transport protocol can radiate toward devices on the path that makes it possible for such devices to reduce such traffic, as above.
> 
> Cheers,
> 
> Brian
> 
>> though I very much agree that network operators have to deal with this problem for UDP. Without concrete requirements, it's hard to define a solution in the transport.
>> 
>> - jana
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> QUIC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/quic
>> 
>> 
> 
> _______________________________________________
> QUIC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/quic