Re: new version trusted-proxy20 draft

Hi Thomas,

thanks for your comments,

On Feb 16, 2014, at 11:24 PM, Thomas Fossati <TFossati@velocix.com<mailto:TFossati@velocix.com>>
 wrote:

Hi Sal, thanks for the draft.

On 14/02/2014 18:56, "Salvatore Loreto" <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
I want to highlight that
the only change asked by this draft in order to support an Explicit Trusted Proxy
is the definition of a new ALPN protocol id value as you can read in the Abstract below.
No other changes to HTTP2 spec neither to the TLS protocol are required.

I think one very important change that you propose (for good reasons, IMHO) is to explicitly separate TLS tunnels that are intended for http URIs from those that are to carry https traffic.

yes the separation between TLS tunnels intended for http URI and TLS tunnels intended to transport https
is the main change, really important change, even if the only one the draft is proposing for the HTTP2 protocol.


Maybe this bit of information deserves to be stated more clearly in the document?

I think you are right, I will do my best to make it stated more clearly in the next version.


   Section 3.2 proposes a solution based on the presence of a Captive
   Proxy.

This is the only part of your draft where I have a bit of difficulties in understanding the mechanics.

In step (2), in order to distinguish between a genuine HTTP/1.1 request (one that needs no redirection to the Portal) from a "downgraded” HTTP/2.0 request (i.e. one which is the result of a previously tried&failed “h2clr” handshake and has to go to the Portal), the trusted proxy needs to keep some kind of state about the re-trying user agent.

However, at the point the redirection decision is made, the trusted proxy has no other information than IP address of the user agent.

What’s the heuristics that you envisage to make this work in practice?

this is a good question.
you are right that at the time of receiving the TLS Client Hello the trusted proxy has to keep some kind of state/information about
the re-trying user agent.

In the wireless telephone world the proxy is facilitated because it receives not only the IP address of the user agent but also
the MSISDN.

However also in general that should be so difficult as the solution we are proposing is for access network
so the UA IP address should be enough for a trusted proxy in the same network to discriminate the UA.

Cheers
/Sal


Cheers