From: Steffen Klassert <steffen.klassert@secunet.com>
To: Antony Antony <antony@phenome.org>
Cc: <netdev@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Richard Guy Briggs <rgb@tricolour.ca>
Subject: Re: [PATCH] xfrm: fix state migration replay sequence numbers
Date: Fri, 19 May 2017 11:59:37 +0200 [thread overview]
Message-ID: <20170519095937.GB22049@secunet.com> (raw)
In-Reply-To: <20170518143953.GA64905@AntonyAntony.local>
On Thu, May 18, 2017 at 04:39:53PM +0200, Antony Antony wrote:
> During xfrm migration replay and preplay sequence numbers are not
> copied from the previous state.
>
> Here is tcpdump output showing the problem.
> 10.0.10.46 is running vanilla kernel, IKE/IPsec responder.
> After the migration it sent wrong sequence number, reset to 1.
> The migration is from 10.0.0.52 to 10.0.0.53.
>
> IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7cf), length 136
> IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7cf), length 136
> IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d0), length 136
> IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7d0), length 136
>
> IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa inf2[I]
> IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa inf2[R]
> IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa inf2[I]
> IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa inf2[R]
>
> IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d1), length 136
>
> NOTE: next sequence is wrong 0x1
>
> IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x1), length 136
> IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d2), length 136
> IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x2), length 136
>
> The attached patch fix it by copying replay and preplay.
The patch looks ok, but please do a v2 and put the above
informations into the commit message. This is usefull
information that we would loose otherwise.
Thanks!
next prev parent reply other threads:[~2017-05-19 9:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 14:39 [PATCH] xfrm: fix state migration replay sequence numbers Antony Antony
2017-05-18 15:55 ` Richard Guy Briggs
2017-05-19 9:59 ` Steffen Klassert [this message]
2017-05-19 10:47 ` [PATCH v2] xfrm: fix state migration copy " Antony Antony
2017-05-19 11:19 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170519095937.GB22049@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=antony@phenome.org \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=rgb@tricolour.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.