NVMe over Fabrics transport requirements support

[Boris Pismenny]

On 24/06/2020 23:06, Sagi Grimberg wrote:
>>> Hey Alex,
>>>
>>>> Is it true that setting any value in addr_treq attribute of port in via
>>>> configfs
>>>>
>>>> only affects displaying TREQ on discovery page and doesn't anyhow inflicts
>>>>
>>>> "whether connections shall be made over a fabric secure channel"?
>>>>
>>>>
>>>> I can't find much about whether RDMA(RoCE in particular) is secure
>>>>
>>>> but for TCP TLS is must-do these days I think.
>>>>
>>>>
>>>> Is this functionality planned to be implemented in near future?
>>> There were some discussions around adding this. Currently there is
>>> some infrastructure work that we need to do first to have a kernel
>>> consumer utilize ktls (mostly revolves around the fact that both
>>> ktls and nvme-tcp are socket consumers and implement sk upcalls).
>>>
>>> I'm CC'ing Boris and Or who were very much involved with the
>>> ktls implementation in Linux, they can maybe provide some more
>>> input.
>> 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.

>
> 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!