Re: New tunnel protocol

On Wed, Jan 28, 2015 at 09:59:02AM -0800, Martin Thomson wrote:
> On 28 January 2015 at 02:36, Willy Tarreau <> wrote:
> >
> > 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).
> I have no objection to other signals, certainly.
> The other signals are much harder to conceptualize.  I'm not opposed
> to exposing more information if it can be justified and worked into a
> solution.  If someone has a need, they should develop a solution
> around that need and propose it.

I agree, let's not conflate all needs. I think you should rename your
header field to something like "Tunnel-ALPN" or something like this,
explicitly mentionning ALPN.

In parallel, I think Adrien made a good point about some ambiguities
regarding the transported protocols (sometimes advertised as the legacy
protocol transported over TLS, sometimes as the TLS variant of the
protocol). h2/h2c is probably what ignited the beginning of the confusion,
but as long as you copy the same protocol IDs in your header as present
in the TLS handshake, this issue is out of the scope of this WG.

That's why I think it makes sense to declare that you're simply mirroring
the ALPN value whatever it is, regardless of whether it makes sense or not,
and how you encode it. *That* is in the scope of this WG.

And as much as I would love to see a protocol declaration header field for
tunnels, it's something different and complementary to your work that can
be worked on later (maybe Adrien, Amos and I could work on this later).


Received on Thursday, 29 January 2015 07:38:44 UTC