Cisco Cisco Packet Data Interworking Function (PDIF)
IPSec Network Applications
IPSec for LTE/SAE Networks ▀
IPSec Reference, StarOS Release 18 ▄
47
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:
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: 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:
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.
modification.
If a TSr (Traffic Selector responder) configuration exists in the crypto template, traffic selector negotiation
automatically occurs for the TSr in accordance with RFC 5996 (see exception the note below). If no TSr is configured,
the gateway simply respects received traffic selectors and responds with the received traffic selectors. In either case, the
gateway can send a maximum of four traffic selectors per TSr.
automatically occurs for the TSr in accordance with RFC 5996 (see exception the note below). If no TSr is configured,
the gateway simply respects received traffic selectors and responds with the received traffic selectors. In either case, the
gateway can send a maximum of four traffic selectors per TSr.
The negotiation process respects a UE request for a smaller range of IP addresses. Packets are then sent to the target
server over the negotiated range.
server over the negotiated range.
For additional information on TSr configuration, refer to the Crypto Template IKEv2-Dynamic Payload Parameters
section in the Crypto Templates chapter.
section in the Crypto Templates chapter.
Important:
For Wireless Security Gateway (WSG) remote access service (RAS), incoming traffic selectors are
honored and sent back in the response without negotiation. This exception applies to Security Gateways (SecGWs).
Authentication Methods
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.
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 Certificate-based Peer Authentication
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.
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.