[PATCH 1/6] nvmeof-tcp/001: simple test for nvmeof-tcp connection

[Hannes Reinecke]

On 11/15/21 9:12 AM, Sagi Grimberg wrote:
> 
>>> It is unclear to me why the separate directory is needed. But at least
>>> call it something else if you must have it.
>>>
>>>> Especially as I still fail to see the actual use-case for using
>>>> in-band authentication _without_ encryption.
>>>
>>> Not sure what you mean. For the same use-case that iscsi chap exists
>>> for. The secrets are pre-shared.
>>>
>> And that's the use case I don't really get; the authentication is done
>> only once during connection establishment, and then completely ignored
>> for the remainder of the session.
> 
> I have a different view on this. Authentication isn't really related to
> the datapath, but really only relevant to the queue establishment.
> 
>>
>>> Perhaps you can explain? My understanding is that the extension for
>>> nvme-tcp TLS based auth is to avoid maintaining two sets of pre-shared
>>> keys, i.e just maintain the TLS ones and not the dhchap ones. But maybe
>>> I am missing something.
>>>
>> Yes, and no.
>> Technically TLS is independent from authentication, and as such you
>> can 'just' use encryption.
>> But if you want to have both there is the so-called secure
>> concatenation, which allows you to use the negotiated shared key from
>> authentication as PSK for TLS.
> 
> Well, TLS is a longer journey for a number of reasons which I won't
> elaborate here.
> 
Quite.

>> And that's where I think the real value lies for authentication; you
>> precisely do _not_ have to maintain two sets of keys.
> 
> I can't say I completely agree with you. There are means today to
> encrypt data over the wire. Granted, it will negate possible data
> reduction gains, but still a mitigation exists.
> 
> On the other hand, today any unauthenticated host can connect to
> any fabrics controller, which is a problem. I don't think you should
> minimize the magnitude of your contribution as this is a real issue
> with nvmeof acceptance in enterprise environments.
> 
That why I always took care to state that it's _my_ view.
Security is still a rather new topic to me, and as such quite some
techniques used here (derive key (a) from key (b) which is derived from
key (c) etc) feel rather redundant to me.
So there's a bit of a learning curve ahead :-)

> I do agree that when TLS is used, it is indeed very useful to not
> have to maintain two sets of pre-shared secrets, but I don't think
> that there is no use-case for inband authentication in the absence
> of TLS.
> 

Oh, surely not. I have been assured from several parties that they want
to use authentication, so who am I to argue with them :-)
And anyway, motivation was to have a working implementation before HW
vendors have a chance to mess things up :-)

>>
>>>> We could rename it to nvmeof-auth, though.
>>>
>>> or just add it as more tests under nvme (or create a subdirectory).
>>>
>> Sure we can. I just found it easier to create my own directory,
>> especially seeing that the nvme subdir has the largest number of tests
>> already.
>> But if you prefer I can move it under the 'nvme' directory.
> 
> I think that it would definitely be an improvement, also because people
> usually run the nvme directory tests which is nice and simple, we should
> strive to keep it this way.

Okay, will be doing so.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer