Cisco Cisco Packet Data Interworking Function (PDIF)
IPSec Network Applications
IPSec for LTE/SAE Networks ▀
IPSec Reference, StarOS Release 18 ▄
49
Step
Description
2
The local node responds with an IKE_SA_INIT Response by choosing a cryptographic suite from the initiator’s offered
choices, completing the Diffie-Hellman and nonce exchanges with the peer node. In addition, the local node includes
the list of CA certificates that it will accept in its CERTREQ payload. For successful peer authentication, the
CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate. At this point
in the negotiation, the IKE_SA_INIT exchange is complete and all but the headers of all the messages that follow are
encrypted and integrity-protected.
choices, completing the Diffie-Hellman and nonce exchanges with the peer node. In addition, the local node includes
the list of CA certificates that it will accept in its CERTREQ payload. For successful peer authentication, the
CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate. At this point
in the negotiation, the IKE_SA_INIT exchange is complete and all but the headers of all the messages that follow are
encrypted and integrity-protected.
3
The peer node initiates an IKE_AUTH exchange with the local node by including the IDi payload, setting the CERT
payload to the peer certificate, and including the AUTH payload containing the signature of the previous IKE_SA_INIT
Request message (in step 1) generated using the private key of the peer certificate. The authentication algorithm used to
generate the AUTH payload is also included in the AUTH payload. The peer node also includes the CERTREQ payload
containing the list of SHA-1 hash algorithms for local node authentication. For successful server authentication, the
CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate.
payload to the peer certificate, and including the AUTH payload containing the signature of the previous IKE_SA_INIT
Request message (in step 1) generated using the private key of the peer certificate. The authentication algorithm used to
generate the AUTH payload is also included in the AUTH payload. The peer node also includes the CERTREQ payload
containing the list of SHA-1 hash algorithms for local node authentication. For successful server authentication, the
CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate.
4
Using the CA certificate corresponding to the peer certificate, the local node first verifies that the peer certificate in the
CERT payload has not been modified and the identity included in the IDi corresponds to the identity in the peer
certificate. If the verification is successful, using the public key of the peer certificate, the local node generates the
expected AUTH payload and compares it with the received AUTH payload. If they match, the authentication of the peer
node is successful. Otherwise, the local node sends an IKEv2 Notification message indicating authentication failure.
CERT payload has not been modified and the identity included in the IDi corresponds to the identity in the peer
certificate. If the verification is successful, using the public key of the peer certificate, the local node generates the
expected AUTH payload and compares it with the received AUTH payload. If they match, the authentication of the peer
node is successful. Otherwise, the local node sends an IKEv2 Notification message indicating authentication failure.
5
The local node responds with the IKE_AUTH Response, including the IDr payload, setting the CERT payload to the
local node certificate, and including the AUTH payload containing the signature of the IKE_SA_INIT Response
message (in step 2) generated using the private key of the local node certificate. The authentication algorithm used to
generate the AUTH payload is also included in the AUTH payload.
local node certificate, and including the AUTH payload containing the signature of the IKE_SA_INIT Response
message (in step 2) generated using the private key of the local node certificate. The authentication algorithm used to
generate the AUTH payload is also included in the AUTH payload.
6
Using the CA certificate corresponding to the local node certificate, the peer node first verifies that the local node
certificate in the CERT payload has not been modified. If the verification is successful, using the public key of the local
node certificate, the peer generates the expected AUTH payload and compares it with the received AUTH payload. If
they match, the local node authentication is successful. This completes the IKE_AUTH exchange.
certificate in the CERT payload has not been modified. If the verification is successful, using the public key of the local
node certificate, the peer generates the expected AUTH payload and compares it with the received AUTH payload. If
they match, the local node authentication is successful. This completes the IKE_AUTH exchange.
7
An IPSec SA gets established between the peer node and the local node. If more IPSec SAs are needed, either the peer
or local node can initiate the creation of additional Child SAs using a CREATE_CHILD_SA exchange.
or local node can initiate the creation of additional Child SAs using a CREATE_CHILD_SA exchange.
Certificate Revocation Lists
Certificate revocation lists track certificates that have been revoked by the CA (Certificate Authority) and are no longer
valid. Per RFC 3280, during certificate validation, IPSec for LTE/SAE checks the certificate revocation list to verify
that the certificate the local node receives from the remote node has not expired and hence is still valid.
valid. Per RFC 3280, during certificate validation, IPSec for LTE/SAE checks the certificate revocation list to verify
that the certificate the local node receives from the remote node has not expired and hence is still valid.
During configuration via the system CLI, one certificate revocation list is bound to each crypto template and can be
fetched from its repository via HTTP or FTP.
fetched from its repository via HTTP or FTP.
For additional information refer to the CRL Fetching section of the IPSec Certificates chapter of this guide.
Child SA Rekey Support
Rekeying of an IKEv2 Child Security Association (SA) occurs for an already established Child SA whose lifetime
(either time-based or data-based) is about to exceed a maximum limit. The IPSec subsystem initiates rekeying to replace
the existing Child SA. During rekeying, two Child SAs exist momentarily (500ms or less) to ensure that transient
packets from the original Child SA are processed by the IPSec node and not dropped.
(either time-based or data-based) is about to exceed a maximum limit. The IPSec subsystem initiates rekeying to replace
the existing Child SA. During rekeying, two Child SAs exist momentarily (500ms or less) to ensure that transient
packets from the original Child SA are processed by the IPSec node and not dropped.