netdev - Re: [PATCH net-next 0/9] tcp: Add support for L3 domains to MD5 auth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20200102.155148.1732235071668848764.davem@davemloft.net>
Date:   Thu, 02 Jan 2020 15:51:48 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...nel.org
Cc:     jakub.kicinski@...ronome.com, netdev@...r.kernel.org,
        eric.dumazet@...il.com, roopa@...ulusnetworks.com,
        sharpd@...ulusnetworks.com, dsahern@...il.com
Subject: Re: [PATCH net-next 0/9] tcp: Add support for L3 domains to MD5
 auth

From: David Ahern <dsahern@...nel.org>
Date: Mon, 30 Dec 2019 14:14:24 -0800

> With VRF, the scope of network addresses is limited to the L3 domain
> the device is associated. MD5 keys are based on addresses, so proper
> VRF support requires an L3 domain to be considered for the lookups.
> 
> Leverage the new TCP_MD5SIG_EXT option to add support for a device index
> to MD5 keys. The __tcpm_pad entry in tcp_md5sig is renamed to tcpm_ifindex
> and a new flag, TCP_MD5SIG_FLAG_IFINDEX, in tcpm_flags determines if the
> entry is examined. This follows what was done for MD5 and prefixes with
> commits
>    8917a777be3b ("tcp: md5: add TCP_MD5SIG_EXT socket option to set a key address prefix")
>    6797318e623d ("tcp: md5: add an address prefix for key lookup")
> 
> Handling both a device AND L3 domain is much more complicated for the
> response paths. This set focuses only on L3 support - requiring the
> device index to be an l3mdev (ie, VRF). Support for slave devices can
> be added later if desired, much like the progression of support for
> sockets bound to a VRF and then bound to a device in a VRF. Kernel
> code is setup to explicitly call out that current lookup is for an L3
> index, while the uapi just references a device index allowing its
> meaning to include other devices in the future.

Really nice work David, series applied to net-next.