[tcpinc] Linux TCP-ENO implementation

Kyle Rose <krose@krose.org> Mon, 27 March 2017 23:17 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CCD37127A97 for <tcpinc@ietfa.amsl.com>; Mon, 27 Mar 2017 16:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nHtxT3GPD7TI for <tcpinc@ietfa.amsl.com>; Mon, 27 Mar 2017 16:17:07 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A00B129645 for <tcpinc@ietf.org>; Mon, 27 Mar 2017 16:17:06 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id f11so52396533qkb.0 for <tcpinc@ietf.org>; Mon, 27 Mar 2017 16:17:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=FgPhhscyKD5Vi+cpEW1vHR10wfdRRnv+NsUrPDwG/tc=; b=iBGhmOVaRsSqmFQiVGA5Xk5qxYzaSzHtbimaeQkkSy6xh3rU0RH6rAsKcTh15anlSX LWVSAUON0kxEGGBnmRSwbs6qkpH7hRotWcLizHKt83qHcyXFCgeO4IjQTHGinhCPoGyz d/g4DYM+BocmXX4ZXUu6blV7TdCtRiQPLKZwg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=FgPhhscyKD5Vi+cpEW1vHR10wfdRRnv+NsUrPDwG/tc=; b=j4eTLWaFh1Wn/vGHIvtnXaet98Zm5fsAi5IFn5xCEH/gHPWCOr9xqPWzbAPlmtYNfU curuWeWRKZENzS0ZXJvvladMVJCfoEVZbSi/PME67pMTNwon1KDgHXlgg78ufzO1VQV7 T1PJbSzRkO1CG/vC0g76hKdD815xNaw/RO5QZHU09UOwyOhIVUkmgyW4rJ/OdoNixbzN /45wYNCNY4eZUh//KZSbjMFR6mmFxbYDXKtd51Y2Ev+vAvaoltRQqNyTU4qBp6Q0gWH/ /8MG+AgCwGJr4BJduxdcrXiFUN7dMBlvaF4JrJGxv6Mk0JA+5FDgSkYaKqo5BqqpSIy+ AU0w==
X-Gm-Message-State: AFeK/H2BMG+zRZ6NVvg2h0cHbVNdn46ZL8ef+mZwEbv95Ebd2WDqr8LEUCox1tQXNBbs38i7Kd1r4XU87uan5Q==
X-Received: by with SMTP id o85mr21058776qko.247.1490656625352; Mon, 27 Mar 2017 16:17:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 Mar 2017 16:17:04 -0700 (PDT)
X-Originating-IP: []
From: Kyle Rose <krose@krose.org>
Date: Mon, 27 Mar 2017 19:17:04 -0400
Message-ID: <CAJU8_nWdbZH4Hhy4gDgvNYohH-_RxjL99d5qauCNK05LG2nnVQ@mail.gmail.com>
To: tcpinc <tcpinc@ietf.org>
Cc: Martin Stiemerling <mls.ietf@gmail.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="001a113ed068a2fd27054bbe8a18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/TSJ55s3RIBL5-FVh1Z3u8rQwQPY>
Subject: [tcpinc] Linux TCP-ENO implementation
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 23:17:12 -0000

Courtesy of the IETF-98 Hackathon, I was able to focus enough to generate a
roughly-working TCP-ENO implementation for the Linux kernel:


Definitely not done in any sense, with plenty of to-dos and open questions
about implementation, but it does successfully negotiate ENO with itself
and with the reference implementation from tcpcrypt.org.

>From the commit log:

        - One of many things it does wrong that isn't noted in a comment is
        that the server doesn't set remote-enabled on the third leg of the
        3WHS, because that ACK appears to be processed in a different part
        of the code that I haven't found yet: instead, it sets it after the
        second ACK received from the client.

        - We probably want to avoid copying the ENO SYN suboptions out of
        the received SYN packet since we use that data only while the skb
        exists. We instead need a way to duck type the SYN subopts in the
        ENO negotiation and use a fixed-size buffer for one and a pointer
        for the other.

        - I think it makes sense to move into the tcpcrypt implementation
        next rather than try to refine this too much, because the
        modular implementation of TEPs may motivate changes to ENO with
        respect to the interface between the two.

If anyone would like to help out with further development, please let me
know. I am both happy to help others bootstrap development, and learn from
those who know a lot more about kernel development than I do. My next steps
are to figure out where to inject the INIT messages and to duct-tape on a
P-256 implementation, in an effort to get tcpcrypt successfully
interoperating with the reference implementation, rather than try to
beautify it at the moment. (This conflicts with my usual strategy of
pursuing engineering purity, but in this case what I really want is working

Thanks to the folks who helped organize the Hackathon, and thanks to Jake
and Lucas (of the BBC) for allowing me to squat at the AMT table.