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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Tue, 26 March 2024 13:06 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 20DAAC14F5F9 for <tsvwg@ietfa.amsl.com>; Tue, 26 Mar 2024 06:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 3IGVX-DSaYCS for <tsvwg@ietfa.amsl.com>; Tue, 26 Mar 2024 06:06:09 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D40BC14F6E2 for <tsvwg@ietf.org>; Tue, 26 Mar 2024 06:06:06 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2003:a:e03:d412:fcb7:f0a3:af7a:acd1]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 27DE4721E2806; Tue, 26 Mar 2024 14:06:01 +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: <Zf33tSHk3pL0yPJP@t14s.localdomain>
Date: Tue, 26 Mar 2024 14:06:00 +0100
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B06B8274-7085-4743-9967-801F4FAA4397@lurchi.franken.de>
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> <Zf33tSHk3pL0yPJP@t14s.localdomain>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/z00atHTbUYwMUJUe2LBpETOt9Qk>
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: Tue, 26 Mar 2024 13:06:14 -0000

> On 22. Mar 2024, at 22:27, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> 
> 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.
Dear all,

Martin asked at the TSVWG@IETF119 meeting what the position of the OpenSSL
project is on having IPR protected code in their code base.

I contacted Matt Caswell and got the following response:

The OpenSSL contains:

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

and someone contributing the the code base must sign a CLA which contains:

3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.

Therefore, the are two scenarios to distinguish:

1. People from Ericsson will contribute the change to the OpenSSL project.
2. People not from Ericsson will contribute code changes to the OpenSSL project.

The first case is simple: Then it is simple, since they grant the patent license.
However, based on the communication up to now, I don't think this is the plan
of the people affiliated with Ericsson and participating in the discussion
right now. Magnus, please correct me, if I'm wrong. I also formulates it in a
way that you don't have to speak for all of Ericsson, which might be hard.

The second case is what seems to be more realistic. At least Hannes wanted to
work on OpenSSL and I would look at that implementation also. However, before
it would be accepted by the OpenSSL team, they need to think about an exception
and they must basically be convinced they they have the patent licenses they
need. I guess, based on the statements of the people from Ericsson in the discussion,
that such a license would not be granted.
From a contributor point of view, I would not even start spending cycles on an
implementation, when I would expect that it can not be accepted by the OpenSSL
team. My guess is that, for example, Hannes shares the same view.

@Magnus: Again, please correct me if I stated anything in relation of Ericsson
incorrectly. The above statement is intended to be based on facts.
Finally a discalimer: I'm not a lawyer...

Best regards
Michael
> 
> 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
>> 
>>