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

Eric Biggers posted 5 patches 1 month, 2 weeks ago
include/net/tcp.h                             |  42 +-
include/net/tcp_ao.h                          |  74 +-
net/ipv4/Kconfig                              |   8 +-
net/ipv4/Makefile                             |   1 -
net/ipv4/tcp_ao.c                             | 677 +++++++++---------
net/ipv4/tcp_output.c                         |  10 +-
net/ipv4/tcp_sigpool.c                        | 366 ----------
net/ipv6/tcp_ao.c                             | 139 ++--
tools/testing/selftests/net/tcp_ao/config     |   4 -
.../selftests/net/tcp_ao/key-management.c     |  41 +-
10 files changed, 440 insertions(+), 922 deletions(-)
delete mode 100644 net/ipv4/tcp_sigpool.c
[PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Eric Biggers 1 month, 2 weeks ago
This series can also be retrieved from:

    git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git tcp-ao-v2

This series is targeting net-next for 7.2.  To make this series
self-contained in the networking code, I dropped the patches that remove
support for transformation cloning from the crypto API, which is a
further negative 275-line cleanup and optimization this series enables.
That will be done as a follow-up, either through the crypto tree for
7.3, or still through net-next for 7.2 at maintainer preference.

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 mechanism becomes unnecessary and is removed, as the
problems it was designed to solve don't exist with the library APIs.

The crypto API's support for crypto transformation cloning also becomes
unnecessary and will be removed in follow-up patches.  Note that as part
of that, we'll be able to roll back the addition of the reference count
to crypto_tfm, which had regressed performance for all crypto API users.

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

Changed in v2:
    - Rebased onto v7.1-rc1.
    - Added Ard's Reviewed-by.
    - Dropped patches that clean up things in the crypto/ directory, as
      mentioned above.  They'll be sent separately.
    - Added some mentions of the MAC length being limited by the TCP
      options space.
    - Removed unnecessary explicit assignment of values to enums.

Eric Biggers (5):
  net/tcp-ao: Drop support for most non-RFC-specified algorithms
  net/tcp-ao: Use crypto library API instead of crypto_ahash
  net/tcp-ao: Use stack-allocated MAC and traffic_key buffers
  net/tcp-ao: Return void from functions that can no longer fail
  net/tcp: Remove tcp_sigpool

 include/net/tcp.h                             |  42 +-
 include/net/tcp_ao.h                          |  74 +-
 net/ipv4/Kconfig                              |   8 +-
 net/ipv4/Makefile                             |   1 -
 net/ipv4/tcp_ao.c                             | 677 +++++++++---------
 net/ipv4/tcp_output.c                         |  10 +-
 net/ipv4/tcp_sigpool.c                        | 366 ----------
 net/ipv6/tcp_ao.c                             | 139 ++--
 tools/testing/selftests/net/tcp_ao/config     |   4 -
 .../selftests/net/tcp_ao/key-management.c     |  41 +-
 10 files changed, 440 insertions(+), 922 deletions(-)
 delete mode 100644 net/ipv4/tcp_sigpool.c


base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.54.0
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Dmitry Safonov 1 month, 2 weeks ago
Hi Eric,

On Mon, 27 Apr 2026 at 18:27, Eric Biggers <ebiggers@kernel.org> 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
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Jakub Kicinski 1 month, 2 weeks ago
On Mon, 27 Apr 2026 20:09:05 +0100 Dmitry Safonov wrote:
> 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.

What do you want to happen? You are the maintainer of this code,
you don't get so say "i don't want to nack it but also no" :)
Like Eric says if there are no real users code can be deleted.

Adding deprecation warnings upstream is quite slow, IDK if injecting
deprecation warnings to stable has been discussed..
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Dmitry Safonov 1 month, 2 weeks ago
On Mon, 27 Apr 2026 at 23:55, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 27 Apr 2026 20:09:05 +0100 Dmitry Safonov wrote:
> > 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.
>
> What do you want to happen? You are the maintainer of this code,
> you don't get so say "i don't want to nack it but also no" :)

Yeah, that's not what I meant. I see value in Eric's contribution, and
I like getting rid of tcp-sigpool. So, anything but "nack" is not "no"
:-)

> Like Eric says if there are no real users code can be deleted.
> Adding deprecation warnings upstream is quite slow, IDK if injecting
> deprecation warnings to stable has been discussed..

FWIW, I've written to bird's mailing list inviting them to this
thread; in case if they need other algorithms to be supported,
hopefully that should avoid any breakages on their side.
I'm aware that ciena and fortinet use tcp-ao too, but I'm less
concerned, as they aren't open source.

Thanks,
             Dmitry
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Paolo Abeni 1 month, 2 weeks ago
On 4/28/26 2:00 AM, Dmitry Safonov wrote:
> On Mon, 27 Apr 2026 at 23:55, Jakub Kicinski <kuba@kernel.org> wrote:
>> On Mon, 27 Apr 2026 20:09:05 +0100 Dmitry Safonov wrote:
>>> 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.
>>
>> What do you want to happen? You are the maintainer of this code,
>> you don't get so say "i don't want to nack it but also no" :)
> 
> Yeah, that's not what I meant. I see value in Eric's contribution, and
> I like getting rid of tcp-sigpool. So, anything but "nack" is not "no"
> :-)

I read the above as: "If there isn't any additional feedback soon,
please apply".

>> Like Eric says if there are no real users code can be deleted.
>> Adding deprecation warnings upstream is quite slow, IDK if injecting
>> deprecation warnings to stable has been discussed..
> 
> FWIW, I've written to bird's mailing list inviting them to this
> thread; in case if they need other algorithms to be supported,
> hopefully that should avoid any breakages on their side.
> I'm aware that ciena and fortinet use tcp-ao too, but I'm less
> concerned, as they aren't open source.

Let me add my 2c here:
- the only TCP-AO use-case I'm aware of, is to _drop_ TCP-MD5
- We had some discussion about TCP Extended Options in past netconf, and
IIRC at very best it's not going to happen any time soon kernel wise
because it basically requires disabling GRO.
- the possibility of using crc32 is indeed a security issue, that AFAICS
must be addressed, and can only be fixed removing such option. I'm fine
dropping support for any other algo considered vulnerable.

More than 48H passed since the last email on this thread, I'm going to
apply it.

Thanks,

Paolo
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Dmitry Safonov 1 month, 2 weeks ago
On Thu, 30 Apr 2026 at 08:38, Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 4/28/26 2:00 AM, Dmitry Safonov wrote:
[..]
> > Yeah, that's not what I meant. I see value in Eric's contribution, and
> > I like getting rid of tcp-sigpool. So, anything but "nack" is not "no"
> > :-)
>
> I read the above as: "If there isn't any additional feedback soon,
> please apply".

Thanks, Paolo, that's exactly what I meant.

I think we addressed both concerns I had with the new RFC and BIRD
daemon, and Eric did a good job optimising the crypto layer here, so
we are better with his patches than with my sentimental attachment to
extendability that so far is not really required by BGP. And if we
need to extend the list of algorithms, we will be able to do it on top
later.

Thanks again,
             Dmitry
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Eric Biggers 1 month, 2 weeks ago
On Mon, Apr 27, 2026 at 08:09:05PM +0100, Dmitry Safonov wrote:
> > 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

I think the usual "it's not really broken if no one notices" is likely
to apply here.  Indeed, there have been many cases where algorithms have
been removed from the crypto API before, despite this theoretically
impacting UAPI.  Just some of the removals from crypto_ahash over the
years that come to mind are the Tiger hash algorithms, multiple variants
of RIPEMD, multiple CRC variants, GHASH, Poly1305, NH, and POLYVAL.

The reality is that the crypto API's algorithm specification language
provides way more "flexibility" than anyone knows what to do with or
ever should have existed at all, let alone been exposed directly to
userspace.

We don't have a lot of choice but to clean up these old mistakes to keep
Linux maintainable going forwards, reduce the chance for user error, and
optimize for the things that actually matter.

And again, as I said, if there is another algorithm that someone
actually needs, we can add it back as a bug fix (or as a new feature,
considering that some never worked in the first place).

- Eric
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Eric Biggers 1 month, 2 weeks ago
On Mon, Apr 27, 2026 at 08:01:16PM +0000, Eric Biggers wrote:
> > - Ronald P. Bonica (the original RFC5925 author), together with Tony
> > Li do have an active RFC draft to support the additional algorithms
[...]
> > [1] https://www.ietf.org/archive/id/draft-bonica-tcpm-tcp-ao-algs-00.html

For what it's worth, that draft makes very little sense.  For example,
it proposes three variants of HMAC-SHA3, instead of just making the
modern choice of KMAC256.  And it proposes both HMAC-SHA384 and
HMAC-SHA512, despite them being redundant with each other after the
specified truncation to 128 bits.

Thus, it's clear that draft needs some work.  That would include, for
example, input from people who may be more familiar with best practices
for choosing cryptographic algorithms in new designs.

So I don't think the Linux kernel's implementation should, or needs to,
already implement all the algorithms in that unofficial draft.

All that's needed is the flexibility to add new algorithms later,
whether from a fixed version of that draft or from somewhere else.

We'll still have that with the library.

And to emphasize again, the current code also isn't really generic.  So
the support for new MACs doesn't necessarily come for free currently.
It probably works for arbitrary HMACs.  But HMAC != MAC.  If
AES-256-CMAC, BLAKE2, KMAC256, Poly1305-AES, or just about any other MAC
is ever needed, the code would have to be changed to support it anyway.

- Eric
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Simo Sorce 1 month, 2 weeks ago
On Mon, 2026-04-27 at 16:20 -0700, Eric Biggers wrote:
> On Mon, Apr 27, 2026 at 08:01:16PM +0000, Eric Biggers wrote:
> > > - Ronald P. Bonica (the original RFC5925 author), together with Tony
> > > Li do have an active RFC draft to support the additional algorithms
> [...]
> > > [1] https://www.ietf.org/archive/id/draft-bonica-tcpm-tcp-ao-algs-00.html
> 
> For what it's worth, that draft makes very little sense.  For example,
> it proposes three variants of HMAC-SHA3, instead of just making the
> modern choice of KMAC256.  And it proposes both HMAC-SHA384 and
> HMAC-SHA512, despite them being redundant with each other after the
> specified truncation to 128 bits.

Which is bogus in itself without proper security considerations, the
only considerations cited is an RFC from 1997 ... clearly the pinnacle
of cryptography advice ...

If they need a shorter hash they should make themselves a favor and use
SHAKE and then define the desired output length and desired key size.
That draft is just a disaster as written.

Specifically they should use KMAC128 as defined in NIST SP 800-185
(which uses cSHAKE128 underneath).

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
Posted by Eric Biggers 1 month, 2 weeks ago
On Tue, Apr 28, 2026 at 12:26:44PM -0400, Simo Sorce wrote:
> On Mon, 2026-04-27 at 16:20 -0700, Eric Biggers wrote:
> > On Mon, Apr 27, 2026 at 08:01:16PM +0000, Eric Biggers wrote:
> > > > - Ronald P. Bonica (the original RFC5925 author), together with Tony
> > > > Li do have an active RFC draft to support the additional algorithms
> > [...]
> > > > [1] https://www.ietf.org/archive/id/draft-bonica-tcpm-tcp-ao-algs-00.html
> > 
> > For what it's worth, that draft makes very little sense.  For example,
> > it proposes three variants of HMAC-SHA3, instead of just making the
> > modern choice of KMAC256.  And it proposes both HMAC-SHA384 and
> > HMAC-SHA512, despite them being redundant with each other after the
> > specified truncation to 128 bits.
> 
> Which is bogus in itself without proper security considerations, the
> only considerations cited is an RFC from 1997 ... clearly the pinnacle
> of cryptography advice ...
> 
> If they need a shorter hash they should make themselves a favor and use
> SHAKE and then define the desired output length and desired key size.
> That draft is just a disaster as written.
> 
> Specifically they should use KMAC128 as defined in NIST SP 800-185
> (which uses cSHAKE128 underneath).
> 
> Simo.

FWIW I left some feedback on the draft on on the tcpm mailing list
(https://mailarchive.ietf.org/arch/browse/tcpm/)

Another thing I should note is that the way TCP-AO uses HMAC-SHA1, it's
instantiated with an arbitrary-length key that might not contain full
entropy.  In contrast, the normal practice in cases like that is to do
an entropy extraction step first, e.g. see HKDF which has HKDF-Extract +
HKDF-Expand.

There's a chance this gets fixed in a future addition of HMAC-SHA256 or
whatever.  But in that case, the way the kernel happens to already
implement that algorithm (by assuming that it would be used in exactly
the same way as HMAC-SHA1) wouldn't match the eventual standard.

This is yet another reason why preemptively implementing "support" for
arbitrary algorithms wasn't a great choice...

 Eric