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

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 14 Jun 2016 19:39:57 +0000

On 6/14/16, 1:23 PM, "QUIC on behalf of Joe Hildebrand (jhildebr)" <[email-masked] on behalf of [email-masked]> wrote:

>Please read the draft.  I hope we're not suggesting particular design approaches.  If we are, we'll change the draft.  What I hope we're raising is a set of potential requirements to start the discussion of exactly what you're proposing: what goes inside and outside the crypto veil.  Anything that we expose will ossify immediately.  Anything that we don't expose may still ossify, but it even less predictable ways.

but *in* even less predictable ways.  Sorry for the typo.

-- 
Joe Hildebrand

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Mon, 20 Jun 2016 09:27:03 +0000

Hello Mark,

>>>> 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.

>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. 

Yes, that's right - fair point.

>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.

Yes, my mistake on nomenclature. I'm rather thinking of pushes stemming from Push API/Notification API growing in popularity, but then these involve explicit permission ('assured consent') and so are not unsolicited. 

Thanks for the clarifications!

Cheers
Kevin

Mr Kevin Smith 
Vodafone Group R&D