RE: Questions on HTTP URI schemes and QUIC

Sridhar Bhaskaran <> Wed, 25 July 2018 08:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C818C130E51 for <>; Wed, 25 Jul 2018 01:44:19 -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 CPTuuNzFkE_I for <>; Wed, 25 Jul 2018 01:44: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 E8589130DC6 for <>; Wed, 25 Jul 2018 01:44:17 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id E811DBA222ED1 for <>; Wed, 25 Jul 2018 09:44:13 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 25 Jul 2018 09:44:15 +0100
Received: from ([]) by ([]) with mapi id 14.03.0382.000; Wed, 25 Jul 2018 14:14:05 +0530
From: Sridhar Bhaskaran <>
To: QUIC WG <>
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QAA8EpoAAIxU/UP//4IKA//+hFRCAAHZzAP//npFg
Date: Wed, 25 Jul 2018 08:44:04 +0000
Message-ID: <>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <> <> <> <>, <> <7CF7F94CB496BF4FAB1676F375F9666A3BB799EE@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB799EE@bgb01xud1012>
Accept-Language: zh-CN, 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: Wed, 25 Jul 2018 08:44:20 -0000

Hi Luca / all,

I will take this offlist as this getting more into URI design, 3GPP API design discussion which is not of interest to quic transport group.

Thanks all for the valuable feedback so far.

With this I am concluding the thread on this mailer list.


-----Original Message-----
From: Lucas Pardue [] 
Sent: Wednesday, July 25, 2018 1:54 PM
To: Sridhar Bhaskaran <>; Martin Thomson <>; QUIC WG <>
Cc: Ted Hardie <>
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

What is the relationship between PLMN A and PLMN B? Is this "the public Internet" or more a collection of operator networks? If there is a coordinated handoff then, although operating in different trust domains, it seems feasible for the SEPPS to trust each other. Is that not the case?

Trust of course requires some provisioning/orchestration of services at a system level but from the client perspective,  HTTP clients at any point in the chain could believe they are in communication with the final target server.

From: QUIC [] on behalf of Sridhar Bhaskaran []
Sent: 25 July 2018 08:20
To: Martin Thomson; QUIC WG
Cc: Ted Hardie
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Martin,

Thanks for the clarification.

>> The latter is what we call a reverse proxy or gateway.  For that to work, the "proxy" needs to hold a certificate and keys that are valid for the identified authority.  The proxy can usually only operate for a single authority for each connection (RFC 7540 covers the exceptions to this).  It can use the TLS server_name extension and HTTP Host header field to demultiplex requests for multiple names if it is authoritative for more than one.  Each name typically needs a separate connection.

[Sridhar] Reverse proxies to terminate TLS can be deployed when the proxy is in the same trust domain as the origin server since the reverse proxy can be configured to expose the API endpoint towards the clients and masks the presence of backend servers. . But in 3GPP the HTTP API call is like below

HTTP Client in Network A (PLMN A) --> SEPP of PLMN A [ Trust Boundary crossed here] --> SEPP of PLMN B --> HTTP server in Network B (PLMN B)

So here the client's transport connection (TLS or QUIC) terminates at SEPP of PLMN A which acts as forward proxy. So for a https:// scheme URI, the client has to trust the SEPP A as a certificate authority if it acts as a bump in TLS and provides a certificate on behalf of the HTTP origin server.

I think the back to back user agent type proxy may not exactly fit here due to involvement of multiple proxies (SEPP A, SEPP B).