linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).