From michael.tuexen@lurchi.franken.de Mon Mar 18 04:08:46 2024 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Mon, 18 Mar 2024 12:08:10 +0100 Cc: tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <54EF29EA-B0B4-43E8-A930-B209C99545A5@lurchi.franken.de> References: To: Magnus Westerlund X-Mailer: Apple Mail (2.3774.500.171.1.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2024 11:08:46 -0000 > On 18. Mar 2024, at 08:58, Magnus Westerlund = wrote: >=20 > 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 > Date: Monday, 18 March 2024 at 17:18 > To: Magnus Westerlund > Cc: tsvwg IETF list > Subject: Re: [tsvwg] DTLS for SCTP: DTLS Chunk kernel part testing > > On 18. Mar 2024, at 00:04, Magnus Westerlund = wrote: > >=20 > > Hi, > > In the design team we have discussion around barriers to implement = DTLS Chunk = (https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-westerlund-tsvwg-sctp-dtls-chunk%2F&data=3D0= 5%7C02%7Cmagnus.westerlund%40ericsson.com%7Ca4a855b754f64854b5a108dc471b99= 22%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638463431055544643%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV= CI6Mn0%3D%7C0%7C%7C%7C&sdata=3D%2BKABYn4u4Xl77PKqWt8aN4r3fFchD0MSfXG8Qv1v0= Kc%3D&reserved=3D0) 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=3Dhttps%3A%2F%2Fdatatr= acker.ietf.org%2Fdoc%2Fdraft-westerlund-tsvwg-sctp-dtls-handshake%2F&data=3D= 05%7C02%7Cmagnus.westerlund%40ericsson.com%7Ca4a855b754f64854b5a108dc471b9= 922%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638463431055553156%7CUnkn= own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C0%7C%7C%7C&sdata=3DuaZ2mnJRe3DvzYkS7xqgIFKWErFdmoY0ioBtrvPjrO= g%3D&reserved=3D0. > > 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, >=20 > 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. >=20 > 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