NVMe over Fabrics transport requirements support

[Sagi Grimberg]

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

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).

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