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

> On Nov 22, 2023, at 09:24, 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.
Just to be crystal clear here: You know that middleboxes are doing this or could it also be the
endpoint?

Best regards
Michael
> 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