From c27df890169cfb957d2ec09290714931564251e2 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Tue, 9 May 2017 11:16:31 -0400
Subject: [PATCH] warn against mixing with other multiplexers (Closes #2)
---
draft-dkg-dprive-demux-dns-http.md | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/draft-dkg-dprive-demux-dns-http.md b/draft-dkg-dprive-demux-dns-http.md
index d844a69..4081efa 100644
--- a/draft-dkg-dprive-demux-dns-http.md
+++ b/draft-dkg-dprive-demux-dns-http.md
@@ -33,6 +33,14 @@ informative:
RFC7830:
RFC7858:
I-D.ietf-dnsop-dns-wireformat-http:
+ HAPROXY:
+ target: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
+ title: The Proxy protocol
+ author:
+ name: Willy Tarreau
+ ins: W. Tarreau
+ org: HAProxy Technologies
+ date: 2017-03-10
normative:
RFC1035:
RFC1945:
@@ -144,6 +152,19 @@ fail or trigger other "interesting" behaviors. This approach should
be done only in channels sufficiently obscured that a transparent
proxy would not try to interpret the resultant stream.
+Avoid mixing with other demultiplexing
+--------------------------------------
+
+Some other (non-IETF) systems (e.g. {{HAPROXY}}) take a similar
+approach with multiplexing data on top of HTTP by taking advantage of
+bitpatterns that are presumed to not be present in normal HTTP
+requests.
+
+Use of the approach described in this draft in conjunction with these
+other approaches is not advisable. Doing so safely would require
+explicit and detailed review of all three (or more) protocols
+involved.
+
Why not ALPN?
-------------
--
GitLab