Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing

Michael Tuexen <michael.tuexen@lurchi.franken.de> Mon, 18 March 2024 11:08 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 D07D1C180B4E for <tsvwg@ietfa.amsl.com>; Mon, 18 Mar 2024 04:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 Sd0ENtTlG65m for <tsvwg@ietfa.amsl.com>; Mon, 18 Mar 2024 04:08:44 -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 A8CF2C14CE2B for <tsvwg@ietf.org>; Mon, 18 Mar 2024 04:08:16 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:c6a0:3052:202:550a:8b4c:ffef:3f6f]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 78957721E2806; Mon, 18 Mar 2024 12:08:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <AS4PR07MB88744D44D4FC22A4A364EA5D952D2@AS4PR07MB8874.eurprd07.prod.outlook.com>
Date: Mon, 18 Mar 2024 12:08:10 +0100
Cc: tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <54EF29EA-B0B4-43E8-A930-B209C99545A5@lurchi.franken.de>
References: <AS4PR07MB887498E4AFC609054B074A40952E2@AS4PR07MB8874.eurprd07.prod.outlook.com> <DEB2D70D-C457-4D79-9BED-95582E993B2C@lurchi.franken.de> <AS4PR07MB88744D44D4FC22A4A364EA5D952D2@AS4PR07MB8874.eurprd07.prod.outlook.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/z5RmiK0ChMSLZ2PBdiwZl16G7-I>
Subject: Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
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, 18 Mar 2024 11:08:46 -0000

> On 18. Mar 2024, at 08:58, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> Thanks Michael,
>  I think your answer below makes it clear that it is possible to get DTLS chunk parties implemented in an open source operating system. I do understand the personal angle. I hope when the patent application becomes public before June the WG members will
Please understand what is formally possible might be different from what people
feel comfortable with. I think that the reservation I expressed is shared by
Marcelo, who is one of the Linux maintainers.

Best regards
Michael
> be able to analyze what the claimed IPR covers and what can be done without requiring any licensing and when such is needed in relation to different use cases where DTLS in SCTP would be useful security mechanism.  Cheers
>  Magnus
>   From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
> Date: Monday, 18 March 2024 at 17:18
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Cc: tsvwg IETF list <tsvwg@ietf.org>
> Subject: Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing
> > On 18. Mar 2024, at 00:04, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote:
> > 
> > Hi,
> >  In the design team we have discussion around barriers to implement DTLS Chunk (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-westerlund-tsvwg-sctp-dtls-chunk%2F&data=05%7C02%7Cmagnus.westerlund%40ericsson.com%7Ca4a855b754f64854b5a108dc471b9922%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638463431055544643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BKABYn4u4Xl77PKqWt8aN4r3fFchD0MSfXG8Qv1v0Kc%3D&reserved=0) as part of SCTP stacks that are in open source OS kernels. The discussion in the design team indicated that they could implement and release the functionality described in the above draft. What was raised as an issue was the testing of this code using the API that would exist to the upper layer implementation that would implement the DTLS handshakes and rekeying per: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-westerlund-tsvwg-sctp-dtls-handshake%2F&data=05%7C02%7Cmagnus.westerlund%40ericsson.com%7Ca4a855b754f64854b5a108dc471b9922%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638463431055553156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uaZ2mnJRe3DvzYkS7xqgIFKWErFdmoY0ioBtrvPjrOg%3D&reserved=0.
> >  Is there any reason why one cannot actually write code to test this API without implementing almost any of draft-westerlund-tsvwg-sctp-dtls-handshake? I would think the goal of the kernel parts is to show that the lower layer and its API works and can
> Hi Magnus,
> 
> this is my personal opinion with respect to implementing this in FreeBSD.
> Of course, one can do what you suggest. When I would implement it, most
> likely I would add support for it in packetdrill to do some functional
> testing. I guess some fuzz testing with tools like syzkaller would also
> be done.
> But when I'm implementing something (functionality in the kernel and
> an API for it) which has mainly one use case, I would really prefer to
> be able to test this in this use case. This is my personal preference
> and nothing requires me to do this testing. But not testing it seem
> sub-optimal to me.
> 
> Best regards
> Michael
> > be used by a higher layer application on top of the SCTP stack. In a test application one could use hard coded keys and have multiple sets  to test rekeying and not run DTLS handshakes at all between the endpoints.
> >  Cheers
> >  Magnus