Re: [tsvwg] Errata for SCTP over DTLS
Michael Tuexen <michael.tuexen@lurchi.franken.de> Mon, 20 April 2020 17:43 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 AAA0D3A093E for <tsvwg@ietfa.amsl.com>; Mon, 20 Apr 2020 10:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.287
X-Spam-Level:
X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.275, 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 0Ol7oBKAo7QF for <tsvwg@ietfa.amsl.com>; Mon, 20 Apr 2020 10:43:04 -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 0B4A83A0B69 for <tsvwg@ietf.org>; Mon, 20 Apr 2020 10:42:44 -0700 (PDT)
Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id A8EA27220F41F; Mon, 20 Apr 2020 19:42:33 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <CAM4esxSYQEE8QWFB72adcAhU5ZRm8J8GSvBu92Y39hacjJw9Og@mail.gmail.com>
Date: Mon, 20 Apr 2020 19:42:32 +0200
Cc: tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8ED921F2-4856-4A08-A533-65361F713D39@lurchi.franken.de>
References: <CAM4esxSYQEE8QWFB72adcAhU5ZRm8J8GSvBu92Y39hacjJw9Og@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PnD2sdBFUEBGYq-5KJtJp1ZYVz4>
Subject: Re: [tsvwg] Errata for SCTP over DTLS
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: Mon, 20 Apr 2020 17:43:10 -0000
> On 20. Apr 2020, at 18:06, Martin Duke <martin.h.duke@gmail.com> wrote: > > Hello tsvwg, > > I'm seeking to verify this erratum: https://www.rfc-editor.org/errata/eid5744 but am definitely not an expert on SCTP over DTLS. > > Is this is a simple oversight in the document? A flaw in the design that should be fixed the next time around? Or just an incorrect report? Hi Martin, when sending the ChangeCiperSpec message you use the old SCTP-AUTH key, then you make the new active and then you send the Finished message. The time between the two messages might be short. They can't be in one packet. On the receiver side of these messages, the question is whether the new SCTP-AUTH key is already configured by the DTLS layer, when the second message is processed by the SCTP stack. Part of the answer depends on the interface between the SCTP stack and the DTLS stack and how the SCTP stack behaves of it receives a packet with an AUTH chunk using an unknown key. It could buffer it, for example, that is not specified. If you look at SCTP kernel implementations and DTLS userland implementations using the socket API, what sometimes (it is a race) happens is that the Finished message is processed by the SCTP stack before the DTLS configures the new key. Therefore that packet is dropped by the implementation. A timer based retransmission will fix that, but that is a performance impact. Ways to mitigate this are: (a) the sender waits some time between sending the ChangeCipherSpec and the Finished. This is more a workaround, and since you don't know how long to wait pretty hacky. (b) allow the Finished message to be sent with the old key. That avoids the problem. If I remember it correctly, the OpenSSL implementation of DTLS/SCTP does (b). So I think it can be approved. Best regards Michael > > Thanks, > Martin
- [tsvwg] Errata for SCTP over DTLS Martin Duke
- Re: [tsvwg] Errata for SCTP over DTLS Michael Tuexen
- Re: [tsvwg] Errata for SCTP over DTLS Maksim Proshin
- Re: [tsvwg] Errata for SCTP over DTLS Martin Duke