Subject: QUIC Chrome Error with GSUITE & QUIC transport draft publication ETA

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 Jan 2020 11:13:04 -0500

QUIC WG,

We had some issues at work recently with Chrome and getting QUIC error.
The issue appears to be related to our DMZ firewalls blocking QUIC.

I believe GQUIC was working but was somehow bypassing the firewalls logging
;  but then when google switched to using QUIC IETF standard I believe
that’s when we started seeing the chrome error.

Below is an email I sent at work as an overview of QUIC and recommendations
on how to resolve the QUIC error.

Please provide me any feedback and suggestions on how to best resolve this
issue.

We use GSUITE at work which uses QUIC and we noticed all traffic to GSUITE
was using QUIC over IPV6.  We have our network infrastructure enterprise
fully dual stacked and since google URIs are all dual stacked as well ;
since IPv6 is preferred over IPv4 by default with windows ; all the GSUITE
traffic was now using QUIC over IPv6.

Has anyone else had any encounter with this scenario where they are using
GSUITE and are dual stacked and are seeing all GSUITE traffic use IPv6.

Also what is the appropriate ETA of when the QUIC transport draft will be
approved standard RFC.

——email below related to google chrome QUIC error and remediation——

What was the patch that was applied to the default silo firewalls that was
deployed.

Was the patch for QUIC support?

Also were we seeing QUIC or GQUIC being logged and dropped on the firewall?

Below is some information related to QUIC and how the protocol works:

G-QUIC was the protocol developed by google to improve and secure all web
traffic.

QUIC is the IETF standard version of the protocol.

QUIC protocol brief:

QUIC was designed to be low overhead and robust and secure by default to
eliminate issues with traditional TCP and improving transaction response
times.

QUIC provides a secure default transport using TLS 1.3 by replacing the TLS
record layer with its own framing format while keeping the same TLS
handshake.

QUIC improves head of line blocking issues with HTTP/2 which multiplexes
multiple http requests into the same TCP connection.

QUIC transport stream is delivered just as the acronym states “quick udp
internet connections” over udp instead of traditional TCP.

https://www.google.com/amp/s/blog.cloudflare.com/the-road-to-quic/amp/

Wireshark is able to decode and differentiate both G-QUIC and QUIC.

QUIC has an IETF WG which I am part of as development of standards for quic
transport protocol.

At this time QUIC transport is maturing but is still in draft state
awaiting WG Last call and IESG review and final reviews before publication
as an RFC.

Some vendors have started early adoption of the protocol.  We should reach
out to Checkpoint to see if they support QUIC.

Chrome has QUIC enabled by default.  At this time google sites such as
YouTube and GSUITE apps are the only web URIs that have QUIC protocol
enabled on the server for client/server communication to use QUIC.

QUIC IETF Draft:
https://tools.ietf.org/pdf/draft-ietf-quic-transport-24.pdf

For security reasons If the firewall and security appliances don’t support
QUIC then it is recommend to disable QUIC.

How to disable QUIC on chrome:
https://kinsta.com/knowledgebase/err_quic_protocol_error/

If Checkpoint does support QUIC I would recommend to keep it enabled as it
improves web performance and is more secure than traditional TCP.

———end email————-

Kind regards,

Gyan Mishra
Verizon Communications (VZ)
Cell 301 502-1347
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 4 Jan 2020 16:51:00 -0800

Gyan,

Firewalls that relied on gQUIC signatures to detect QUIC packets are not
going to be able to detect IETF QUIC. You should discuss specific Chrome
errors you are seeing as a result of this on the [email-masked]
mailing list.

- jana

On Sat, Jan 4, 2020 at 8:13 AM Gyan Mishra <[email-masked]> wrote:

> I believe GQUIC was working but was somehow bypassing the firewalls
> logging ;  but then when google switched to using QUIC IETF standard I
> believe that’s when we started seeing the chrome error.
>
> Below is an email I sent at work as an overview of QUIC and
> recommendations on how to resolve the QUIC error.
>
> QUIC provides a secure default transport using TLS 1.3 by replacing the
> TLS record layer with its own framing format while keeping the same TLS
> handshake.
>
> internet connections” over udp instead of traditional TCP..
>
>
> QUIC has an IETF WG which I am part of as development of standards for
> quic transport protocol.
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 Jan 2020 20:10:21 -0500

Thanks Jana!

Gyan

On Sat, Jan 4, 2020 at 7:51 PM Jana Iyengar <[email-masked]> wrote:

>> Please provide me any feedback and suggestions on how to best resolve
>> this issue.
>>
>> We use GSUITE at work which uses QUIC and we noticed all traffic to
>> GSUITE was using QUIC over IPV6.  We have our network infrastructure
>> enterprise fully dual stacked and since google URIs are all dual stacked as
>> well ; since IPv6 is preferred over IPv4 by default with windows ; all the
>> GSUITE traffic was now using QUIC over IPv6.
>>
>> What was the patch that was applied to the default silo firewalls that
>> was deployed.
>>
>> Some vendors have started early adoption of the protocol.  We should
>> reach out to Checkpoint to see if they support QUIC.
>>
>> For security reasons If the firewall and security appliances don’t
>> support QUIC then it is recommend to disable QUIC.
>>
>> If Checkpoint does support QUIC I would recommend to keep it enabled as
>> it improves web performance and is more secure than traditional TCP.
>>
>> ———end email————-
>>
>> Kind regards,
>>
>> Gyan Mishra
>> 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
>> FDC1 3rd Floor
>>
>> Silver Spring, MD 20904
>>
>> United States
>>
>> Phone: 301 502-1347
>>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347