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

Unfortunately, similar issues have been plagued the deployment of any
new features / functions on the two most well known IP protocols for
well over 30 years.

See the Mechanisms developted for IP ECN, TCP AccECN, TFO, ...

For the most part, this meddling is restricted to small parts /
fractions of sessions in the internet - but it is prudent to investigate
the impact of such pathological behavior on the deployment of new
protocols during their design phase.

Maybe you can share more details, which AS exposes this misbehavior, or
if this is observable more widely (eg from specific vantage points).

Investigating this is always a nice project.

Best regards,
   Richard

Am 22.11.2023 um 09:24 schrieb D. Wythe:
>
> 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