RE: Questions on HTTP URI schemes and QUIC

[Sridhar Bhaskaran <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, July 25, 2018 1:54 PM
To: Sridhar Bhaskaran <[e-mail]>; Martin Thomson <[e-mail]>; QUIC WG <[e-mail]>
Cc: Ted Hardie <[e-mail]>
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.

Lucas
________________________________________
From: QUIC [[e-mail]] on behalf of Sridhar Bhaskaran [[e-mail]]
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).

Thanks
Sridhar