Willy, Am 04.04.20 um 13:29 schrieb Willy Tarreau: >> Am 04.04.20 um 12:41 schrieb Tim Düsterhus: >>> The Dovecot source code is here: >>> https://github.com/dovecot/core/blob/de9968d623e331a18b43dfe8a00421f72f7f7962/src/lib-master/master-service-haproxy.c#L354 >>> >>> A quick glance at the Dovecot code looks like Dovecot parses the proxy >>> protocol correctly with regard to TLVs. >> >> I spoke too soon here. Dovecot ignores the addresses as it should for >> LOCAL (i.e. health check) connections [1] and then attempts to parse the >> TLV, interpreting the IP addresses as a TLV [2]. From my understanding >> HAProxy sends IP addresses for LOCAL connections for compatibility. > > Do you think we ought to refrain from sending any address at all ? > I preferred to avoid possibly visible changes and apparently it didn't > go that well :-/ >
Based on a strict reading of the proxy protocol definition Dovecot is wrong here: > The receiver must accept this connection as valid and must use the > real connection endpoints and discard the protocol block including the > family which is ignored. To my understanding the TLV are part of the protocol block, because they were bolted onto the proxy protocol v2 after the fact in commit afb768340c9d7e50d8e7372051c8a9c3b3f2151c (https://github.com/haproxy/haproxy/commit/afb768340c9d7e50d8e7372051c8a9c3b3f2151c). I also notice that this commit made an incompatible change to proxy protocol v2 1.5 years after the initial specification (however both during the 1.5 development cycle). As the TLV are part of the protocol block they must be ignored for LOCAL connections to my understanding, but I'm not sure. I already mentioned / asked about that within my email [PATCH 2/3] MINOR: proxy_protocol: Ingest PP2_TYPE_UNIQUE_ID on incoming connections (Message-Id: <[email protected]>): > I've also added a reg-test that verifies that pulling unique IDs works > properly. My first attempt was to use a LOCAL connection, because then > I would not need to send IP addresses in HEX encoding, however HAProxy > does not appear to read TLVs in LOCAL mode. I've attempted to find out > whether TLVs are supported for LOCAL mode or not in the proxy-protocol > specification, but it was not terribly clear. Supporting unique IDs in > LOCAL mode would definitely make sense to me. And supporting the CRC32 > checksum would also make sense I guess. However HAProxy violates a should: > When a sender presents a > LOCAL connection, it should not present any address so it sets this field to > zero. My conclusion is that the proxy protocol v2 definition is not super clear with regards to TLV. I assume that is because they were not initially part of the specification. Not sending an explicit length for the address and instead only a length for address + TLV is non-ideal. Another case in point: My bugfix for the TLV parsing that ignored the length of the proxy header, because each TLV had its own length. Best regards Tim Düsterhus
