netdev - Re: [PATCH net-next v4 0/6] ipsec: add TCP encapsulation support (RFC 8229)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191015114657.45954831@cakuba.netronome.com>
Date:   Tue, 15 Oct 2019 11:46:57 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Sabrina Dubroca <sd@...asysnail.net>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        herbert@...dor.apana.org.au, steffen.klassert@...unet.com
Subject: Re: [PATCH net-next v4 0/6] ipsec: add TCP encapsulation support
 (RFC 8229)

On Tue, 15 Oct 2019 10:24:24 +0200, Sabrina Dubroca wrote:
> 2019-10-14, 14:43:27 -0400, David Miller wrote:
> > From: Sabrina Dubroca <sd@...asysnail.net>
> > Date: Fri, 11 Oct 2019 16:57:23 +0200
> >   
> > > This patchset introduces support for TCP encapsulation of IKE and ESP
> > > messages, as defined by RFC 8229 [0]. It is an evolution of what
> > > Herbert Xu proposed in January 2018 [1] that addresses the main
> > > criticism against it, by not interfering with the TCP implementation
> > > at all. The networking stack now has infrastructure for this: TCP ULPs
> > > and Stream Parsers.  
> > 
> > So this will bring up a re-occurring nightmare in that now we have another
> > situation where stacking ULPs would be necessary (kTLS over TCP encap) and
> > the ULP mechanism simply can't do this.
> > 
> > Last time this came up, it had to do with sock_map.  No way could be found
> > to stack ULPs properly, so instead sock_map was implemented via something
> > other than ULPs.
> > 
> > I fear we have the same situation here again and this issue must be
> > addressed before these patches are included.
> > 
> > Thanks.  
> 
> I don't think there's any problem here. We're not stacking ULPs on the
> same socket. There's a TCP encap socket for IPsec, which belongs to
> the IKE daemon. The traffic on that socket is composed of IKE messages
> and ESP packets. Then there's whatever userspace sockets (doesn't have
> to be TCP), and the whole IPsec and TCP encap is completely invisible
> to them.
> 
> Where we would probably need ULP stacking is if we implement ESP over
> TLS [1], but we're not there.
> 
> [1] https://tools.ietf.org/html/rfc8229#appendix-A

But can there be any potential issues if the TCP socket with esp ULP is
also inserted into a sockmap? (well, I think sockmap socket gets a ULP,
I think we prevent sockmap on top of ULP but not the other way around..)

Is there any chance we could see some selftests here?