Re: [tsvwg] Some unclear points about rfc4960 (SCTP).

Michael Tuexen <michael.tuexen@lurchi.franken.de> Wed, 18 August 2021 20:36 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 E98613A1CB9 for <tsvwg@ietfa.amsl.com>; Wed, 18 Aug 2021 13:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.489
X-Spam-Level:
X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 8p5oUvH5loJV for <tsvwg@ietfa.amsl.com>; Wed, 18 Aug 2021 13:36:06 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5163A1CB8 for <tsvwg@ietf.org>; Wed, 18 Aug 2021 13:36:04 -0700 (PDT)
Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id AAF62721BE01D; Wed, 18 Aug 2021 22:35:54 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
X-Priority: 3
In-Reply-To: <tencent_44A50ABA9EBA70683A9D0EEA4002DCB08607@qq.com>
Date: Wed, 18 Aug 2021 22:35:54 +0200
Cc: draft-ietf-tsvwg-2960bis <draft-ietf-tsvwg-2960bis@ietf.org>, tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <25F1E85E-CF66-4A49-B2BA-EC46E0428C6E@lurchi.franken.de>
References: <tencent_44A50ABA9EBA70683A9D0EEA4002DCB08607@qq.com>
To: 一念之后★だ <zhouming948@foxmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/AGVvtx1xvSbDew-TK7OyFzsh2OU>
Subject: Re: [tsvwg] Some unclear points about rfc4960 (SCTP).
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2021 20:36:10 -0000

> On 17. Aug 2021, at 18:56, 一念之后★だ <zhouming948@foxmail.com> wrote:
> 
> Dear IETF experts,
> 
> I read rfc4960 (SCTP) and felt that there were some unclear descriptions in the document. I hope to get your reply, so I wrote this email to you. And I think it's better to describe these more clearly in the subsequent version of the RFC.
> The following description describes some scenarios requiring abort Association in rfc4960:
> Page25
> 
> 
> <8BD7343D@5C03830D.45EA1B61.png.jpg>
> 
> Page26
> <35034230@AD73F10A.45EA1B61.png.jpg>
> 
> Page30
> <30040808@E72FC146.45EA1B61.png.jpg>
> 
> Page31
> <3B65D2C9@0ACE147B.45EA1B61.png.jpg>
> 
> Page56
> <8E3B5E0D@11868C69.45EA1B61.png.jpg>
> 
> As can be seen from the above description, when an init message or init ACK message is received,
> (1)If the init tag in the message is 0, the association must be released
> (2)If the mandatory parameters in the message are not fully carried, the association must be released
> (3)When the OS value or MIS value in the message is 0, it is strongly recommended to release this association
> 
> The following description also shows that there can only be one SCTP association between two SCTP endpoints at any time:
> <0096CA66@4B725944.45EA1B61.png.jpg>
> 
> 
> Because init messages can be forged arbitrarily, take the scenario where the initial tag in init message is 0 as an example.
> In this scenario, a malicious attacker can destroy other associations at a very low cost:
> <5E5A32BF@B01FE933.45EA1B61.png.jpg>
> 
> For the other two scenarios, i.e. init message with missing mandatory parameters or init message with OS value / MIS value of 0, the effect may be similar.
> I think from the original intention of the protocol design, these error scenarios should be handled according to the following. However, the RFC does not specify how to deal with the established association endpoint when receiving this wrong init (or init ACK) message, and whether the corresponding association should still be removed.
> <FE060690@88C75D15.45EA1B61.png.jpg>
> 
> Unfortunately, the SCTP implementation of Linux will be affected by the attacks described above, such as the open source lksctp.
Which version of the Linux kernel are you referring to? I tested it on the 5.11 kernel, which is used
by Ubuntu, and can't reproduce the issue. Maybe it was fixed recently?

Best regards
Michael
> I hope to receive your reply to clarify the above unclear areas.
> Thank you very much.
> 
> Yours faithfully!
> Zhouming.