NVMe over Fabrics transport requirements support

[Boris Pismenny]

On 24/06/2020 22:25, 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. At the moment,
I'm busy with other things, but I expect to post an RFC after
I finish with my current project.