From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH 2/3] tcp: Add ESP encapsulation support Date: Fri, 12 Jan 2018 08:38:01 -0800 Message-ID: <1515775081.131759.37.camel@gmail.com> References: <20180111132112.GA9501@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit To: Herbert Xu , Steffen Klassert , netdev@vger.kernel.org Return-path: Received: from mail-pf0-f193.google.com ([209.85.192.193]:33615 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933994AbeALQiE (ORCPT ); Fri, 12 Jan 2018 11:38:04 -0500 Received: by mail-pf0-f193.google.com with SMTP id y89so4764870pfk.0 for ; Fri, 12 Jan 2018 08:38:04 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 2018-01-12 at 00:21 +1100, Herbert Xu wrote: > This patch adds the plumbing in TCP for ESP encapsulation support > per RFC8229. > > The patch mostly deals with inbound processing, as well as enabling > TCP encapsulation on a socket through setsockopt. The outbound > processing is dealt with in the ESP code as is done for UDP. > > The inbound processing is split into two halves. First of all, > the softirq path directly intercepts ESP packets and feeds them > into the IPsec stack. Most of the time the packet will be freed > right away if it contains complete ESP packets. However, if > the message is incomplete or it contains non-ESP data, then the > skb will be added to the receive queue. We also add packets to > the receive queue if it is currently non-emtpy, in order to > preserve sequence number continuity and minimise the changes > to the TCP code. > > On the user-space facing side, packets marked as ESP-only are > skipped and not visible to user-space. However, some ESP data > may seep through. For example, if we receive a partial message > then we will always give it to user-space regardless of whether > it turns out to be ESP or not. So user-space should be prepared > to skip ESP messages (SPI != 0). > > There is a little bit of code dealing with the encapsulation side. > In particular, if encapsulation data comes in while the socket > is owned by user-space, the packets will be stored in tp->encap_out > and processed during release_sock. > > Signed-off-by: Herbert Xu > --- > > include/linux/tcp.h | 15 ++ > include/net/tcp.h | 27 +++ > include/uapi/linux/tcp.h | 1 > include/uapi/linux/udp.h | 1 > net/ipv4/tcp.c | 68 +++++++++ > net/ipv4/tcp_input.c | 326 +++++++++++++++++++++++++++++++++++++++++++++-- > net/ipv4/tcp_ipv4.c | 1 > net/ipv4/tcp_output.c | 48 ++++++ > 8 files changed, 473 insertions(+), 14 deletions(-) > Ouch... Is there any chance this can be done with almost no change in TCP stack, using a layer model ? ( net/kcm comes to mind ) NFS uses TCP sockets, but does not invade TCP stack either. I believe Christoph Paasch sent a patch series during holidays trying to cleanup the MD5 mess (I had no time reviewing it, sorry)