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.
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:
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.
Figure 2. IPSec PDN Access Processing
Table 1. 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.
-
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.
-
Configure one or
more transform sets according to the instructions located in the Transform Set Configuration section
of this chapter.
-
Configure one or
more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section
of this chapter.
-
Configure an ipsec-isakmp
crypto map according to the instructions located in the ISAKMP Crypto Map
Configuration section of this chapter.
-
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.
-
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
The following figure
and the text that follows describe how Mobile IP sessions using
IPSec are processed by the system.
Figure 3. IPSec-based Mobile
IP Session Processing
Table 2. 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Configure the HA
Service or the HA system according to the instructions located in
the section of this chapter.
-
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.
-
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
The following
figure and the text that follows describe how IPSec-encrypted attribute-based L2TP
sessions are processed by the system.
Figure 4. Attribute-based
L2TP, IPSec-Encrypted Session Processing
Table 3. 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.
-
Configure one or
more transform sets according to the instructions located in the Transform Set Configuration section
of this chapter.
-
Configure one or
more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section
of this chapter.
-
Configure an ipsec-isakmp
crypto map according to the instructions located in the Dynamic Crypto Map
Configuration section of this chapter.
-
Configure the subscriber
profile attributes according to the instructions located in the Subscriber Attributes
for L2TP Application IPSec Support section of this chapter.
-
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.
Figure 5. PDSN Compulsory
L2TP, IPSec-Encrypted Session Processing
Table 4. 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.
-
Configure one or
more transform sets according to the instructions located in the Transform Set Configuration section
of this chapter.
-
Configure one or
more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section
of this chapter.
-
Configure an ipsec-isakmp
crypto map according to the instructions located in the Dynamic Crypto Map
Configuration section of this chapter.
-
Configure the subscriber
profile attributes according to the instructions located in the Subscriber Attributes
for L2TP Application IPSec Support section of this chapter.
-
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.
Figure 6. GGSN PDP Context
Processing with IPSec-Encrypted L2TP
Table 5. 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.
-
Configure one or
more transform sets according to the instructions located in the Transform Set Configuration section
of this chapter.
-
Configure one or
more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section
of this chapter.
-
Configure an ipsec-isakmp
crypto map according to the instructions located in the Dynamic Crypto Map
Configuration section of this chapter.
-
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.
-
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:
-
Configure crypto
transform set by applying the example configuration in the Configuring Transform
Set section.
-
Verify your Crypto
Transform Set configuration by following the steps in the Verifying the Crypto
Transform Set Configuration section.
-
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.
-
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:
-
Configure crypto
transform set by applying the example configuration in the Configuring ISAKMP
Policy section.
-
Verify your ISAKMP
policy configuration by following the steps in the Verifying the ISAKMP
Policy Configuration section.
-
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 ISAKMP 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.
-
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:
-
Configure ISAKMP
crypto map by applying the example configuration in the Configuring ISAKMP
Crypto Maps section.
-
Verify your ISAKMP
crypto map configuration by following the steps in the Verifying the ISAKMP
Crypto Map Configuration section.
-
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.
-
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:
-
Configure dynamic
crypto maps by applying the example configuration in the Configuring Dynamic
Crypto Maps section.
-
Verify your dynamic
crypto map configuration by following the steps in the Verifying the Dynamic
Crypto Map Configuration section.
-
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.
-
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:
-
Configure manual
crypto map by applying the example configuration in the Configuring Manual
Crypto Maps section.
-
Verify your manual
crypto map configuration by following the steps in the Verifying the Manual
Crypto Map Configuration section.
-
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.
-
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:
-
Configure a manual
or ISAKMP crypto map by applying the example configuration in any
of the following sections:
-
Apply desired crypto
map to system interface by following the steps in the Applying Crypto Map
to an Interface section
-
Verify your manual
crypto map configuration by following the steps in the Verifying the Interface
Configuration with Crypto Map section.
-
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.
-
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:
-
Modify FA service
configuration by following the steps in the Modifying FA service
to Support IPSec section
-
Verify your FA service
configuration by following the steps in the Verifying the FA Service
Configuration with IPSec section.
-
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.
-
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:
-
Modify HA service
configuration by following the steps in the Modifying HA service
to Support IPSec section
-
Verify your HA service
configuration by following the steps in the Verifying the HA Service
Configuration with IPSec section.
-
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.
-
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.
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:
-
Modify LAC service
configuration by following the steps in the Modifying LAC service
to Support IPSec section.
-
Verify your LAC service
configuration by following the steps in the Verifying the LAC
Service Configuration with IPSec section.
-
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.
-
Verify that your
LAC service is configured properly with IPSec by entering the following
command in Exec Mode in specific context:
show lac-service nameservice_name
The
output of this command is a concise listing of LAC service parameter
settings configured on the system.
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:
-
Modify PDSN service
to configure compulsory tunneling or attribute-based tunneling by
applying the example configuration in any of the following sections:
-
Verify your LAC service
configuration by following the steps in the Verifying the PDSN
Service Configuration for L2TP section.
-
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.
-
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:
-
Configure a crypto
group by following the steps in the Configuring Crypto
Group section
-
Configure one or
more ISAKMP policies according to the instructions provided in the ISAKMP Policy Configuration section
of this chapter.
-
Configure IPSec DPD
settings using the instructions provided in the Dead Peer Detection
(DPD) Configuration section of this chapter.
-
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.
-
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
-
Verify your Crypto
Group configuration by following the steps in the Verifying the Crypto
Group Configuration section.
-
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.
-
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:
-
Enable dead peer
detection on system in support of the IPSec Tunnel Failover feature
by following the steps in the Configuring Crypto
Group section
-
Verify your Crypto
Group configuration by following the steps in the Verifying the DPD
Configuration section.
-
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.
-
Verify that your
system is configured properly with crypto group with DPD 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.
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:
-
Modify preconfigured
APN template by following the steps in the Modifying APN Template
to Support L2TP section
-
Verify your APN configuration
by following the steps in the Verifying the APN
Configuration for L2TP section.
-
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.
-
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.
Figure 7. X.509 Certificate-based
Peer Authentication
Table 8. 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.
Figure 8. E-UTRAN/EPC
Logical Network Interfaces Supporting IPSec Tunnels
Table 9. 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.