> Configuring Subscriber Session Tracing
> This chapter provides information on subscriber session trace functionality to allow an operator to trace subscriber activity at various points in the network and at various level of details in EPS network. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
> This chapter discusses following topics for feature support of Subscriber Session Tracing in LTE service:

> • | Introduction

> • | Supported Standards

> • | Subscriber Session Tracing Functional Description

> • | Subscriber Session Trace Configuration

> • | Verifying Your Configuration

> Introduction
> The Subscriber Level Trace provides a 3GPP standards-based session-level trace function for call debugging and testing new functions and access terminals in an LTE environment.
> In general, the Session Trace capability records and forwards all control activity for the monitored subscriber on the monitored interfaces. This is typically all the signaling and authentication/subscriber services messages that flow when a UE connects to the access network.
> The EPC network entities like MME, S-GW, P-GW support 3GPP standards based session level trace capabilities to monitor all call control events on the respective monitored interfaces including S6a, S1-MME and S11 on MME, S5, S8, S11 at S-GW and S5 and S8 on P-GW. The trace can be initiated using multiple methods:

> • | Management initiation via direct CLI configuration

> • | Management initiation at HSS with trace activation via authentication response messages over S6a reference interface

> • | Signaling based activation through signaling from subscriber access terminal

> Important: Once the trace is provisioned it can be provisioned through the access cloud via various signaling interfaces.
> The session level trace function consists of trace activation followed by triggers. The time between the two events is where the EPC network element buffers the trace activation instructions for the provisioned subscriber in memory using camp-on monitoring. Trace files for active calls are buffered as XML files using non-volatile memory on the local dual redundant hard drives on the chassis. The Trace Depth defines the granularity of data to be traced. Six levels are defined including Maximum, Minimum and Medium with ability to configure additional levels based on vendor extensions.
> Important: Only Maximum Trace Depth is supported in the current release.
> The following figure shows a high-level overview of the session-trace functionality and deployment scenario:
> Session Trace Function and Interfaces
> All call control activity for active and recorded sessions is sent to an off-line Trace Collection Entity (TCE) using a standards-based XML format over a FTP or secure FTP (SFTP) connection.
> Note: In the current release the IPv4 interfaces are used to provide connectivity to the TCE. Trace activation is based on IMSI or IMEI.
> Supported Functions
> This section provides the list of supported functionality of this feature support:

> • | Support to trace the control flow through the access network.

> • | Trace of specific subscriber identified by IMSI

> • | Trace of UE identified by IMEI(SV)

> • | Ability to specify specific functional entities and interfaces where tracing should occur.

> • | Scalability and capacity

> • | Support up to 32 simultaneous session traces per NE

> • | Capacity to activate/deactivate TBD trace sessions per second

> • | Each NE can buffer TBD bytes of trace data locally

> • | Statistics and State Support

> • | Session Trace Details

> • | Management and Signaling-based activation models

> • | Trace Parameter Propagation

> • | Trace Scope (EPS Only)

> • | MME: S1, S3, S6a, S10, S11

> • | S-GW: S4, S5, S8, S11, Gxc

> • | PDN-GW: S2a, S2b, S2c, S5, S6b, Gx, S8, SGi

> • | Trace Depth: Maximum, Minimum, Medium (with or without vendor extension)

> • | XML Encoding of Data as per 3GPP standard 3GPP TS 32.422 V8.6.0 (2009-09)

> • | Trace Collection Entity (TCE) Support

> • | Active pushing of files to the TCE

> • | Passive pulling of files by the TCE

> • | 1 TCE support per context

> • | Trace Session Recovery after Failure of Session Manager

> Supported Standards
> Support for the following standards and requests for comments (RFCs) have been added with this interface support:

> • | 3GPP TS 32.421 V8.5.0 (2009-06): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Subscriber and equipment trace: Trace concepts and requirements (Release 8)

> • | 3GPP TS 32.422 V8.6.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Subscriber and equipment trace; Trace control and configuration management (Release 8)

> • | 3GPP TS 32.423 V8.2.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Subscriber and equipment trace: Trace data definition and management (Release 8)

> Subscriber Session Trace Functional Description
> This section describes the various functionality involved in tracing of subscriber session on EPC nodes:
> Operation
> The session trace functionality is separated into two steps - activation and trigger.
> Before tracing can begin, it must be activated. Activation is done either via management request or when a UE initiates a signaled connection. After activation, tracing actually begins when it is triggered (defined by a set of trigger events).
> Trace Session
> A trace session is the time between trace activation and trace de-activation. It defines the state of a trace session, including all user profile configuration, monitoring points, and start/stop triggers. It is uniquely identified by a Trace Reference.
> The Trace Reference id is composed of the MCC (3 digits) + the MNC (3 digits) + the trace Id (3 byte octet string).
> Trace Recording Session
> A trace recording session is a time period in which activity is actually being recorded and traceable data is being forwarded to the TCE. A trace recording session is initiated when a start trigger event occurs and continues until the stop trigger event occurs and is uniquely identified by a Trace Recording Session Reference.
> Network Element (NE)
> Network elements are the functional component to facilitate subscriber session trace in mobile network.
> The term network element refers to a functional component that has standard interfaces in and out of it. It is typically shown as a stand-alone AGW. Examples of NEs are the MME, S-GW, and P-GW.
> Currently, subscriber session trace is not supported for co-located network elements in the EPC network.
> Activation
> Activation of a trace is similar whether it be via the management interface or via a signaling interface. In both cases, a trace session state block is allocated which stores all configuration and state information for the trace session. In addition, a (S)FTP connection to the TCE is established if one does not already exist (if this is the first trace session established, odds are there will not be a (S)FTP connection already established to the TCE).
> If the session to be traced is already active, tracing may begin immediately. Otherwise, tracing activity concludes until the start trigger occurs (typically when the subscriber or UE under trace initiates a connection). A failure to activate a trace (due to max exceeded or some other failure reason) results in a notification being sent to the TCE indicating the failure.
> Management Activation
> With a management-initiated activation, the WEM sends an activation request directly to the NE where the trace is to be initiated. The NE establishes the trace session and waits for a triggering event to start actively tracing. Depending upon the configuration of the trace session, the trace activation may be propagated to other NEs.
> Signaling Activation
> With a signaling based activation, the trace session is indicated to the NE across a signaling interface via a trace invocation message. This message can either be piggybacked with an existing bearer setup message (in order to trace all control messages) or by sending a separate trace invocation message (if the user is already active).
> Start Trigger
> A trace recording session starts upon reception of one of the configured start triggers. Once the start trigger is received, the NE generates a Trace Recording Session Reference (unique to the NE) and begins to collect and forward trace information on the session to the TCE.
> List of trigger events are listed in 3GPP standard 3GPP TS 32.422 V8.6.0 (2009-09).
> Deactivation
> Deactivation of a Trace Session is similar whether it was management or signaling activated. In either case, a deactivation request is received by the NE that contains a valid trace reference results in the de-allocation of the trace session state block and a flushing of any pending trace data. In addition, if this is the last trace session to a particular TCE, the (S)FTP connection to the TCE is released after the last trace file is successfully transferred to the TCE.
> Stop Trigger
> A trace recording session ends upon the reception of one of the configured stop triggers. Once the stop trigger is received, the NE will terminate the active recording session and attempt to send any pending trace data to the TCE. The list of triggering events can be found in 3GPP standard 3GPP TS 32.422 V8.6.0 (2009-09).
> Data Collection and Reporting
> Subscriber session trace functionality supprots data collection and reporting system to provide historical usage adn event analysis.
> All data collected by the NE is formatted into standard XML file format and forwarded to the TCE via (S)FTP. The specific format of the data is defined in 3GPP standard 3GPP TS 32.423 V8.2.0 (2009-09)
> Trace Depth
> The Trace Depth defines what data is to be traced. There are six depths defined: Maximum, Minimum, and Medium all having with and without vendor extension flavors. The maximum level of detail results in the entire control message getting traced and forwarded to the TCE. The medium and minimum define varying subsets of the control messages (specific decoded IEs) to be traced and forwarded. The contents and definition of the medium and minimum trace can be found in 3GPP standard 3GPP TS 32.423 V8.2.0 (2009-09).
> Important: Only Maximum Trace Depth is supported in the current release.
> Trace Scope
> The Trace Scope defines what NEs and what interfaces have the tracing capabilities enabled on them. This is actually a specific list of NE types and interfaces provided in the trace session configuration by the operator (either directly via a management interface or indirectly via a signaling interface).
> Network Element Details
> Trace functionality for each of the specific network elements supported by this functionality are described in this section.
> This section includes the trace monitoring points applicable to them as well as the interfaces over which they can send and/or receive trace configuration.
> MME
> The MME support tracing of the following interfaces with the following trace capabilities:

> Interface Name | Remote Device | Trace Signaling (De)Activation RX | Trace Signaling (De)Activation TX
> S1a | eNodeB | N | Y
> S3 | SGSN | Y | Y
> S6a | HSS | Y | N
> S10 | MME | Y | Y
> S11 | S-GW | N | Y

> ‌
> S-GW
> The S-GW support tracing of the following interfaces with the following trace capabilities:

> Interface Name | Remote Device | Trace Signaling (De)Activation RX | Trace Signaling (De)Activation TX
> S1-U | eNodeB | Y | N
> S4 | SGSN | N | N
> S5 | P-GW (Intra-PLMN) | Y | N
> S8 | P-GW (Inter-PLMN) | N | N
> S11 | MME | Y | N
> S12 | RNC | Y | N
> Gxc | Policy Server | Y | N

> ‌
> P-GW
> The P-GW support tracing of the following interfaces with the following trace capabilities:

> Interface Name | Remote Device | Trace Signaling (De)Activation RX | Trace Signaling (De)Activation TX
> S2abc | Various NEs | N | N
> S5 | S-GW (Intra-PLMN) | Y | N
> S6b | AAA Server/Proxy | Y | N
> S8 | S-GW (Inter-PLMN) | N | N
> Gx | Policy Server | Y | N
> SGi | IMS | Y | N

> ‌
> Subscriber Session Trace Configuration
> This section provides a high-level series of steps and the associated configuration examples for configuring the system to enable the Subscriber Session Trace collection and monitoring function on network elements s in LTE/EPC networks.
> Important: This section provides the minimum instruction set to enable the Subscriber Session Trace functionality to collect session traces on network elements on EPC networks. Commands that configure additional function for this feature are provided in the Command Line Interface Reference.
> These instructions assume that you have already configured the system level configuration as described in the System Administration Guide and specific product Administration Guide.
> To configure the system to support subscriber session trace collection and trace file transport on a system:

> Step 1 | Enable the subscriber session trace functionality with NE interface and TCE address at the Exec Mode level on an EPC network element by applying the example configurations presented in the Enabling Subscriber Session Trace on EPC Network Element section.

> Step 2 | Configure the network and trace file transportation parameters by applying the example configurations presented in the Trace File Collection Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Step 4 | Verify the configuration of Subscriber Session Trace related parameters by applying the commands provided in the Verifying Your Configuration section of this chapter.

> Enabling Subscriber Session Trace on EPC Network Element
> This section provides the configuration example to enable the subscriber session trace on a system at the Exec mode:
> session trace subscriber network-element { ggsn | mme | pgw | sgw } { imei <imei_id> } { imsi <imsi_id> } { interface { all | <interface> } } trace-ref <trace_ref_id> collection-entity <ip_address>
> Notes:

> • | <interface> is the name of the interfaces applicable for specific NE on which subscriber session traces have to be collected. For more information, refer to the session trace subscriber command in the Command Line Interface Reference.

> • | <trace_ref_id> is the configured Trace Id to be used for this trace collection instance. It is composed of MCC (3 digit)+MNC (3 digit)+Trace Id (3 byte octet string).

> • | <ip_address> is the IP address of Trace collection Entity in IPv4 notation.

> Trace File Collection Configuration
> This section provides the configuration example to configure the trace fil e collection parameters and protocols to be used to store trace files on TCE through FTP/S-FTP:
> configure
> session trace subscriber network-element { all | ggsn | mme | pgw | sgw } [ collection-timer <dur> ] [ tce-mode { none | push transport { ftp | sftp } path <string> username <name> { encrypted password <enc_pw> ] | password <password> } } ]
> end
> Notes:

> • | <string> is the location/path on the trace collection entity (TCE) where trace files will be stored on TCE. For more information, refer to the session trace command in the Command Line Interface Reference.

> Verifying Your Configuration
> This section explains how to display and review the configurations after saving them in a .cfg file as described in the System Administration Guide and also to retrieve errors and warnings within an active configuration for a service.
> Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
> These instructions are used to verify the Subscriber Session Trace configuration.

> Step 1 | Verify that your subscriber session support is configured properly by entering the following command in Exec Mode:

> show session trace statistics
> The output of this command displays the statistics of the session trace instance.
> Num current trace sessions: 5
> Total trace sessions activated: 15
> Total Number of trace session activation failures: 2
> Total Number of trace recording sessions triggered: 15
> Total Number of messages traced: 123
> Number of current TCE connections: 2
> Total number of TCE connections: 3
> Total number of files uploaded to all TCEs: 34

> Step 2 | View the session trace references active for various network elements in an EPC network by entering the following command in Exec Mode:

> show session trace trace-summary
> The output of this command displays the summary of trace references for all network elements:
> MME
> Trace Reference: 310012012345
> Trace Reference: 310012012346
> SGW
> Trace Reference: 310012012345
> Trace Reference: 310012012346
> PGW
> Trace Reference: 310012012347
> Appendix A
> Direct Tunnel
> This chapter briefly describes the 3G/4G UMTS direct tunnel (DT) feature, indicates how it is implemented on various systems on a per call basis, and provides feature configuration procedures.
> Products supporting direct tunnel include:

> • | 3G devices (per 3GPP TS 23.919 v8.0.0):

> • | the Serving GPRS Support Node (SGSN)

> • | the Gateway GPRS Support Node (GGSN)

> • | LTE devices (per 3GPP TS 23.401 v8.3.0):

> • | Serving Gateway (S-GW)

> • | PDN Gateway (P-GW)

> Important: Direct tunnel is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> The SGSN determines if setup of a direct tunnel is allowed or disallowed. Currently, the SGSN and S-GW are the only products that provide configuration commands for this feature. All other products that support direct tunnel do so by default.
> This chapter provides the following information:

> • | Direct Tunnel Feature Overview

> • | Direct Tunnel Configuration

> Direct Tunnel Feature Overview
> The direct tunnel architecture allows the establishment of a direct user plane (GTP-U) tunnel between the radio access network equipment (RNC) and the GGSN/P-GW.
> Once a direct tunnel is established, the SGSN/S-GW continues to handle the control plane (RANAP/GTP-C) signaling and retains the responsibility of making the decision to establish direct tunnel at PDN context activation.
> GTP-U Direct Tunneling
> A direct tunnel improves the user experience (for example, expedites web page delivery, reduces round trip delay for conversational services) by eliminating switching latency from the user plane. An additional advantage, direct tunnel functionality implements optimization to improve the usage of user plane resources (and hardware) by removing the requirement from the SGSN/S-GW to handle the user plane processing.
> A direct tunnel is achieved upon PDN context activation in the following ways:

> • | 3G network: The SGSN establishes a user plane (GTP-U) tunnel directly between the RNC and the GGSN, using an Updated PDN Context Request toward the GGSN.

> Direct Tunneling - 3G Network

> • | LTE network: When Gn/Gp interworking with pre-release 8 (3GPP) SGSNs is enabled, the GGSN service on the P-GW supports direct tunnel functionality. The SGSN establishes a user plane (GTP-U) tunnel directly between the RNC and the GGSN/P-GW, using an Update PDN Context Request toward the GGSN/P-GW.

> Direct Tunneling - LTE Network, GTP-U Tunnel

> • | LTE network: The SGSN establishes a user plane tunnel (GTP-U tunnel over an S12 interface) directly between the RNC and the S-GW, using an Update PDN Context Request toward the S-GW.

> Direct Tunneling - LTE Network, S12 Interface
> A major consequence of deploying a direct tunnel is that it produces a significant increase in control plane load on both the SGSN/S-GW and GGSN/P-GW components of the packet core. Hence, deployment requires highly scalable GGSNs/P-GWs since the volume and frequency of Update PDP Context messages to the GGSN/P-GW will increase substantially. The SGSN/S-GW platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
> The following figure illustrates the logic used within the SGSN/S-GW to determine if a direct tunnel will be setup.
> Direct Tunneling - Establishment Logic
> Direct Tunnel Configuration
> The following configurations are provided in this section:

> • | Configuring Direct Tunnel Support on the SGSN

> • | Configuring S12 Direct Tunnel Support on the S-GW

> Configuring Direct Tunnel Support on the SGSN
> By default, direct tunnel support is

> • | disallowed on the SGSN/S-GW

> • | allowed on the GGSN/P-GW.

> The SGSN/S-GW direct tunnel functionality is enabled within an operator policy configuration. One aspect of an operator policy is to allow or disallow the setup of direct GTP-U tunnels. If no operator policies are configured, the system looks at the settings in the system operator policy named default.
> For more information about operator policies and configuration details, refer to the Operator Policy chapter also in this guide.
> Important: If direct tunnel is allowed in the default operator policy, then any incoming call that does not have an applicable operator policy configured will have direct tunnel allowed.
> The following is a high-level view of the steps, and the associated configuration examples, to configure the SGSN to setup a direct tunnel.
> Before beginning any of the following procedures, you must have completed (1) the basic service configuration for the SGSN, as described in the Cisco ASR Serving GPRS Support Node Administration Guide, and (2) the creation and configuration of a valid operator policy, as described in the Operator Policy chapter in this guide.

> Step 1 | Configure the SGSN to setup GTP-U direct tunnel between an RNC and an access gateway by applying the example configuration presented in the Enabling Setup of GTP-U Direct Tunnels section below.

> Step 2 | Configure the SGSN to allow GTP-U direct tunnels to an access gateway, for a call filtered on the basis of the APN, by applying the example configuration presented in the Enabling Direct Tunnel per APN section below.

> Important: It is only necessary to complete either step 2 or step 3 as a direct tunnel can not be setup on the basis of call filtering matched with both an APN profile and an IIMEI profile.

> Step 3 | Configure the SGSN to allow GTP-U direct tunnels to a GGSN, for a call filtered on the basis of the IMEI, by applying the example configuration presented in the Enabling Direct Tunnel per IMEI section below.

> Step 4 | Configure the SGSN to allow GTP-U direct tunnel setup from a specific RNC by applying the example configuration presented in the Enabling Direct Tunnel to Specific RNCs section below.

> Step 5 | (Optional) Configure the SGSN to disallow direct tunnel setup to a single GGSN that has been configured to allow it in the APN profile. This command allows the operator to restrict use of a GGSN for any reason, such as load balancing. Refer to the direct-tunnel-disabled-ggsn command in the SGTP Service Configuration Mode chapter of the Command Line Interface Reference.

> Step 6 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Step 7 | Check that your configuration changes have been saved by using the sample configuration found in the Verifying the SGSN Direct Tunnel Configuration section in this chapter.

> Enabling Setup of GTP-U Direct Tunnels
> The SGSN determines whether a direct tunnel can be setup and by default the SGSN doesn’t support direct tunnel.
> Example Configuration
> Enabling direct tunnel setup on an SGSN is done by configuring direct tunnel support in a call-control profile.
> config
> call-control-profile <policy_name>
> direct-tunnel attempt-when-permitted
> end
> Notes:

> • | A call-control profile must have been previously created, configured, and associated with a previously created, configured, and valid operator policy. For information about operator policy creation/configuration, refer to the Operator Policy chapter in this guide.

> • | Direct tunnel is now allowed on the SGSN but will only setup if allowed on both the destination node and the RNC.

> Enabling Direct Tunnel per APN
> In each operator policy, APN profiles are configured to connect to one or more GGSNs and to control the direct tunnel access to that GGSN based on call filtering by APN. Multiple APN profiles can be configured per operator policy.
> By default, APN-based direct tunnel functionality is allowed so any existing direct tunnel configuration must be removed to return to default and to ensure that the setup has not been restricted.
> Example Configuration
> The following is an example of the commands used to ensure that direct tunneling, to a GGSN(s) identified in the APN profile, is enabled:
> config
> apn-profile <profile_name>
> remove direct tunnel
> end
> Notes:

> • | An APN profile must have been previously created, configured, and associated with a previously created, configured, and valid operator policy. For information about operator policy creation/configuration, refer to the Operator Policy chapter in this guide.

> • | Direct tunnel is now allowed for the APN but will only setup if also allowed on the RNC.

> Enabling Direct Tunnel per IMEI
> Some operator policy filtering of calls is done on the basis of international mobile equipment identity (IMEI) so the direct tunnel setup may rely upon the feature configuration in the IMEI profile.
> The IMEI profile basis its permissions for direct tunnel on the RNC configuration associated with the IuPS service.
> By default, direct tunnel functionality is enabled for all RNCs.
> Example Configuration
> The following is an example of the commands used to enable direct tunneling in the IMEI profile:
> config
> imei-profile <profile_name>
> direct-tunnel check-iups-service
> end
> Notes:

> • | An IMEI profile must have been previously created, configured, and associated with a previously created, configured, and valid operator policy. For information about operator policy creation/configuration, refer to the Operator Policy chapter in this guide.

> • | Direct tunnel is now allowed for calls within the IMEI range associated with the IMEI profile but a direct tunnel will only setup if also allowed on the RNC.

> Enabling Direct Tunnel to Specific RNCs
> SGSN access to radio access controllers (RNCs) is configured in the IuPS service.
> Each IuPS service can include multiple RNC configurations that determine communications and features depending on the RNC.
> By default, direct tunnel functionality is enabled for all RNCs.
> Example Configuration
> The following is an example of the commands used to ensure that restrictive configuration is removed and direct tunnel for the RNC is enabled:
> config
> context <ctx_name>
> iups-service <service_name>
> rnc id <rnc_id>
> default direct-tunnel
> end
> Notes:

> • | An IuPS service must have been previously created, and configured.

> • | An RNC configuration must have been previously created within an IuPS service configuration.

> • | Command details for configuration can be found in the Command Line Interface Reference.

> Verifying the SGSN Direct Tunnel Configuration
> Enabling the setup of a GTP-U direct tunnel on the SGSN is not a straight forward task. It is controlled by an operator policy with related configuration in multiple components. Each of these component configurations must be checked to ensure that the direct tunnel configuration has been completed. You need to begin with the operator policy itself.
> Verifying the Operator Policy Configuration
> For the feature to be enabled, it must be allowed in the call-control profile and the call-control profile must be associated with an operator policy. As well, either an APN profile or an IMEI profile must have been created/configured and associated with the same operator policy. Use the following command to display and verify the operator policy and the association of the required profiles:
> show operator-policy full name <policy_name>
> The output of this command displays profiles associated with the operator policy.
> [local]asr5x00# show operator-policy full name oppolicy1
> Operator Policy Name = oppolicy1
> Call Control Profile Name : ccprofile1
> Validity : Valid
> IMEI Range 99999999999990 to 99999999999995
> IMEI Profile Name : imeiprofile1
> Validity : Invalid
> APN NI homers1
> APN Profile Name : apnprofile1
> Validity : Valid
> APN NI visitors2
> APN Profile Name : apnprofile2
> Validity : Invalid
> Notes:

