From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5FD0ECE58E for ; Thu, 17 Oct 2019 14:33:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A055821A4C for ; Thu, 17 Oct 2019 14:33:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437444AbfJQOdS (ORCPT ); Thu, 17 Oct 2019 10:33:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58280 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726583AbfJQOdS (ORCPT ); Thu, 17 Oct 2019 10:33:18 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9411E307CDE7; Thu, 17 Oct 2019 14:33:17 +0000 (UTC) Received: from bistromath.localdomain (unknown [10.36.118.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2BE960600; Thu, 17 Oct 2019 14:33:15 +0000 (UTC) Date: Thu, 17 Oct 2019 16:33:14 +0200 From: Sabrina Dubroca To: Jakub Kicinski Cc: David Miller , netdev@vger.kernel.org, herbert@gondor.apana.org.au, steffen.klassert@secunet.com Subject: Re: [PATCH net-next v4 0/6] ipsec: add TCP encapsulation support (RFC 8229) Message-ID: <20191017143314.GA621051@bistromath.localdomain> References: <20191014.144327.888902765137276425.davem@davemloft.net> <20191015082424.GA435630@bistromath.localdomain> <20191015114657.45954831@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191015114657.45954831@cakuba.netronome.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Thu, 17 Oct 2019 14:33:17 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 2019-10-15, 11:46:57 -0700, Jakub Kicinski wrote: > 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 > > > 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..) Yeah, there's nothing preventing a socket that's already in a sockmap from getting a ULP, only for inserting a socket in a sockmap if it already has a ULP (see sock_map_update_common). I gave it a quick test with espintcp, it doesn't quite seem to work: a sockmap program that drops everything actually drops messages, but a sockmap program that drops some messages based on length... doesn't. Although, to be honest, I don't see a use case for sockmap on espintcp sockets. > Is there any chance we could see some selftests here? For espintcp? That's planned, I need to rework my test scripts so that they don't need human interaction, and turn them into selftests. -- Sabrina