Re: HAProxy and proxy protocol support

Nathan Phillip Brink writes:

>> https://netty.io/wiki/tcp-fast-open.html
>>
>> "TFO cannot always be used, however, because it changes how TCP behave: The  
>> receiving end might see this data duplicated due to retransmission of the  
>> SYN packet. For this reason, TFO must only be used when the data in the  
>> initial packet will be processed idempotently. Whether this is the case,  
>> depends on the protocol and the application."
>>
>>> That seems like a catastrophic bug in the TCP contract. I'd like to make  
>>> some colleagues aware of the issue, ideally with a reference to some  
>>> analysis of it.
>>
>> This seems like a well known, known issue with this.
>
> Doesn’t this just mean that a single connection could be seen by the server  
> as two connections? As long as the initial data isn’t enough to actually  
> enqueue an email, one of those ghost connections should just timeout and the  
> other real connection actually process.

I considered this interpretation while trying to wrap my own brain around  
this. I don't believe this is the case, here's why.

A TCP connection is defined by: source ip, source port, destination ip, and  
destination port. My understanding of TCP is that it is logically impossible  
for two logical connections exist at the same time that have identical  
source/destination ip/ports. There is no unique identifier, of some kind,  
that's assigned to each logical connection. This quadruplet is what defines  
a unique TCP connection.

So, a duplicated packet can't possibly create a new logical connection with  
the same source and destination. It already exists. The only possible  
interpretation of the above is that the payload gets duplicated on a single  
connection.

> I also apologize for any misunderstanding of SMTP as I am not very familiar  
> with it. I would like some confirmation if I am interpreting the concern  
> correctly. I do not think it was mentioned explicitly (unless I missed it).  
> Is the concern the possibility of double-queuing a single email as I  
> purported above?

The concern is that the server expects and receives the first PROXY  
statement, and sets things up accordingly. Now the SMTP session starts.

The server then logically receives another PROXY command, as logical data  
that's read from the socket, but the server is now talking SMTP. And the  
sender did not actually send it. The sender sent the initial SMTP command  
(I'm ignoring the deal with the initial SMTP banner, and how it works, it's  
immaterial here). The sender is waiting for a response to the initial  
command, which would be EHLO.

But the server has logically read the PROXY command, that's logically read  
from the socket, before the EHLO. That's not a valid SMTP command, so the  
server sends an error. Which the client reads as the response to the EHLO  
command.

Stick a fork in this connection. It's done.

The same deal applies to IMAP, POP3, or anything else for that matter that  
works similarly.

I'm adding code that will completely ignore any PROXY command that the SMTP,  
IMAP, or the POP3 server appears to receive, initially. Completely ignore  
it, and don't send any response. This should put things back on the right  
track, or, more technically accurate: prevent it from getting derailed in  
the first place.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCZmp9OQAKCRCKYPgoojZS
4t6XAQCkQW/7wAodWr8rTDMSy0gieAIYiM6N8AnjXKG5ZdQuOQD/bJDiiMFG1D1r
+ZSvx/pVjjODbHdCaGlDm0luhMBBHAo=
=htW5
-----END PGP SIGNATURE-----