> • | Validity refers to the status of the profile. Valid indicates that profile has been created and associated with the policy. Invalid means only the name of the profile has been associated with the policy.

> • | The operator policy itself will only be valid if one or more IMSI ranges have been associated with it - refer to the Operator Policy chapter, in this guide, for details.

> Verifying the Call-Control Profile Configuration
> Use the following command to display and verify the direct tunnel configuration for the call-control profiles:
> show call-control-profile full name <profile_name>
> The output of this command displays all of the configuration, including direct tunnel for the specified call-control profile.
> Call Control Profile Name = ccprofile1
> ...
> Re-Authentication : Disabled
> Direct Tunnel : Not Restricted
> GTPU Fast Path : Disabled
> ..
> Verifying the APN Profile Configuration
> Use the following command to display and verify the direct tunnel configuration in the APN profile:
> show apn-profile full name <profile_name>
> The output of this command displays all of the configuration, including direct tunnel for the specified APN profile.
> Call Control Profile Name = apnprofile1
> ...
> IP Source Validation : Disabled
> Direct Tunnel : Not Restricted
> Service Restriction for Access Type > UMTS : Disabled
> ..
> Verifying the IMEI Profile Configuration
> Use the following command to display and verify the direct tunnel configuration in the IMEI profile:
> show imei-profile full name <profile_name>
> The output of this command displays all of the configuration, including direct tunnel for the specified IMEI profile.
> IMEI Profile Name = imeiprofile1
> Black List : Disabled
> GGSN Selection : Disabled
> Direct Tunnel : Enabled
> Verifying the RNC Configuration
> Use the following command to display and verify the direct tunnel configuration in the RNC configuration:
> show iups-service name <service_name>
> The output of this command displays all of the configuration, including direct tunnel for the specified IuPS service.
> IService name : iups1
> ...
> Available RNC:
> Rnc-Id : 1
> Direct Tunnel : Not Restricted
> Configuring S12 Direct Tunnel Support on the S-GW
> The example in this section configures an S12 interface supporting direct tunnel bypass of the S4 SGSN for inter-RAT handovers.
> The direct tunnel capability on the S-GW is enabled by configuring an S12 interface. The S4 SGSN is then responsible for creating the direct tunnel by sending an FTEID in a control message to the MME over the S3 interface. The MME forwards the FTEID to the S-GW over the S11 interfaces. The S-GW responds with it’s own U-FTEID providing the SGSN with the identification information required to set up the direct tunnel over the S12 interface.
> Use the following example to configure this feature:
> configure
> context <egress_context_name> -noconfirm
> interface <s12_interface_name>
> ip address <s12_ipv4_address_primary>
> ip address <s12_ipv4_address_secondary>
> exit
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s12_interface_name> <egress_context_name>
> exit
> context <egress_context_name> -noconfirm
> gtpu-service <s12_gtpu_egress_service_name>
> bind ipv4-address <s12_interface_ip_address>
> exit
> egtp-service <s12_egtp_egress_service_name>
> interface-type interface-sgw-egress
> validation-mode default
> associate gtpu-service <s12_gtpu_egress_service_name>
> gtpc bind address <s12_interface_ip_address>
> exit
> sgw-service <sgw_service_name> -noconfirm
> associate egress-proto gtp egress-context <egress_context_name> egtp-service <s12_egtp_egress_service_name>
> end
> Notes:

> • | The S12 interface IP address(es) can also be specified as IPv6 addresses using the ipv6 address command.

> Appendix B
> IP Security
> This chapter provides information on configuring an enhanced or extended service. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
> Important: The IP Security is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> Caution: IPSec parameter configurations saved using this release may not function properly with older software releases.
> This chapter contains the following sections:

> • | Overview

> • | IPSec Terminology

> • | Implementing IPSec for PDN Access Applications

> • | Implementing IPSec for Mobile IP Applications

> • | Implementing IPSec for L2TP Applications

> • | Transform Set Configuration

> • | ISAKMP Policy Configuration

> • | ISAKMP Crypto Map Configuration

> • | Dynamic Crypto Map Configuration

> • | Manual Crypto Map Configuration

> • | Crypto Map and Interface Association

> • | FA Services Configuration to Support IPSec

> • | HA Service Configuration to Support IPSec

> • | RADIUS Attributes for IPSec-based Mobile IP Applications

> • | LAC Service Configuration to Support IPSec

> • | Subscriber Attributes for L2TP Application IPSec Support

> • | PDSN Service Configuration for L2TP Support

> • | Redundant IPSec Tunnel Fail-Over

> • | Redundant IPSec Tunnel Fail-over Configuration

> • | Dead Peer Detection (DPD) Configuration

> • | APN Template Configuration to Support L2TP

> • | IPSec for LTE/SAE Networks

> Overview
> IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways. IPSec can be implemented on the system for the following applications:

> • | PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria. This application can be implemented for both core network service and HA-based systems. The following figure shows IPSec configurations.

> IPSec Applications

> • | Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.

> Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

> • | L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.

> Note that: IPSec can be implemented for both attribute-based and compulsory tunneling applications for 3GPP2 services.
> Applicable Products and Relevant Sections
> The IPSec feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.

> Applicable Product(s) | Refer to Sections
> PDSN/FA/HA |
> • | Implementing IPSec for PDN Access Applications
> • | Implementing IPSec for Mobile IP Applications
> • | Transform Set Configuration
> • | ISAKMP Policy Configuration
> • | ISAKMP Crypto Map Configuration
> • | Dynamic Crypto Map Configuration
> • | Manual Crypto Map Configuration
> • | Crypto Map and Interface Association
> • | FA Services Configuration to Support IPSec
> • | HA Service Configuration to Support IPSec
> • | RADIUS Attributes for IPSec-based Mobile IP Applications
> • | LAC Service Configuration to Support IPSec
> • | Subscriber Attributes for L2TP Application IPSec Support
> • | PDSN Service Configuration for L2TP Support
> • | Redundant IPSec Tunnel Fail-Over
> • | Dead Peer Detection (DPD) Configuration
> GGSN/FA/HA |
> • | Implementing IPSec for PDN Access Applications
> • | Implementing IPSec for Mobile IP Applications
> • | Implementing IPSec for L2TP Applications
> • | Transform Set Configuration
> • | ISAKMP Policy Configuration
> • | ISAKMP Crypto Map Configuration
> • | Dynamic Crypto Map Configuration
> • | Manual Crypto Map Configuration
> • | Crypto Map and Interface Association
> • | FA Services Configuration to Support IPSec
> • | HA Service Configuration to Support IPSec
> • | RADIUS Attributes for IPSec-based Mobile IP Applications
> • | LAC Service Configuration to Support IPSec
> • | Redundant IPSec Tunnel Fail-Over
> • | Dead Peer Detection (DPD) Configuration
> • | TAPN Template Configuration to Support L2TP
> ASN GW |
> • | Implementing IPSec for PDN Access Applications
> • | Implementing IPSec for Mobile IP Applications
> • | Implementing IPSec for L2TP Applications
> • | Transform Set Configuration
> • | ISAKMP Policy Configuration
> • | ISAKMP Crypto Map Configuration
> • | Dynamic Crypto Map Configuration
> • | Manual Crypto Map Configuration
> • | Crypto Map and Interface Association
> • | FA Services Configuration to Support IPSec
> • | HA Service Configuration to Support IPSec
> • | RADIUS Attributes for IPSec-based Mobile IP Applications
> • | LAC Service Configuration to Support IPSec
> • | Subscriber Attributes for L2TP Application IPSec Support
> • | Redundant IPSec Tunnel Fail-Over
> • | Dead Peer Detection (DPD) Configuration

> ‌
> IPSec Terminology
> There are four items related to IPSec support on the system that must be understood prior to beginning configuration. They are:

> • | Crypto Access Control List (ACL)

> • | Transform Set

> • | ISAKMP Policy

> • | Crypto Map

> Crypto Access Control List (ACL)
> As described in the IP Access Control Lists chapter of this guide, ACLs on the system define rules, usually permissions, for handling subscriber data packets that meet certain criteria. Crypto ACLs, however, define the criteria that must be met in order for a subscriber data packet to be routed over an IPSec tunnel.
> Unlike other ACLs that are applied to interfaces, contexts, or one or more subscribers, crypto ACLs are matched with crypto maps. In addition, crypto ACLs contain only a single rule while other ACL types can consist of multiple rules.
> 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 will initiate the IPSec policy dictated by the crypto map.
> Transform Set
> Transform Sets are used to define IPSec security associations (SAs). IPSec SAs specify the IPSec protocols to use to protect packets.
> Transform sets are used during Phase 2 of IPSec establishment. In this phase, the system and a peer security gateway negotiate one or more transform sets (IPSec SAs) containing the rules for protecting packets. This negotiation ensures that both peers can properly protect and process the packets.
> ISAKMP Policy
> Internet Security Association Key Management Protocol (ISAKMP) policies are used to define Internet Key Exchange (IKE) SAs. The IKE SAs dictate the shared security parameters (i.e. which encryption parameters to use, how to authenticate the remote peer, etc.) between the system and a peer security gateway.
> During Phase 1 of IPSec establishment, the system and a peer security gateway negotiate IKE SAs. These SAs are used to protect subsequent communications between the peers including the IPSec SA negotiation process.
> Crypto Map
> Crypto Maps define the tunnel policies that determine how IPSec is implemented for subscriber data packets.
> There are three types of crypto maps supported by the system. They are:

> • | Manual crypto maps

> • | ISAKMP crypto maps

> • | Dynamic crypto maps

> Manual Crypto Maps
> These are static tunnels that use pre-configured information (including security keys) for establishment. Because they rely on statically configured information, once created, the tunnels never expire; they exist until their configuration is deleted.
> Manual crypto maps define the peer security gateway to establish a tunnel with, the security keys to use to establish the tunnel, and the IPSec SA to be used to protect data sent/received over the tunnel. Additionally, manual crypto maps are applied to specific system interfaces.
> Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
> ISAKMP Crypto Maps
> These tunnels are similar to manual crypto maps in that they require some statically configured information such as the IP address of a peer security gateway and that they are applied to specific system interfaces.
> However, ISAKMP crypto maps offer greater security because they rely on dynamically generated security associations through the use of the Internet Key Exchange (IKE) protocol.
> When ISAKMP crypto maps are used, the system uses the pre-shared key configured for map as part of the Diffie-Hellman (D-H) exchange with the peer security gateway to initiate Phase 1 of the establishment process. Once the exchange is complete, the system and the security gateway dynamically negotiate IKE SAs to complete Phase 1. In Phase 2, the two peers dynamically negotiate the IPSec SAs used to determine how data traversing the tunnel will be protected.
> Dynamic Crypto Maps
> These tunnels are used for protecting L2TP-encapsulated data between the system and an LNS/security gateway or Mobile IP data between an FA service configured on one system and an HA service configured on another.
> The system determines when to implement IPSec for L2TP-encapsulated data either through attributes returned upon successful authentication for attribute based tunneling, or through the configuration of the LAC service used for compulsory tunneling.
> The system determines when to implement IPSec for Mobile IP based on RADIUS attribute values as well as the configurations of the FA and HA service(s).
> Implementing IPSec for PDN Access Applications
> This section provides information on the following topics:

> • | How the IPSec-based PDN Access Configuration Works

> • | Configuring IPSec Support for PDN Access

> In covering these topics, this section assumes that ISAKMP crypto maps are configured/used as opposed to manual crypto maps.
> How the IPSec-based PDN Access Configuration Works
> The following figure and the text that follows describe how sessions accessing a PDN using IPSec are processed by the system.
> IPSec PDN Access Processing
> IPSec PDN Access Processing

