Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Hi Colm--

On Wed 2017-05-03 12:26:40 -0700, Colm MacCárthaigh wrote:
> Cool idea. One concern might be compatibility with other similar
> mechanisms. For example, there are protocols such as Netscaler Client IP:
>
> https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/
>
> or HAProxy's Proxy Protocol:
>
> https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
>
> Where proxies may insert their own pre-amble on the connection, to pass on
> something like an L4 X-Forwarded-For.
>
> Sometimes the backends behind these proxies have to accept traffic directly
> too, and they fingerprint the first few bytes to determine whether it's a
> direct HTTP connection, or a proxied request. I haven't thought through it,
> but it might get a little complicated doing two levels of demuxing, and it
> might not even be possible in some cases.

Thanks for the pointers to these protocols!  It's good to know that
people are already doing this sort of demuxing on the fly in some cases,
and that they haven't broken HTTP for everyone else yet :)

One approach for the current draft would be to explicitly call these
protocols out as things that are incompatible with he proposed form of
demuxing.  I'd be happy to add a generic "do not mix this mechanism with
other similar mechanisms" section.  I've just opened
https://gitlab.com/dkg/hddemux/issues/2 to make sure that doesn't get
lost.

FWIW, it actually looks like both versions of haproxy's Proxy Protocol
can be distinguished from DNS just by looking at the same octet ranges.
For the human-readable protocol, its first many octets (more than 14 of
them) are all within the 0x0A and 0x7F range.  for the binary protocol,
its initial static 12-octet preamble puts a 0xD nybble directly in the
DNS header's RCODE field, which should be 0x0 in a DNS stream assuming
the initial client message must be a Query and not a Response.

But i don't plan to turn this draft into a generic
how-to-demux-anything-with-anything draft, so i don't think i'll write
that up more formally ;)

So i think the result is to say that if a server is already demuxing an
inbound stream based on the same octets, they might not want to adopt
this.  Do you have any qualms with making this particular concern
something that is out-of-scope for the draft?

Regards,

        --dkg