RFC 2401: Security Architecture for the Internet Protocol
4.3 Combining Security Associations
The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.)
Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling.
There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3.:
- Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination.
- Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than what can be specified through appropriate SPD entries (See Case 3 in Section 4.5)
- both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP.
- one endpoint of the SAs is the same -- The inner and uter tunnels could each be either AH or ESP.
- neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
Data networks: routing, security ... - Tony Kenyon - Google Books
Section 10.5. Combining Security Associations
22.4.4 Combining IPSec protocols
Question on SA Bundle
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
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.
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".(which means Key management SA bundle at once)
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.
interpretation of SA bundle.
(I'm somehow confused by this thread)
> Do you say that each attributes of multiple proposal with same number
> MUST have same transport mode ?
The encapsulation is applied to the SAs as a whole. So, yes.
See section 2.1 of RFC 2408. Here's what you're doing when you have multiple proposal payloads with the same number in a single SA payload:Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security protocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole.
"All of the protections in a suite must be treated as a single unit."
In other words, the group of SAs that make up the suite live and die as a unit, and have encapsulation applied as a single logical unit.