> Step | Description
> 1. | A subscriber session or PDP context Request, in GGSN service, arrives at the system.
> 2. | The system processes the subscriber session or request as it would typically.
> 3. | Prior to routing the session packets, the system compares them against configured Access Control Lists (ACLs).
> 4. | The system determines that the packet matches the criteria of an ACL that is associated with a configured crypto map.
> 5. | From the crypto map, the system determines the following:
> • | The map type, in this case ISAKMP
> • | The pre-shared key used to initiate the Internet Key Exchange (IKE) and the IKE negotiation mode
> • | The IP address of the security gateway
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of a configured transform set defining the IPSec SA
> 6. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the pre-shared key specified in the crypto map with the specified peer security gateway.
> 7. | The system and the security gateway negotiate an ISAKMP policy (IKE SA) to use to protect further communications.
> 8. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the security gateway using the transform method specified in the transform sets.
> 9. | Once the IPSec SA has been negotiated, the system protects the data according to the IPSec SAs established during step 8 and sends it over the IPSec tunnel.

> ‌
> Configuring IPSec Support for PDN Access
> This section provides a list of the steps required to configure IPSec functionality on the system in support of PDN access. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA. In addition, parameters configured using this procedure must be configured in the same destination context on the system.

> Step 1 | Configure one or more IP access control lists (ACLs) according to the information and instructions located in IP Access Control Lists chapter of this guide.

> Step 2 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 3 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 4 | Configure an ipsec-isakmp crypto map according to the instructions located in the ISAKMP Crypto Map Configuration section of this chapter.

> Step 5 | Apply the crypto map to an interface on the system according to the instructions located in the Crypto Map and Interface Association section of this chapter.

> Step 6 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Implementing IPSec for Mobile IP Applications
> This section provides information on the following topics:

> • | How the IPSec-based Mobile IP Configuration Works

> • | Configuring IPSec Support for Mobile IP

> How the IPSec-based Mobile IP Configuration Works
> The following figure and the text that follows describe how Mobile IP sessions using IPSec are processed by the system.
> IPSec-based Mobile IP Session Processing
> IPSec-based Mobile IP Session Processing

> Step | Description
> 1. | FA service receives a Mobile IP registration request from the mobile node.
> 2. | FA sends an Access-Request to the FAAA server with the 3GPP2-IKE-Secret-Request attribute equal to yes.
> 3. | The FAAA proxies the request to the HAAA.
> 4. | The HAAA returns an Access-Accept message including the following attributes:
> • | 3GPP2-Security-Level set to 3 for IPSec tunnels and registration messages
> • | 3GPP2-MIP-HA-Address indicating the IP address of the HA that the FA is to communicate with.
> • | 3GPP2-KeyId providing an identification number for the IKE secret (alternatively, the keys may be statically configured for the FA and/or HA)
> • | 3GPP2-IKE-Secret indicating the pre-shared secret to use to negotiate the IKE SA
> 5. | The FAAA passes the accept message to the FA with all of the attributes.
> 6. | The FA determines if an IPSec SA already exists based on the HA address supplied. If so, that SA will be used. If not, a new IPSec SA will be negotiated.
> 7. | The FA determines the appropriate crypto map to use for IPSec protection based on the HA address attribute. It does this by comparing the address received to those configured using the isakmp peer-ha command. From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 8. | To initiate the IKE SA negotiation, the FA performs a Diffie-Hellman (D-H) exchange of the ISAKMP secret specified in the IKE secret attribute with the peer HA dictated by the HA address attribute. Included in the exchange is the Key ID received from the HAAA.
> 9. | Upon receiving the exchange, the HA sends an access request to the HAAA with the following attributes:
> • | 3GPP2-S-Request (note that this attribute is not used if the IPSec keys are statically configured)
> • | 3GPP2-User-name (the username specified is the IP addresses of the FA and HA).
> The password used in the access request is the RADIUS shared secret.
> 10. | The HAAA returns an Access-Accept message to the HA with the following attributes:
> • | 3GPP2-S indicating the “S” secret used to generate the HA’s response to the D-H exchange
> • | 3GPP2-S-Lifetime indicating the length of time that the “S” secret is valid
> • | 3GPP2-Security-Level set to 3 for IPSec tunnels and registration messages (optional)
> 11. | The HA determines the appropriate crypto map to use for IPSec protection based on the FA’s address. It does this by comparing the address received to those configured using the isakmp peer-fa command. From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 12. | The HA creates a response to the D-H exchange using the “S” secret and the Key ID sent by the FA.
> 13. | The HA sends IKE SA negotiation D-H exchange response to the FA.
> 14. | The FA and the HA negotiate an ISAKMP (IKE) policy to use to protect further communications.
> 15. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the security gateway using the transform method specified in the transform sets.
> 16. | Once the IPSec SA has been negotiated, the system protects the data according to the IPSec SAs established during step 15 and sends it over the IPSec tunnel.

> ‌
> Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
> Configuring IPSec Support for Mobile IP
> This section provides a list of the steps required to configure IPSec functionality on the system in support of Mobile IP. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the systems were previously configured to support subscriber data sessions either as an FA or an HA.

> Step 1 | Configure one or more transform sets for the FA system according to the instructions located in the Transform Set Configuration section of this chapter.

> The transform set(s) must be configured in the same context as the FA service.

> Step 2 | Configure one or more ISAKMP policies or the FA system according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> The ISAKMP policy(ies) must be configured in the same context as the FA service.

> Step 3 | Configure an ipsec-isakmp crypto map or the FA system according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> The crypto map(s) must be configured in the same context as the FA service.

> Step 4 | Optional. Configure DPD for the FA to help prevent IPSec tunnel state mismatches between the FA and HA according to the instructions located in the Dead Peer Detection (DPD) Configuration section of this chapter.

> Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.

> Step 5 | Configure the FA Service or the FA system according to the instructions located in the FA Services Configuration to Support IPSec section of this chapter.

> Step 6 | Configure one or more transform sets for the HA system according to the instructions located in the Transform Set Configuration section of this chapter.

> The transform set(s) must be configured in the same context as the HA service.

> Step 7 | Configure one or more ISAKMP policies or the HA system according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> The ISAKMP policy(ies) must be configured in the same context as the HA service.

> Step 8 | Configure an ipsec-isakmp crypto map or the HA system according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> The crypto map(s) must be configured in the same context as the HA service.

> Step 9 | Optional. Configure DPD for the HA to help prevent IPSec tunnel state mismatches between the FA and HA according to the instructions located in the Dead Peer Detection (DPD) Configuration section of this chapter.

> Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.

> Step 10 | Configure the HA Service or the HA system according to the instructions located in the section of this chapter.

> Step 11 | Configure the required attributes for RADIUS-based subscribers according to the information located in the RADIUS Attributes for IPSec-based Mobile IP Applications section of this chapter.

> Step 12 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Implementing IPSec for L2TP Applications
> This section provides information on the following topics:

> • | How IPSec is Used for Attribute-based L2TP Configurations

> • | Configuring Support for L2TP Attribute-based Tunneling with IPSec

> • | How IPSec is Used for PDSN Compulsory L2TP Configurations

> • | Configuring Support for L2TP PDSN Compulsory Tunneling with IPSec

> • | How IPSec is Used for L2TP Configurations on the GGSN

> • | Configuring GGSN Support for L2TP Tunneling with IPSec

> How IPSec is Used for Attribute-based L2TP Configurations
> The following figure and the text that follows describe how IPSec-encrypted attribute-based L2TP sessions are processed by the system.
> Attribute-based L2TP, IPSec-Encrypted Session Processing
> Attribute-based L2TP, IPSec-Encrypted Session Processing

> Step | Description
> 1. | A subscriber session arrives at the system.
> 2. | The system attempts to authenticate the subscriber with the AAA server.
> 3. | The profile attributes returned upon successful authentication by the AAA server indicate that session data is to be tunneled using L2TP. In addition, attributes specifying a crypto map name and ISAKMP secret are also supplied indicating that IP security is also required.
> 4. | The system determines that the crypto map name supplied matches a configured crypto map.
> 5. | From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 6. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the ISAKMP secret specified in the profile attribute with the specified peer LNS/security gateway.
> 7. | The system and the LNS/security gateway negotiate an ISAKMP (IKE) policy to use to protect further communications.
> 8. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway using the transform method specified in the transform sets.
> 9. | Once the IPSec SA has been negotiated, the system protects the L2TP encapsulated data according to the IPSec SAs established during step 9 and sends it over the IPSec tunnel.

> ‌
> Configuring Support for L2TP Attribute-based Tunneling with IPSec
> This section provides a list of the steps required to configure IPSec functionality on the system in support of attribute-based L2TP tunneling. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support subscriber data sessions and L2TP tunneling either as a PDSN or an HA. In addition, with the exception of subscriber attributes, all other parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.

> Step 1 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 2 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure an ipsec-isakmp crypto map according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> Step 4 | Configure the subscriber profile attributes according to the instructions located in the Subscriber Attributes for L2TP Application IPSec Support section of this chapter.

> Step 5 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> How IPSec is Used for PDSN Compulsory L2TP Configurations
> The following figure and the text that follows describe how IPSec-encrypted PDSN compulsory L2TP sessions are processed by the system.
> PDSN Compulsory L2TP, IPSec-Encrypted Session Processing
> PDSN Compulsory L2TP, IPSec-Encrypted Session Processing

> Step | Description
> 1. | A subscriber session arrives at a PDSN service on the system that is configured to perform compulsory tunneling. The system uses the LAC service specified in the PDSN service’s configuration.
> 2. | The LAC service dictates the peer LNS to use and also specifies the following parameters indicating that IP security is also required:
> • | Crypto map name
> • | ISAKMP secret
> 3. | The system determines that the crypto map name supplied matches a configured crypto map.
> 4. | From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 5. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the ISAKMP secret specified by the attribute with the specified peer LNS/security gateway.
> 6. | The system and the LNS/security gateway negotiate an ISAKMP policy (IKE SA) to use to protect further communications.
> 7. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway.
> 8. | Once the IPSec SA has been negotiated, the system protects the L2TP encapsulated data according to the rules specified in the transform set and sends it over the IPSec tunnel.

> ‌
> Configuring Support for L2TP PDSN Compulsory Tunneling with IPSec
> This section provides a list of the steps required to configure IPSec functionality on the system in support of PDSN compulsory L2TP tunneling. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support PDSN compulsory tunneling subscriber data sessions. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.

> Step 1 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 2 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure an ipsec-isakmp crypto map according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> Step 4 | Configure the subscriber profile attributes according to the instructions located in the Subscriber Attributes for L2TP Application IPSec Support section of this chapter.

> Step 5 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> How IPSec is Used for L2TP Configurations on the GGSN
> The following figure and the text that follows describe how IPSec-encrypted attribute-based L2TP sessions are processed by the system.
> GGSN PDP Context Processing with IPSec-Encrypted L2TP
> GGSN PDP Context Processing with IPSec-Encrypted L2TP

> Step | Description
> 1. | A subscriber session/PDP Context Request arrives at the system.
> 2. | The configuration of the APN accessed by the subscriber indicates that session data is to be tunneled using L2TP. In addition, attributes specifying a crypto map name and ISAKMP secret are also supplied indicating that IP security is also required.
> 3. | The system determines that the crypto map name supplied matches a configured crypto map.
> 4. | From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 5. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the ISAKMP secret specified in the profile attribute with the specified peer LNS/security gateway.
> 6. | The system and the LNS/security gateway negotiate an ISAKMP (IKE) policy to use to protect further communications.
> 7. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway using the transform method specified in the transform sets.
> 8. | Once the IPSec SA has been negotiated, the system protects the L2TP encapsulated data according to the IPSec SAs established during step 9 and sends it over the IPSec tunnel.

> ‌
> Configuring GGSN Support for L2TP Tunneling with IPSec
> This section provides a list of the steps required to configure the GGSN to encrypt L2TP tunnels using IPSEC. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support subscriber PDP contexts and L2TP tunneling either as a GGSN. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.

