[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.55.40.216 with SMTP id o85mr21058776qko.247.1490656625352; Mon, 27 Mar 2017 16:17:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.129.194 with HTTP; Mon, 27 Mar 2017 16:17:04 -0700 (PDT)
X-Originating-IP: [31.133.141.179]
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: https://github.com/squarooticus/tcpinc-linux/tree/tcpinc 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 code.) 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. Kyle
- [tcpinc] Linux TCP-ENO implementation Kyle Rose