[tsvwg] Re: [Technical Errata Reported] RFC9260 (7988)

Randall Stewart <randall@lakerest.net> Thu, 13 June 2024 17:03 UTC

Return-Path: <randall@lakerest.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0066EC180B6E for <tsvwg@ietfa.amsl.com>; Thu, 13 Jun 2024 10:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tEaYgN3QWBtY for <tsvwg@ietfa.amsl.com>; Thu, 13 Jun 2024 10:03:09 -0700 (PDT)
Received: from smtp-out.a.misk.com (smtp-out.a.misk.com []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB4DC15152E for <tsvwg@ietf.org>; Thu, 13 Jun 2024 10:03:09 -0700 (PDT)
X-Authenticated-User: randall@lakerest.net
Received: from (syn-072-239-139-254.res.spectrum.com []) by smtp.misk.com (MiskSMTP) with ESMTPSA id be495c6d170c4ad5a68c2eb3252802d7 for <tsvwg@ietf.org>; Thu, 13 Jun 2024 16:32:59 +0000
Message-ID: <2fbe4420-1121-4de9-8f2b-b74f20c585eb@lakerest.net>
Date: Thu, 13 Jun 2024 12:32:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: RFC Errata System <rfc-editor@rfc-editor.org>, tuexen@fh-muenster.de, kee@kamstrup.com, tsvwg-ads@ietf.org, gorry@erg.abdn.ac.uk, martenseemann@gmail.com
References: <20240613135721.49E7A204E21@rfcpa.rfc-editor.org>
Content-Language: en-US
From: Randall Stewart <randall@lakerest.net>
In-Reply-To: <20240613135721.49E7A204E21@rfcpa.rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-MailFrom: randall@lakerest.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: milen.hristov@huawei.com, tsvwg@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: [Technical Errata Reported] RFC9260 (7988)
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2-rEu_uM2Cvl923IGq4AIstrtxU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>


So I have just had a look at this "Errata". I disagree with it. Section 
3 defines data formats and

does not specify what IP addresses are accepted or used in sending an 
INIT. Section 5 has details

on association setup. Note also that Section 5 explicitly states that 
the receiver of an INIT must

respond to the senders IP address NOT any of the IP addresses listed 
within the INIT chunk. This

is an important security concern. A secondary listed address cannot be 
used until a heart beat

validates the address by sending a HB to the address and receiving a 
response from the address.

The Errata IMO is invalid ... Michael? Do you agree or am I missing 


On 6/13/24 9:57 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC9260,
> "Stream Control Transmission Protocol".
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7988
> --------------------------------------
> Type: Technical
> Reported by: Milen Hristov <milen.hristov@huawei.com>
> Section: 3.3.2.  Initiation
> Original Text
> -------------
> not clearly specified  sending IP Address for INIT
> Corrected Text
> --------------
> INIT can be accepted from either the Primary or Secondary IP Address
> Notes
> -----
> Oracle explained clear
> https://docs.oracle.com/cd/E57516_01/docs.70/Transport_Manager/concepts/c_transport_mgr_multihoming.html
> Some vendors do not accept INIT sent by Secondary Peer IP Address
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
> --------------------------------------
> RFC9260 (draft-ietf-tsvwg-rfc4960-bis-19)
> --------------------------------------
> Title               : Stream Control Transmission Protocol
> Publication Date    : June 2022
> Author(s)           : R. Stewart, M. Tüxen, K. Nielsen
> Category            : PROPOSED STANDARD
> Source              : Transport and Services Working Group
> Stream              : IETF
> Verifying Party     : IESG