> Step 1 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 2 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure an ipsec-isakmp crypto map according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> Step 4 | Configure APN support for encrypting L2TP tunnels using IPSec according to the instructions located in the APN Template Configuration to Support L2TP section of this chapter.

> Step 5 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Transform Set Configuration
> This section provides instructions for configuring transform sets on the system.
> Important: This section provides the minimum instruction set for configuring transform set on your system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Transform Configuration Mode chapters in the Command Line Interface Reference.
> To configure the crypto transform set for IPSec:

> Step 1 | Configure crypto transform set by applying the example configuration in the Configuring Transform Set section.

> Step 2 | Verify your Crypto Transform Set configuration by following the steps in the Verifying the Crypto Transform Set Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Transform Set
> Use the following example to create the crypto transform set on your system:
> configure
> context <ctxt_name>
> crypto ipsec transform-set <transform_name> ah hmac { md5-96 | none |sha1-96 } esp hmac { { md5-96 | none | sha1-96 } { cipher {des-cbc | 3des-cbc | aes-cbc } | none }
> mode { transport | tunnel }
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the crypto transform set(s).

> • | <transform_name> is the name of the crypto transform set in the current context that you want to configure for IPSec configuration.

> • | For more information on parameters, refer to the IPSec Transform Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the Crypto Transform Set Configuration
> These instructions are used to verify the crypto transform set(s) was/were configured.

> Step 1 | Verify that your header crypto transform set configurations by entering the following command in Exec Mode in specific context:

> show crypto transform-set transform_name
> This command produces an output similar to that displayed below using the configuration of a transform set named test1.
> Transform-Set test1 :
> AH : none
> ESP :hmac md5-96, 3des-cbc
> Encaps Mode: TUNNEL
> ISAKMP Policy Configuration
> This section provides instructions for configuring ISAKMP policies on the system. ISAKMP policy configuration is only required if the crypto map type is either ISAKMP or Dynamic.
> Important: This section provides the minimum instruction set for configuring ISAKMP policies on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and ISAKMP Configuration Mode Commands chapters in the Command Line Interface Reference.
> To configure the ISAKMP policy for IPSec:

> Step 1 | Configure crypto transform set by applying the example configuration in the Configuring ISAKMP Policy section.

> Step 2 | Verify your ISAKMP policy configuration by following the steps in the Verifying the ISAKMP Policy Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring ISAKMP Policy
> Use the following example to create the ISAKMP policy on your system:
> configure
> context <ctxt_name>
> ikev1 policy <priority>
> encryption { 3des-cbc | des-cbc }
> hash { md5 | sha1 }
> group { 1 | 2 | 3 | 4 | 5 }
> lifetime <time>
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the ISAKMP policy.

> • | <priority> dictates the order in which the ISAKMP policies are proposed when negotiating IKE SAs.

> • | For more information on parameters, refer to the I SAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the ISAKMP Policy Configuration
> These instructions are used to verify the ISAKMP policy configuration.

> Step 1 | Verify that your ISAKMP policy configuration by entering the following command in Exec Mode in specific context:

> show crypto isakmp policy priority
> This command produces an output similar to that displayed below that displays the configuration of an ISAKMP policy with priority 1.
> 1 ISAKMP Policies are configured
> Priority : 1
> Authentication Method : preshared-key
> Lifetime : 120 seconds
> IKE group : 5
> hash : md5
> encryption : 3des-cbc
> Caution: Modification(s) to an existing ISAKMP policy configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> ISAKMP Crypto Map Configuration
> This section provides instructions for configuring ISAKMP crypto maps.
> Important: This section provides the minimum instruction set for configuring ISAKMP crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map ISAKMP Configuration Mode chapters in the Command Line Interface Reference.
> To configure the ISAKMP crypto maps for IPSec:

> Step 1 | Configure ISAKMP crypto map by applying the example configuration in the Configuring ISAKMP Crypto Maps section.

> Step 2 | Verify your ISAKMP crypto map configuration by following the steps in the Verifying the ISAKMP Crypto Map Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring ISAKMP Crypto Maps
> Use the following example to create the ISAKMP crypto map on your system:
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-isakmp
> set peer <agw_address>
> set isakmp preshared-key <isakmp_key>
> set mode { aggressive | main }
> set pfs { group1 | group2 | group5 }
> set transform-set <transform_name>
> match address <acl_name> [ preference ]
> match crypto-group <group_name> { primary | secondary }
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.

> • | <map_name> is name by which the ISAKMP crypto map will be recognized by the system.

> • | <acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.

> • | <group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter. For more information, refer to the Redundant IPSec Tunnel Fail-Over section of this chapter.

> • | For more information on parameters, refer to the Crypto Map ISAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the ISAKMP Crypto Map Configuration
> These instructions are used to verify the ISAKMP crypto map configuration.

> Step 1 | Verify that your ISAKMP crypto map configurations by entering the following command in Exec Mode in specific context:

> show crypto map [ tag map_name | type ipsec-isakmp ]
> This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map2.
> Map Name : test_map2
> ========================================
> Payload :
> crypto_acl2: permit tcp host 10.10.2.12 neq 35 any
> Crypto map Type : ISAKMP
> IKE Mode : MAIN
> IKE pre-shared key : 3fd32rf09svc
> Perfect Forward Secrecy : Group2
> Hard Lifetime :
> 28800 seconds
> 4608000 kilobytes
> Number of Transforms: 1
> Transform : test1
> AH : none
> ESP: md5 3des-cbc
> Encaps mode: TUNNEL
> Local Gateway: Not Set
> Remote Gateway: 192.168.1.1
> Caution: Modification(s) to an existing ISAKMP crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> Dynamic Crypto Map Configuration
> This section provides instructions for configuring dynamic crypto maps. Dynamic crypto maps should only be configured in support of L2TP or Mobile IP applications.
> Important: This section provides the minimum instruction set for configuring dynamic crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Dynamic Configuration Mode chapters in the Command Line Interface Reference.
> To configure the dynamic crypto maps for IPSec:

> Step 1 | Configure dynamic crypto maps by applying the example configuration in the Configuring Dynamic Crypto Maps section.

> Step 2 | Verify your dynamic crypto map configuration by following the steps in the Verifying the Dynamic Crypto Map Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Dynamic Crypto Maps
> Use the following example to create the crypto transform set on your system:
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-dynamic
> set pfs { group1 | group2 | group5 }
> set transform-set <transform_name>
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the dynamic crypto maps.

> • | <map_name> is name by which the dynamic crypto map will be recognized by the system.

> • | For more information on parameters, refer to the Crypto Map Dynamic Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the Dynamic Crypto Map Configuration
> These instructions are used to verify the dynamic crypto map configuration.

> Step 1 | Verify that your dynamic crypto map configurations by entering the following command in Exec Mode in specific context:

> show crypto map [ tag map_name | type ipsec-dynamic ]
> This command produces an output similar to that displayed below using the configuration of a dynamic crypto map named test_map3.
> Map Name : test_map3
> ========================================
> Crypto map Type : ISAKMP (Dynamic)
> IKE Mode : MAIN
> IKE pre-shared key :
> Perfect Forward Secrecy : Group2
> Hard Lifetime :
> 28800 seconds
> 4608000 kilobytes
> Number of Transforms: 1
> Transform : test1
> AH : none
> ESP: md5 3des-cbc
> Encaps mode: TUNNEL
> Local Gateway: Not Set
> Remote Gateway: Not Set
> Caution: Modification(s) to an existing dynamic crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> Manual Crypto Map Configuration
> This section provides instructions for configuring manual crypto maps on the system.
> Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
> Important: This section provides the minimum instruction set for configuring manual crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Manual Configuration Mode chapters in the Command Line Interface Reference.
> To configure the manual crypto maps for IPSec:

> Step 1 | Configure manual crypto map by applying the example configuration in the Configuring Manual Crypto Maps section.

> Step 2 | Verify your manual crypto map configuration by following the steps in the Verifying the Manual Crypto Map Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Manual Crypto Maps
> Use the following example to create the manual crypto map on your system:
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-manual
> set peer <agw_address>
> match address <acl_name> [ preference ]
> set transform-set <transform_name>
> set session-key { inbound | outbound } { ah <ah_spi> [ encrypted ] key <ah_key> | esp <esp_spi> [ encrypted ] cipher <encryption_key> [ encrypted ] authenticator <auth_key> }
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the manual crypto maps.

> • | <map_name> is name by which the manual crypto map will be recognized by the system.

> • | <acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.

> • | The length of the configured key must match the configured algorithm.

> • | <group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter.

> • | For more information on parameters, refer to the Crypto Map Manual Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the Manual Crypto Map Configuration
> These instructions are used to verify the manual crypto map configuration.

> Step 1 | Verify that your manual crypto map configurations by entering the following command in Exec Mode in specific context:

> show crypto map [ tag map_name | type ipsec-manual ]
> This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map.
> Map Name : test_map
> ========================================
> Payload :
> crypto_acl1: permit tcp host 1.2.3.4 gt 30 any
> Crypto map Type : manual(static)
> Transform : test1
> Encaps mode: TUNNEL
> Transmit Flow
> Protocol : ESP
> SPI : 0x102 (258)
> Hmac : md5, key: 23d32d23cs89
> Cipher : 3des-cbc, key: 1234asd3c3d
> Receive Flow
> Protocol : ESP
> SPI : 0x101 (257) Hmac : md5, key: 008j90u3rjp
> Cipher : 3des-cbc, key: sdfsdfasdf342d32
> Local Gateway: Not Set
> Remote Gateway: 192.168.1.40
> Caution: Modification(s) to an existing manual crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> Crypto Map and Interface Association
> This section provides instructions for applying manual or ISAKMP crypto maps to interfaces configured on the system. Dynamic crypto maps should not be applied to interfaces.
> Important: This section provides the minimum instruction set for applying manual or ISAKMP crypto maps to an interface on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To apply the crypto maps to an interface:

> Step 1 | Configure a manual or ISAKMP crypto map by applying the example configuration in any of the following sections:

> Step 2 | Apply desired crypto map to system interface by following the steps in the Applying Crypto Map to an Interface section

> Step 3 | Verify your manual crypto map configuration by following the steps in the Verifying the Interface Configuration with Crypto Map section.

> Step 4 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Applying Crypto Map to an Interface
> Use the following example to apply an existing crypto map to an interface on your system:
> configure
> context <ctxt_name>
> interface <interface_name>
> crypto-map <map_name>
> end
> Notes:

> • | <ctxt_name> is the system context in which the interface is configured to apply crypto map.

> • | <interface_name> is the name of a specific interface configured in the context to which the crypto map will be applied.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypto map.

> Verifying the Interface Configuration with Crypto Map
> These instructions are used to verify the interface configuration with crypto map.

> Step 1 | Verify that your interface is configured properly with crypto map by entering the following command in Exec Mode in specific context:

> show configuration context ctxt_name | grep interface
> The interface configuration aspect of the display should look similar to that shown below. In this example an interface named 20/6 was configured with a crypto map called isakmp_map1.
> interface 20/6
> ip address 192.168.4.10 255.255.255.0
> crypto-map isakmp_map1
> FA Services Configuration to Support IPSec
> This section provides instructions for configuring FA services to support IPSec.
> These instructions assume that the FA service was previously configured and system is ready to serve as an FA.
> Important: This section provides the minimum instruction set for configuring an FA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the FA service to support IPSec:

> Step 1 | Modify FA service configuration by following the steps in the Modifying FA service to Support IPSec section

> Step 2 | Verify your FA service configuration by following the steps in the Verifying the FA Service Configuration with IPSec section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying FA service to Support IPSec
> Use the following example to modify FA service to support IPSec on your system:
> configure
> context <ctxt_name>
> fa-service <fa_svc_name>
> isakmp peer-ha <ha_address> crypto-map <map_name> [ secret <preshared_secret> ]
> isakmp default crypto-map <map_name> [ secret <preshared_secret> ]
> end
> Notes:

> • | <ctxt_name> is the system context in which the FA service is configured to support IPSec.

> • | <fa_svc_name> is name of the FA service for which you are configuring IPSec.

> • | <ha_address> is IP address of the HA service to which FA service will communicate on IPSec.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypto map.

> • | A default crypto map for the FA service to be used in the event that the AAA server returns an HA address that is not configured as an ISAKMP peer HA.

> • | For maximum security, the default crypto map should be configured in addition to peer-ha crypto maps instead of being used to provide IPSec SAs to all HAs. Note that once an IPSec tunnel is established between the FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

> Verifying the FA Service Configuration with IPSec
> These instructions are used to verify the FA service to support IPSec.

> Step 1 | Verify that your FA service is configured properly with IPSec by entering the following command in Exec Mode in specific context:

> show fa-service { name service_name | all }
> The output of this command is a concise listing of FA service parameter settings configured on the system.
> HA Service Configuration to Support IPSec
> This section provides instructions for configuring HA services to support IPSec.
> These instructions assume that the HA service was previously configured and system is ready to serve as an HA.
> Important: This section provides the minimum instruction set for configuring an HA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the HA service to support IPSec:

> Step 1 | Modify HA service configuration by following the steps in the Modifying HA service to Support IPSec section

> Step 2 | Verify your HA service configuration by following the steps in the Verifying the HA Service Configuration with IPSec section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying HA service to Support IPSec
> Use the following example to modify an existing HA service to support IPSec on your system:
> configure
> context <ctxt_name>
> ha-service <ha_svc_name>
> isakmp aaa-context <aaa_ctxt_name>
> isakmp peer-fa <fa_address> crypto-map <map_name> [ secret <preshared_secret> ]
> end
> Notes:

> • | <ctxt_name> is the system context in which the FA service is configured to support IPSec.

> • | <ha_svc_name> is name of the HA service for which you are configuring IPSec.

> • | <fa_address> is IP address of the FA service to which HA service will communicate on IPSec.

> • | <aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypot map.

> Verifying the HA Service Configuration with IPSec
> These instructions are used to verify the HA service to support IPSec.

> Step 1 | Verify that your HA service is configured properly with IPSec by entering the following command in Exec Mode in specific context:

> show ha-service { name service_name | all }
> The output of this command is a concise listing of HA service parameter settings configured on the system.
> RADIUS Attributes for IPSec-based Mobile IP Applications
> As described in the How the IPSec-based Mobile IP Configuration Works section of this chapter, the system uses attributes stored in a subscriber’s RADIUS profile to determine how IPSec should be implemented.
> The table below lists the attributes that must be configured in the subscriber’s RADIUS attributes to support IPSec for Mobile IP. These attributes are contained in the following dictionaries:

> • | 3GPP2

> • | 3GPP2-835

> • | Starent

> • | Starent-835

> • | Starent-VSA1

> • | Starent-VSA1-835

> Attributes Used for Mobile IP IPSec Support

> Attribute | Description | Variable
> 3GPP2-Security-Level | This attribute indicates the type of security that the home network mandates on the visited network. | Integer value: 3 : Enables IPSec for tunnels and registration messages 4 : Disables IPSec
> 3GPP2 -KeyId | This attribute contains the opaque IKE Key Identifier for the FA/HA shared IKE secret. | Supported value for the first eight bytes is the network-order FA IP address in hexadecimal characters. Supported value for the next eight bytes is the network-order HA IP address in hexadecimal characters. Supported value for the final four bytes is a timestamp in network order, indicating when the key was created, and is the number of seconds since January 1, 1970, UTC.
> 3GPP2-IKE-Secret | This attribute contains the FA/HA shared secret for the IKE protocol. This attribute is salt-encrypted. | A binary string of 1 to 127 bytes.
> 3GPP2-S | This attribute contains the 'S' secret parameter used to make the IKE pre-shared secret. | A binary string of the value of 'S' consisting of 1 to 127 characters.
> 3GPP2- S-Lifetime | This attribute contains the lifetime of the 'S' secret parameter used to make the IKE pre-shared secret. | An integer in network order, indicating the time in seconds since January 1, 1970 00:00 UTC. Note that this is equivalent to the Unix operating system expression of time.

> ‌
> LAC Service Configuration to Support IPSec
> This section provides instructions for configuring LAC services to support IPSec.
> Important: These instructions are required for compulsory tunneling. They should only be performed for attribute-based tunneling if the Tunnel-Service-Endpoint, the SN1-Tunnel-ISAKMP-Crypto-Map, or the SN1 -Tunnel-ISAKMP-Secret are not configured in the subscriber profile.
> These instructions assume that the LAC service was previously configured and system is ready to serve as an LAC server.
> Important: This section provides the minimum instruction set for configuring an LAC service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the LAC service to support IPSec:

> Step 1 | Modify LAC service configuration by following the steps in the Modifying LAC service to Support IPSec section.

> Step 2 | Verify your LAC service configuration by following the steps in the Verifying the LAC Service Configuration with IPSec section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying LAC service to Support IPSec
> Use the following example to modify an existing LAC service to support IPSec on your system:
> configure
> context <ctxt_name>
> lac-service <lac_svc_name>
> peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> { [encrypted] isakmp-secret <secret> } ] [ description <text> ] [ preference <integer>]
> isakmp aaa-context <aaa_ctxt_name>
> isakmp peer-fa <fa_address> crypto-map <map_name> [ secret <preshared_secret> ]
> end
> Notes:

> • | <ctxt_name> is the destination context where the LAC service is configured to support IPSec.

> • | <lac_svc_name> is name of the LAC service for which you are configuring IPSec.

> • | <lns_address> is IP address of the LNS node to which LAC service will communicate on IPSec.

> • | <aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypot map.

> Verifying the LAC Service Configuration with IPSec
> These instructions are used to verify the LAC service to support IPSec.

> Step 1 | Verify that your LAC service is configured properly with IPSec by entering the following command in Exec Mode in specific context:

> show lac-service name service_name
> The output of this command is a concise listing of LAC service parameter settings configured on the system.
> Subscriber Attributes for L2TP Application IPSec Support
> In addition to the subscriber profile attributes listed in the RADIUS and Subscriber Profile Attributes Used section of the L2TP Access Concentrator chapter in this guide, the table below lists the attributes required to support IPSec for use with attribute-based L2TP tunneling.
> These attributes are contained in the following dictionaries:

> • | Starent

> • | Starent-835

> Subscriber Attributes for IPSec encrypted L2TP Support

> RADIUS Attribute | Local SubscriberAttribute | Description | Variable
> SN1-Tunnel-ISAKMP- Crypto-Map | tunnel l2tp crypto-map | The name of a crypto map configured on the system. | A salt-encrypted ascii string specifying the crypto-map to use for this subscriber. It can be tagged, in which case it is treated as part of a tunnel group.
> SN1 -Tunnel-ISAKMP- Secret | tunnel l2tp crypto-map isakmp-secret | The pre-shared secret that will be used as part of the D-H exchange to negotiate an IKE SA. | A salt-encrypted string specifying the IKE secret. It can be tagged, in which case it is treated as part of a tunnel group.

> ‌
> PDSN Service Configuration for L2TP Support
> PDSN service configuration is required for compulsory tunneling and optional for attribute-based tunneling.
> For attribute-based tunneling, a configuration error could occur such that upon successful authentication, the system determines that the subscriber session requires L2TP but can not determine the name of the context in which the appropriate LAC service is configured from the attributes supplied. As a precautionary, a parameter has been added to the PDSN service configuration options that will dictate the name of the context to use. It is strongly recommended that this parameter be configured.
> This section contains instructions for modifying the PDSN service configuration for either compulsory or attribute-based tunneling.
> These instructions assume that the PDSN service was previously configured and system is ready to serve as a PDSN.
> This section provides the minimum instruction set for configuring an L2TP service on the PDSN system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the PDSN service to support L2TP:

> Step 1 | Modify PDSN service to configure compulsory tunneling or attribute-based tunneling by applying the example configuration in any of the following sections:

> • | Modifying PDSN service to Support Attribute-based L2TP Tunneling

> • | Modifying PDSN service to Support Compulsory L2TP Tunneling

> Step 2 | Verify your LAC service configuration by following the steps in the Verifying the PDSN Service Configuration for L2TP section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying PDSN service to Support Attribute-based L2TP Tunneling
> Use the following example to modify an existing PDSN service to support attribute-based L2TP tunneling on your system:
> configure
> context <ctxt_name>
> pdsn-service <pdsn_svc_name>
> ppp tunnel-context <lac_ctxt_name>
> end
> Notes:

> • | <ctxt_name> is the destination context where the PDSN service is configured.

> • | <pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.

> • | <lac_ctxt_name> is the name of the destination context where the LAC service is located.

> Modifying PDSN service to Support Compulsory L2TP Tunneling
> Use the following example to modify an existing PDSN service to support compulsory L2TP tunneling on your system:
> configure
> context <ctxt_name>
> pdsn-service <pdsn_svc_name>
> ppp tunnel-context <lac_ctxt_name>
> ppp tunnel-type l2tp
> end
> Notes:

> • | <ctxt_name> is the destination context where the PDSN service is configured.

> • | <pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.

> • | <lac_ctxt_name> is name of the destination context where the LAC service is located.

> Verifying the PDSN Service Configuration for L2TP
> These instructions are used to verify the PDSN service to support L2TP.

> Step 1 | Verify that your PDSN service is configured properly with L2TP by entering the following command in Exec Mode in specific context:

> show pdsn-service name service_name
> The output of this command is a concise listing of PDSN service parameter settings configured on the system.
> Redundant IPSec Tunnel Fail-Over
> The Redundant IPSec Tunnel Fail-Over functionality is included with the IPSec feature license and allows the configuration of a secondary ISAKMP crypto map-based IPSec tunnel over which traffic is routed in the event that the primary ISAKMP crypto map-based tunnel cannot be used.
> This feature introduces the concept of crypto (tunnel) groups when using IPSec tunnels for access to packet data networks (PDNs). A crypto group consists of two configured ISAKMP crypto maps. Each crypto map defines the IPSec policy for a tunnel. In the crypto group, one tunnel serves as the primary, the other as the secondary (redundant). Note that the method in which the system determines to encrypt user data in an IPSec tunnel remains unchanged.
> Group tunnels are perpetually maintained with IPSec Dead Peer Detection (DPD) packets exchanged with the peer security gateway.
> Important: The peer security gateway must support RFC 3706 in order for this functionality to function properly.
> When the system determines that incoming user data traffic must be routed over one of the tunnels in a group, the system automatically uses the primary tunnel until either the peer is unreachable (the IPSec DPD packets cease), or the IPSec tunnel fails to re-key. If the primary peer becomes unreachable, the system automatically begins to switch user traffic to the secondary tunnel. The system can be configured to either automatically switch user traffic back to the primary tunnel once the corresponding peer security gateway is reachable and the tunnel is configured, or require manual intervention to do so.
> This functionality also supports the generation of Simple network Management Protocol (SNMP) notifications indicating the following conditions:

> • | Primary Tunnel is down: A primary tunnel that was previously "up" is now "down" representing an error condition.

> • | Primary Tunnel is up: A primary tunnel that was previously "down" is now "up".

> • | Secondary tunnel is down: A secondary tunnel that was previously "up" is now "down" representing an error condition.

> • | Secondary Tunnel is up: A secondary tunnel that was previously "down" is now "up".

> • | Fail-over successful: The switchover of user traffic was successful. This is generated for both primary-to-secondary and secondary-to-primary switchovers.

> • | Unsuccessful fail-over: An error occurred when switching user traffic from either the primary to secondary tunnel or the secondary to primary tunnel.

> Supported Standards
> Support for the following standards and requests for comments (RFCs) has been added with the Redundant IPSec Tunnel Fail-over functionality:

> • | RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, February 2004

> Redundant IPSec Tunnel Fail-over Configuration
> This section provides information and instructions for configuring the Redundant IPSec Tunnel Fail-over feature. These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA.
> Important: Parameters configured using this procedure must be configured in the same context on the system.
> Important: The system supports a maximum of 32 crypto groups per context. However, configuring crypto groups to use the same loopback interface for secondary IPSec tunnels is not recommended and may compromise redundancy on the chassis.
> Important: This section provides the minimum instruction set for configuring crypto groups on the system. For more information on commands that configure additional parameters and options, refer Command Line Interface Reference.
> To configure the Crypto group to support IPSec:

> Step 1 | Configure a crypto group by following the steps in the Configuring Crypto Group section

> Step 2 | Configure one or more ISAKMP policies according to the instructions provided in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure IPSec DPD settings using the instructions provided in the Dead Peer Detection (DPD) Configuration section of this chapter.

> Step 4 | Configure an ISAKMP crypto map for the primary and secondary tunnel according to the instructions provided in the ISAKMP Crypto Map Configuration section of this chapter.

> Step 5 | Match the existing ISAKMP crypto map to Crypto group by following the steps in the Modify ISAKMP Crypto Map Configuration to Match Crypto Group section

> Step 6 | Verify your Crypto Group configuration by following the steps in the Verifying the Crypto Group Configuration section.

> Step 7 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Crypto Group
> Use the following example to configure a crypto group on your system for redundant IPSec tunnel fail-over support:
> configure
> context <ctxt_name>
> ikev1 keepalive dpd interval <dur> timeout <dur> num-retry <retries>
> crypto-group <group_name>
> match address <acl_name> [ <preference> ]
> switchover auto [ do-not-revert ]
> end
> Notes:

> • | <ctxt_name> is the destination context where the Crypto Group is to be configured.

> • | <group_name> is name of the Crypto group you want to configure for IPSec tunnel failover support.

> • | <acl_name> is name of the pre-configured crypto ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. For more information on crypto ACL, refer Crypto Access Control List (ACL) section of this chapter.

> Modify ISAKMP Crypto Map Configuration to Match Crypto Group
> Use the following example to match the crypto group with ISAKMP crypto map on your system:
> configure
> context <ctxt_name>
> crypto map <map_name1> ipsec-isakmp
> match crypto-group <group_name> primary
> end
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-isakmp
> match crypto-group <group_name> secondary
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.

> • | <group_name> is name of the Crypto group configured in the same context for IPSec Tunnel Failover feature.

> • | <map_name1> is name of the preconfigured ISAKMP crypto map to match with crypto group as primary.

> • | <map_name2> is name of the preconfigured ISAKMP crypto map to match with crypto group as secondary.

> Verifying the Crypto Group Configuration
> These instructions are used to verify the crypto group configuration.

> Step 1 | Verify that your system is configured properly with crypto group by entering the following command in Exec Mode in specific context:

> show crypto group [ summary | name group_name ]
> The output of this command is a concise listing of crypto group parameter settings configured on the system.
> Dead Peer Detection (DPD) Configuration
> This section provides instructions for configuring the Dead Peer Detection (DPD).
> Defined by RFC 3706, Dead Peer Detection (DPD) is used to simplify the messaging required to verify communication between peers and tunnel availability.
> DPD is configured at the context level and is used in support of the IPSec Tunnel Failover feature (refer to the Redundant IPSec Tunnel Fail-Over section) and/or to help prevent tunnel state mismatches between an FA and HA when IPSec is used for Mobile IP applications. When used with Mobile IP applications, DPD ensures the availability of tunnels between the FA and HA. (Note that the starIPSECDynTunUp and starIPSECDynTunDown SNMP traps are triggered to indicate tunnel state for the Mobile IP scenario.)
> Regardless of the application, DPD must be supported/configured on both security peers. If the system is configured with DPD but it is communicating with a peer that does not have DPD configured, IPSec tunnels still come up. However, the only indication that the remote peer does not support DPD exists in the output of the show crypto isakmp security-associations summary command.
> Important: If DPD is enabled while IPSec tunnels are up, it will not take affect until all of the tunnels are cleared.
> Important: DPD must be configured in the same context on the system as other IPSec Parameters.
> To configure the Crypto group to support IPSec:

> Step 1 | Enable dead peer detection on system in support of the IPSec Tunnel Failover feature by following the steps in the Configuring Crypto Group section

> Step 2 | Verify your Crypto Group configuration by following the steps in the Verifying the DPD Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Crypto Group
> Use the following example to configure a crypto group on your system for redundant IPSec tunnel fail-over support:
> configure
> context <ctxt_name>
> ikev1 keepalive dpd interval <dur> timeout <dur> num-retry <retries>
> end
> Notes:

> • | <ctxt_name> is the destination context where the Crypto Group is to be configured.

> Verifying the DPD Configuration
> These instructions are used to verify the dead peer detection configuration.

> Step 1 | Verify that your system is configured properly with crypto group with DPD by entering the following command in Exec Mode in specific context:

> sshow crypto group [ summary | name group_name ]
> The output of this command is a concise listing of crypto group parameter settings configured on the system.
> APN Template Configuration to Support L2TP
> This section provides instructions for adding L2TP support for APN templates configured on the system.
> These instructions assume that the APN template was previously configured on this system.
> Important: This section provides the minimum instruction set for configuring an APN template to support L2TP for APN. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference. To configure the APN to support L2TP:

> Step 1 | Modify preconfigured APN template by following the steps in the Modifying APN Template to Support L2TP section

