[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8989A671-47DB-4910-AFE8-8A6E6E30A827@gmail.com>
Date: Sun, 24 Feb 2019 14:31:29 +0900
From: Hayakawa Yutaro <yhayakawa3720subscribe@...il.com>
To: Vakul Garg <vakul.garg@....com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: kTLS getsockopt TLS_RX support
> 2019/02/24 10:50、Vakul Garg <vakul.garg@....com>のメール:
>
>
>
>> -----Original Message-----
>> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
>> Behalf Of Hayakawa Yutaro
>> Sent: Saturday, February 23, 2019 10:59 PM
>> To: netdev@...r.kernel.org
>> Subject: kTLS getsockopt TLS_RX support
>>
>> Hello,
>>
>> While trying the kTLS, I found out that currently, there is no support for kTLS
>> getsockopt TLS_RX which extracts receive side crypto information from kTLS
>> socket. Since setting crypto information for RX side is supported, I felt
>> wonder why it is not supported.
>>
>> Is there any particular reason for it?
>
> What use case do you have in mind?
> Why give back state of record layer which also contains (record sequence number) to user space?
I’d like to checkpoint/restore the TLS session in conjunction with TCP_REPAIR.
When we checkpoint the kTLS session, we need to pick the record sequence number or
any other session information from kernel. For TX side, it is already supported (getsockopt
TLS_TX), so I’m wondering why RX side is missing.
Is there any technical difficulty or it will never supported in future?
Regards,
Yutaro
>
>>
>> Regards,
>> Yutaro
Powered by blists - more mailing lists