Subject: Questions on HTTP URI schemes and QUIC

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 18 Jul 2018 10:49:53 +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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Jul 2018 09:38:11 -0400

On Wed, Jul 18, 2018 at 6:49 AM, Sridhar Bhaskaran <
[email-masked]> wrote:

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

There is an experimental RFC, 8164, that would probably apply here for
consenting endpoints. 8164 requires the same crypto and authentication as
https - so you should probably just go with https unless you're already
using that strategy with h2 for legacy mixed content.

> 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
>         b. HTTP client issues a HTTP CONNECT request to the proxy with the
> ":authority" HTTP/2 pseudo header pointing to the origin server
>         e. HTTP client then initiates a TLS connection towards the origin
> server via the proxy and the proxy simply tunnels it.
i believe so

> 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.
>
>
yes, connect tunnels are end to end encryption for their content so the
data that flows between the client and proxy is encrypted twice. That's the
same in all versions of http.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Jul 2018 13:52:17 +0000

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.

Regards
Lucas

[1] - https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-helium.pdf

>-----Original Message-----
>From: QUIC [mailto:[email-masked]] On Behalf Of Sridhar Bhaskaran
>Sent: 18 July 2018 11:50
>To: IETF QUIC WG <[email-masked]>
>Subject: Questions on HTTP URI schemes and QUIC
>
>Dear Quic experts,
>
>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
>	e. HTTP client then initiates a TLS connection towards the origin server
>via the proxy and the proxy simply tunnels it.
>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.
>

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Thu, 19 Jul 2018 03:40:02 +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 

http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_80_La_Jolla/Docs/CP-181194.zip

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

Thanks
Sridhar

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

Hi Sridhar,

Regards
Lucas

>alternate service via QUIC, can a HTTP client use QUIC to connect to 
>the origin server and still use the http:// scheme URI?
>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.
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 19 Jul 2018 19:36:23 +0000

Hi Sridhar,

Thanks for sharing the 3GPP work.

Sridhar wrote:

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

Are the required transformations shareable (or captured in some 3GPP document). We are aware of a congestion control use case but additional ones are welcome.

However, considering the model I have for tunnelling QUIC, the amount of in-the-loop processing possible is likely to be minimal due to the end-to-end QUIC security context. The proxy will have access to IP, UDP and QUIC headers but not QUIC protected payload.

Kind regards
Lucas

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Tue, 24 Jul 2018 03:36:50 +0000

Hi Lucas,

>> Are the required transformations shareable (or captured in some 3GPP document). We are aware of a congestion control use case but additional ones are welcome.

The draft change requests are currently being discussed between 3GPP SA3 and CT4. You will see the updated specs once this is agreed - after September. The latest draft CR is available @ http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_91Bis_LaJolla/Docs/S3-181937.zip. Note that this draft CR is for 3GPP release 15 where the transport is TCP/TLS. My questions below are for the study item in 3GPP release 16 where we are exploring if QUIC can be used as an alternate transport.

>> However, considering the model I have for tunnelling QUIC, the amount of in-the-loop processing possible is likely to be minimal due to the end-to-end QUIC security context. The proxy will have ac…

Yes this is understood. One follow up question is - can a bump in TLS (TLS interception) where a proxy provides certificates on behalf of origin host signed by its own CA (provided the client is configured to trust this CA) work with QUIC? Can this be made to work to intercept the protected payload at a proxy?

Thanks
Sridhar
-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Friday, July 20, 2018 1:06 AM
To: Sridhar Bhaskaran <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

Sridhar wrote:

>transformations based on operator policies. So as highlighted in slide 
>8 SEPP's role is "in the loop".

Kind regards
Lucas

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 Jul 2018 09:07:53 -0700

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <
[email-masked]> wrote:

> Yes this is understood. One follow up question is - can a bump in TLS (TLS
> interception) where a proxy provides certificates on behalf of origin host
> signed by its own CA (provided the client is configured to trust this CA)
> work with QUIC? Can this be made to work to intercept the protected payload
> at a proxy?
>
> Thanks
> Sridhar

