IETF Logo Mail Archive

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

"D. Wythe" <alibuda@linux.alibaba.com> Thu, 23 November 2023 06:43 UTC

Return-Path: <alibuda@linux.alibaba.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436B7C15108E for <tcpm@ietfa.amsl.com>; Wed, 22 Nov 2023 22:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.996
X-Spam-Level:
X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, NICE_REPLY_A=-0.091, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evSc2Nsvxzuo for <tcpm@ietfa.amsl.com>; Wed, 22 Nov 2023 22:43:49 -0800 (PST)
Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8EFC14F726 for <tcpm@ietf.org>; Wed, 22 Nov 2023 22:43:48 -0800 (PST)
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R691e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018046056; MF=alibuda@linux.alibaba.com; NM=1; PH=DS; RN=1; SR=0; TI=SMTPD_---0VwyETRr_1700721825;
Received: from 30.221.149.60(mailfrom:alibuda@linux.alibaba.com fp:SMTPD_---0VwyETRr_1700721825) by smtp.aliyun-inc.com; Thu, 23 Nov 2023 14:43:46 +0800
Message-ID: <2af6cd6e-5600-9fd9-f4ac-2669a15e7741@linux.alibaba.com>
Date: Thu, 23 Nov 2023 14:43:44 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: tcpm@ietf.org
References: <fc2d032a-eed3-536a-7131-f4c8ba697136@linux.alibaba.com> <2765BAF2-21F2-4A6B-A12D-47E5B43A4CCC@lurchi.franken.de>
From: "D. Wythe" <alibuda@linux.alibaba.com>
In-Reply-To: <2765BAF2-21F2-4A6B-A12D-47E5B43A4CCC@lurchi.franken.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/W_iSfXenwPXLNXRKZ1VPURCCP0s>
Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-13
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Nov 2023 06:43:53 -0000

Hi Michael,

On 11/22/23 6:56 PM, Michael Tuexen wrote:
>> 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?

Yes, we found evidence of the code, an incorrect syn-proxy 
implementation. You can see more information
in the email I sent to Yoshi. If you have any other doubts, please let 
me know.

Best wishes,
D. Wythe

> 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

v2.23.0 | Report a Bug | By Email