Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC] tcp: Initial support for RFC5925 auth option
To:     Francesco Ruggeri <fruggeri@arista.com>,
        David Ahern <dsahern@gmail.com>
Cc:     Eric Dumazet <edumazet@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        Jakub Kicinski <kuba@kernel.org>,
        David Ahern <dsahern@kernel.org>,
        Yuchung Cheng <ycheng@google.com>,
        Mat Martineau <mathew.j.martineau@linux.intel.com>,
        Christoph Paasch <cpaasch@apple.com>,
        Priyaranjan Jha <priyarjha@google.com>,
        Kuniyuki Iwashima <kuniyu@amazon.co.jp>,
        Menglong Dong <dong.menglong@zte.com.cn>,
        open list <linux-kernel@vger.kernel.org>,
        linux-crypto@vger.kernel.org, netdev <netdev@vger.kernel.org>,
        Salam Noureddine <noureddine@arista.com>,
        Bob Gilligan <gilligan@arista.com>,
        Dmitry Safonov <dima@arista.com>
References: <01383a8751e97ef826ef2adf93bfde3a08195a43.1626693859.git.cdleonard@gmail.com>
 <e2215577-2dc5-9669-20b8-91c7700fa987@gmail.com>
 <CA+HUmGhtPHbT=aBLS_Ny_t802s3RWaE+tupd4T8U9x50eW3JXg@mail.gmail.com>
From:   Leonard Crestez <cdleonard@gmail.com>
Message-ID: <3afe618a-e848-83c3-2cc5-6ad66f3ef44b@gmail.com>
Date:   Tue, 27 Jul 2021 21:05:59 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CA+HUmGhtPHbT=aBLS_Ny_t802s3RWaE+tupd4T8U9x50eW3JXg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 7/27/21 6:05 AM, Francesco Ruggeri wrote:
> Hi Leonard,
> 
> thanks for taking on this task!
> 
>> I'm especially interested in feedback regarding ABI and testing.
> 
> I noticed that the TCP connection identifier is not part of the
> representation of the MKT (tcp_authopt_key_info).
> This could cause some issues if, for example 2 MKTs with different
> <remote IP, remote TCP port> in the TCP connection identifier but same
> KeyID (recv_id) are installed on a socket. In that case
> tcp_authopt_inbound_key_lookup() may not pick the correct MKT for the
> connection. Matching incoming segments only based on recv_id may not
> comply with the RFC.
> I think there may be other cases where TCP connection identifiers may
> be needed to resolve conflicts, but I have to look at your patch in
> more detail.

The RFC doesn't specify what the "tcp connection identifier" needs to 
contains so for this first version nothing was implemented.

Looking at MD5 support in linux the initial commit only supported 
binding keys to addresses and only relatively support was added for 
address prefixes and interfaces. Remote ports still have no effect.

I think adding explicit address binding for TCP-AO would be sufficient, 
this can be enhanced later. The most typical usecase for TCP auth is to 
connect with a BGP peer with a fixed IP address.

As far as I understand this only actually matters for SYN packets where 
you want a single listen socket to accept client using overlapping 
keyids. For an active connection userspace can only add keys for the 
upcoming destination.

> It would be helpful if you could split your patch into smaller
> incremental chunks.

OK