[PATCH 17/17] nvmet-tcp: peek icreq before starting TLS
Hannes Reinecke
hare at suse.de
Mon Aug 14 23:20:39 PDT 2023
On 8/14/23 21:05, Sagi Grimberg wrote:
>
>
> On 8/14/23 16:18, Hannes Reinecke wrote:
>> On 8/14/23 14:11, Sagi Grimberg wrote:
>>>
>>>> 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 at 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
More information about the Linux-nvme
mailing list