Re: HAProxy and proxy protocol support

Sam:

I've been AFK all day.

I think you are wrong in this case.  I have literally never seen any
mention of duplicated data within the same TCP channel, nor seen such a
thing while using TFO. I was very surprised to hear you say this could be
an issue and started googling for bugs in TFO implementations because given
what I knew, this was the only way I could make sense of what you were
saying.

The operating statement in the RFC is "Since the replay only happens
specifically when the SYN data packet is duplicated and also the duplicate
arrives after the receiver has cleared the original SYN's connection state,
the replay is thought to be uncommon in practice. "

The words "the receiver has cleared the original SYN's connection state"
indicate the duplicated data would be received into a new connection, per
the second SYN causing a new socket with the same quadruplet ID as a
recently closed socket.

We can raise the discussion in one of the linux kernel networking groups
for final adjudication, but I agree with Nathan. The "idempotency"
discussed in the RFC is relative to overall system state should a new TCP
channel end up duplicating a request previously handled on the server in a
prior TCP channel.

Imagine that you quickly shut down the incoming HAProxy TFO connection
immediately after receiving the v1 header, and the kernel discards all
traces of the TCP connection, and then due to some network issue the
original SYN packet is re-received...

In short, I think your existing implementation is probably just fine, and I
would implement either a configurable or very short timeout for proxy v1
header reception per my prior note.

All the best,
A.

On Wed, Jun 12, 2024 at 10:02 PM Sam Varshavchik <[email protected]>
wrote:

> 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
>

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