IETF Logo Mail Archive

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

Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Fri, 27 August 2021 01:53 UTC

Return-Path: <marcelo.leitner@gmail.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 32F313A00F7 for <tsvwg@ietfa.amsl.com>; Thu, 26 Aug 2021 18:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Eq1j96JIm3_Y for <tsvwg@ietfa.amsl.com>; Thu, 26 Aug 2021 18:53:53 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2DA3A00E2 for <tsvwg@ietf.org>; Thu, 26 Aug 2021 18:53:53 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id x5so4183778qtq.13; Thu, 26 Aug 2021 18:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5zgUjOYOeInMWdEBpeW+xFv09bvEjMSDDuMWkGbDiHc=; b=muAFmikmvY8M9Eb6ijPJs5gMY21cdZBDureWQNdM76bu3DKN7gqHXneoC+ZORPrteR k9MXK96uf+P5LjzpCuT8RY1/W5S2/4b/LuiSIWigfKPZ25kub7eXFNJfVrRaYlG97Lay i0F4is00l2f0cnEsBxpk8FUeBN+1hUAeMxtvkSpC1skmZaZVB4SUtJHKbYQ6c8TmujHx tfZRo/HsIPTd0cC5I3WqtCz2EAN9JX4WYBs8WyHWzL08nU9M4XXrW8Se40s44zEW1Nui MqPm1AzsJjyltWjOmsZBCnMhy/uQNqLkAOIEfEPLS69BLGYX6crL6HFzw99iFEr5uiNp rwSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5zgUjOYOeInMWdEBpeW+xFv09bvEjMSDDuMWkGbDiHc=; b=XS8bsy6s/LBiVyf9bmnkR26C0Ge6cR2UkKNldFJzaewZJNkFrycwft3VuOZsMGmaC1 YdkQ7gAoJgZkX1zGzpOVZ9/2ayyrykwtkN3nidkmUIkfkhlQbAJHcUCjF2mzLk3rgg4f AefRB3+COyp4CGf0YzqqTp7opSoRFMrYQjixXVMod1BL6tobOU8QGQUk5ogsbibctszE cI2eTdKnFQUfuhSXOtWZ49uKniQ4n3rD2rgvrNCiFGClgfio0eZ3K95bJ4m4i/NA2kHC mSB0tXk8Mg+Tavt6HC6xMu6XnpcKqpJSKZil3WeQ8dgxmmU7djXXYnNrqQFDC28DshQF MCHA==
X-Gm-Message-State: AOAM531ZdDFDeaqGcCvqLmCN2rWwGLNx22uPBpyLtl11B8yhtJSPXU8F rkTkZnQgu644b+zKRLpKzY+w3p4uHqE64g==
X-Google-Smtp-Source: ABdhPJwz7WA/PbssG4ChBj9mNW7OLoSaV/GAlQfy1DVErk9S9NXtW0vaAZtmlqTeLguRzp9Buj0nLQ==
X-Received: by 2002:a05:622a:14d:: with SMTP id v13mr6153354qtw.241.1630029230716; Thu, 26 Aug 2021 18:53:50 -0700 (PDT)
Received: from horizon.localdomain ([2001:1284:f013:b489:4ad2:2726:4869:7bb6]) by smtp.gmail.com with ESMTPSA id g11sm2831292qtk.50.2021.08.26.18.53.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Aug 2021 18:53:50 -0700 (PDT)
Received: by horizon.localdomain (Postfix, from userid 1000) id 12CE3C3D18; Thu, 26 Aug 2021 22:53:48 -0300 (-03)
Date: Thu, 26 Aug 2021 22:53:47 -0300
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: 一念之后★だ <zhouming948@foxmail.com>, gorry <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-2960bis <draft-ietf-tsvwg-2960bis@ietf.org>
Message-ID: <YShFq9zcfqDx1e3r@horizon.localdomain>
References: <tencent_020235B85610F75C84CBD32D777C04FEE00A@qq.com> <C6464D19-93F8-4A7C-B0E6-55ED35ACDA72@lurchi.franken.de> <YSUEBmWHpx6srF6V@horizon.localdomain> <55203F67-951A-4622-9991-56D9090E36E1@lurchi.franken.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55203F67-951A-4622-9991-56D9090E36E1@lurchi.franken.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PE3i0UrT47ki0I1KPYiV3i1EKZM>
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: Fri, 27 Aug 2021 01:53:59 -0000

On Wed, Aug 25, 2021 at 01:19:06AM +0200, Michael Tuexen wrote:
> > On 24. Aug 2021, at 16:36, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> > 
> > Hi,
> > 
> > Thanks Michael for the ping.
> > 
> > I tried to catch up with the thread here but I'm very confused. Can
> > somebody do a write up on the issue please? :-)
> Hi Marcelo,
> 
> Zhouming reported the issues in the Linux SCTP stack based on experiments
> with the handling of INIT chunks. It was assumed that the handling of
> INIT ACK has similar problems, but as far as my testing shows, there
> is a different issue with INIT ACK chunks. 
> 
...
> 
> (A) and (B) are critical, since they allow a blind attacker to kill an
> existing association if the attacker knows the IP-addresses and port numbers
> being used and the attacker can send packets with spoofed IP addresses.
> The attacker does not need to know the verification tag.
> 
> Does that make things clearer?

It does. Thanks Michael. I could reproduce the issues here as well.

On a quick debug now (nearly 11pm here, be warned ;) ), it seems (B)
is a more generic issue. The abort is being generated here:

packetdrill  4099 [014]   268.865045: probe:sctp_sf_violation_chunklen: (ffffffffc05edd1e)
        ffffffffc05edd1f sctp_sf_discard_chunk+0x4f (/lib/modules/5.14.0-rc6+/kernel/net/sctp/sctp.>
        ffffffffc05f0d94 sctp_do_sm+0x84 (/lib/modules/5.14.0-rc6+/kernel/net/sctp/sctp.ko)
        ffffffffc05f5deb sctp_assoc_bh_rcv+0xfb (/lib/modules/5.14.0-rc6+/kernel/net/sctp/sctp.ko)

By the check in [1]. The function sctp_sf_discard_chunk() is a generic
handler, and other chunk types (not just INIT_ACK) should be able to
trigger it as it is used in many other places [2] (search for it on
the defines. Line 95 is just an example). Whooops.

1.https://elixir.bootlin.com/linux/latest/source/net/sctp/sm_statefuns.c#L4545
2.https://elixir.bootlin.com/linux/latest/source/net/sctp/sm_statetable.c#L95

Best regards,
Marcelo

v2.23.0 | Report a Bug | By Email