[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