Re: [PATCH 00/19] tcp: Initial support for RFC5925 auth option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/22/21 2:13 AM, Jakub Kicinski wrote:
On Tue, 21 Sep 2021 19:14:43 +0300 Leonard Crestez wrote:
This is similar to TCP MD5 in functionality but it's sufficiently
different that wire formats are incompatible. Compared to TCP-MD5 more
algorithms are supported and multiple keys can be used on the same
connection but there is still no negotiation mechanism.

Hopefully there will be some feedback / discussion, but even if
everyone acks this you'll need to fix all the transient build
failures, and kdoc warnings added - and repost.
git rebase --exec='make' and scripts/kernel-doc are your allies.

Hello,

I already went through several round of testing with git rebase --exec='$test' but it seems I introduced a few new failures after several rounds of squashing fixes. I'll need to check kernel-doc comments for source files not referenced in documenation.

Many of the patch splits were artificially created in order to ease review, for example "signing packets" doesn't do anything without also "hooking in the tcp stack". Some static functions will trigger warnings because they're unused until the next patch, not clear what the preferred solution would be here. I could remove the "static" marker until the next patch or reverse the order and have the initial "tcp integration" patches call crypto code that just returns an error and fills-in a signature of zeros.

A large amount of the code is just selftests and much of it is not completely specific to TCP-AO. Maybe I could try to repost the parts that verify handling of timewait corners and resets in a variant that only handles "md5" and "unsigned"?

I already tried posting my scapy implementation of TCP-AO and MD5 to scapy upstream because it is not specific to linux .

--
Regards,
Leonard



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux