Hi,
Does ESP support 64 bit sequence numbering for use with the
authentication HMAC ?
I've looked at struct aead_givcrypt_request and it has a u64 seq member.
Does ESP populate this with a 64 bit sequence number ?
If 32 bit sequence numbering negotiated then how does the HMAC routine
know that it should not use the top 32 bits of seq ? Or is it simply
that if the top 32 bits are zero then the HMAC just uses the lower 32
bits ?
Thanks for any insight.
Regards,
Dean Jenkins
MontaVista Software
Dean Jenkins <[email protected]> wrote:
>
> Does ESP support 64 bit sequence numbering for use with the
> authentication HMAC ?
We don't support 64-bit sequence numbers yet. If you look at
struct xfrm_replay_state which is where we store the sequence
number internally you'll find that it uses u32s.
Patches for 64-bit support are welcome of course.
> I've looked at struct aead_givcrypt_request and it has a u64 seq member.
> Does ESP populate this with a 64 bit sequence number ?
That's different. That's a generic value used to construct the IV.
> If 32 bit sequence numbering negotiated then how does the HMAC routine
> know that it should not use the top 32 bits of seq ? Or is it simply
> that if the top 32 bits are zero then the HMAC just uses the lower 32
> bits ?
Because the value we start out with is a u32, the high bits are
never set for IPsec.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Jan 15, 2009 at 04:56:44PM +1100, Herbert Xu wrote:
> Dean Jenkins <[email protected]> wrote:
> >
> > Does ESP support 64 bit sequence numbering for use with the
> > authentication HMAC ?
>
> We don't support 64-bit sequence numbers yet. If you look at
> struct xfrm_replay_state which is where we store the sequence
> number internally you'll find that it uses u32s.
>
> Patches for 64-bit support are welcome of course.
>
Is there actually anybody working on 64-bit sequence number support?
If not, I'd start to look at it.
On Tue, Sep 01, 2009 at 02:09:15PM +0200, Steffen Klassert wrote:
>
> > Patches for 64-bit support are welcome of course.
>
> Is there actually anybody working on 64-bit sequence number support?
> If not, I'd start to look at it.
I certainly am not :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On 09/01/2009 03:09 PM, Steffen Klassert wrote:
> On Thu, Jan 15, 2009 at 04:56:44PM +1100, Herbert Xu wrote:
>> Dean Jenkins <[email protected]> wrote:
>>> Does ESP support 64 bit sequence numbering for use with the
>>> authentication HMAC ?
>> We don't support 64-bit sequence numbers yet. If you look at
>> struct xfrm_replay_state which is where we store the sequence
>> number internally you'll find that it uses u32s.
>>
>> Patches for 64-bit support are welcome of course.
>>
>
> Is there actually anybody working on 64-bit sequence number support?
> If not, I'd start to look at it.
A while ago I implemented a rough version of ESN support. It's against
an ancient 2.6.7 kernel though, and is only superficially tested.
I suppose there's no reason not to publish them here, if only for
historical reasons. My apologies to anyone not interested :)
Alex Badea (6):
xfrm: move xfrm_replay_{check,advance} to their own source file
xfrm: introduce XFRM_STATE_ESN flag, and extended replay structure
xfrm: add generic support for replay protection with Extended
Sequence Numbers
ipsec: Extended Sequence Numbers support for ESP
ipsec: Extended Sequence Numbers support for AH
xfrm: add test harness for Extended Sequence Numbers replay
protection algorithm
Best regards,
Alex
On Tue, Sep 01, 2009 at 03:23:21PM +0300, Alex Badea wrote:
>
> A while ago I implemented a rough version of ESN support. It's against
> an ancient 2.6.7 kernel though, and is only superficially tested.
>
> I suppose there's no reason not to publish them here, if only for
> historical reasons. My apologies to anyone not interested :)
>
I'll have a look whether I can use some parts of it, thanks.