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

Claudio Porfiri <claudio.porfiri@ericsson.com> Wed, 19 June 2024 13:21 UTC

Return-Path: <claudio.porfiri@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA25C16942C; Wed, 19 Jun 2024 06:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.255
X-Spam-Level:
X-Spam-Status: No, score=-7.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ericsson.com
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 cPiyRKeYWndu; Wed, 19 Jun 2024 06:21:40 -0700 (PDT)
Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2088.outbound.protection.outlook.com [40.107.247.88]) (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 5D4C3C14F701; Wed, 19 Jun 2024 06:21:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C7Lxokoks8UHm9kctPjbjU6ZXvRk1VZ+PeE9JxuDpv6l37fnlG7B1QcsB82OYKhVYQAD97qkXfZrARgmcWtSG0w5msCVPx/H6frb+uyuuj/hksuY8MKNJn4Mldm6Pr+HIGZaLI75lTUiUVG0eDV+HZxeqOe4ORmfOrD3F+HDewjnbOdCgJjwU9Yg3dBLHlcd9CeU4GlBVf07qtrDI24b9gf10/biyvFVZo74n0OkE77EExQ4QLbcljGLoXyb/yf6dGxH45VpWbocDAVrcQJm9dPrRppWKP9YBVZaqYQWnZsD7zWeVW4se3BhidWI5gTi3ymg3V0cQ8Cz+DR1O3J1vQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Lc0FHRq2pXUytrvjxmTxfa5ywyXgxyCQosgD8vAUFJY=; b=XiX+svVsH6vWVKUAgx3WLyxcVsHd6jxcl9zjQQnZfHBrGVwZ5HOQkFGhkNV+FnO4sKAG5pcz2mJ/UFjLogJqiJaAYVIwET4aGnouwMbvEYCm6qMCMpRUmXTdacTRztNXrEkhTEJBbh9tUt/PnkynlygrC/dHaUwbt20vVJRSABq2XyNi9gAk1EYMGNUZEmqJiN/2WynyGjIl53a2qYirs4oN2PAMvefYo/ntyFbj/WbihKIXmkha+/XC4Zjc9UFbXCP49eH7Gt2IQiJwmG7TX/bmtu69/LdEFKEtbk2yrjQDXOb+Ql/sMsPweFK5slvmrAezLshE6ZfNF+HGlIuqMQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lc0FHRq2pXUytrvjxmTxfa5ywyXgxyCQosgD8vAUFJY=; b=YBqJHDUeeOsb53+DFHhqQ+B13WcNjONi2JHbhHMVUPZANAYZ63I2mktbHzMUM5MlmaoKXE78yoJc/R4tISXTnCQLwZfkWwTeIakCVf+1QDNF4MusuAvsTN7KqAMoTdxrFd0RTxVVxsEZeG6Ni96Qsf6939O742hTK/lN8Ik2BQGPhLMcwLE7ocX8nf8t5JY3TWBJCzKyOBalEzMOPhz8BHWNBcks2iZ7FJC/J0/EN97/j/bWS+PqKZllpQTkAx4iQL1s30FxGhBhARLBhoATXFTc46uH2Pl2IrrcsSRKi9us1BAD0m339tq1Cgi32Z3s/sCZcKS3pRxvGVH0WoFWew==
Received: from PA4PR07MB7568.eurprd07.prod.outlook.com (2603:10a6:102:c7::23) by AS2PR07MB9121.eurprd07.prod.outlook.com (2603:10a6:20b:558::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.17; Wed, 19 Jun 2024 13:21:34 +0000
Received: from PA4PR07MB7568.eurprd07.prod.outlook.com ([fe80::24ac:f21:985e:9f57]) by PA4PR07MB7568.eurprd07.prod.outlook.com ([fe80::24ac:f21:985e:9f57%6]) with mapi id 15.20.7698.017; Wed, 19 Jun 2024 13:21:34 +0000
From: Claudio Porfiri <claudio.porfiri@ericsson.com>
To: Milen Hristov <milen.hristov@huawei.com>, "tuexen@fh-muenster.de" <tuexen@fh-muenster.de>
Thread-Topic: [tsvwg] [Technical Errata Reported] RFC9260 (7988)
Thread-Index: AQHawkD19uPx0RGj4UWNX49YKEyzmrHPCtMAgAAB5LCAAAOkAIAAAaww
Date: Wed, 19 Jun 2024 13:21:34 +0000
Message-ID: <PA4PR07MB7568DE4887465290FC1D7D4887CF2@PA4PR07MB7568.eurprd07.prod.outlook.com>
References: <20240613135721.49E7A204E21@rfcpa.rfc-editor.org> <2fbe4420-1121-4de9-8f2b-b74f20c585eb@lakerest.net> <4FEBA794-80C9-4505-95AF-F7200F126386@fh-muenster.de> <e45611bf9aa7456c9615e22f35ef0a8d@huawei.com> <4333FC2B-779A-4F2F-8BAB-96315DDB9807@fh-muenster.de> <208A36A5-A56E-4107-A07E-67AEBCD68837@fh-muenster.de> <CAEh=tcdaagPCmT3JyZfq_XhzMf=VHsY3unmgviDn6y29imXDcA@mail.gmail.com> <PA4PR07MB7568CB0836C28585807A368D87CF2@PA4PR07MB7568.eurprd07.prod.outlook.com> <b75cb0b19d9948b3899da8ed1a18f9e4@huawei.com> <3BF73DBE-EB9A-4C81-B8C8-4BA3FACC16DF@fh-muenster.de> <8f681d29b2284812a39f96d28d2ba000@huawei.com> <PA4PR07MB75687C6DC37E481F519375AA87CF2@PA4PR07MB7568.eurprd07.prod.outlook.com> <2061b041493449b695ba085770312d43@huawei.com>
In-Reply-To: <2061b041493449b695ba085770312d43@huawei.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PA4PR07MB7568:EE_|AS2PR07MB9121:EE_
x-ms-office365-filtering-correlation-id: ba4c96f3-4c70-4aab-8f7b-08dc9062bdee
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230037|1800799021|376011|366013|38070700015;
x-microsoft-antispam-message-info: rSR5XW7YQwvKTA4VJdPRH4SSOcv3m9ZDh3eZuxn3rM/I8WH4wHl77SiyH239MvZoRwlGA1g4lGZwMdvre31gcaM1GwuIOzShiCt+24EsguoZ2/7ZjMhgnBz6zXzR33AipCqKMhCvgXXUFZ15JrkD21RkWfKQPomHSCsmjXegWqLFiBEu1aVaSp+wxrBLnkoybydhKyWTH11gsKa4u5LahiDGi/oMNI/SlW0ydiP5B7dJz9F9BOW36bpokV+F9QM1+fANn+Jbv6mEnLWZ456uLuJaaFbKXSpSDcGMUYgxx6mdJR9LShb6PXyAm936Ux5qlWurtI0y4JAT2FDtJq5loPsrfbXzpJEXfLe+NWIIFvPABI9ltfjKkY0KVEj2soFLepobydPVkUxLp+SpCb3lduLreHZOe0lw0QqrAm7rXt7wllDdwYk42UaH8qZd6GwdL6B3BJwljx1kMwgDuXtDomJpRKl2sDzc0S6ppCc+E2L+a8kR+jREOR2Xx5QwjTZcjwP1bl7/ERh+cEvpmKArmbQG2OTZEiek933OgNsFtZ+cDoV2I55NRLMgyUDrw0/EwU1ga5GZDgE/Kvu2LLkAuwCde50RJ7U/wcZvhfkoW23SqVFccxjoR8vhsehP9Eo63WqxrxVoSvhWMGPaF6F7XBfLt0+CM0afCKGRfDJYclwKAkr1CIsk9gnoT1bNTu+WOghmPPGmWHWUs6z4tPd7TqYLLroAHCQfWFnTjhJZMTfVnlcMmOxRIlfHcRKtsGCjHSD18JA744FVo8PN/pyhOUa9RQiK5QAspgJKjDb5nKSBdrowh8O/zn/fGy5lgpklbVqe+apfJ5K8jJsL1sNe9gNpxbaFyHxIdWj8do1A8qoW+dMw1HGWIpsRbn3HdK+SyVnL7WS/jJ1KEIQQobPyHxE+zFOGuZgilbbmaly8iTLHYJTDWk9Yp6ggVzAfk8Ohgth7KoGCJAgZDkai4wohv1AI6UVIqxTGq4lg9n1kc7pAvIkgjYdMYkPBzfBQVf0nbLAIWM/5EYcOT5h60bgoVSNPqN8HqAFany4/k6R/dyZYazMGlk1zPOaclkNX+vGwXCihEMc+/1YZnPFCsa2MWXTI7cFbzp/5VAifs2utBJ+K/e5HIrhG/q15eyjkRPT/wmgXUH0COZ2idJzkkLvjUxuobe+eFtCo+I/FicBYxfiQpZfxmLE39xuesleGcs8PH5ud1+InOZpCh2FgYHbN90O3f3qIoEGSJJCEnuKwqPt9/9sY+RhKF7xZY5GshCc6Iy8JfkaGmF2Rq7LaYePuszu2fBPjBQP1wyBaiAPCAO6hOcNLGJTfAoNBvUUJ10vG
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR07MB7568.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230037)(1800799021)(376011)(366013)(38070700015);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: RZJKnvhrXhEYytfbsNlGZROcq/GDOkaR4HSqEn5ayxFsAEl/CMbj1fIibQTsQ0iVRev7V8pDutwo2JaCtW7u29ZyStWzlLayZSbuxMO9fbLwXRI65HBWUHwGceTb+Eyn/Ewud251SRv/1vWjBiSwVr5R2B41c/a4LO61eMrKiZVTd/x7my4UVLsKTSQfjx+ronyDf6gtGZyAHw3jg4q6h05NgvMNzmu3DvkmF/f8RFmYleH95ZrLVCuTj4wb750iMsc0TfQHr6PzzBsab4DJhI/Vbh7S4mJxTseuTE5RasFxNSCpGKOEaVlPu9zQUac7SctbZcQQsvp6FBgF6q25s3Og892hriaiUPPjbG/vSZCOAPucjvpBgNWbJCmOhrEMQfMIO+QQONzkQve4CrDJZ7Lu7XymX8sECiBaqc16iFfSNlCX1GkoJc9aue7FtN/I6ATBg5AkhrldGffvwdq4xdLuicXcU1FhjP0v3jvi1oXt13GfiYqTC4uFjubZ9x4YTzuqywMdJ5sOoPf6d/gtUKT9lmytZz3ZYpFUmuTsOPpfBGZ8sl9RfSHTGWAq2ELIddHxmyRGIOl5wmLRHlLQo31vK/OCq0gwwOs+wo4TfslcYPcQq7kbwqo6q8O/UtgVcGo8F/t1EbSmSDxlzTv5T9mznSZn76sf78nmUOnOP+fHGSj3M2367lhswA2BolXLy4XhDFBOEuESnXShwrzUnpDFLXVqagxdbIqL8SnoJXBg3vCSlcz0qVqeZ0n07MiwAea6jrM6jh6yyBMykjIZKMg0T3ZSLgRgOh7r6//n7SZz1rcb1uY/g87bXzuHqi0v0B9oPhk/7jcgVyZyT/t5hHY4r10UR8n43pDGMFfvxov6Vwxv+BI+XpkqgNntkM2fENcai7DPmbzHAXqNxbpXL+bI0jWcX5JHs5QznZVAeIwZ/zVueVmJTVH56kmy14/28p7TIxLtDT5MpbtVYRrkHAwEPWSE8CmcmOuE5WeeK2Yq8nO/xkI4NKoxEHyyfZcDJUiXu0lkgbgXqu5JWAtsXhOYucd/U0pg3LDz9D/s95L35ifeytgdBdX+bkBlEUx/yE9aB4efGZWgrN9J1L1beVbnCNSdKvZyI1E1j6IMhSJNRUnLnBXrZCZs8hLxVDX+eeimE0U+GRjKsp4pxk1vbWCAj+TCiPtS3YZ4UuS6vXaWQ0HB3DjsxhgbLsOyO1RzGLn2aTcf0bMG6OYY1YSSLhTBF4ohPlxgN2tT10fG/WLa/T6GpFdCCKg2vRViLPcU2BxU9+L9Z8WXpbh0GYXmw+sLO9Zr9PHw8GqjoUkF/Pa7x7GyiOcpOl117+v9zovAcDZo0s2dX5v7WGlNBUP24cas/xtXZhmokvK3cnV9yvIgI2zOFK/9p794I94BMBWY15aq59HOOtMggCOhosbcsAsz2iz2aMCbYDUzw6e75lHoM3zjzCS/ziXuOHgif5A8I/6bjmk9yWzAJdT161GwBY7zvIwl+rUwKyC9MfQdcvQD34dCcgymlEeSUyTD+sSSMi5+HGsmBkqbSlPNvtct/7HWQoiHpbLgNNlX8msUpVeDzDH/EsykTrKYknsh3M/WgkdMeOhxGy7M0tOH8dCRhA==
Content-Type: multipart/related; boundary="_004_PA4PR07MB7568DE4887465290FC1D7D4887CF2PA4PR07MB7568eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PA4PR07MB7568.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba4c96f3-4c70-4aab-8f7b-08dc9062bdee
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2024 13:21:34.6878 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ubQBc+0TH3yjjYwCGZNGKgWQs1PewTR7TZOPhEkFHSLwEXE2fELssBzApVSrmbNPRbI4Hy8XOXWe4SbtPn0odAAIlk0kQqEwX/BskdQ/ovA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR07MB9121
Message-ID-Hash: V6VXU5LAEIG56REU77FEUY3XZT7QNMV2
X-Message-ID-Hash: V6VXU5LAEIG56REU77FEUY3XZT7QNMV2
X-MailFrom: claudio.porfiri@ericsson.com
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: Randall Stewart <randall@lakerest.net>, RFC Errata System <rfc-editor@rfc-editor.org>, tsvwg-ads <tsvwg-ads@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <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/KmARqJ0C3lDnyrv9Wz_IH0Rwqyc>
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>

Hi Milen,
It’s not really the RFC that should dictate to the application how to behave, but since I guess that this is 3GPP related,
It may be a good point to propose to 3GPP, the relevant TS are the ones describing how protocols such as S1-APP etc use SCTP.

Regards,
Claudio

From: Milen Hristov <milen.hristov@huawei.com>
Sent: Wednesday, June 19, 2024 3:13 PM
To: Claudio Porfiri <claudio.porfiri@ericsson.com>; tuexen@fh-muenster.de
Cc: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>; Randall Stewart <randall@lakerest.net>; RFC Errata System <rfc-editor@rfc-editor.org>; tsvwg-ads <tsvwg-ads@ietf.org>; Gorry Fairhurst <gorry@erg.abdn.ac.uk>; tsvwg <tsvwg@ietf.org>
Subject: RE: [tsvwg] [Technical Errata Reported] RFC9260 (7988)

Hi Claudio,

Yes, it is application layer sending SHUTDOWN, but it is related with SCTP IP addresses
That’s why I think should be clarified in RFC for SCTP that Secondary SCTP path can be used for INIT

If not, where should be?

Best Regards
Milen Hristov

From: Claudio Porfiri <claudio.porfiri@ericsson.com<mailto:claudio.porfiri@ericsson.com>>
Sent: 19 June 2024 15:06
To: Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>; tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>
Cc: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com<mailto:zahed.sarker.ietf@gmail.com>>; Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>; Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: RE: [tsvwg] [Technical Errata Reported] RFC9260 (7988)

Hi Milen,
Now I see the problem.
Actually it’s not SCTP deciding to shutdown the Association.
The Association has been accepted, it is up because the initial handshake has been completed and  I guess communicated to the client.
It’s the client that, based on design decision, has decided to shutdown the Association.
It’s not and cannot be the SCTP protocol stack as far as I see.

Regards,
Claudio.


From: Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>
Sent: Wednesday, June 19, 2024 2:53 PM
To: tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>
Cc: Claudio Porfiri <claudio.porfiri@ericsson.com<mailto:claudio.porfiri@ericsson.com>>; Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com<mailto:zahed.sarker.ietf@gmail.com>>; Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>; Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: RE: [tsvwg] [Technical Errata Reported] RFC9260 (7988)


Hi Michael,



Again to clarify the setup and example with trace



endpoint C (acting as a client) has two IP addresses -IP1_client(10.218.121.247) and IP2_client (10.218.121.248)

and

endpoint S (acting as a server) two IP addresses- IP1_server(10.218.6.26) and IP2_server (10.218.6.154)



Primary SCTP path1 (IP1_client 10.218.121.247- IP1_server 10.218.6.26)

Secondary SCTP path2 (IP2_client 10.218.121.248- IP2_server 10.218.6.154)



Both endpoint C and endpoint S are located in same network– both endpoint know all IPs

The problem is only with  the receiving side-- endpoint S (acting as a server)



receiving side-- endpoint S  received INIT  via Secondary SCTP path2

receiving side-- endpoint S  replied with INIT_ACK

the client sent COOKIE_ECHO

receiving side-- endpoint S  replied COOKIE_ACK



and after that …SHUTDOWN…

the vendor of  receiving side confirmed the reason is the sending IP is IP2_client , but not IP1_client



[cid:image001.png@01DAC25C.5E60E880]



Best Regards

Milen



-----Original Message-----
From: tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de> <tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>>
Sent: 19 June 2024 14:05
To: Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>
Cc: Claudio Porfiri <claudio.porfiri@ericsson.com<mailto:claudio.porfiri@ericsson.com>>; Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com<mailto:zahed.sarker.ietf@gmail.com>>; Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>; Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: Re: [tsvwg] [Technical Errata Reported] RFC9260 (7988)



> On 19. Jun 2024, at 11:09, Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>> wrote:

>

> Hi Claudio,

>  I cannot agree that The implementor(vendor) can decide anything, when is related to interconnect to other vendors

> This is not some internal proprietary  solution

>  Finally the purpose of RFC is to define rules and all vendors must follow them

> Otherwise interconnection will not work, if all vendors  decide to implement  their own solutions

>  The document from Oracle is describing specific scenario– yes could be, but this scenario should be described in RFC

> This is not case with dynamically IPs- all IPs are defined statically on both ends- Client and Server

> So the server knows the sending IP, but rejects the INIT, just because is Secondary IP

>  Finally the rule in RFC should clearly specify- secondary path can be used for INIT or not

> If not- then all vendors  should disable sending INIT by secondary IP

> Why secondary IP could not be used for INIT?

Dear all,



I think we should be clear on terminology. RFC 9260 does not define the term secondary

IP address or secondary path. It only uses the term primary path. This is the pair

of source and destination address used for *sending* packets, not for receiving.



I guess we are focussing on a client/server setup.



In this case the client must know at least one address used by the server.

The application can pass this list of IP addresses to the SCTP stack

(sctp_connectx() in the socket API) and I would expect the client to use

all of the known addresses to setup the association.

This is described in

https://www.rfc-editor.org/rfc/rfc9260.html#section-5.1-5

But this is the sending side, not the receiving side.



For the receiving side we need to look at the local side.

An endpoint has a list of addresses. In the context of

the abstract API, this is provided by the

https://www.rfc-editor.org/rfc/rfc9260.html#section-11.1.1

primitive. In the socket API, it is by using sctp_bindx().

Without doing Dynamic Address Reconfiguration (RFC 5061),

this local list does not change over time.

All these addresses can be used to sent packets to. And these

are the addresses, which will be listed in the INIT or INIT ACK

chunk (modulo address scoping).



So I guess that question is whether the client knows in advance

only a single IP address or multiple IP addresses of the server.



In my view for redundant communication it is important that both

sides use at least two independent IP addresses. And this includes

the association setup. Therefore the client needs to know multiple

IP addresses of the peer in advance. This knowledge should not come

from previous associations, but from explicit configuration.

But this is not a requirement of the protocol, but how people want to

operate their network.



Best regards

Michael

>  Best regards

> Milen

>   From: Claudio Porfiri <claudio.porfiri@ericsson.com<mailto:claudio.porfiri@ericsson.com>>

> Sent: 19 June 2024 07:10

> To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com<mailto:zahed.sarker.ietf@gmail.com>>; tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>

> Cc: Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>; Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>; Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>

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

>  Hi Michael, Milen,

> About the specific case described, I am not sure that anything needs to be changed at the RFC, I think it’s clear as it is.

> The implementor can decide that the pubic SCTP Endpoint is limited to a single IP address and then decide that it only answers to that IP address, this cannot be forced by RFC,

> It may even be that the other addresses used for multihoming are instantiated dynamically and only exist during the lifetime of an Association.

> The owner of the node may have implemented Access Rules that filter out INIT and having the same result.

> If you have interoperability problems this should be solved by proper configuration.

> The document from oracle is describing a very small subset of what is possible with SCTP and multihoming, it cannot be taken for replacing the RFC.

>  That is my 10 cent to the discussion.

>  Best regards,

> Claudio

>  From: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com<mailto:zahed.sarker.ietf@gmail.com>>

> Sent: Tuesday, June 18, 2024 10:38 PM

> To: tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>

> Cc: Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>; Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>; Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>

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

>  Hi Michael,

>  Yes, you are accurate about the process ( for more information see : https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/) What I need to see is the proposed text then decide on whether the change is technical or not. I am expecting here, from the discussions, is "hold for document update" status. Let me know if that not the correct status for this errata.

>  So, please proposed the text so we can agree on the text.

>  //Zahed

>  On Tue, Jun 18, 2024 at 11:45 AM <tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>> wrote:

> > On 18. Jun 2024, at 20:39, Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>> wrote:

> >

> >

> > Hello,

> >

> > if everyone agree with this statement, can be written in the RFC ?

> You cannot change an RFC. And only ADs can change Erratas. So I can propose

> some text change, we can agree on it, and then either an AD has to put

> that text change in your errata or I (or you) file a new one. That would

> (in my view) be classified as Editorial and can be approved by an AD, if

> the AD agrees with it.

>

> So should I propose some text change?

>

> Best regards

> Michael

> >

> >

> > Regards

> > Milen Hristov

> >

> > From:Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>

> > To:tuexen <tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>>

> > Cc:Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>;RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>;kee <kee@kamstrup.com<mailto:kee@kamstrup.com>>;tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>;Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>;Marten Seemann <martenseemann@gmail.com<mailto:martenseemann@gmail.com>>;tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>

> > Date:2024-06-14 12:10:32

> > Subject:RE: [Technical Errata Reported] RFC9260 (7988)

> >

> > Hello, yes, the Secondary path to be used, because the Primary is unavailable

> >

> > Regards

> > Milen Hristov

> >

> > From:tuexen <tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>>

> > To:Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>

> > Cc:Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>;RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>;kee <kee@kamstrup.com<mailto:kee@kamstrup.com>>;tsvwg-ads <tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>>;Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>;Marten Seemann <martenseemann@gmail.com<mailto:martenseemann@gmail.com>>;tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>

> > Date:2024-06-14 12:04:49

> > Subject:Re: [Technical Errata Reported] RFC9260 (7988)

> >

> > > On 14. Jun 2024, at 10:24, Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>> wrote:

> > >

> > > Hello All,

> > >

> > > Thank you for  the quick reply

> > >

> > > The errata is not intended to change any network element function, but only to make the RFC more clear

> > > I am not sure in which section is better to be, you decide

> > >

> > > The multihoming SCTP description by Oracle is very clear and same is implemented by most of big vendors like Huawei and other

> > > https://docs.oracle.com/cd/E57516_01/docs.70/Transport_Manager/concepts/c_transport_mgr_multihoming.html

> > >

> > > but some small vendors do not accept INIT sent via  the Secondary path by Secondary IP Address

> > > they consider Secondary path to be used only for failover , but not to re-establish the SCTP association

> > >

> > > this issue was raised by the following scenario:

> > >

> > > endpoint C (acting as a client) has two IP addresses -IP1_client and IP2_client

> > > and

> > > endpoint S (acting as a server) two IP addresses- IP1_server and IP2_server

> > >

> > > Primary SCTP path1 (IP1_client- IP1_server)

> > > Secondary SCTP path2 (IP2_client- IP2_server)

> > >

> > > Both paths  use  separate IP transmissions

> > > Initially the association was  established by Primary SCTP path1

> > >

> > > There was  transmission outage, affecting both SCTP paths-  SCTP association was down

> > > Later only the transmission for  Secondary SCTP path2 was recovered

> > > Endpoint C detected IP2_server is reachable and started sending INIT (via Secondary SCTP path2 )

> > > but endpoint S rejected the INIT sent by IP2_client

> > Assuming that the server is bound to both addresses, it should accept the INIT and

> > send an INIT ACK back using IP2_client and IP2_server. This should work even in the

> > restart case.

> >

> > Is that what you want to clarify?

> >

> > Best regards

> > Michael

> > >

> > > Best Regards

> > > Milen Hristov

> > >

> > >

> > > -----Original Message-----

> > > From: tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de> <tuexen@fh-muenster.de<mailto:tuexen@fh-muenster.de>>

> > > Sent: 14 June 2024 09:10

> > > To: Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>>

> > > Cc: RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; kee@kamstrup.com<mailto:kee@kamstrup.com>; tsvwg-ads@ietf.org<mailto:tsvwg-ads@ietf.org>; Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; Marten Seemann <martenseemann@gmail.com<mailto:martenseemann@gmail.com>>; Milen Hristov <milen.hristov@huawei.com<mailto:milen.hristov@huawei.com>>;tsvwg@ietf.org

> > > Subject: Re: [Technical Errata Reported] RFC9260 (7988)

> > >

> > >> On 13. Jun 2024, at 18:32, Randall Stewart <randall@lakerest.net<mailto:randall@lakerest.net>> wrote:

> > >>

> > >> Hello:

> > >>

> > >>

> > >> 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 something??

> > > I agree with content of your answer: the destination address of the packet containing

> > > the INIT ACK chunk MUST be the source address of the packet containing the INIT chunk.

> > > This is stated in

> > > https://www.rfc-editor.org/rfc/rfc9260.html#section-5.1-4

> > >

> > > But I am not sure if this is what Milen is referring to. He only refers to the packet

> > > containing the INIT chunk. SO I guess it would be best if Milen can clarify, which

> > > problem he is experiencing.

> > >

> > > Just to be clear:

> > > Assume the endpoint C (acting as a client) has two IP addresses P_client and S_client, the

> > > endpoint S (acting as a server) two IP addresses P_server and S_server.

> > > If the application tells C to initiate an association towards S and provides both IP addresses

> > > (doing someting like sctp_connectx(P_server, S_server)), the packet containing and INIT

> > > chunk sent by C can use P_client or S_client as the source address and P_server and S_server

> > > as the destination address. The server S would except all possible four combination and would

> > > send a packet containing an INIT ACK chunk in response to the source address of the incoming

> > > packet as described above.

> > > I am wondering if Milen has observed a problem related to this description.

> > > Please note: whether or not the networks between C and S will forward packets with all

> > > four combinations is a different question.

> > >

> > > Best regards

> > > Michael

> > >>

> > >>

> > >> R

> > >>

> > >>

> > >> 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<mailto: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

> > >