Re: [tcpm] 793bis: what to say about source routing

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Fri, 03 December 2021 16:17 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 7E2223A078E for <tcpm@ietfa.amsl.com>; Fri, 3 Dec 2021 08:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP4afCLi4IH7 for <tcpm@ietfa.amsl.com>; Fri, 3 Dec 2021 08:17:30 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216C03A058F for <tcpm@ietf.org>; Fri, 3 Dec 2021 08:17:29 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 66AC025A13; Fri, 3 Dec 2021 17:17:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1638548247; bh=DAsSAm1eOPFypmBXbnzAiD0VzBynxL2gPHUqlOC1Xyg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mJP1036uEn3zUkdCZR0RmY0zc/SlSN8CXr2V9tlBbcl2I7RNbRuxEOmZIH3PB6ihk gatQZu9rSKz02Fzvjo9nvc9dpcbe720ghnaxo1WdoUYYsEnoPUudv4SnsmRtIRp+dj EovUpJsjCI8BqjmvRBFeP2kQ5W5+0biFzHFe0hIg=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYjXbF-UrDFW; Fri, 3 Dec 2021 17:17:25 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 3 Dec 2021 17:17:25 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Fri, 3 Dec 2021 17:17:25 +0100
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Fri, 3 Dec 2021 17:17:25 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "touch@strayalpha.com" <touch@strayalpha.com>
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tcpm IETF list <tcpm@ietf.org>
Thread-Topic: [tcpm] 793bis: what to say about source routing
Thread-Index: AQHX5ZghpMrKhYm65E+HP1+KV2CWVKwbcGGAgABJywCAAUYKgIADjv2ggABMYICAABpbQA==
Date: Fri, 03 Dec 2021 16:17:25 +0000
Message-ID: <4a3afe282c2e4ccbb61d652c8de54852@hs-esslingen.de>
References: <242bd633-0a7b-51dd-9200-3e3360d75e83@mti-systems.com> <E5ACB10A-FB03-4A5C-9862-400E6FB8F4F1@strayalpha.com> <2095724f-5db8-bcd7-df4e-b655b92d5cf6@erg.abdn.ac.uk> <6DDF9B1D-7EA4-4B3A-BF8F-7AD8F050E32A@strayalpha.com> <a7e99870c6584f9daf38f9d6312e8c99@hs-esslingen.de> <FE9149CC-79BA-4501-A074-981F58A20EB6@strayalpha.com>
In-Reply-To: <FE9149CC-79BA-4501-A074-981F58A20EB6@strayalpha.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
Content-Type: multipart/alternative; boundary="_000_4a3afe282c2e4ccbb61d652c8de54852hsesslingende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/LeFhJPYC-muuv-hZEkOgpUrsjoA>
Subject: Re: [tcpm] 793bis: what to say about source routing
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 03 Dec 2021 16:17:36 -0000

Hi Joe,

Maybe the statement

“use of source routing may be disabled on some systems”

would just avoid the terms “support” and “implementation”?

Anyway, I am not a native speaker, and I don’t have a strong personal preference.

Michael



From: touch@strayalpha.com <touch@strayalpha.com>
Sent: Friday, December 3, 2021 4:38 PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Michael,

Although *use* of source routing with TCP is optional, *support for* source routing is not.

Source routing is not deprecated for IPv4 and we should not imply support for it in TCP is optional in any way.

TCP isn’t deciding whether to use source routing, so this doc has no rationale for warning about whether source routing is enabled or not.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>


On Dec 3, 2021, at 2:51 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>> wrote:

Hi all,

The existing 793bis test already implies that use of source routing is optional, since it starts with an if-clause.

For what it is worth, I think that we could add a comment along the lines of „source routing may be disabled or unsupported on some systems“ to make this more explicit. I don’t see much harm in such an informative statement. If we go down this route, IMHO the 793bis spec does not have to discuss why stacks implement or don’t implement features below TCP.

Having said this, I don’t see a strong need for any additional wording. I just don’t object to a brief note.

In any case, as long as there is no other PS or BCP guidance, the normative statements in 793bis should not change 1122.
Michael (with no hat whatsoever)


From: tcpm <tcpm-bounces@ietf.org<mailto:tcpm-bounces@ietf.org>> On Behalf Of touch@strayalpha.com<mailto:touch@strayalpha.com>
Sent: Wednesday, December 1, 2021 5:44 AM
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>
Cc: tcpm IETF list <tcpm@ietf.org<mailto:tcpm@ietf.org>>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Gorry,

To me, your final point is the most significant.

Notably, putting the proposed note in TCP would suggest either that IP source routing is deprecated (it isn’t) or that TCP support for it should be considered optional (it should not) - regardless of whether is deprecated in the future or not.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>



On Nov 30, 2021, at 1:17 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>> wrote:

To me the security concerns are not relevant here - this is a transport spec., and the mechanisms below need to be designed correctly, and while an exmaple or two are good, it seems rather silly to state or enumerate the different sub-transport protocols or their individual concerns.


_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm