search

raybellis / draft-bellis-dnsop-xpf

DNS X-Proxied-For
0 stars 1 forks source link

haproxy PROXY protocol? #14

Open Habbie opened 6 years ago

Habbie commented 6 years ago

@enygren wrote:

Have you considered modelling XPF after the HAProxy protocol?

https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

There was some discussion at an HTTP workshop as to whether it would be worth getting the HAProxy protocol IETF-standardized, perhaps also adding some things like encryption. (eg, having a shared key and doing AES-SIV encryption+authentication might address some of the privacy concerns). Having a shared format/payload across HTTP, DNS, and other protocols might be useful and might be BOF-worthy?

Erik

Habbie commented 6 years ago

It does not solve the 'protocol' layer the way we suggested in #11, instead relying on ALPN for that, which as I understand is not great for our use case.

I do like 'prepend the whole thing to your UDP packet or TCP connection' a bit, it avoids all the record mangling.

rgacogne commented 6 years ago

As much as I like the proxy protocol, it becomes something that a non-proxy protocol-aware receiver can't parse at all, as opposed to the current solution that can be safely ignored.

rgacogne commented 6 years ago

Also, AFAIK the proxy protocol currently only exists over TCP.

Habbie commented 6 years ago

As much as I like the proxy protocol, it becomes something that a non-proxy protocol-aware receiver can't parse at all, as opposed to the current solution that can be safely ignored.

Well, we did write down that anybody seeing XPF while not expecting it should refuse the query. This would give us that for free (although it might turn it into a drop). That's actually what I like about it.

Habbie commented 6 years ago

Also, AFAIK the proxy protocol currently only exists over TCP.

I saw the suggestion as having two sides: (1) the wire format for PROXY (2) the 'wrapping'. I'm unsure (1) makes sense for us, it's all quite verbose and to people already having a DNS wire parser it's actually more work. For (2) see above.

I'm not at all advocating for either side, but there is some minor food for thought in the document.

zeha commented 6 years ago

From other protocol implementations I found that it's often easier to unwrap something than to peek into the inner packet.

Extra points for unwrapping just meaning stripping something in front, but not from the back.

rgacogne commented 6 years ago

Extra points for unwrapping just meaning stripping something in front, but not from the back.

This.

raybellis commented 6 years ago

This does have a certain appeal, but how (should?) we distinguish between a wrapped connection from a plain one? For the proxy case I can see some benefit in restricting this to [persistent] TCP only, but it would perhaps need alternate ports.

rgacogne commented 6 years ago

I believe we would have to use alternate ports dedicated to this indeed. I'm not sure this is a better solution than the current XPF one, both make sense and might have different use cases.

raybellis commented 6 years ago

Using an entirely separate port with a prepended "wrapper" rather than something in the tail of the packet should satisfy the privacy advocates, though.

It would also simplify things for those implementations (including BIND AFAIK) that would like to examine (and act on) the transport meta data before parsing the entirety of the packet.

I'm also undecided either way, but there's merit in having the discussion.