Re: [PATCH 17/17] nvmet-tcp: peek icreq before starting TLS

On 8/14/23 21:05, Sagi Grimberg wrote:

On 8/14/23 16:18, Hannes Reinecke wrote:

quoted

On 8/14/23 14:11, Sagi Grimberg wrote:

quoted

quoted

Incoming connection might be either 'normal' NVMe-TCP connections
starting with icreq or TLS handshakes. To ensure that 'normal'
connections can still be handled we need to peek the first packet
and only start TLS handshake if it's not an icreq.

That depends if we want to do that.
Why should we let so called normal connections if tls1.3 is
enabled?

Because of the TREQ setting.
TREQ can be 'not specified, 'required', or 'not required'.
Consequently when TSAS is set to 'tls1.3', and TREQ to 'not required' 
the initiator can choose whether he wants to do TLS.

And we don't need this weird 'select TREQ required' when TLS is active;
never particularly liked that one.

The guideline should be that treq 'not required' should be the explicit
setting in tls and not the other way around. We should be strict by
default and permissive only if the user explicitly chose it, and log
a warning in the log.

Whatever you say. I'll modify the patch.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman