Questions on HTTP URI schemes and QUIC

Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com> Wed, 18 July 2018 10:50 UTC

Return-Path: <sridhar.bhaskaran@huawei.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C85313116B for <quic@ietfa.amsl.com>; Wed, 18 Jul 2018 03:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWnvdjyBPsFQ for <quic@ietfa.amsl.com>; Wed, 18 Jul 2018 03:50:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E2E131177 for <quic@ietf.org>; Wed, 18 Jul 2018 03:50:09 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D7E82306158F4 for <quic@ietf.org>; Wed, 18 Jul 2018 11:50:04 +0100 (IST)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 18 Jul 2018 11:50:06 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0382.000; Wed, 18 Jul 2018 16:19:54 +0530
From: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQ==
Date: Wed, 18 Jul 2018 10:49:53 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.148.59]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mvIRsMD4Fh65D1BX7Z2KFE-ToXY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2018 10:50:18 -0000

Dear Quic experts,

I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC transport and HTTP over QUIC, I have the following queries

1. If a HTTP URI uses http:// scheme and the origin server advertises alternate service via QUIC, can a HTTP client use QUIC to connect to the origin server and still use the http:// scheme URI?
2. If a HTTP URI uses https:// scheme and the HTTP client is configured to connect to a HTTP proxy and if the HTTP proxy supports QUIC, my understanding is the following sequence of events
	a. HTTP client to HTTP proxy QUIC connection is setup
	b. HTTP client issues a HTTP CONNECT request to the proxy with the ":authority" HTTP/2 pseudo header pointing to the origin server
	c. HTTP proxy upon getting the CONNECT request sets up a TCP connection with the origin server
	d. HTTP proxy sends HTTP CONNECT response to the client
	e. HTTP client then initiates a TLS connection towards the origin server via the proxy and the proxy simply tunnels it.
	f. Actual HTTP traffic happens between client and origin server

Is this correct?

Where I am not clear is whether step /e/ actually happens. If it does, then for step /f/ is the client required to do ciphering 2 times - one for the TLS and other for the QUIC connection to proxy itself.

Could you please clarify?

Thanks
Sridhar