Re: TLS certificates for NFS-over-TLS floating client

From: Jan Bramkamp <crest_at_rlwinm.de>
Date: Sat, 21 Mar 2020 00:56:21 +0100
On 20.03.20 20:45, John-Mark Gurney wrote:
> Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100:
>> On 20.03.20 02:44, Russell L. Carter wrote:
>>> Here I commit heresy, by A) top posting, and B) by just saying, why
>>> not make it easy, first, to tunnel NFSv4 sessions through
>>> e.g. net/wireguard or sysutils/spiped?  NFS is point to point.
>>> Security infrastructure that actually works understands the shared
>>> secret model.
> VPN tunneling doesn't provide the security that most people thinks it
> does...  It requires complicated configuration, and often doesn't
> provide e2e protections.
I fully agree that IPsec is a bitch to configure, but IPsec tranport 
mode between NFSv4 client and server would provide end to end encryption.
>> Why not use IPsec in transport mode instead of a tunnel? It avoids
>> unnecessary overhead and is already implemented in the kernel. It should
>> be enough to "just" require IPsec for TCP port 2049 and run a suitable
>> key exchange daemon.
> Because IPsec is a PITA to configure and work, and lots of consumer OSes
> don't make it at all easy.
Does any consumer OS support NFSv4 over TLS?
> Also, you forget that FreeBSD has ktls, which usees the same crypto
> offload engine that IPsec does, so it will effectively have similar
> overhead, and might actually perform better due to TLS having a 16k
> record encryption size vs IPsec limiting itself to packet size, usually
> 1500, though possibly 9k if you're using jumbo frames...
I compared IPsec to userspace tunnels like spiped or wireguard-go not 
kTLS. If kTLS can use LRO/TSO etc. it would avoid even more overhead.
> I fully support doing NFS over TLS.
I would love to run NFS over TLS, but it isn't implemented yet and afaik 
kTLS only accelerates TLS sending and would require a userspace proxy to 
receive TLS at the moment while IPsec transport mode is just a nasty 
fight with strongSwan away.
Received on Fri Mar 20 2020 - 22:56:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC