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 <herb...@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 ) 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)
