QUIC Chrome Error with GSUITE & QUIC transport draft publication ETA

[Gyan Mishra <[e-mail]>]

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: [phone]

Email: [e-mail]

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