Multiple Child SA (MCSA) Support
Overview
A child SA is an Encapsulating Security Payload (ESP) or Authentication header (AH) security association (SA) carrying the secure user traffic. An SA is a "simplex connection"; to achieve bidirectional secure traffic a pair of SAs is required (RFC 5996). To meet this common requirement, IKE explicitly creates SA pairs. An SA pair is referred to as a "Child SA"; one child SA is a pair of IPsec SAs in each direction.
StarOS supports creation up to five child SAs under the crypto template configuration. Child SAs are supported only for IKEv2.
Each child SA should consist of mutually exclusive traffic selectors which are configured via crypto template payloads.
The following traffic selectors would match UDP packets from 198.51.100.66 to anywhere, with any of the four combinations of source/destination ports (100,300), (100,400), (200,300), and (200, 400). Thus, some types of policies may require several Child SA pairs. For instance, a policy matching only source/destination ports (100,300) and (200,400), but not the other two combinations, cannot be negotiated as a single Child SA pair.
TSi = ((17, 100, 198.51.100.66-198.51.100.66),(17, 200, 198.51.100.66-198.51.100.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),(17, 400, 0.0.0.0-255.255.255.255)) -
The initiator of IKE_INIT can start subsequent Child SA creations after the first Child SA creation based on initiator traffic selector (TSi) configuration which calls for multiple Child SAs. StarOS receives CREATE_CHILD_SA request after IKE_AUTH.
-
The responder can initiate subsequent Child SA creation after the first child SA creation based on the responder traffic selector configurations (TSr) which calls for multiple Child SAs. StarOS sends CREATE_CHILD_SA request after IKE_AUTH.
Deployment Scenarios
The creation of multiple child SAs helps an operator to segregate and limit the secure traffic into multiple flows. For example, control and data paths between two nodes can be established over two child SAs; the rest of the data between the nodes will bypass IPSec.
Multiple child SAs may be used for carrying traffic with different class of services (QoS). Similarly, different SAs could be used to carry different traffic with specific security properties. For example, one SA with strongest protection, another with a weaker one, and still another with a proprietary one stipulated by legal, performance or cost needs.
Call Flows
Child SA Creation by Initiator
With crypto template configuration, Child SA creation is initiated by the IKE_INIT initiator through a CREATE_CHILD_SA exchange or by StarOS acting as the responder. The first Child SA is created using the first traffic selector. After creating the first Child SA, the initiator requests the second Child SA using the second traffic selector. The responder completes the creation of the second Child SA.
Child SA Creation by Responder
After negotiating a transform set (TS), the responder detects the need to create more child SAs to support configured traffic selectors. It sends CREATE_CHILD_SA to create as many child SAs as required to meet the TS configuration. The initiator completes subsequent child SA creations.
Feedback