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

Gyan Mishra <hayabusagsm@gmail.com> Sun, 05 January 2020 01:10 UTC

MIME-Version: 1.0
References: <CABNhwV28q_3VfgNUCBqGHCpNbyMH8bewkND7_aX5DnsKF52K6Q@mail.gmail.com> <CACpbDcdmT4Qk5FW-OnKhcbCjWSDrSr16ug201rCyJT_fMvdCVQ@mail.gmail.com>
In-Reply-To: <CACpbDcdmT4Qk5FW-OnKhcbCjWSDrSr16ug201rCyJT_fMvdCVQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 04 Jan 2020 20:10:21 -0500
Message-ID: <CABNhwV2TcS_6s+PJrdmcwiTGasUoQDiuATU57Eysc27nX13V1w@mail.gmail.com>
Subject: Re: QUIC Chrome Error with GSUITE & QUIC transport draft publication ETA
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000934581059b5a35ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iT9B4fqwoKM3rdjp4OV8nChWE3Y>
Precedence: list

Thanks Jana!

Gyan

On Sat, Jan 4, 2020 at 7:51 PM Jana Iyengar <jri.ietf@gmail.com> wrote:

> 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 proto-quic@chromium.org
> mailing list.
>
> - jana
>
> On Sat, Jan 4, 2020 at 8:13 AM Gyan Mishra <hayabusagsm@gmail.com> 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
>> <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
>>
>> Email: gyan.s.mishra@verizon.com
>>
>> www.linkedin.com/in/networking-technologies-consultant
>>
>> --

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: gyan.s.mishra@verizon.com

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

QUIC Chrome Error with GSUITE & QUIC transport dr… Gyan Mishra
Re: QUIC Chrome Error with GSUITE & QUIC transpor… Jana Iyengar
Re: QUIC Chrome Error with GSUITE & QUIC transpor… Gyan Mishra