Re: [QUIC] Network Path Requirements for QUIC

[Jana Iyengar <[e-mail]>]

>
>
> 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? I don't know of a clear definition of "attack traffic", 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
>
>