NVMe over Fabrics transport requirements support

NVMe over Fabrics transport requirements support

[Alex Talker]

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?


_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

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

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

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



_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

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

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

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

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: NVMe over Fabrics transport requirements support

[Sagi Grimberg]

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

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

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: NVMe over Fabrics transport requirements support

[Chuck Lever]

> On Jun 24, 2020, at 4:25 PM, Sagi Grimberg <sagi@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




_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme