Subject: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's

From: Frank Bailey <[email-masked]>
Date: Tue, 5 Apr 2011 14:07:30 -0700

I have a question about what is meant by 'equivalent' SA's wrt
to rekeying.   If someone has already addressed this, my apologies
and please point to the thread I missed. - thx.

In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that
the peers should establish an 'equivalent' SA.  The question I have,
is what is meant by equivalent?  Does that mean there can only be
one proposal in the SA when rekeying? And, does that proposal have
to match the currently used algorithms for that SA (i.e. the new SA,
must match the SA (as far as transforms) to be rekeyed)?

In section 2.18, 4th paragraph, it mentions that the 'old and new IKE SA
may have selected a different PRF. ...'    Which leads me to think that
we can re-negotiate the transforms during a rekey.

-          thanks in advance for the help, Frank B.

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 18:23:12 -0500

On Tue, Apr 5, 2011 at 4:07 PM, Frank Bailey
<[email-masked]> wrote:
> I have a question about what is meant by ‘equivalent’ SA’s wrt
> and please point to the thread I missed. – thx.
>
> the peers should establish an ‘equivalent’ SA.  The question I have,
> In section 2.18, 4th paragraph, it mentions that the ‘old and new IKE SA
> may have selected a different PRF. …’    Which leads me to think that

My take is that "equivalent SA" means "the same type of SA (IKE or
not) with the same traffic selectors and with transforms that are
allowed by the policy (SPD)".

Think of it this way: suppose you have an extant packet flow (e.g., an
open TCP connection) with no traffic, SAs expire, later new outbound
traffic triggers the creation of new SAs for that flow's traffic
selectors -- if the new SAs meet local policy, then nothing stops
their being installed in the SAD and taking effect to protect the
packet flow.  That is re-keying.  If policy allows a range of
transforms, then otherwise equivalent SAs remain equivalent even if
their transforms differ as long as the transforms are all allowed by
policy.

Nico
--

---

From: "Frank Bailey" <[email-masked]>
Date: Tue, 5 Apr 2011 17:11:07 -0700

- thank you, that clears it up.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Apr 2011 14:24:02 +0300

Frank Bailey writes:
> is what is meant by equivalent?  

It means mostly same... I.e. protecting same traffic and using same
parameters, ciphers etc.

> Does that mean there can only be one proposal in the SA when
> rekeying?

As the RFC5996 says that traffic selectors and algorithms SHOULD NOT
be different, there is no point of including more than one proposal.
The best is just to propose exactly same algorithms, and traffic
selectors which are used by the Child SA you are rekeying.

> And, does that proposal have to match the currently used algorithms
> for that SA (i.e. the new SA, must match the SA (as far as
> transforms) to be rekeyed)?

The RFC5996 has "SHOULD" for that, so unless you have good reasons
(which you can explain) why you are not following that SHOULD then
that is the way to go.

> we can re-negotiate the transforms during a rekey.

This is for IKE SA rekey. The crypt algorithms and traffic selectors
"SHOULD" in the RFC5996 only applies to the Child SAs. For the IKE SA
there is no suggestion that you need to keep ciphers same.

The reason for why the algorithms SHOULD NOT change during the Child
SA rekey is that on some implementation or on some hardware the rekey
is optimized so that the newly created Child SA does not really
allocate new full SA, but instead the newly rekeyed SA is added to the
existing SA with some new parameters (i.e SPI and keying material).
Then when the old SA is deleted the rekeyed SA is moved to be the
primary SA of this kind of bundle. This is done so that the statistics
and so on can be kept over the SA rekeys etc. This is purely local
implementation issue and this kind of optimization quite often share
lots of data with the previous SA, and those shared data can and often
will include algoritms and the traffic selectors.

So following that SHOULD NOT allows more efficient use of resources on
some implementations. Of course most likely those implementation will
enforce this by always picking the same set of algorithms the are
already using on the old SA if they have been proposed multiple
algorithms.

On the other hand if the proposed set does not include currently used
crypto algorithms, those implementations might return error like
NO_PROPOSAL_CHOSEN for the rekey attempts, even when similar alrogithm
set could be used to create SA from the scratch. This might cause the
situation where the host A tries to rekey and host B always says
NO_PROPOSAL_CHOSEN and finally the Child SA expires, and then it is
created again from the beginning (i.e. no rekey) and then it succeeds,
meaning that this setup still works, but is not as optimized as it
could be and it might cause few packets to be lost during the
operation. 
-- 
[email-masked]