Cisco Cisco Packet Data Gateway (PDG)

 

IPSec for LTE/SAE enables network nodes to initiate an IPSec tunnel with another node for secure signaling and data 
traffic between the nodes, enabling up to 64K dynamic, service-integrated IPSec tunnels per chassis. Once established, a 
dynamic node-to-node IPSec tunnel continues to carry all of the signaling and/or bearer traffic between the nodes. 
Dynamic node-to-node IPSec for LTE/SAE is supported on the S1-MME interface for signaling traffic between the 
eNodeB and the MME, on the S1-U interface for data traffic between the eNodeB and the S-GW, and on the S5 
interface for data traffic between the S-GW and the P-GW. 

Dynamic node-to-node IPSec gets configured using dynamic IKEv2 crypto templates, which are used to specify 
common cryptographic parameters for the IPSec tunnels such as the encryption algorithm, HMAC function, and Diffie-
Hellman group. Additional information necessary for creating node-to-node IPSec tunnels such as revocation lists are 
fetched dynamically from the IPSec tunnel requests. 

For configuration instructions for dynamic node-to-node IPSec, see the configuration chapter in the administration 
guides for the MME, S-GW, and P-GW. 

Node-to-node IPSec for LTE/SAE can also be configured using crypto ACLs (Access Control Lists), which define the 
matching criteria used for routing subscriber data packets over an IPSec tunnel. ACL-based node-to-node IPSec tunnels 
are supported on the S1-MME interface for signaling traffic between the eNodeB and the MME, on the S1-U interface 
for data traffic between the eNodeB and the S-GW, and on the S5 interface for data traffic between the S-GW and the 
PGW. 

Unlike other ACLs that are applied to interfaces, contexts, or to one or more subscribers, crypto ACLs are applied via 
matching criteria to crypto maps, which define tunnel policies that determine how IPSec is implemented for subscriber 
data packets. Prior to routing, the system examines the properties of each subscriber data packet. If the packet properties 
match the criteria specified in the crypto ACL, the system initiates the IPSec policy dictated by the crypto map. ACL-
based node-to-node IPSec tunnels are configured using either IKEv2-IPv4 or IKEv2-IPv6 crypto maps for IPv4 or IPv6 
addressing. 

Up to 150 ACL-based node-to-node IPSec tunnels are supported on the system, each with one SA bundle that includes 
one Tx and one Rx endpoint. However, to avoid significant performance degradation, dynamic node-to-node IPSec 
tunnels are recommended. If ACL-based node-to-node IPSec tunnels are used, a limit of about ten ACL-based node-to-
node IPSec tunnels per system is recommended. 

For configuration instructions for ACL-based node-to-node IPSec, see the configuration chapter in the administration 
guides for the MME, S-GW, and P-GW. 

For more information on ACLs, see the System Administration Guide. 

Per RFC 4306, when a packet arrives at an IPSec subsystem and matches a 'protect' selector in its Security Policy 
Database (SPD), the subsystem must protect the packet via IPSec tunneling. Traffic selectors enable an IPSec subsystem 
to accomplish this by allowing two endpoints to share information from their SPDs. Traffic selector payloads contain 
the selection criteria for packets being sent over IPSec security associations (SAs). Traffic selectors can be created on 
the P-GW, S-GW, and MME for dynamic node-to-node IPSec tunnels during crypto template configuration by 
specifying a range of peer IPv4 or IPV6 addresses from which to carry traffic over IPSec tunnels.