[PATCH 1/3] nvmet: expose discovery subsystem in sysfs

[Knight, Frederick]

I agree that a reasonably configured environment will distribute keys and unique NQNs at the same time (as a pair).  A configuration that tries to use a well-known NQN and authentication isn't very secure in the first place, so there isn't much point.  And a well-known discovery controller that REQUIRES authentication, well, its getting what it asked for.

	Fred

> -----Original Message-----
> From: John Meneghini <jmeneghi at redhat.com>
> Sent: Wednesday, March 23, 2022 2:04 PM
> To: Knight, Frederick <Frederick.Knight at netapp.com>; Christoph Hellwig
> <hch at lst.de>; Hannes Reinecke <hare at suse.de>
> Cc: Sagi Grimberg <sagi at grimberg.me>; Keith Busch
> <keith.busch at wdc.com>; linux-nvme at lists.infradead.org; Chris Leech
> <cleech at redhat.com>
> Subject: Re: [PATCH 1/3] nvmet: expose discovery subsystem in sysfs
> 
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> 
> 
> 
> 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