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:38 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 80F3FC151073 for <tcpm@ietfa.amsl.com>; Wed, 22 Nov 2023 22:38:22 -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 rr29IvoffpYS for <tcpm@ietfa.amsl.com>; Wed, 22 Nov 2023 22:38:21 -0800 (PST)
Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (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 2151BC14CE51 for <tcpm@ietf.org>; Wed, 22 Nov 2023 22:38:20 -0800 (PST)
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R161e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018045176; MF=alibuda@linux.alibaba.com; NM=1; PH=DS; RN=1; SR=0; TI=SMTPD_---0Vwy9bIV_1700721497;
Received: from 30.221.149.60(mailfrom:alibuda@linux.alibaba.com fp:SMTPD_---0Vwy9bIV_1700721497) by smtp.aliyun-inc.com; Thu, 23 Nov 2023 14:38:18 +0800
Message-ID: <8871b0b3-ca6a-1a17-25c9-36759c92446e@linux.alibaba.com>
Date: Thu, 23 Nov 2023 14:38:16 +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> <4d093f24-0edf-4fd9-81e6-d042ce1be841@gmx.at>
From: "D. Wythe" <alibuda@linux.alibaba.com>
In-Reply-To: <4d093f24-0edf-4fd9-81e6-d042ce1be841@gmx.at>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/deUEBk0CLdSbNQaQvC0fNcsHsVc>
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:38:22 -0000

Hi Richard,

Thank you for your feedback.

After including additional details in my email to Yoshi, I have come to 
the conclusion that this issue
may not be widely prevalent and, thus, does not necessitate any protocol 
intervention.

Thanks,
D. Wythe


On 11/22/23 5:11 PM, rs.ietf@gmx.at wrote:
> 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
>

v2.23.0 | Report a Bug | By Email