> Step 2 | Verify your APN configuration by following the steps in the Verifying the APN Configuration for L2TP section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying APN Template to Support L2TP
> Use the following example to modify APN template to support L2TP:
> configure
> context <ctxt_name>
> apn <apn_name>
> tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <num> ] [ tunnel-context <tunnel_ctxt_name> ] [ local-address <agw_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
> end
> Notes:

> • | <ctxt_name> is the system context in which the APN template is configured.

> • | <apn_name> is name of the preconfigured APN template in which you want to configure L2TP support.

> • | <lns_address> is IP address of the LNS node to which this APN will communicate.

> • | <tunnel_ctxt_name> is the L2TP context in which the L2TP tunnel is configured.

> • | <agw_ip_address> is the local IP address of the GGSN in which this APN template is configured.

> • | <map_name> is the preconfigured crypto map (ISAKMP or manual) which is to use for L2TP.

> Verifying the APN Configuration for L2TP
> These instructions are used to verify the APN template configuration for L2TP.

> Step 1 | Verify that your APN is configured properly with L2TP by entering the following command in Exec Mode in specific context:

> show apn { all | name apn_name }
> The output of this command is a concise listing of FA service parameter settings configured on the system.
> IPSec for LTE/SAE Networks
> The Cisco MME (Mobility Management Entity), S-GW (Serving Gateway), and P-GW (Packet Data Network Gateway) support IPSec and IKEv2 encryption using IPv4 and IPv6 addressing in LTE/SAE (Long Term Evolution/System Architecture Evolution) networks. IPSec and IKEv2 encryption enables network domain security for all IP packet-switched networks, providing confidentiality, integrity, authentication, and anti-replay protection via secure IPSec tunnels.
> Encryption Algorithms
> IPSec for LTE/SAE supports the following control and data path encryption algorithms:

> • | AES-CBC-128 (Advanced Encryption Standard-Cipher Block Chaining-128)

> • | AES-CBC-256 (Advanced Encryption Standard-Cipher Block Chaining-256)

> • | DES-CBC (Data Encryption Standard-Cipher Block Chaining)

> • | 3DES-CBC (Triple Data Encryption Standard-Cipher Bock Chaining)

> HMAC Functions
> IPSec for LTE/SAE supports the following data path HMAC (Hash-based Message Authentication Code) functions:

> • | AES-XCBC-MAC-96 (Advanced Encryption Standard-X Cipher Block Chaining-Message Authentication Code-96)

> • | MD5-96 (Message Digest 5-96)

> • | SHA1-96 (Secure Hash Algorithm 1-96)

> IPSec for LTE/SAE supports the following control path HMAC (Hash-based Message Authentication Code) functions:

> • | AES-XCBC-MAC-96 (Advanced Encryption Standard-X Cipher Block Chaining-Message Authentication Code-96)

> • | MD5-96 (Message Digest 5-96)

> • | SHA1-96 (Secure Hash Algorithm 1-96)

> • | SHA2-256-128 (Secure Hash Algorithm 2-256-128)

> • | SHA2-384-192 (Secure Hash Algorithm 2-384-192)

> • | SHA2-512-256 (Secure Hash Algorithm 2-512-256)

> Diffie-Hellman Groups
> IPSec for LTE/SAE supports the following Diffie-Hellman groups for IKE and Child SAs (Security Associations):

> • | Diffie-Hellman Group 1: 768-bit MODP (Modular Exponential) Group

> • | Diffie-Hellman Group 2: 1024-bit MODP Group

> • | Diffie-Hellman Group 5: 1536-bit MODP Group

> • | Diffie-Hellman Group 14: 2048-bit MODP Group

> • | None: No Diffie-Hellman Group (no perfect forward secrecy)

> Dynamic Node-to-Node IPSec Tunnels
> 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.
> ACL-based Node-to-Node IPSec Tunnels
> 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 P-GW.
> 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.
> Traffic Selectors
> 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.
> 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

> Note that for ACL-based node-to-node IPSec tunnels, the configured crypto ACL becomes the traffic selector with no modification.
> 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.

> • | 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.
> 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.
> X.509 Certificate-based Peer Authentication
> X.509 Certificate-based Peer Authentication

> Step | Description
> 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
> 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.
> 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.
> Child SA rekeying is disabled by default, and rekey requests are ignored. This feature gets enabled in the Crypto Configuration Payload Mode of the system’s CLI.
> IKEv2 Keep-Alive Messages (Dead Peer Detection)
> IPSec for LTE/SAE supports IKEv2 keep-alive messages, also known as Dead Peer Detection (DPD), originating from both ends of an IPSec tunnel. Per RFC 3706, DPD is used to simplify the messaging required to verify communication between peers and tunnel availability. You configure DPD on each IPSec node. You can also disable DPD, and the node will not initiate DPD exchanges with other nodes. However, the node always responds to DPD availability checks initiated by another node regardless of its DPD configuration.
> E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
> The figure below shows the logical network interfaces over which secure IPSec tunnels can be created in an E-UTRAN/EPC (Evolved UMTS Terrestrial Radio Access Network/Evolved Packet Core) network. The table that follows the figure provides a description of each logical network interface.
> E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
> E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels

> Interface | Description
> S1-MME Interface | This interface is the reference point for the control plane protocol between the eNodeB and the MME. The S1-MME interface uses S1-AP (S1- Application Protocol) over SCTP (Stream Control Transmission Protocol) as the transport layer protocol for guaranteed delivery of signaling messages between the MME and the eNodeB (S1). When configured, the S1-AP over SCTP signaling traffic gets carried over an IPSec tunnel. When a subscriber UE initiates a connection with the eNodeB, the eNodeB initiates an IPSec tunnel with the MME, and SCTP signaling for all subsequent subscriber UEs served by this MME gets carried over the same IPSec tunnel. The MME can also initiate an IPSec tunnel with the eNodeB when the following conditions exist:
> • | The first tunnel setup is always triggered by the eNodeB. This is the tunnel over which initial SCTP exchanges occur.
> • | The MME initiates additional tunnels to the eNodeB after an SCTP connection is set up if the MME is multi-homed: a tunnel is initiated from MME's second address to the eNodeB.
> • | The eNodeB is multi-homed: tunnels are initiated from the MME's primary address to each secondary address of the eNodeB.
> • | Both of the prior two conditions: a tunnel is initiated from each of MME's addresses to each address of the eNodeB.
> S1-U Interface | This interface is the reference point for bearer channel tunneling between the eNodeB and the S-GW. Typically, the eNodeB initiates an IPSec tunnel with the S-GW over this interface for subscriber data traffic. But the S-GW may also initiate an IPSec tunnel with the eNodeB, if required.
> S5 Interface | This interface is the reference point for tunneling between the S-GW and the P-GW. Based on the requested APN from a subscriber UE, the MME selects both the S-GW and the P-GW that the S-GW connects to. GTP-U data traffic is carried over the IPSec tunnel between the S-GW and P-GW for the current and all subsequent subscriber UEs.

> ‌
> IPSec Tunnel Termination
> IPSec tunnel termination occurs during the following scenarios:

> • | Idle Tunnel Termination: When a session manager for a service detects that all subscriber sessions using a given IPSec tunnel have terminated, the IPSec tunnel also gets terminated after a timeout period.

> • | Service Termination: When a service running on a network node is brought down for any reason, all corresponding IPSec tunnels get terminated. This may be caused by the interface for a service going down, a service being stopped manually, or a task handling an IPSec tunnel restarting.

> • | Unreachable Peer: If a network node detects an unreachable peer via Dead Peer Detection (DPD), the IPSec tunnel between the nodes gets terminated. DPD can be enabled per P-GW, S-GW, and MME service via the system CLI during crypto template configuration.

> • | E-UTRAN Handover Handling: Any IPSec tunnel that becomes unusable due to an E-UTRAN network handover gets terminated, while the network node to which the session is handed initiates a new IPSec tunnel for the session.

> Appendix C
> Sample Configuration Files
> This appendix contains sample configuration files for the S-GW. The following configurations are supported:

> • | Standalone eGTP Serving Gateway

> In each configuration example, commented lines are labeled with the number symbol (#) and variables are identified using italics within arrow brackets (<variable>).
> Standalone eGTP Serving Gateway
> Configuration Sample
> # Configuration file for an ASR 5000 in an eGTP S-GW role
> #
> # Send S-GW licenses
> configure /flash/flashconfig/<sgw_license_name>.cfg
> end
> #
> # Set system to not require confirmation when creating new contexts and/or services. Config file must end with “no autoconfirm” to return the CLI to its default setting.
> #
> configure
> autoconfirm
> #
> # Configure ASR 5000 cards
> #
> # Activate the PSCs
> card <slot_number>
> mode active psc
> exit
> card <slot_number>
> mode active psc
> exit
> # Repeat for the number of PSCs in the system
> end
> #
> # Modify the local context for local system management
> configure
> context local
> interface <name>
> ip address <address> <mask>
> exit
> server ftpd
> exit
> ssh key <key> length <bytes>
> server sshd
> subsystem sftp
> exit
> server telnetd
> exit
> subscriber default
> exit
> administrator <name> encrypted password <password> ftp
> aaa group default
> exit
> administrator <name> encrypted password <password> ftp
> ip route <ip_addr/ip_mask> <next_hop_addr> <lcl_cntxt_intrfc_name>
> exit
> port ethernet <slot#/port#>
> no shutdown
> bind interface <lcl_cntxt_intrfc_name> local
> exit
> ntp
> enable
> server 10.2.10.2
> exit
> snmp engine-id local <id>
> snmp notif-threshold <count> low <low_count> period <seconds>
> snmp authentication-failure-trap
> snmp heartbeat interval <minutes>
> snmp community <string> read-write
> snmp target <name> <ip_address>
> system contact <string>
> system location <string>
> # Ingress context configuration
> context <sgw_context_name> -noconfirm
> subscriber default
> exit
> interface <s1u-s11_interface_name>
> ip address <ipv4_address_primary>
> ip address <ipv4_address_secondary>
> exit
> interface <s4_interface_name>
> ip address <ipv4_address_primary>
> ip address <ipv4_address_secondary>
> # note alternative IPv6 address for both interfaces:
> ipv6 address <address>
> exit
> gtpp group default
> exit
> gtpu-service <gtpu_s1us11_ingress_service_name>
> bind ipv4-address <s1-us11_interface_ip_address>
> # note alternative IPv6 address:
> bind ipv6-address <s1-us11_interface_ip_address>
> exit
> gtpu-service <gtpu_s4_ingress_service_name>
> bind ipv4-address <s4_interface_ip_address>
> # note alternative IPv6 address:
> bind ipv6-address <s4_interface_ip_address>
> exit
> egtp-service <egtp_s1u-s11_ingress_service_name>
> interface-type interface-sgw-ingress
> validation-mode default
> associate gtpu-service <gtpu_ingress_service_name>
> gtpc bind address <s1u-s11_interface_ip_address>
> exit
> egtp-service <egtp_s4_ingress_service_name>
> interface-type interface-sgw-ingress
> validation-mode default
> associate gtpu-service <gtpu_ingress_service_name>
> gtpc bind address <s4_interface_ip_address>
> exit
> sgw-servers <sgw_service_name> -noconfirm
> associate ingress egtp-service <egtp_ingress_service_name>
> associate egress-proto gtp egress-context <egress_context_name>
> qci-qos-mapping <map_name>
> exit
> ip route <pgw_ip_addr/mask> <sgw_next_hop_addr> <sgw_intrfc_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s1u-s11_interface_name> <sgw_context_name>
> exit
> # Egress context configuration
> context <egress_context_name> -noconfirm
> interface <s5s8_interface_name>
> ipv6 address <address>
> tunnel-mode ipv6ip
> source interface <name>
> destination address <ipv4_or_ipv6_address>
> exit
> exit
> # note alternative IPv4 address:
> ip address <ipv4_address>
> exit
> interface <s12_interface_name>
> ip address <ipv4_address_primary>
> ip address <ipv4_address_secondary>
> # note alternative IPv6 address:
> ipv6 address <address>
> exit
> gtpu-service <gtpu_s5s8_egress_service_name>
> bind ipv4-address <s5s8_interface_ip_address>
> # note alternative IPv6 address:
> bind ipv6-address <s5s8_interface_ip_address>
> exit
> gtpu-service <gtpu_s12_egress_service_name>
> bind ipv4-address <s12_interface_ip_address>
> # note alternative IPv6 address:
> bind ipv6-address <s12_interface_ip_address>
> exit
> egtp-service <egtp_s5s8_egress_service_name>
> interface-type interface-sgw-egress
> validation-mode default
> associate gtpu-service <gtpu_egress_service_name>
> gtpc bind address <s5s8_interface_ip_address>
> exit
> egtp-service <egtp_s12_egress_service_name>
> interface-type interface-sgw-egress
> validation-mode default
> associate gtpu-service <gtpu_egress_service_name>
> gtpc bind address <s12_interface_ip_address>
> exit
> ip route <pgw_ip_addr/mask> <sgw_next_hop_addr> <sgw_intrfc_name>
> exit
> port ethernet <slot_number/port_number>
> no shutdown
> bind interface <s5s8_interface_name> <sgw_context_name>
> end
> configure
> # Optional IPSec IKEv2 configuration for S1-U interface
> context <ingress_context_name>
> ipsec transform-set <name>
> exit
> ikev2-ikesa transform-set <name>
> lifetime <seconds>
> exit
> crypto template <name> ikev2-dynamic
> authentication remote pre-shared-key encrypted key <enc_key>
> ikev2-ikesa transform-set list <list_name>
> payload <payload_name> match childsa
> ipsec transform-set list <name>
> lifetime <seconds>
> rekey keepalive
> exit
> peer network <ip_address> mask <ip_mask> encrypted pre-shared-key <key>
> end
> # QCI-QoS mapping
> qci-qos-mapping <name>
> qci 1 user-datagram dscp-marking <hex>
> qci 3 user-datagram dscp-marking <hex>
> qci 9 user-datagram dscp-marking <hex>
> end
> Appendix D
> S-GW Engineering Rules
> This appendix provides Serving Gateway-specific engineering rules or guidelines that must be considered prior to configuring the ASR 5x00 for your network deployment. General and network-specific rules are located in the appendix of the System Administration Guide for the specific network type.
> The following rules are covered in this appendix:

> • | Interface and Port Rules

> • | S-GW Service Rules

> • | S-GW Subscriber Rules

> Interface and Port Rules
> The assumptions and rules discussed in this section pertain to Ethernet line cards and the type of interfaces they facilitate.
> Assumptions
> Overall assumptions for the S5/S8 and S11 interfaces used in the LTE EPC between Serving Gateway and PDN-GW are listed below.

> • | GTPv2-C is the signaling protocol used on the S5/S8 and S11 interfaces. Message and IE definitions comply with 3GPP 29.274.

> • | S5 and S11 interfaces use IPv6 transport as defined in 29.274, section 10.

> • | MSISDN is assumed to be sent by MME in initial attach.

> • | MEI will always be retrieved by MME from UE and sent on S11 during initial attach and UE Requested PDN connectivity procedure.

> • | MME will always send UE time zone information.

> • | The default bearer does not require any TFT.

> • | The PCO IE in Create Session Request shall contain two DNS server IP addresses. [S5/S8]

> • | UE's location change reporting support is required. [S5/S8]

> • | The S-GW does not verify the content of the IEs which are forwarded on the S5/S8 interface from the S11 interface. The P-GW verifies the content of all the IEs received on the S5/S8 interface.

> S1-U/S11 Interface Rules
> The following engineering rules apply to the S1-U0/S11 interface:

> • | An S1-U0/S11 interface is created once the IP address of a logical interface is bound to an S-GW service.

> • | The logical interface(s) that will be used to facilitate the S1-U0/S11 interface(s) must be configured within an “ingress” context.

> • | S-GW services must be configured within an “ingress” context.

> • | At least one S-GW service must be bound to each interface, however, multiple S-GW services can be bound to a single interface if secondary addresses are assigned to the interface.

> • | Depending on the services offered to the subscriber, the number of sessions facilitated by the S1-U0/S11 interface can be limited.

> S5/S8 Interface Rules
> This section describes the engineering rules for the S5 interface for communications between the Mobility Access Gateway (MAG) service residing on the S-GW and the Local Mobility Anchor (LMA) service residing on the P-GW.
> MAG to LMA Rules
> The following engineering rules apply to the S5/S8 interface from the MAG service to the LMA service residing on the P-GW:

> • | An S5/S8 interface is created once the IP address of a logical interface is bound to an MAG service.

> • | The logical interface(s) that will be used to facilitate the S5/S8 interface(s) must be configured within the egress context.

> • | MAG services must be configured within the egress context.

> • | MAG services must be associated with an S-GW service.

> • | Depending on the services offered to the subscriber, the number of sessions facilitated by the S5/S8 interface can be limited.

> S-GW Service Rules
> The following engineering rules apply to services configured within the system:

> • | A maximum of 256 services (regardless of type) can be configured per system.

> Caution: Large numbers of services greatly increase the complexity of management and may impact overall system performance. Only create a large number of services only be configured if your application absolutely requires it. Please contact your local service representative for more information.

> • | The system maintains statistics for a maximum of 4,096 peer LMAs per MAG service.

> • | The total number of entries per table and per chassis is limited to 256.

> • | Even though service names can be identical to those configured in different contexts on the same system, this is not a good practice. Having services with the same name can lead to confusion, difficulty troubleshooting problems, and make it difficulty understanding outputs of show commands.

> S-GW Subscriber Rules
> The following engineering rule applies to subscribers configured within the system:

> • | A maximum of 2,048 local subscribers can be configured per context.

> • | Default subscriber templates may be configured on a per S-GW or MAG service.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883