Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-13

[Yoshifumi Nishida <[e-mail]>]

Hi Wythe,

On Wed, Nov 22, 2023 at 10:25 PM D. Wythe <[e-mail]> wrote:

>
> Hi Yoshi,
>
> Thanks for you comments.
>
> On 11/23/23 3:26 AM, Yoshifumi Nishida wrote:
> > Hi Wythe,
> >
> > I'm not the author of the draft. But, there are the following texts in
> > the draft.
> >
> > "Once enabled on a connection, all segments in both directions MUST
> > include the EDO Extension option."
> > "If EDO has been negotiated, any subsequent segments arriving without
> > the EDO Extension option MUST be silently ignored."
> >
> > So, I think you'll probably see connection timeouts in such cases.
> > This may look suboptimal behavior, but at the same time, we probably
> > don't want to think about buggy implementations too much because it
> > can be endless. The behavior you describe is prohibited by RFC9293.
>
> I believe that in that case, connections may not end with timeouts but
> instead receive an erroneous application
> response from the server. This is because the server does not support
> EDO, and an incorrectly implemented middlebox
> copies the EDO support option, which misleading the client.
>

Do you mean incorrectly implemented middle box attaches EDO supported
options used in SYN to data packets from the server?
Or,  the middle box copies EDO extension options to the ACKs from the
server for the data packets from the client?
It's a bit hard for me to believe such behavior.. Because I think it can be
complicated to implement such behavior.

> BTW, I'm curious about how frequently we see this kind of behavior.
>
> Previously, I had the belief that this might was a widespread scenario,
> but as I conducted further investigation,
> I realized that this issue may only exist in specific organizations or
> regions..
>
> We are now convinced that this issue is caused by a type of incorrect
> syn-proxy implementation, who
> acts as an intermediary to protect against SYN flood attacks by
> completing TCP handshakes on behalf of clients,
> preventing server overload.
>
> The problem is that when the syn-proxy receives a syn from the client,
> in order to avoid memory allocation and copying,
> some implementations reuse the SYN packets, exchange IP addresses and
> ports, and send it out as SYN/ACK to client.
> Unfortunately, it did not consider the impact of TCP options being
> simply copied.
>
> A example I found is:
>
> https://github.com/iqiyi/dpvs/blob/master/src/ipvs/ip_vs_synproxy.c
>
>  From this perspective, it is worth considering that these issues may
> only affect certain organizations and regions.
> I agree with your point about buggy implementations, as these types of
> issues can be never-ending and are
> beyond the protocol's control or responsibility to handle.
>

Thanks for the info. But, does it copy options other than SYN or SYN/ACK
packets?
--
Yoshi