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 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.

Use the following procedure to create, sign, and configure certificates:

1. Add a file location where the certificates and private keys will be stored:

   config
       cmp cert-store location path_name
       end

2. Generate a Certificate Signing Request (CSR):

   crypto rsa-keygen modulus { 1024 | 2048 | 4096 | 512 } id-type { fqdn id fqdn_id | ip id IP_address | rfc822-addr id id_type } subject-name subject_string

   A new private key along with the certificate request will be generated in the configured file location.

3. Use the generated certificate request to apply for a digital identity certificate from the certificate authority (CA).

4. Once the certificate is received, download and configure the certificate file to an accessible path:

   certificate name name { der url pathname | pem { data pemdata | url pathname } private-key pem { [ encrypted ] data pemdata | url pathname [cert-enc] [cert-hash-url url patname ] } }

Notes:

• Use the no cmp cert-store command to remove the certificate storage location configuration.

• Use the no certificate name name command to remove the certificate configuration.

• pathname must be in one of the following formats:

  • [ file:]{ /flash | /usb1 | /hd-raid }[/directory]/filename

  • tftp://host[:port][/directory]/filename

  • ftp://[username[:password]@]host[:port][/directory]/filename

  • sftp://[username[:password]@]host[:port][/directory]/filename

  • http://[username[:password]@]host[:port][/directory]/filename

• fqdn_id, id_type, subject_string must be an alphanumeric string from 1 to 256 characters

• IP_address can be an IPv4 address with dotted-decimal notation, or an IPv6 address with colon-separated hexa-decimal notation.

• pemdata must be an alphanumeric string of 1 through 4095 (if private key is not implemented) or 1 through 8191 (if private key is implemented) characters.