Re: [PATCH 2/3] tcp: Add ESP encapsulation support

On Fri, Jan 12, 2018 at 08:38:01AM -0800, Eric Dumazet wrote:

On Fri, 2018-01-12 at 00:21 +1100, Herbert Xu wrote:

quoted

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 <herbert@gondor.apana.org.au>
---

 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 )

Herbert, would this be an option or is this not possible?

Thanks!