Re: [Maprg] [EToSat] [IETF112] Recommendations on using VPN over SATCOM

Michael Welzl <michawe@ifi.uio.no> Fri, 12 November 2021 09:26 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: maprg@ietfa.amsl.com
Delivered-To: maprg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335673A0867 for <maprg@ietfa.amsl.com>; Fri, 12 Nov 2021 01:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GxrlZTA3Sl8r for <maprg@ietfa.amsl.com>; Fri, 12 Nov 2021 01:26:30 -0800 (PST)
Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BFB3A0844 for <maprg@irtf.org>; Fri, 12 Nov 2021 01:26:29 -0800 (PST)
Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <michawe@ifi.uio.no>) id 1mlSp7-00BfuT-50; Fri, 12 Nov 2021 10:26:17 +0100
Received: from ti0182q160-6712.bb.online.no ([95.34.115.135] helo=[192.168.1.7]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from <michawe@ifi.uio.no>) id 1mlSp6-0005zE-Gb; Fri, 12 Nov 2021 10:26:17 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <B6860E47-A95A-4CDD-83C3-A883B7BE66D0@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_734A584B-F30F-4C93-A6D4-4ED0C7E37409"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 12 Nov 2021 10:26:14 +0100
In-Reply-To: <f274aa24-48fb-00df-9ea6-e44720a6254b@fau.de>
Cc: Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>, maprg@irtf.org, etosat@ietf.org, Kristjon Ciko <kristjoc@ifi.uio.no>
To: Joerg Deutschmann <joerg.deutschmann@fau.de>
References: <CAL0D2oRNxS1Qid153Ead5Ntk-BdRJLnN1OdZhPiyQQHK+0NTjQ@mail.gmail.com> <f274aa24-48fb-00df-9ea6-e44720a6254b@fau.de>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 95.34.115.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.115.135; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 77F5BC73E7C52E3BC0D44992C7092E39A484270E
Archived-At: <https://mailarchive.ietf.org/arch/msg/maprg/j_nauErobDhTXYzqN-lU_LBc3G8>
Subject: Re: [Maprg] [EToSat] [IETF112] Recommendations on using VPN over SATCOM
X-BeenThere: maprg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" <maprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/maprg>, <mailto:maprg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/maprg/>
List-Post: <mailto:maprg@irtf.org>
List-Help: <mailto:maprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/maprg>, <mailto:maprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 09:26:33 -0000

Hi everyone,

I wanted to follow up on a particular point here, in the question from Joerg to Nicolas - with a shameless plug  :-)


> - Which PEP did you use, was it PEPsal?

For our own research (on something completely different) we looked for an open source split-connection PEP, and PEPsal was indeed the fastest - and, it seems, the most common - open source PEP that we found.
However, we needed something slightly different: translating not only TCP-TCP but TCP-whatever (truly “whatever”: TCP-RINA, TCP-ICN, … but also TCP-TCP), and we needed it to work in the kernel.
So, we made that - and it’s generally faster than PEPsal. For one, because it’s in the kernel - but also because, being in the kernel, it doesn’t need a SYN handshake to complete before it can start establishing its own connection.

It’s open source, and it’s here:
https://github.com/kr1stj0n/pep-dna <https://github.com/kr1stj0n/pep-dna>

I said “we” above but this should be “he”: this was all done by my Ph.D. student Kristjon Ciko.

Cheers,
Michael