Re: Questions on HTTP URI schemes and QUIC

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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

________________________________
From: QUIC <[e-mail]> on behalf of Sridhar Bhaskaran <[e-mail]>
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,

>> 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:[e-mail]]
Sent: Tuesday, July 24, 2018 9:38 PM
To: Sridhar Bhaskaran <[e-mail]>
Cc: Lucas Pardue <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: Re: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <[e-mail]> 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