netdev - Re: IPSec ESN: Packets decryption fail with ESN enabled connection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Jan 2019 20:51:09 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Harsh Jain <harsh@...lsio.com>
Cc:     steffen.klassert@...unet.com, davem@...emloft.net,
        netdev@...r.kernel.org,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        atul.gupta@...lsio.com, harshjain.prof@...il.com
Subject: Re: IPSec ESN: Packets decryption fail with ESN enabled connection

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 <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt