NVMe over Fabrics transport requirements support

[Chuck Lever]

> On Jun 24, 2020, at 4:25 PM, Sagi Grimberg <sagi at grimberg.me> wrote:
> 
> 
>>>> I have some early-stage patches the enable NVMe-TLS on the host's
>>>> receive side and on the target's transmit side. It requires
>>>> some TLS infra work, but the real problem is the userspaece side,
>>>> as the TLS handshake cannot be in the kernel. Consequently,
>>>> nvme-tcp must be modified to use sockets provided by userspace,
>>>> and I suspect that this may be controversial.
>>> Yes... That part is going to be annoying as hell. It's unnatural
>>> no matter how we tackle it...
>> Annoying, but I doubt that it is worth adding the TLS handshake to the kernel to overcome it.
> 
> I tend to agree, I've heard that Trond is looking to do something
> similar with NFS rpc.gssd but I wasn't able to get a hold of him to
> share where he is at.
> 
> CC'ing Chuck, whom I've briefly discussed this with some time ago.

I don't know of any recent progress.

The plan was to build something similar to gssd based on netlink as
the upcall mechanism (gssd uses RPC pipefs). Trond is aware of the
desire to treat TLS handshake as a generic mechanism rather than
one that is RPC-centric.


>>> Please do note that there is ongoing update technical proposal on the
>>> NVMe TWG to update the spec to match TLS v1.3 (not sure if you are a
>>> member or not).
>> Yes, I've seen some draft for this, although I'm not a member.
>> TLS1.3 is supported by KTLS in the same way as TLS1.2, e.g. the
>> handshake must go through a userspace application, and the data-path
>> is in the kernel.
>>>> At the moment,
>>>> I'm busy with other things, but I expect to post an RFC after
>>>> I finish with my current project.
>>> Great! Looking forward to seeing some patches for it!

--
Chuck Lever