Re: New tunnel protocol

Hi Mark,

On Wed, Jan 28, 2015 at 01:35:48PM +1100, Mark Nottingham wrote:
> Hi Amos et al,
> 
> Personally, I generally agree much of your concern here -- the ad hoc way in
> which ALPN identifiers sprung up always made me nervous (and I've expressed
> that a few times). It would be nicer if there were (dare I say it) a more
> well-defined architecture around ALPN-as-protocol-identifier.
> 
> HOWEVER, in this case we're not talking about a negotiation mechanism, nor
> are we trying to allow intermediaries to parse the contents of the
> connection. Rather, the purpose of tunnel-protocol is a hint as to the
> semantics of the application inside the tunnel, so as to enable application
> of policy.
> 
> E.g., if the content is WebRTC, the network might want to apply different
> QoS, or refuse the tunnel because they're extremely bandwidth-constrained.
> 
> For those use cases, it makes no difference (that I can see) as to whether
> the content is encrypted or not.

Yes it still makes a difference for banner protocols. For example, if you
pass POP in clear, the proxy must not disable quick-ack like it can do for
TLS since the first packet of the connection will be sent by itself.

That's why I think it's reasonable to consider that, as a first step, we
could have something which satisfies exactly what Martin needs (eg: repeat
in a header field what is supposed to be advertised in the TLS ALPN), and
to ensure that the name of this header doesn't make it difficult to later
add information about what is being tunnelled (eg: TLS vs VPN vs anything
else).

Regards,
Willy

Received on Wednesday, 28 January 2015 10:37:27 UTC