From: David Ahern <dsahern@gmail.com>
To: Leonard Crestez <cdleonard@gmail.com>,
David Ahern <dsahern@kernel.org>, Shuah Khan <shuah@kernel.org>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Eric Dumazet <edumazet@google.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
Kuniyuki Iwashima <kuniyu@amazon.co.jp>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Jakub Kicinski <kuba@kernel.org>,
Yuchung Cheng <ycheng@google.com>,
Francesco Ruggeri <fruggeri@arista.com>,
Mat Martineau <mathew.j.martineau@linux.intel.com>,
Christoph Paasch <cpaasch@apple.com>,
Ivan Delalande <colona@arista.com>,
Priyaranjan Jha <priyarjha@google.com>,
netdev@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] tcp: Initial support for RFC5925 auth option
Date: Tue, 2 Nov 2021 21:18:41 -0600 [thread overview]
Message-ID: <832e6d49-8490-ab8b-479b-0420596d0aaa@gmail.com> (raw)
In-Reply-To: <cover.1635784253.git.cdleonard@gmail.com>
On 11/1/21 10:34 AM, 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.
>
> Expected use-case is protecting long-duration BGP/LDP connections
> between routers using pre-shared keys. The goal of this series is to
> allow routers using the linux TCP stack to interoperate with vendors
> such as Cisco and Juniper.
>
> Both algorithms described in RFC5926 are implemented but the code is not
> very easily extensible beyond that. In particular there are several code
> paths making stack allocations based on RFC5926 maximum, those would
> have to be increased.
>
> This version implements SNE and l3mdev awareness and adds more tests.
> Here are some known flaws and limitations:
>
> * Interaction with TCP-MD5 not tested in all corners
> * Interaction with FASTOPEN not tested and unlikely to work because
> sequence number assumptions for syn/ack.
> * Not clear if crypto_shash_setkey might sleep. If some implementation
> do that then maybe they could be excluded through alloc flags.
> * Traffic key is not cached (reducing performance)
> * User is responsible for ensuring keys do not overlap.
> * There is no useful way to list keys, making userspace debug difficult.
> * There is no prefixlen support equivalent to md5. This is used in
> some complex FRR configs.
>
> Test suite was added to tools/selftests/tcp_authopt. Tests are written
> in python using pytest and scapy and check the API in some detail and
> validate packet captures. Python code is already used in linux and in
> kselftests but virtualenvs not very much, this particular test suite
> uses `pip` to create a private virtualenv and hide dependencies.
>
> This actually forms the bulk of the series by raw line-count. Since
> there is a lot of code it was mostly split on "functional area" so most
> files are only affected by a single code. A lot of those tests are
> relevant to TCP-MD5 so perhaps it might help to split into a separate
> series?
>
> Some testing support is included in nettest and fcnal-test.sh, similar
> to the current level of tcp-md5 testing.
>
> SNE was tested by creating connections in a loop until a large SEQ is
> randomly selected and then making it rollover. The "connect in a loop"
> step ran into timewait overflow and connection failure on port reuse.
> After spending some time on this issue and my conclusion is that AO
> makes it impossible to kill remainders of old connections in a manner
> similar to unsigned or md5sig, this is because signatures are dependent
> on ISNs. This means that if a timewait socket is closed improperly then
> information required to RST the peer is lost.
>
> The fact that AO completely breaks all connection-less RSTs is
> acknowledged in the RFC and the workaround of "respect timewait" seems
> acceptable.
>
> Changes for frr (old): https://github.com/FRRouting/frr/pull/9442
> That PR was made early for ABI feedback, it has many issues.
>
overall looks ok to me. I did not wade through the protocol details.
I did see the comment about no prefixlen support in the tests. A lot of
patches to absorb, perhaps I missed it. Does AuthOpt support for
prefixes? If not, you should consider adding that as a quick follow on
(within the same dev cycle). MD5 added prefix support for scalability;
seems like AO should be concerned about the same.
next prev parent reply other threads:[~2021-11-03 3:18 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 16:34 [PATCH v2] tcp: Initial support for RFC5925 auth option Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 01/25] tcp: authopt: Initial support and key management Leonard Crestez
2021-11-03 2:29 ` David Ahern
2021-11-05 12:10 ` Leonard Crestez
2021-11-05 1:22 ` Dmitry Safonov
2021-11-05 7:04 ` Leonard Crestez
2021-11-05 14:50 ` Dmitry Safonov
2021-11-05 18:00 ` Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 02/25] docs: Add user documentation for tcp_authopt Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 03/25] selftests: Initial tcp_authopt test module Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 04/25] selftests: tcp_authopt: Initial sockopt manipulation Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 05/25] tcp: authopt: Add crypto initialization Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 06/25] tcp: authopt: Compute packet signatures Leonard Crestez
2021-11-05 1:53 ` Dmitry Safonov
2021-11-05 6:39 ` Leonard Crestez
2021-11-05 2:08 ` Dmitry Safonov
2021-11-05 6:09 ` Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 07/25] tcp: Use BIT() for OPTION_* constants Leonard Crestez
2021-11-03 2:31 ` David Ahern
2021-11-03 22:19 ` Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 08/25] tcp: authopt: Hook into tcp core Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 09/25] tcp: authopt: Disable via sysctl by default Leonard Crestez
2021-11-03 2:39 ` David Ahern
2021-11-05 8:50 ` Leonard Crestez
2021-11-05 1:46 ` Dmitry Safonov
2021-11-01 16:34 ` [PATCH v2 10/25] selftests: tcp_authopt: Test key address binding Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 11/25] tcp: authopt: Implement Sequence Number Extension Leonard Crestez
2021-11-01 19:22 ` Francesco Ruggeri
2021-11-02 10:03 ` Leonard Crestez
2021-11-02 19:21 ` Francesco Ruggeri
2021-11-03 22:01 ` Leonard Crestez
2021-11-01 20:54 ` Eric Dumazet
2021-11-02 9:50 ` Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 12/25] tcp: ipv6: Add AO signing for tcp_v6_send_response Leonard Crestez
2021-11-03 2:44 ` David Ahern
2021-11-03 22:09 ` Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 13/25] tcp: authopt: Add support for signing skb-less replies Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 14/25] tcp: ipv4: Add AO signing for " Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 15/25] selftests: tcp_authopt: Implement SNE in python Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 16/25] selftests: tcp_authopt: Add scapy-based packet signing code Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 17/25] selftests: tcp_authopt: Add packet-level tests Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 18/25] selftests: tcp_authopt: Initial sne test Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 19/25] tcp: authopt: Add key selection controls Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 20/25] selftests: tcp_authopt: Add tests for rollover Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 21/25] tcp: authopt: Add initial l3index support Leonard Crestez
2021-11-03 3:06 ` David Ahern
2021-11-05 12:26 ` Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 22/25] selftests: tcp_authopt: Initial tests for l3mdev handling Leonard Crestez
2021-11-01 16:34 ` [PATCH v2 23/25] selftests: nettest: Rename md5_prefix to key_addr_prefix Leonard Crestez
2021-11-03 3:08 ` David Ahern
2021-11-01 16:34 ` [PATCH v2 24/25] selftests: nettest: Initial tcp_authopt support Leonard Crestez
2021-11-03 3:09 ` David Ahern
2021-11-01 16:35 ` [PATCH v2 25/25] selftests: net/fcnal: " Leonard Crestez
2021-11-03 3:18 ` David Ahern [this message]
2021-11-03 22:22 ` [PATCH v2] tcp: Initial support for RFC5925 auth option Leonard Crestez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=832e6d49-8490-ab8b-479b-0420596d0aaa@gmail.com \
--to=dsahern@gmail.com \
--cc=0x7f454c46@gmail.com \
--cc=cdleonard@gmail.com \
--cc=colona@arista.com \
--cc=cpaasch@apple.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=fruggeri@arista.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.co.jp \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=priyarjha@google.com \
--cc=shuah@kernel.org \
--cc=ycheng@google.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).