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

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.

Consequently, a legacy server might interpret the TCP option as 
application data.

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

Best wishes,
D. Wythe

> --
> Yoshi
>
>
> On Wed, Nov 22, 2023 at 12:28 AM D. Wythe <alibuda@linux.alibaba.com> 
> wrote:
> >
> >
> > Hi all,
> >
> > I am D. Wythe from Alibaba, currently conducting research on EDO. I
> > would like to report an issue
> > involving certain middleboxes that may have an impact on EDO.
> >
> > We have observed that some middleboxes incorrectly copy unknown TCP
> > options from SYN packets into the SYN-ACK packets.
> > We believe this behavior is entirely incorrect, although we are
> > uncertain of the reasons behind it.
> >
> > Here is an example of a TCP SYN packet I constructed with an unknown SYN
> > TCP option:
> >
> > local.32218 > remote.http: Flags [S], seq 4026107292, win 8192, options
> > [unknown-100 0x01020304,nop,nop], length 0
> > remote.http > local.32218: Flags [S.], seq 3220955308, ack 4026107293,
> > win 8192, options [unknown-100 0x01020304,nop,nop], length 0
> >
> > Unfortunately, this is not an isolated incident. We have observed
> > several publicly available services on the internet
> > exhibiting the same incorrect behavior.
> >
> > We would like to know if anyone else has encountered similar issues and
> > how you perceive the impact of EDO in this scenario
> > (we believe it may result in the server interpreting the TCP options as
> > application data).
> >
> > Additionally, is there any possibility of adding an explicit
> > notification when one side detects a violation of the EDO protocol.
> > This could potentially prevent all segments from being discarded by
> > restricting the peer from further extending the TCP header.
> >
> >
> > Best regards,
> > D. Wythe
> >
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm