Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library

[Dmitry Safonov]

Hi Eric,

On Mon, 27 Apr 2026 at 18:27, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
[..]
> To make this simplification and optimization possible, this series also
> updates the TCP-AO code to support a specific set of algorithms, rather
> than arbitrary algorithms that don't make sense and are very likely not
> being used, e.g. CRC-32 and HMAC-MD5.
>
> Specifically, this series retains the support for AES-128-CMAC,
> HMAC-SHA1, and HMAC-SHA256.  AES-128-CMAC and HMAC-SHA1 are the only
> algorithms that are actually standardized for use in TCP-AO, while
> HMAC-SHA256 makes sense to continue supporting as a Linux extension.  Of
> course, other algorithms can still be (re-)added later if ever needed.
> It's worth noting that TCP-AO MACs are limited to 20 bytes by the TCP
> options space, which limits the benefit of further algorithm upgrades.
>
> This series passes the tcp_ao selftests
> (sudo make -C tools/testing/selftests/net/tcp_ao/ run_tests).
>
> 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 do like these numbers quite much! Yet, as I mentioned in version 1,
removing a fallback for other algorithms' support does not sound good
to me. There are two reasons:
- Ronald P. Bonica (the original RFC5925 author), together with Tony
Li do have an active RFC draft to support the additional algorithms
[1], potentially in addition to TCP Extended Options [2]
- There is at least one open-source BGP implementation (BIRD) that
allows using the algorithms that you are removing [3]. Without a
deprecation period and communication with at least known open source
users, it implies intentionally breaking them, which I can't agree
with.

I don't feel like Naking as we don't have any customers using anything
other than the 3 algorithms above (and BGP implementation is
[unfortunately] closed-source, so that would not feel appropriate even
if we had such customers), yet I do feel like it's worth and
appropriate to express my thoughts/concerns.

[1] https://www.ietf.org/archive/id/draft-bonica-tcpm-tcp-ao-algs-00.html
[2] https://www.ietf.org/archive/id/draft-bonica-tcpm-extended-options-00.html
[3] https://github.com/CZ-NIC/bird/blob/master/sysdep/linux/sysio.h#L246

Thanks,
             Dmitry