Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f02ae4bb-2e50-e096-7505-3928b16d4009@gmail.com>
Date:   Sat, 27 Aug 2022 11:55:19 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH 00/31] net/tcp: Add TCP-AO support
Content-Language: en-US
To:     Andrew Lunn <andrew@lunn.ch>, Dmitry Safonov <dima@arista.com>
Cc:     David Ahern <dsahern@kernel.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Ard Biesheuvel <ardb@kernel.org>,
        Bob Gilligan <gilligan@arista.com>,
        Dmitry Safonov <0x7f454c46@gmail.com>,
        Eric Biggers <ebiggers@kernel.org>,
        Francesco Ruggeri <fruggeri@arista.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        Ivan Delalande <colona@arista.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Salam Noureddine <noureddine@arista.com>,
        Shuah Khan <shuah@kernel.org>, netdev@vger.kernel.org,
        linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>
References: <20220818170005.747015-1-dima@arista.com>
 <fc05893d-7733-1426-3b12-7ba60ef2698f@gmail.com>
 <a83e24c9-ab25-6ca0-8b81-268f92791ae5@kernel.org>
 <8097c38e-e88e-66ad-74d3-2f4a9e3734f4@arista.com>
 <7ad5a9be-4ee9-bab2-4a70-b0f661f91beb@gmail.com> <YwYdqEFQuQjXxATb@lunn.ch>
From:   Leonard Crestez <cdleonard@gmail.com>
In-Reply-To: <YwYdqEFQuQjXxATb@lunn.ch>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 8/24/22 15:46, Andrew Lunn wrote:
>> I think it would make sense to push key validity times and the key selection
>> policy entirely in the kernel so that it can handle key rotation/expiration
>> by itself. This way userspace only has to configure the keys and doesn't
>> have to touch established connections at all.
> 
> I know nothing aobut TCP-AO, nor much about kTLS. But doesn't kTLS
> have the same issue? Is there anything which can be learnt from kTLS?
> Maybe the same mechanisms can be used? No point inventing something
> new if you can copy/refactor working code?
> 
>> My series has a "flags" field on the key struct where it can filter by IP,
>> prefix, ifindex and so on. It would be possible to add additional flags for
>> making the key only valid between certain times (by wall time).
> 
> What out for wall clock time, it jumps around in funny ways. Plus the
> kernel has no idea what time zone the wall the wall clock is mounted
> on is in.

A close equivalent seems to exist in ipsec in the "xfrm_lifetime_cfg" 
struct, specifically the soft/hard expires timers. These are optional 
validity times for each xfrm_state which is equivalent to a "key".

I'm not familiar with how those are used but ipsec usually relies on 
complex userspace daemons for managing xfrm states and policies and 
those daemons should be capable of adding and removing keys based on 
internal timers. Still, the linux kernel supports checking for key 
validity on it's own.

--
Regards,
Leonard