Cisco Cisco Packet Data Interworking Function (PDIF) Prospecto

 

▄  Cisco StarOS IP Security (IPSec) Reference 

For example, consider an eNodeB with an IP address of 1.1.1.1 and an S-GW with a service address of 2.2.2.2. The S-
GW is registered to listen for IKE requests from the eNodeBs in the network using the following information: 



 

Local Address: 2.2.2.2 



 

Peer Address Network: 1.1.0.0 Mask: 255.255.0.0 



 

Payload ACL (Access Control List): udp host 2.2.2.2 eq 2123 1.1.0.0 0.0.255.255 

When an IKE request arrives the S-GW from eNodeB address 1.1.1.1, the IPSec subsystem converts the payload ACL 
to: udp host 2.2.2.2 eq 2123 host 1.1.1.1, and this payload becomes the traffic selector for the IPSec tunnel being 
negotiated. 

To properly accommodate control traffic between IPSec nodes, each child SA must include at least two traffic selectors: 
one with a well-known port in the source address, and one with a well-known port in the destination address. Continuing 
the example above, the final traffic selectors would be: 



 

Destination port as well-known port: udp host 2.2.2.2 1.1.0.0 0.0.255.255 eq 2123 



 

Source port as well-known port: udp host 2.2.2.2 eq 2123 1.1.0.0 0.0.255.255 

For ACL-based node-to-node IPSec tunnels, the configured crypto ACL becomes the traffic selector with no 
modification. 

IPSec for LTE/SAE includes the following authentication methods: 



 

PSK (Pre-Shared Key) Authentication. A pre-shared key is a shared secret that was previously shared between 

two network nodes. IPSec for LTE/SAE supports PSK such that both IPSec nodes must be configured to use 
the same shared secret. 



 

X.509 Certificate-based Peer Authentication. IPSec for LTE/SAE supports X.509 certificate-based peer 

authentication and CA (Certificate Authority) certificate authentication as described below. 

X.509 specifies standard formats for public key certificates, certificate revocation lists, attribute certificates, and a 
certification path validation algorithm. X.509 certificates are configured on each IPSec node so that it can send the 
certificate as part of its IKE_AUTH_REQ for the remote node to authenticate it. These certificates can be in PEM 
(Privacy Enhanced Mail) or DER (Distinguished Encoding Rules) format, and can be fetched from a repository via 
HTTP or FTP. 

CA certificate authentication is used to validate the certificate that the local node receives from a remote node during an 
IKE_AUTH exchange. 

A maximum of sixteen certificates and sixteen CA certificates are supported per system. One certificate is supported per 
service, and a maximum of four CA certificates can be bound to one crypto template. 

For configuration instructions for X.509 certificate-based peer authentication, see the configuration chapter in the 
administration guides for the MME, S-GW, and P-GW. 

The figure below shows the message flow during X.509 certificate-based peer authentication. The table that follows the 
figure describes each step in the message flow. 

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