Re: IPSec ESN: Packets decryption fail with ESN enabled connection
From: Harsh Jain <hidden>
Date: 2019-01-03 10:47:27
Also in:
linux-crypto
On 02-01-2019 18:21, Herbert Xu wrote:
On Wed, Dec 26, 2018 at 03:16:29PM +0530, Harsh Jain wrote:quoted
+linux-crypto On 26-12-2018 14:54, Harsh Jain wrote:quoted
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 listDoes 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,