lkml.org 
[lkml]   [2021]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] tcp: Initial support for RFC5925 auth option
From
Date


On 7/27/21 6:05 AM, Francesco Ruggeri wrote:
> Hi Leonard,
>
> thanks for taking on this task!
>
>> I'm especially interested in feedback regarding ABI and testing.
>
> I noticed that the TCP connection identifier is not part of the
> representation of the MKT (tcp_authopt_key_info).
> This could cause some issues if, for example 2 MKTs with different
> <remote IP, remote TCP port> in the TCP connection identifier but same
> KeyID (recv_id) are installed on a socket. In that case
> tcp_authopt_inbound_key_lookup() may not pick the correct MKT for the
> connection. Matching incoming segments only based on recv_id may not
> comply with the RFC.
> I think there may be other cases where TCP connection identifiers may
> be needed to resolve conflicts, but I have to look at your patch in
> more detail.

The RFC doesn't specify what the "tcp connection identifier" needs to
contains so for this first version nothing was implemented.

Looking at MD5 support in linux the initial commit only supported
binding keys to addresses and only relatively support was added for
address prefixes and interfaces. Remote ports still have no effect.

I think adding explicit address binding for TCP-AO would be sufficient,
this can be enhanced later. The most typical usecase for TCP auth is to
connect with a BGP peer with a fixed IP address.

As far as I understand this only actually matters for SYN packets where
you want a single listen socket to accept client using overlapping
keyids. For an active connection userspace can only add keys for the
upcoming destination.

> It would be helpful if you could split your patch into smaller
> incremental chunks.

OK

\
 
 \ /
  Last update: 2021-07-27 20:06    [W:0.122 / U:1.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site