From: Steffen Klassert <steffen.klassert@secunet.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>,
Andreas Gruenbacher <agruen@suse.de>,
Alex Badea <abadea@ixiacom.com>,
netdev@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [RFC] [PATCH 06/11] esp4: Add support for IPsec extended sequence numbers
Date: Tue, 8 Mar 2011 08:04:46 +0100 [thread overview]
Message-ID: <20110308070446.GA31402@secunet.com> (raw)
In-Reply-To: <20101202072947.GA22998@gondor.apana.org.au>
Sorry for the huge delay...
On Thu, Dec 02, 2010 at 03:29:47PM +0800, Herbert Xu wrote:
> On Mon, Nov 22, 2010 at 11:30:14AM +0100, Steffen Klassert wrote:
> >
> > @@ -205,11 +228,18 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
> > skb_to_sgvec(skb, sg,
> > esph->enc_data + crypto_aead_ivsize(aead) - skb->data,
> > clen + alen);
> > - sg_init_one(asg, esph, sizeof(*esph));
> > +
> > + if ((x->props.flags & XFRM_STATE_ESN)) {
> > + sg_init_table(asg, 2);
> > + sg_set_buf(asg, esph, sizeof(*esph));
> > + *seqhi = htonl(XFRM_SKB_CB(skb)->seq.output.hi);
> > + sg_set_buf(asg + 1, seqhi, seqhilen);
> > + } else
> > + sg_init_one(asg, esph, sizeof(*esph));
>
> I think this is wrong for AEAD algorithms. You want the sequence
> number in network byte order for them so the high bits need to be
> inserted into the middle of the ESP header.
>
Yes, indeed.
> The other problem is that you're currently requiring the authencesn
> user to provide two SG entries which is fine for now. However,
> since this might be exported to user-space in future, authenecesn
> shouldn't really rely on that, or at least it shouldn't BUG.
>
> So one solution is to do it based on bytes in authencesn. That is,
> your associated input should always be 12 bytes long, and then you
> simply construct a new SG list for your actual processing with the
> middle 4 bytes taken out.
>
> For IPsec it could just provide an SG list with three entries,
> of 4 bytes each.
Ok, I've updated the patchset in this regard.
>
> Of course for simplicity, you could require this to be the case in
> authencesn and return -EINVAL (not BUG :) if it's not the case.
>
Doing BUG was a leftover from debugging the thing. On debugging it is
sometimes better to pull the emergency brake as soon as something
unexpected happens. I replaced BUG with return -EINVAL now.
I'll resend the patchset for a second round of review.
next prev parent reply other threads:[~2011-03-08 7:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 10:24 [RFC] [PATCH 0/11] Add IPsec extended (64-bit) sequence numbers Steffen Klassert
2010-11-22 10:25 ` [RFC] [PATCH 01/11] crypto: scatterwalk - Add scatterwalk_crypto_chain helper Steffen Klassert
2010-11-22 10:26 ` [RFC] [PATCH 02/11] crypto: Use scatterwalk_crypto_chain Steffen Klassert
2010-12-02 6:48 ` Herbert Xu
2010-11-22 10:27 ` [RFC] [PATCH 03/11] crypto: authencesn - Add algorithm to handle IPsec extended sequence numbers Steffen Klassert
2010-11-22 10:28 ` [RFC] [PATCH 04/11] xfrm: Add basic infrastructure to support " Steffen Klassert
2010-11-22 10:29 ` [RFC] [PATCH 05/11] xfrm: Use separate low and high order bits of the sequence numbers in xfrm_skb_cb Steffen Klassert
2010-11-22 10:30 ` [RFC] [PATCH 06/11] esp4: Add support for IPsec extended sequence numbers Steffen Klassert
2010-12-02 7:29 ` Herbert Xu
2011-03-08 7:04 ` Steffen Klassert [this message]
2010-11-22 10:31 ` [RFC] [PATCH 07/11] esp6: " Steffen Klassert
2010-11-22 10:31 ` [RFC] [PATCH 08/11] xfrm: Move IPsec replay detection functions to a separate file Steffen Klassert
2010-11-22 10:32 ` [RFC] [PATCH 09/11] xfrm: Support anti-replay window size bigger than 32 packets Steffen Klassert
2010-11-22 10:33 ` [RFC] [PATCH 10/11] xfrm: Add support for IPsec extended sequence numbers Steffen Klassert
2010-11-22 10:34 ` [RFC] [PATCH 11/11] xfrm: Add user interface for esn and big anti-replay windows Steffen Klassert
2010-11-22 10:37 ` [RFC] [PATCH] iproute2: Add IPsec extended sequence number support 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=20110308070446.GA31402@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=abadea@ixiacom.com \
--cc=agruen@suse.de \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).