Re: [RFC PATCH 0/8] Reimplement TCP-AO using crypto library

[Dmitry Safonov]

Hi Eric,

On Sat, 7 Mar 2026 at 22:46, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
[..]
> This series refactors the TCP-AO (TCP Authentication Option) code to do
> MAC and KDF computations using lib/crypto/ instead of crypto_ahash.
> This greatly simplifies the code and makes it much more efficient.  The
> entire tcp_sigpool and crypto_ahash cloning mechanisms become
> unnecessary and are removed, as the problems they were designed to solve
> don't exist with the library APIs.
>
> To make this possible, this series also restricts the supported
> algorithms to a reasonable set, rather than supporting arbitrary
> algorithms that don't make sense and are very likely not being used.
> Specifically, this series leaves in place the support for AES-128-CMAC
> and HMAC-SHA1 which are the only algorithms that actually have an RFC
> specifying their use in TCP-AO, along with HMAC-SHA256 which is a
> reasonable algorithm to continue supporting as a Linux extension.
>
> This passes the tcp_ao selftests (tools/testing/selftests/net/tcp_ao).
>
> To get a sense for how much more efficient this makes the TCP-AO code,
> here's a microbenchmark for tcp_ao_hash_skb() with skb->len == 128:
>
>         Algorithm       Avg cycles (before)     Avg cycles (after)
>         ---------       -------------------     ------------------
>         HMAC-SHA1       3319                    1256
>         HMAC-SHA256     3311                    1344
>         AES-128-CMAC    2720                    1107

I like the numbers that you achieved here and tcp_sigpool riddance.
If you want to measure the throughput difference, there are iperf
hacks I made at the time of upstreaming TCP-AO:
https://github.com/0x7f454c46/iperf/tree/tcp-md5-ao

We certainly have to support AES-128-CMAC, HMAC-SHA1 and HMAC-SHA2.
For the last one, we specifically had an RFE from a customer.

It's a little pity to go from ">> Additional algorithms, beyond those
mandated for TCP-AO, MAY be supported." back to "The
mandatory-to-implement MAC algorithms for use with TCP-AO are
described in a separate RFC [RFC5926]." as I've always enjoyed Linux
(and opensource in general) that provides more flexibility than just
strict mandatory required options - that's why I originally
intentionally gave a user options to use not only mandatory
algorithms. Well, that's sentimental, and yet I see that other BGP
implementations already allow these optional algorithms.

I.e.:
"Of course, TCP-AO key contains a shared secret key. It is specified
by the option secret as a text string or as a sequence of hexadecimal
digit pairs (bytestring).
Used cryptographic algorithm can be specified for each key with the
option algorithm. Possible values are: hmac md5, hmac sha1, hmac
sha224, hmac sha256, hmac sha384, hmac sha512, and cmac aes128.
Default value is hmac sha1." [1][2]

I guess that may cause a regression for an existing config.
So, I don't know, could we get your big speedup and yet let the user
choose what algorithm they want to use? Basically, making
tcp_ao_hash_skb() a callback with optional algorithms implementation
and a faster mandatory algorithms that will use
hmac_sha1_init_usingrawkey(), hmac_sha256_init_usingrawkey(),
aes_cmac_preparekey()?

[1] https://bird.nic.cz/doc/bird-3.2.0.html
[2] https://github.com/CZ-NIC/bird/blob/0ee9f93bd076c5cc425ceaec9acedbbb7c9021ec/sysdep/linux/sysio.h#L246

Thanks,
             Dmitry