Cisco Cisco Packet Data Gateway (PDG)

 

▄  IPSec Reference, StarOS Release 16 

 

 

1 

The peer node initiates an IKEv2 exchange with the local node, known as the IKE_SA_INIT exchange, by issuing an 
IKE_SA_INIT Request to negotiate cryptographic algorithms, exchange nonces, and perform a Diffie-Hellman 
exchange with the local node. 

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. 

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. 

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. 

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. 

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. 

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. 

 

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. 

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. 

For additional information refer to the CRL Fetching section of the IPSec Certificates chapter of this guide.