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

Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Fri, 22 March 2024 21:27 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 BFF07C14F68A for <tsvwg@ietfa.amsl.com>; Fri, 22 Mar 2024 14:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGhjWh70gvmy for <tsvwg@ietfa.amsl.com>; Fri, 22 Mar 2024 14:27:22 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23C2C14F609 for <tsvwg@ietf.org>; Fri, 22 Mar 2024 14:27:22 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6e6afb754fcso2201465b3a.3 for <tsvwg@ietf.org>; Fri, 22 Mar 2024 14:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711142842; x=1711747642; darn=ietf.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=mCdqxJHuWFA3pRq6/9Fee9cN7ndT1KkqfwTIX8InyPI=; b=KEsYzziKrHnPxnTxd+0sODvmALi9mivv2aDK8p1joFbVyLa971X+gXfwDVIGBk3Ka8 8teq6FD4giHQDkoQ5hXXf8mTzbHymafOzy1uMHircNMDdWdNrJ5G8x0anfGfaTEyyZbo LgvkFjXiYE90g4ffwQSeggrxJ3TDr7f9k+Uw8Ea4aumQfao+4xOyKL2C26JuYOCbtUIS 6nkFBW8KfxmOBLazspknnWGIZeMsf80RQzhOlk48rUucpX1r7iuFYPHEY0bDXYkw2tLl J8wvkHfU5mA09ehZSNZNFOeT3Oly2pfmzY8731zYQLa3ctxodMJdnzluN4djk6Jm1fCf vk1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711142842; x=1711747642; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mCdqxJHuWFA3pRq6/9Fee9cN7ndT1KkqfwTIX8InyPI=; b=VB4MVWra1O7qIlih7HMQDihF1qZzHxI0nsyA4r4cpKO7LN0ggX3QbB6lGe+brGFBsk a6iqovTij5rTE2JsjLxlfuEYJUMkvobsUyG7R/DX/ss76oBXGdwJ2wndauL6Ggvvf/cH ugSsU5NU0m06IieQXCVMkuU1cAYCO2t9ElnEAn5aufAns2VEsWMCQvGbE75cUanJd6nI kPFMTRhGCIKQt6q4LOmznFAQtBwA+JRAqqyqenbvnBdWKaow80VyxKzo5XL3WbaF2n+4 dPK/teCAm4ru20nHzvLxtYKwCauQm6Lw7sc2zlblLhNyGCliOv2ZvEKyr3fbwXaFP0yN 3bjA==
X-Forwarded-Encrypted: i=1; AJvYcCVEmhyky457mzgSvInIgRrRTXfRc8fP7uQhEMnH167aCqtD3pYojAmmnFC4Q4f+lKxLxNGBTPbZ2LNZWGkJ7Q==
X-Gm-Message-State: AOJu0YzFPZRizNOjOuYV4xXTA3aV4U4K2ffuuaQVr3kFjj30aD7xTsmF euh7ZJl9nT3beqerIY0OqdXSTR8gxppE2LhJ3OwIJ3Hw62/RhVgy
X-Google-Smtp-Source: AGHT+IEPe0zx0PRNc8qdglMslP9LzFnkZE4+vcar0QPWivgOPqAOhnuHaR1UgfkVyE4HsWvY5DDSgA==
X-Received: by 2002:a17:902:fc45:b0:1e0:983c:d686 with SMTP id me5-20020a170902fc4500b001e0983cd686mr1097870plb.20.1711142841774; Fri, 22 Mar 2024 14:27:21 -0700 (PDT)
Received: from t14s.localdomain ([2804:29b8:508a:7f2b:b9aa:eb89:fa54:c8de]) by smtp.gmail.com with ESMTPSA id n6-20020a170902e54600b001def0897284sm200720plf.76.2024.03.22.14.27.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 14:27:21 -0700 (PDT)
Received: by t14s.localdomain (Postfix, from userid 1000) id 03D5B90EEA2; Fri, 22 Mar 2024 18:27:18 -0300 (-03)
Date: Fri, 22 Mar 2024 18:27:17 -0300
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg IETF list <tsvwg@ietf.org>
Message-ID: <Zf33tSHk3pL0yPJP@t14s.localdomain>
References: <AS4PR07MB887498E4AFC609054B074A40952E2@AS4PR07MB8874.eurprd07.prod.outlook.com> <DEB2D70D-C457-4D79-9BED-95582E993B2C@lurchi.franken.de> <AS4PR07MB88744D44D4FC22A4A364EA5D952D2@AS4PR07MB8874.eurprd07.prod.outlook.com> <54EF29EA-B0B4-43E8-A930-B209C99545A5@lurchi.franken.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <54EF29EA-B0B4-43E8-A930-B209C99545A5@lurchi.franken.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LyPrzKvffyphCzhIumEG3xGowgY>
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: Fri, 22 Mar 2024 21:27:24 -0000

Hi,

On Mon, Mar 18, 2024 at 12:08:10PM +0100, Michael Tuexen wrote:
> > 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.

Exactly, Michael. Magnus, please consider that Linux (and FreeBSD) are
Open Source software, which are known to dislike licensed code for
many reasons. Even though the suggestion could fit technically, what
it essentially does is (with my upstream maintainer hat on) give me/us
maintainers more work, to maintain this additional code, that only
those willing to pay you can use. So thanks but no, I'm not interested
in finding hacky ways to (partially?) test code that the majority of
the users cannot benefit from.

I hope that the WG realizes the problem that this represents before it
is too late, otherwise we may never support DTLS over SCTP in the
Linux kernel.

Best regards,
Marcelo

> 
> 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
> 
>