On 27/05/2016 2:42 a.m., Willy Tarreau wrote: > On Thu, May 26, 2016 at 10:20:36AM -0400, Erik Seres wrote: >> Hi Willy, >> >> Attached is my updated patch per your styling update request. > > Thanks Erik. I'm now CCing Dave and Amos, both of whom worked on this > 18 months ago. Amos requested the use of value 0x01 for ALPN and 0x02 > for SNI by then, though I don't know if in the end he implemlented > anything. Same for Dave who wanted to implement them in the protocol. > > Guys, for a bit of context, Erik proposes a patch to implement SNI on > PP2. If nobody implemented anything yet, maybe it's best to continue with > 0x23 and so on for now. Otherwise if anything was already implemented, we'll > stay on what was already done. Please however, do provide patches at least > for the doc if anything was done, as it's quite hard to have to dig through > e-mail archives to find the details :-/ > > Thus please just check between all of you and tell me if I apply the > attached patch or if we need to change the ID. We absolutely need to work > on this to define how to extend the protocol in the future and to register > new IDs...
PP2_TYPE_AUTHORITY as 0x02 is already mentioned in your 1.5 and 1.6 PP documents. Though I have not taken the final step of using it as a substitute for SNI (was just about to start that actually - good timing). AFAICT you have a good pattern started already and documented in section 2.2. <http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt> There is a bit of a pattern in the registrations so far; - 0x0* are transport description details. * (protocol type, server authoruty) - 0x2* are TLS specific details. * (version, CN) - 0x3* namespace ?? Both ALPN and SNI are transport description details that have been essentially tacked onto TLS at the last minute. It makes sense to keep them separate as transport details at other levels. The TLS layer requires SNI to be clamped to the underlying protocols authority value. Which means receivers will need to be verifying that SNI matches the PP2_TYPE_AUTHORITY value anyway. Duplicating it makes little sense. One of the issues we are seeing with HTTP CONNECT messages is that there are already two HTTP representations of authority to correlate both up to TCP IP:port and down to TLS SNI. Either one being weird causes issues. IMO copying that duplication problem into PP2 would be a mistake. Amos
