[PATCH 1/3] nvmet: expose discovery subsystem in sysfs
John Meneghini
jmeneghi at redhat.com
Wed Mar 23 11:03:56 PDT 2022
On 3/23/22 13:34, Knight, Frederick wrote:
> Please don't make this assumption:
>
> 3. Hosts that support Authentication can then disconnect from the Well Known
> Discovery Controller and re-connect with the Unique Discovery NQN. These
> hosts should expect an AUTHREQ=1 response.
>
> 4. Hosts that don't want to support Authentication can ignore the SUBTYPE 03h
> Log Page Entries and operate normally. This would include legacy hosts.
>
> There should be NO assumption that subtype 03h requires authentication. It should use AUTHREQ only.
Well, then maybe we need to figure that out. I agree that any wire protocol that depends on an assumption is
a broken wire protocol.
> And, while using authentication with the well-known discovery controller NQN is not recommended (and not very secure),
> there is nothing that prevents the setting of AUTHREQ=1 when using the well-known discovery controller NQN;
This is true. According to the protocol AUTHREQ=1 can be returned to any Fabric Connect command. But if Discovery Controllers
start doing this, they will probably break 99% of the running hosts out here. So that's whats preventing it from happening.
> so again, I would suggest you do not just assume that is true, and that the host still use AUTHREQ to control authentication
> no matter what/who you are talking to. As for targets - they are free to implement what their customers require.
I don't disagree. I'm just saying, the realities of turning on AUTHREQ=1 with the exiting well known discovery service is:
you will have many host that suddenly fail to interoperate.
/John
More information about the Linux-nvme
mailing list