+linux-crypto
On 26-12-2018 14:54, Harsh Jain wrote:
> Hi All,
>
> Kernel version on both machines: 4.19.7.
>
> Packet drops with EBADMSG is observed on receive end of connection. It seems that sometimes crypto driver receives packet with wrong "seq_hi" value in AAD. See below the dump of assoc data for 1 such instance.
>
> [ 380.823454] assoclen 8th byte 1 clen 1464 op 1 ==> High byte of ESN
> [ 380.828398] authsize 12 cryptlen 1464
> [ 380.832637] dt00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 ==> Decrypted data seems correct,last byte is proto(06 TCP)
> [ 380.840215] dt00000010: bf ee 4f 80 a4 7f 2a 50 6a 5a 0b 10
> [ 380.846636] ass00000000: 0a bc d3 31 <00 00 00 01> 00 1c e5 ec 0e af 04 69 ==> ESN-Hi = 1
> [ 380.854316] ass00000010: a4 fc 08 ad
>
> Note: If I decrypt the same packet with ESN - Hi = 0. It Decrypt successfully means peer machine has used ESN-HI = 0 while encrypting.
>
> To debug further we added trace in "xfrm_replay_seqhi". Following was the output:
>
> <idle>-0 [003] ..s. 380.967766: xfrm_replay_seqhi: seq_hi 0x 1 seq 0x 1ce5ec bottom 0x 1ce5ee replay seq 0x 1ce62d replay window 0x 40
>
> 1) Is this an expected variable with ESN enables connection?.
>
> 2) If packets are supposed to be dropped can't we avoid decryption overhead.
>
> Following logs are attached
>
> 1) dmesg log
>
> 2) debug patch used to reproduce the issue.
>
> 3) ftace log file
>
> 4) ip xfrm state list
>
>
> Regards
>
> Harsh Jain
>
>
On Thu, Jan 03, 2019 at 04:16:56PM +0530, Harsh Jain wrote:
>
> On 02-01-2019 18:21, Herbert Xu wrote:
> > Does this occur if you use software crypto on the receiving end
> > while keeping the sending end unchanged?
>
> I tried with "authencesn(hmac(sha1-ssse3),cbc(aes-asm))" on both sides.
>
> Server : iperf? -s? -w 512k? -p 20002
>
> Client : iperf? -t 60 -w 512k -l 2048 -c 1.0.0.96 -P 32 -p 20002
>
> >
> > If not then I would start debugging this within your driver.
>
> ESP Packet whose's sequence No. is out of window gets dropped with EBADMSG.? It seems that "xfrm_replay_seqhi" intentionally increments the "seq_hi" to fail verification for Out of seq packet.
Yes, this is defined in RFC 4303 Appendix A2.2.
On Wed, Dec 26, 2018 at 03:16:29PM +0530, Harsh Jain wrote:
> +linux-crypto
>
> On 26-12-2018 14:54, Harsh Jain wrote:
> > Hi All,
> >
> > Kernel version on both machines: 4.19.7.
> >
> > Packet drops with EBADMSG is observed on receive end of connection. It seems that sometimes crypto driver receives packet with wrong "seq_hi" value in AAD. See below the dump of assoc data for 1 such instance.
> >
> > [? 380.823454] assoclen 8th byte 1 clen 1464 op 1? ==> High byte of ESN
> > [? 380.828398] authsize 12 cryptlen 1464
> > [? 380.832637] dt00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 ==> Decrypted data seems correct,last byte is proto(06 TCP)
> > [? 380.840215] dt00000010: bf ee 4f 80 a4 7f 2a 50 6a 5a 0b 10
> > [? 380.846636] ass00000000: 0a bc d3 31 <00 00 00 01> 00 1c e5 ec 0e af 04 69 ==> ESN-Hi = 1
> > [? 380.854316] ass00000010: a4 fc 08 ad
> >
> > Note: If I decrypt the same packet with ESN - Hi = 0. It Decrypt successfully means peer machine has used ESN-HI = 0 while encrypting.
> >
> > To debug further we added trace in "xfrm_replay_seqhi". Following was the output:
> >
> > ?<idle>-0???? [003] ..s.?? 380.967766: xfrm_replay_seqhi: seq_hi 0x 1 seq 0x 1ce5ec bottom 0x 1ce5ee replay seq 0x 1ce62d replay window 0x 40
> >
> > 1) Is this an expected variable with ESN enables connection?.
> >
> > 2) If packets are supposed to be dropped can't we avoid decryption overhead.
> >
> > Following logs are attached
> >
> > 1) dmesg log
> >
> > 2) debug patch used to reproduce the issue.
> >
> > 3) ftace log file
> >
> > 4) ip xfrm state list
Does this occur if you use software crypto on the receiving end
while keeping the sending end unchanged?
If not then I would start debugging this within your driver.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On 02-01-2019 18:21, Herbert Xu wrote:
> On Wed, Dec 26, 2018 at 03:16:29PM +0530, Harsh Jain wrote:
>> +linux-crypto
>>
>> On 26-12-2018 14:54, Harsh Jain wrote:
>>> Hi All,
>>>
>>> Kernel version on both machines: 4.19.7.
>>>
>>> Packet drops with EBADMSG is observed on receive end of connection. It seems that sometimes crypto driver receives packet with wrong "seq_hi" value in AAD. See below the dump of assoc data for 1 such instance.
>>>
>>> [ 380.823454] assoclen 8th byte 1 clen 1464 op 1 ==> High byte of ESN
>>> [ 380.828398] authsize 12 cryptlen 1464
>>> [ 380.832637] dt00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 ==> Decrypted data seems correct,last byte is proto(06 TCP)
>>> [ 380.840215] dt00000010: bf ee 4f 80 a4 7f 2a 50 6a 5a 0b 10
>>> [ 380.846636] ass00000000: 0a bc d3 31 <00 00 00 01> 00 1c e5 ec 0e af 04 69 ==> ESN-Hi = 1
>>> [ 380.854316] ass00000010: a4 fc 08 ad
>>>
>>> Note: If I decrypt the same packet with ESN - Hi = 0. It Decrypt successfully means peer machine has used ESN-HI = 0 while encrypting.
>>>
>>> To debug further we added trace in "xfrm_replay_seqhi". Following was the output:
>>>
>>> <idle>-0 [003] ..s. 380.967766: xfrm_replay_seqhi: seq_hi 0x 1 seq 0x 1ce5ec bottom 0x 1ce5ee replay seq 0x 1ce62d replay window 0x 40
>>>
>>> 1) Is this an expected variable with ESN enables connection?.
>>>
>>> 2) If packets are supposed to be dropped can't we avoid decryption overhead.
>>>
>>> Following logs are attached
>>>
>>> 1) dmesg log
>>>
>>> 2) debug patch used to reproduce the issue.
>>>
>>> 3) ftace log file
>>>
>>> 4) ip xfrm state list
> Does this occur if you use software crypto on the receiving end
> while keeping the sending end unchanged?
I tried with "authencesn(hmac(sha1-ssse3),cbc(aes-asm))" on both sides.
Server : iperf -s -w 512k -p 20002
Client : iperf -t 60 -w 512k -l 2048 -c 1.0.0.96 -P 32 -p 20002
>
> If not then I would start debugging this within your driver.
ESP Packet whose's sequence No. is out of window gets dropped with EBADMSG. It seems that "xfrm_replay_seqhi" intentionally increments the "seq_hi" to fail verification for Out of seq packet.
>
> Thanks,
On 04-01-2019 14:04, Steffen Klassert wrote:
> On Thu, Jan 03, 2019 at 04:16:56PM +0530, Harsh Jain wrote:
>> On 02-01-2019 18:21, Herbert Xu wrote:
>>> Does this occur if you use software crypto on the receiving end
>>> while keeping the sending end unchanged?
>> I tried with "authencesn(hmac(sha1-ssse3),cbc(aes-asm))" on both sides.
>>
>> Server : iperf -s -w 512k -p 20002
>>
>> Client : iperf -t 60 -w 512k -l 2048 -c 1.0.0.96 -P 32 -p 20002
>>
>>> If not then I would start debugging this within your driver.
>> ESP Packet whose's sequence No. is out of window gets dropped with EBADMSG. It seems that "xfrm_replay_seqhi" intentionally increments the "seq_hi" to fail verification for Out of seq packet.
> Yes, this is defined in RFC 4303 Appendix A2.2.
Thanks, It means we cannot avoid verification part for packets with low seql.