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

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.
BTW, I'm curious about how frequently we see this kind of behavior.
--
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