Subject: Re: [QUIC] Network Path Requirements for QUIC

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 17 Jun 2016 19:53:35 +0000

On 6/17/16, 10:09 AM, "QUIC on behalf of Smith, Kevin, (R&D) Vodafone Group" <[email-masked] on behalf of [email-masked]> wrote:

>Dan and Joe, many thanks for drafting this.
>
>>1.  Introduction
>> Unfortunately, the lack of header information in QUIC prevents the network path from identifying QUIC
>   traffic 
>
>Well, it's not _prevented_ from being identified by a network probe, because of the QUIC public flags: but yes, an IANA protocol number for the IP header would indeed help get QUIC through anti-UDP firewalls and make the QUIC distinction from other UDP faster.

I’m worried about the real-world deployability of a new protocol number.  That’s something that will require both endpoint kernel changes as well as lots of network equipment changes.  We’ve learned from SCTP that just having a better protocol has not been enough to overcome that set of limitations at Internet scale.

The QUIC public flags may or may not be enough to distinguish QUIC traffic from other traffic on the same UDP destination port.  That is useful analysis for a potential working group to pursue, and it should be in scope in the charter.

>> 3.  Association with Existing Consent
>> [...] If QUIC does not allow the path to associate packets with a consent at greater assurance
>   than just matching the 5-tuple (relying on the endpoint software to filter all attacks) the network cannot filter attacks such as denials of service.
>
>The public ConnectionID should allow that assurance, no? Or do you mean specifically at the firewall which may not be looking beyond IP headers?

The ConnectionID may be enough for this, if we can tell which direction the connection attempt is going, particularly in all of the edge cases, and while the protocol is under attack.  There might need to be some text in the document that describes how you tell which end is the client, and then when and how to maintain and match the ConnectionID in the network.  Or there may not.  But a potential working group should be able to do that analysis.

>> 4.  Long-lived Connections and HTTP Server Push
>The public ConnectionID could help here as well, to detect a QUIC connection and allow a longer-lived firewall pinhole. But again this depends on the firewall capability.
>
>Please can you expand on the HTTP Server Push case? Currently our firewalls allow UDP for network-attached device requests, which open a firewall pinhole for a set time. Unsolicited UDP pushed from the Internet will be subject to blocking or rate-limiting, so assuring the consent is important here.

I’m envisioning that your firewalls will be able to treat QUIC connections very similarly to how you treat TCP connections, in terms of security, but without as much insight into the congestion and retransmission properties.  We don’t yet have analysis that suggests that it’s possible to do this, however, and a potential working group should be able to have that discussion.

>5. Identification
>> Recommendation: Provide path-visible mechanism to identify a QUIC packet.
>Specifically I'd like that in the IP header (i.e. IANA number) for performance.
>
>(and from a later point by Joe:)
>> The protocol needs to say what happens when a network or host receives a QUIC packet it wasn't expecting. 
>
>Yes, and knowing quickly that it is a _QUIC_ packet certainly helps.

Nod.  We currently have a QUIC version number that’s visible, but that version number will change over time.  The analysis that we did for the SPUD prototype showed that the magic number we picked rendered SPUD packets distinguishable from the existing widely-deployed UDP protocols.  Similar analysis should be done for QUIC by a potential working group.

-- 
Joe Hildebrand

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jun 2016 14:19:34 +1000

> On 18 Jun 2016, at 5:53 AM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
> 

The Server Push mention here seems spurious; I think you're trying to talk about the issues with long-lived, idle / "long polling" styles of communication, not specific to Server Push. 

The biggest current use cases for Server Push are around avoiding a RT to fetch a pages' assets; WebPush is using it for long polling, but that's relatively obscure, so referring to Server Push here is going to confuse people.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 20 Jun 2016 20:35:57 +0000

>The biggest current use cases for Server Push are around avoiding a RT to fetch a pages' assets; WebPush is using it for long polling, but that's relatively obscure, so referring to Server Push here…

Agree.  I had actually translated that in my head into websockets, webpush, and XMPP over QUIC.  Each of those are more concrete than what is currently in the draft; we’ll do what we can to make it more easily comprehensible in a future version.

The important part is that QUIC connections might last a long time.  Right now, section 8.10 of the draft says that by default, you send a ping “after 15 seconds of quiescence, which is much shorter than most NATs time out”.  Does this mean 15 seconds since I last received data?  15s since I last sent data If I’m a network device tracking QUIC state, should I take 16 seconds of quiescence as an implicit shutdown?  This is an example of the sort of thing we could discuss.  

-- 
Joe Hildebrand