Subject: Question on SA Bundle

From: Lokesh <[email-masked]>
Date: Tue, 08 Apr 2003 15:24:33 +0530

Hi all,
I have a question on Ipsec.
SA's are bundled in SABundle. and there can be multiple SA Bundles existing 
linked together
in a SPD entry.

1]  under what conditions it is decided that a new SA created should be 
bundled in a New SABundle? not in a existing one?

can anyone point me to literature on this or similar issue ? ( that is 
regarding SPD and SA Bundles)
Thanks
Lokesh

---

From: Ramana Yarlagadda <[email-masked]>
Date: Tue, 08 Apr 2003 10:53:37 -0700

Lokesh

At 03:24 PM 4/8/03 +0530, Lokesh wrote:
>SA's are bundled in SABundle. and there can be multiple SA Bundles 
>existing linked together
>in a SPD entry.
>

The SA  is negotiated (created) in two events:
1) where an SA doesn't exist for a flow, New SA.
2) the second case is because of an SA expiry timer.

The first case is a simple case and there shouldn't be any issues with 
this. But in second case you might run
into som problems like whether you should hold-on or delete the old SA ? 
And which one to use in case of
IPSec processing. And for more information about this refer to rekeying 
isses draft.

>regarding SPD and SA Bundles)

-cheers
-ramana

---

From: Ravi <[email-masked]>
Date: Wed, 09 Apr 2003 09:48:22 +0530

Hi ,

I don't think there is public literature on this other than IPSEC architecture
document. Note that, SPD defines the security protocols such as ESP, AH.
In a given SPD policy, you can have both ESP and AH together. This results
into two SAs. Typically, IPSEC informs IKE to get the keys for both of them
together. once IKE gets the keys, it can inform IPSEC packet processing to create
the SA bundle with two SAs.

  Since, IKE negotiates both together, if one SA life time expires, other SAs in 
the SA Bundle can be removed. That means either all SAs in the SA bundle exist
or none exist

-Ravi

Lokesh wrote:

> 1]  under what conditions it is decided that a new SA created should 
> be bundled in a New SABundle? not in a existing one?
>

-- 

The views presented in this mail are completely mine. The company is not 
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Apr 2003 15:43:30 -0400

At 3:24 PM +0530 4/8/03, Lokesh wrote:
>can anyone point me to literature on this or similar issue ? ( that 
>is regarding SPD and SA Bundles)
>Thanks
>Lokesh

Lokesh,

When writing 2401 we thought it might be possible to provide the 
ability to link together a number of SAs into a bundle, similar to 
what you describe in #1 above. However, in reality, IKE v1 was not 
able to negotiate a general notion of bundling, specifically a way to 
link new SAs to existing SAs. Thus, in practice the only bundles that 
occur arise when one negotiates both AH and ESP in a single IKE 
negotiaiton.

As we revise 2401, I anticipate clarifying this, and essentially 
doing away with the notion of bundles. I have not see a strong need 
for them in list discussions, nor does IKE v2 have support for adding 
SAs to a bundle.

If folks think this is not the right path for 2401bis, let me know.

Steve

---

From: Markku Savela <[email-masked]>
Date: Thu, 10 Apr 2003 00:41:44 +0300

> From: Stephen Kent <[email-masked]>

> If folks think this is not the right path for 2401bis, let me know.

In my understanding "bundle" is loose concept, e.g. in a policy I
could specify

  selector1 -> apply SA1(AH), apply SA2(ESP), apply SA2(ESP)
  selector2 -> apply SA2(ESP)

Bundle is just a set of IPSEC transformations (and SA's) that are
specified to be applied to a packet that maches a particular
selector. The same component SA can be used in different "bundles".

That's about all that "bundle" means to me. Unfortunately, IKEv1
thinks/requires more strict "bundle" concept. It cannot negotiate
individual SA's belonging to same "bundle" separately, or share SA's
between bundles.

Key management should negotiate SA's individually.

Speaking of bundles, I just currently trying examine how to get IPSEC
to work with MIPv6.

Assume you have mobile node (MN) and correspondent node (CN), home
agent (HA). Assume CN is some service that requires IPSEC to be
used. Thus I have a policy

  remote=CN -> use CN-SA

works just fine, as long as MN is at home, with packets

  IP: dst=CN
      src=MN-home
      IPSEC(CN-SA)
      Payload

Now, when MN moves away from home, one possibility is tunneling the
packets via home agent. However, MN - HA path must also be protected
by IPSEC. Thus the required packet leaving from MN must look

  IP: dst=HA
      src=MN-care
      IPSEC(HA-SA)
  IP: dst=CN
      src=MN-home
      IPSEC(CN-SA)
      Payload

It just happens that I can generate above packet using existing IPSEC
implementation by writing a policy (because it allows pretty random
combination of IPSEC transforms)

  away-from-home and remote=CN -> use CN-SA, use HA-SA (tunnel=HA)
  at-home and remote=CN -> use CN-SA

However, there is no hope for IKEv1 or IKEv2 to handle this. Manual
keys work. (system will ask the two SA's with two separate ACQUIRE
requests using PFKEYv2).

I've been fairly happy with 2401 as is. I hope the flexibility that it
allowed is not reduced too much to make things like in above
non-standard.