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

[Sagi Grimberg]

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

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

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.

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