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

"touch@strayalpha.com" <touch@strayalpha.com> Tue, 30 November 2021 04:53 UTC

Return-Path: <touch@strayalpha.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 4366D3A0D46 for <tcpm@ietfa.amsl.com>; Mon, 29 Nov 2021 20:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 VlFIdAtjuhH9 for <tcpm@ietfa.amsl.com>; Mon, 29 Nov 2021 20:53:17 -0800 (PST)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCE63A0DB5 for <tcpm@ietf.org>; Mon, 29 Nov 2021 20:53:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m0N7kPbx2Senn+/sAx7EoiF3ukWsBuu0pEnyiHJ9Ews=; b=YfF0u2vMFJmuuP6/Ys/YP9R/GE vg64mm4xS556d2QRdV3bRV2PzbgFdVQxyH/A+XCUFHj2JEoy24MoutwWqJ1Pz7nOhlhHg/WRxJZpB wrEw/taTezzZv/QA0Zzanm1J9N+Y3OO1yG2oHjY20hvkMhJYCM6bXHN/cY58Iq1r9a7+p4A9LA5TI ZLddyfcCsSrE7BS+HWHqu/QtfYqnaR6hNzhYqGsu9G1sup2zvQ0dYmQnMwpTqqYgblKYEaSqyPBJk 1jPXlVnyYnhF+IO3eIw49FC34mLXE4+laucVGzu46o2rIyYjiFT1r/kYhls6NQ2PReD2yqGjdWw8i yWPmqsdw==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:57089 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1mrv8e-0054l3-3v; Mon, 29 Nov 2021 23:53:14 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_2676049D-251C-4FBE-96D1-07F870330BAA"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <242bd633-0a7b-51dd-9200-3e3360d75e83@mti-systems.com>
Date: Mon, 29 Nov 2021 20:53:07 -0800
Cc: tcpm IETF list <tcpm@ietf.org>
Message-Id: <E5ACB10A-FB03-4A5C-9862-400E6FB8F4F1@strayalpha.com>
References: <242bd633-0a7b-51dd-9200-3e3360d75e83@mti-systems.com>
To: Wes Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/pUTsj25jJwHG-opidrJ5pRGasgE>
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: Tue, 30 Nov 2021 04:53:22 -0000

Hi, Wes,

The text in RFC793bis is correct and sufficient regarding TCP. TCP has no business making recommendations about what options IP uses.

Let’s please not continue to propagate the misconception that features that are not expected are either errors or attacks. And let’s please stop citing this deeply flawed work that is not BCP. Whether IP source routing is disabled or not on a system should be of no consequence to TCP. It is either used or not; when used, TCP *MUST* support its use

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Nov 29, 2021, at 7:12 PM, Wesley Eddy <wes@mti-systems.com> wrote:
> 
> One of the IESG comments that needs to be addressed on 793bis regards source routing.  There is the comment:
> 
> [S3.9.2.1]
> 
> * I feel like there should be some additional caveat about security
>   implications of support for source routing.  RFC 6274, for example, says
>   packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
>   be dropped, citing various security concerns.
> 
>   I'm not sure there needs to be a lot of text; perhaps just an observation
>   that some end systems may not support the source route semantics described
>   here for security (or policy) reasons?
> After looking at what 6274 says (which is Informational) and 793bis, here are my main thoughts:
> 
> (1) The text in question was written for IPv4, prior to IPv6 with its own methods (deprecated RH0, and now other things like segment routing).
> 
> (2) I'm not aware of anything changing with regard to 1122's description of IPv4 source routing support in IP stacks.
> 
> (3) Looking at defaults on popular Linux systems, it looks like "net.ipv4.conf.default.accept_source_route = 1" is not uncommon ... so source routing support probably still exists.  I didn't look at what the TCP code does though, with regard to incoming source routed packets to see if it matches what 793bis says.
> 
> So, my suggestion is that we rename that section of 793bis (section 3.9.2.1) to be specific to *IPv4* source routing, and then append at the end of the section a sentence like:
> 
> RFC 6274 describes security concerns with IP source routing, and source routing may be disabled or unsupported on some systems.
> 
> Does this sound good?  Note that it basically leaves any flavors of IPv6 source routing unmentioned (which seems right, since there isn't anything on standards track to use).  I would be very happy if someone more knowledgeable about the state of source routing support and usage could check this and share their thoughts.
> 
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm