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

[Paolo Abeni]

On 4/28/26 2:00 AM, Dmitry Safonov wrote:
> On Mon, 27 Apr 2026 at 23:55, Jakub Kicinski <kuba@xxxxxxxxxx> 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