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: > > 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 )
Herbert, would this be an option or is this not possible? Thanks!
