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

[Jana Iyengar <[e-mail]>]

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 [e-mail]
mailing list.

- jana

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

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