RE: Questions on HTTP URI schemes and QUIC

Sridhar Bhaskaran <> Thu, 19 July 2018 03:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D9AB130ED3 for <>; Wed, 18 Jul 2018 20:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mg5x9Ir-krbv for <>; Wed, 18 Jul 2018 20:40:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE27112D949 for <>; Wed, 18 Jul 2018 20:40:17 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id CEF024537DB4B for <>; Thu, 19 Jul 2018 04:40:14 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 19 Jul 2018 04:40:15 +0100
Received: from ([]) by ([::1]) with mapi id 14.03.0382.000; Thu, 19 Jul 2018 09:10:02 +0530
From: Sridhar Bhaskaran <>
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kA=
Date: Thu, 19 Jul 2018 03:40:02 +0000
Message-ID: <>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jul 2018 03:40:21 -0000

Thank you Lucas and Patrick for the clarification. The hint-helium presentation was very useful. It was just pure co-incidence of me asking this question. I did not attend the session in IETF 102.

For the background, 3GPP CT4 is doing a study on the use of QUIC as transport protocol for the 5G control plane interfaces. The 5G control plane interfaces use HTTP APIs (HTTP/2 over TCP) in 3GPP Release 15. The objective of this new study is to look into the benefits of replacing TCP with QUIC from Release 16 onwards.

I am the rapporteur for that study. The study objectives can be found at

In 5G control plane architecture there is a network function called "Security Protection and Edge Proxy - SEPP" which sits at the edge of each PLMN (an operator's network) connecting the network functions of one PLMN with the other PLMN. I was wondering how http:// and https:// scheme APIs would work when SEPP, as a proxy, supports QUIC and the network functions in the two PLMNs support QUIC and they communicate via SEPP which is a HTTP/QUIC proxy. Looks like this latter scenario is bit challenging as there is no standard means as highlighted in slide 6.

Note that this SEPP is not a blind forwarding proxy. It does message transformations based on operator policies. So as highlighted in slide 8 SEPP's role is "in the loop". 


-----Original Message-----
From: Lucas Pardue [] 
Sent: Wednesday, July 18, 2018 7:22 PM
To: Sridhar Bhaskaran <>; IETF QUIC WG <>
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

I presented some slides [1] about HTTP proxying (including HTTP over QUIC) at the IETF 102 HTTPbis session this week. I'm not sure if your questions are motivated by that session, or if it is coincidence. There are some visualisations of the various tunnelling options (as I understand them) across the main slides and backup slides.


[1] -

>-----Original Message-----
>From: QUIC [] On Behalf Of Sridhar 
>Sent: 18 July 2018 11:50
>Subject: Questions on HTTP URI schemes and QUIC
>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?