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

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

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.

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

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

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.

All best,
Kevin

Mr Kevin Smith 
Vodafone R&D

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Fri, 17 Jun 2016 09:45:14 -0700

On Fri, Jun 17, 2016 at 9:09 AM, Smith, Kevin, (R&D) Vodafone Group <
[email-masked]> wrote:

> 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.
>
>    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 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.
>
> HTTP/2.0 server push is not fully general push, and specifically does not
allow unsolicited pushes, the RFC
<https://tools.ietf.org/html/rfc7540#section-8.2.1> says "Pushed responses
are always associated with an explicit request from
   the client".

5. Identification
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

-- 
Charles 'Buck' Krasic | Software Engineer | [email-masked] | +1 (408)
412-1141