Before going down that road, may I ask why 3gpp prefers the
bump-in-the-wire style proxy, rather than a configured proxy?  A configured
proxy can act as a back-to-back user agent, which allows the kind of
inspection you describe.  The  mechanism can also be set to work either on
a per-network basis or globally (depending on the configuration and the
topology).  Is that not a better fit for your deployment model?

regards,

Ted

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 25 Jul 2018 03:33:09 +0000

Hi Ted,

>> Before going down that road, may I ask why 3gpp prefers the bump-in-the-wire style proxy, rather than a configured proxy?  A configured proxy can act as a back-to-back user agent, which allows the kind of inspection you describe.  The  mechanism can also be set to work either on a per-network basis or globally (depending on the configuration and the topology).  Is that not a better fit for your deployment model?

[Sridhar] In 3GPP architecture, from a HTTP client perspective it believes it is invoking the API exposed by a HTTP server. If the client is configured to route the request via a proxy (configuration is at HTTP level and application is unaware of it), then what should be the ":authority" pseudo header in a HTTP/2 request (i.e the authority part of the URI)? If the authority part of the URI still refers to an FQDN / IP address of the HTTP server, then isn’t the TLS certificate exchange supposed to happen against this? On the other hand, if the authority part of the URI refers to the proxy's endpoint itself, then how does the proxy know where to route the request further? 

By the way are there any IETF drafts / RFCs that explain how this would work?

I may be missing few details here. Could you please clarify how a configured proxy acting as B2B user agent would 

a) terminate TLS by providing a valid certificate for the domain / authority with which the client is intending to communicate 
b) how the proxy will route the HTTP/2 request to the right server (and based on which information in the HTTP/2 request)?
c) Any IETF draft / RFC that explains this.

Thanks
Sridhar

From: Ted Hardie [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2018 9:38 PM
To: Sridhar Bhaskaran <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <[email-masked]> wrote:

Thanks
Sridhar

Before going down that road, may I ask why 3gpp prefers the bump-in-the-wire style proxy, rather than a configured proxy?  A configured proxy can act as a back-to-back user agent, which allows the kind of inspection you describe.  The  mechanism can also be set to work either on a per-network basis or globally (depending on the configuration and the topology).  Is that not a better fit for your deployment model?

regards,

Ted

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 25 Jul 2018 05:48:17 +0000

Another option is to connect to the backend directly, then forward traffic keys to the proxy.

________________________________
From: QUIC <[email-masked]> on behalf of Sridhar Bhaskaran <[email-masked]>
Sent: Wednesday, July 25, 2018 5:33:09 AM
To: Ted Hardie; IETF QUIC WG
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Ted,

Thanks
Sridhar

Hi Sridhar,

Thanks
Sridhar

regards,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jul 2018 16:59:43 +1000

On Wed, Jul 25, 2018 at 1:34 PM Sridhar Bhaskaran
<[email-masked]> wrote:
> If the client is configured to route the request via a proxy (configuration is at HTTP level and application is unaware of it), then what should be the ":authority" pseudo header in a HTTP/2 request (i.e the authority part of the URI)?

Yes, this is as defined in RFC 7540.  The identity of the proxy
doesn't matter.  Of course, that places a lot of trust in the proxy,
and clients rarely do that.  In most cases, a (forward) proxy will
instead see a CONNECT request instead.  (I'm assuming HTTPS here, as
deployment of unsecured HTTP/2 is both effectively non-existent and
prohibited by 3GPP.)

> If the authority part of the URI still refers to an FQDN / IP address of the HTTP server, then isn’t the TLS certificate exchange supposed to happen against this? On the other hand, if the authority part of the URI refers to the proxy's endpoint itself, then how does the proxy know where to route the request further?

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.

> By the way are there any IETF drafts / RFCs that explain how this would work?

RFC 7540 should describe most of this, either directly or by
reference.  TLS server_name is described in RFC 6066.

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 25 Jul 2018 07:20:16 +0000

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

Thanks
Sridhar

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 25 Jul 2018 08:23:56 +0000

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.

Lucas
________________________________________
From: QUIC [[email-masked]] on behalf of Sridhar Bhaskaran [[email-masked]]
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
Sridhar

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 25 Jul 2018 08:44:04 +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.

Sridhar

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

Hi Sridhar,

Lucas

Hi Martin,

Thanks
Sridhar