This chapter
discusses the features and functions of Packet Data Interworking
Function (PDIF) software. It includes the following topics:
Product Description
The goal of
the Fixed Mobile Convergence (FMC) application is to enhance the
in-building cellular coverage for FMC subscribers, to reduce the
cost of the infrastructure required to carry these calls, and to
provide secure access to the carrier’s network from a non-secure
network. Designed for use exclusively on the Cisco® ASR
5x00 Chassis, the Packet Data Interworking Function (PDIF) is a
network function based on the 3GPP2 X.S0028-200 standard defining
CDMA2000 Packet Data Services over an 802.11 WLAN.
A PDIF allows mobile
devices to access the Internet over an all-IP WLAN using IKEv2 as
the signaling interface. The IKEv2 control path exists between the
mobile station (MS) (a dual-mode handset (DMH)) and the PDIF establishing
an IPSec tunnel. PDIF also acts as a security gateway protecting
CDMA network resources and data. The PDIF is tightly integrated
with a collocated Foreign Agent (FA) service, and the PDIF is known
throughout this manual as PDIF/FA.
For handsets that do
not support mobile IP, PDIF supports proxy mobile IP. If the MS
is not suitable for proxy mobile IP registration, it may still be
allowed to establish a simple IP session, in which case the traffic
is directly routed to the Internet or corporate network from the
PDIF. This behavior is controlled through the proxy-mip-required configuration
in the domain, local default subscriber, or the corresponding Diameter
AVP or RADIUS Access Accept. If this is not present, establishing
a simple IP session is permitted. Although not required for Proxy-MIP,
this manual documents Proxy-MIP with a custom-designed feature called
multiple authentication (Multi-Auth). Instead of the more usual
subscriber authentication, Multi-Auth requires both the device and
the subscriber be authenticated using EAP/AKA authentication
for the first stage (the device authentication) and GTC/MD5
for the second stage (the subscriber authentication). For this installation,
neither GTC nor MD5 is supported, which means authentication is
done using PAP/CHAP instead.
When the subscriber
is mobile, the MS operates as a normal mobile phone, sending voice and
data over the CDMA network. When the FMC subscriber returns home,
or encounters a WiFi hotspot, the MS detects the presence of the
WiFi network, and automatically establishes an IPSec session with
the PDIF/FA. When the secure connection has been established
and mobile IP registration procedures successfully finished, the
PDIF/FA works with other network elements to provide the
MS with access to packet data services.
From here, all voice
and data communication is carried over the IPSec tunnel and the
PDIF/FA functions as a pass-through for the authentication
and accounting information on a RADIUS and/or Diameter
server. The MS continues operating over the IPSec tunnel until such
time as it can no longer access the WiFi Access Point (AP). At this
point, the MS switches back to the CDMA network for normal mobile
operation.
Platform Requirements
The PDIF service
runs on a Cisco® ASR 5x00 chassis running StarOS. The chassis
can be configured with a variety of components to meet specific
network deployment requirements. For additional information, refer
to the installation guide for the chassis and/or contact
your Cisco account representative.
Licenses
The PDIF is a
licensed Cisco product. Separate session and feature licenses 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.
Features and Functionality
- Base Software
This section
describes the features and functions supported by default in the
base PDIF software and the benefits they provide.
IMPORTANT:
All known restrictions
are shown in Appendix B.
The following is a
list of the features in this section:
PSC2 Support
The PDIF supports
the Packet Services Card 2 (PSC2). The PSC2 is the next-generation packet
forwarding card for the ASR 5000. The PSC2 provides increased aggregate
throughput and performance, and a higher number of subscriber sessions.
The PSC2 has been
enhanced with a faster network processor unit, featuring two quad-core
x86 2.5Ghz CPUs, 32 GB of RAM. These processors run a single copy of
the operating system. The operating system running on the PSC2 treats
the two dual-core processors as a 4-way multi-processor.
The PSC2 has a 2.5
G/bps-based security processor that provides the highest
performance for cryptographic acceleration of next-generation IP
Security (IPSec), Secure Sockets Layer (SSL), and wireless LAN/WAN
security applications with the latest security algorithms.
For more information
about PSC2s, see the Product
Overview Guide.
Duplicate Session
Detection
When an MS sets
up a new session, the PDIF automatically checks for any remnants
of abandoned calls and if found, clears them.
During a call, the
processes of clearing the old session and establishing the new session
run in parallel, optimizing processing functions.
With every new session
setup, the PDIF supports a mechanism to verify whether there is
any old session that is bound with the same International Mobile
Subscriber Identity (IMSI) number. This is derived from the Callback-Id
AVP in the last DEA message from the HSS after it has verified the
subscriber.
For example, if an
MS accesses the PDIF and subsequently moves out of the Wi-Fi coverage area,
when the MS comes back on line, it could initiate a new session.
After authentication, if an old session with the same IMSI is detected,
the PDIF starts clearing it by sending a proxy-MIP Deregistration
request to the HA. Once a Deregistration request is sent and a Deregistration response
is received, the PDIF resumes the new session setup by sending a
proxy-MIP Registration request. This setup procedure continues after
the PDIF receives a proxy-MIP Deregistration response from the HA.
IMSI-based duplicate
session detection is supported per source PDIF context. The PDIF requires
only one source context to be configured per PDIF, therefore duplicate
session detection across the entire chassis is possible. The feature
is designed with the assumption that no more than one call with
duplicate identifies are in the setup stage at any time. There is
no limit to the number of duplicate session handling iterations.
When an old session
is cleared, the PDIF sends Diameter STR messages and Radius Accounting
STOP messages to corresponding AAA servers.
The PDIF allows duplicate
session detection based on the NAI or IMSI. Note that when detecting
based on the NAI, it is the first-phase (Multi-Authentication device
authentication phase) NAI that is used.
If NAI-based duplication
session handling is enabled, the PDIF sends an INFORMATIONAL (Delete)
message to the MS.
Duplicate Session Detection
is configured in PDIF-Service mode. The default is NAI-based.
Note that this configuration
applies only to calls established after the configuration is made. It
is therefore suggested that this selection be made in the boot-time
configuration before any calls are established. For example, if
NAI-based is used initially and an X number of calls is established,
and then the configuration changes to IMSI-based, IMSI-based duplicate
session handling does not apply to the calls established before
the configuration change.
Unsupported Critical
Payload Handling
This feature
provides a mechanism whereby the PDIF ignores all unsupported critical
payloads and continues processing as if those payloads were never
received.
For MOBIKE IKEv2 messages,
the PDIF returns UNSUPPORTED_CRITICAL_PAYLOAD
in the IKEv2 response messages. The PDIF also drops all NAT-T keep-alive
messages.
Registration Revocation
Registration
Revocation is a general mechanism whereby the HA providing mobile
IP or proxy mobile IP functionality to a mobile node notifies the
PDIF/FA of the termination of a binding. This functionality
provides the following benefits:
- Timely release of mobile
IP resources at the FA and/or HA
- Accurate accounting
- Timely notification
to mobile node of change in service
IMPORTANT:
Mobile IP registration
revocation is also supported for proxy mobile IP. However, in this implementation,
only the HA can initiate the revocation.
IMPORTANT:
For more information,
see Mobile-IP Registration Revocation chapter in this guide.
CHILD SA Rekey Support
During Child
SA (Security Association) rekeying, there exists momentarily (500ms
or less) two Child SAs. This is to make sure that transient packets
for the old Child SA are still processed and not dropped.
PDIF-initiated rekeying
is disabled by default. This is the recommended setting, although
rekeying can be enabled through the Crypto Configuration Payload
mode commands. By default, rekey request messages from the MS are ignored.
Denial of Service
(DoS) Protection: “Cookie Challenge”
There are several
known Denial of Service (DoS) attacks associated with IKEv2. Through
a configurable option in the Config Crypto-Template mode,
the PDIF can implement the IKEv2 “cookie challenge” payload
method as described in [RFC 4306]. This is intended
to protect against the PDIF creating too many half-opened sessions
or other similar mechanisms. The default is not enabled. If the
IKEv2 cookie feature is enabled, when the number of half-opened
IPSec sessions exceeds the reasonable limit (or the trigger point
with other detection mechanisms), the PDIF invokes the cookie challenge
payload mechanism to insure that only legitimate subscribers are
initiating the IKEv2 tunnel request, and not a spoofed attack.
If the IKEv2 cookie
feature is enabled, and the number of half-opened IPSec sessions
exceeds the configured limit of any integer between 0 and 100,000,
the call setup is as shown in the figure below.
Figure 6. DoS Cookie-Challenge-Enabled
IKEv2 Message Exchange
Table 3. DoS Cookie Challenge
Enabled IKEv2 Message Exchange
Step |
Description |
1 |
The
MS places a call to the WiFi AP. |
2 |
The
WiFi AP returns the IP address of the PDIF. |
3 |
The
MS sends an IKE_SA_INIT request. message. |
4 |
The
PDIF sends the Notify (cookie) payload to the MS to request retransmission
of the IKE_SA_INIT request message to include
the Notify (cookie) payload in the message. |
5 |
Upon
receipt of the retransmitted message, the PDIF verifies the cookie
payload and ensures it is the same cookie as the one it had sent. |
6 |
If
the cookie challenge is met, setup continues as normal with an IKE_SA_INIT
response message. |
Cookie Challenge
Statistics
Cookie challenge
statistics appear in the outputs for the following commands:
-
show crypto managers
summary ikev2-stats: Shows the total number of invalid
cookies per manager instance.
-
show crypto managers
summary npu-stats: Shows NPU statistics on each IPSec
manager.
-
show crypto statistics:
Shows the combined data statistics for the given context name. Includes
the number of cookie flows, the number of cookie flow packets, and
the total number of cookie errors.
-
show crypto statistics
ikev2: Shows the control statistics for a given context
name. Includes the output for show crypto statistics, plus
Total IKEv2 Cookie Statistics, Cookie Notify Sent, Cookie Notify
Received, Cookie Notify Match, Cookie Notify NOT Match, and Invalid
Notify Payload Cookie.
MAC Address Validation
The MS embeds
the MAC address from the WiFi AP in the NAI when it sends an IKEv2 AUTH
request. If MAC address validation is enabled on the PDIF, it sends
a Diameter User-Data-Request (UDR) message to the HSS with the NAI
from the MS. The HSS returns a User-Data-Answer (UDA) message to
the PDIF containing a list of authorized MAC addresses.
If the PDIF finds the
MAC address in this list, the MAC address validation succeeds, and
the PDIF continues with the IKEv2 call. The MS starts EAP authentication
through IKEv2 AUTH procedures. If configured to do so, the PDIF
removes the MAC address from the NAI when sending authentication
requests to external RADIUS servers. If the embedded MAC address
is not removed, the authentication check fails, because the AAA server
cannot accommodate embedded MAC addresses.
If the MAC address
is not in the list, the MAC address authorization fails, and the
IKEv2 session is terminated with a Notify Message Type 16382 - Private
User Errors message.
If the HSS interface
is not reachable, it is possible that the IKEv2 session setup could continue
as if the MAC authorization had succeeded. However, such error behaviors,
including various Diameter error codes from the HSS, are configuration
options. That means if an HSS returns an error, the action could
be either to continue or to terminate the session. This is discussed
in Diameter Failure Handling.
IMPORTANT:
See also Diameter Authentication
Failure-Handling in the CDMA
Command Line Interface Reference.
RADIUS Accounting
RADIUS Accounting
messages are not generated while mobile IP setup is in progress.
- A RADIUS accounting
START message is generated when the session is established.
- RADIUS INTERIM accounting
messages are generated at configured intervals in a call.
- A RADIUS STOP accounting
message is sent to the AAA server when the call ends.
There is no session
dormancy in the PDIF. Once the session is active, the session never
goes to a dormant state.
IMPORTANT:
For more information
on RADIUS attributes and customizable dictionary types, refer to the
AAA and GTPP Interface Administration
and Reference. For the impact of attributes in Request
and Reply messages, see also
Mobile IP Native Simple
IP Call Minimum Requirements. There is additional attribute
information in the
Session
Termination section in
Troubleshooting.
Special RADIUS Attribute
Handling
Certain attributes
require special handling on the PDIF with the attribute values either
controlled by a RADIUS dictionary entry or a PDIF-service configurable.
No configuration has no behavioral effect.
- 3GPP2-Serving-PCF.
The generation of each new custom dictionary requires a new PDIF
image. Configured in the pdif-service mode, the command aaa attribute 3gpp2-serving-pcf <ip-address>
specifies the required values for the attribute without building
a new software image. If configured, this attribute is sent in RADIUS accounting
messages.
The following attributes
are in custom dictionaries but have a customer-requested component.
- Calling-Station-ID.
Required for PDIF RADIUS messages, there is a “dummy” value
of 000000000000000 (fifteen zeros) set in this attribute. For non-PDIF
product lines, the configured value may be taken only if no attributes
are received through the corresponding access protocols. Configurable
in the PDIF-service.
- NAS-Port-Type. The
3GPP2 X.P0028-200 standard requires this value to be set as “5 (= Virtual).” Controlled
through the RADIUS dictionary.
- Service-Type. Cisco
specifies a Service Type of “framed” for PDIF
messages. Controlled through the RADIUS dictionary.
- Framed-Protocol. There
is no attribute value defined for IPSec. Cisco specifies a value of “PPP” for
PDIF messages. Controlled through the RADIUS dictionary.
- BSID. Base Station
ID is used in billing for calculating time-zone offsets. There is
a dummy value set in this attribute for RADIUS messages from the
PDIF. Configured in the PDIF-service.
- 3GPP2-MEID and 3GPP2-ESN.
Since the customer billing system expects these attributes, a null
value is set in these attributes for RADIUS messages from the PDIF.
Mobile Equipment Identifier (MEID) uniquely identifies the mobile
equipment and is the future replacement for Electronic Serial Number
(ESN) of the Mobile Station. Controlled through the RADIUS dictionary.
- 3GPP2-Last-Activity.
The event timestamp is set in this attribute where applicable in RADIUS
messages from PDIF. This attribute is the same as the 3GPP2-Last-User-Activity-Time standard
attribute.
- 3GPP2-Service-Option.
Set with a default value of 4095. Configurable in the PDIF-service.
- SN-Disconnect-Reason.This
is a Cisco VSA that specifies a more detailed reason for session
disconnection.
- 3GPP2-Active-Time If
required for billing purposes, this VSA could be populated with the
session length by generating a new RADIUS dictionary with this attribute.
Unless specifically requested, a custom RADIUS dictionary does not
include the 3GPP2-Active-Time VSA.
Mobile IP and Proxy
Mobile IP Attributes
The SN-Proxy-MIP attribute
is required when PDIF supports proxy mobile IP. The PDIF-Mobile-IP-Required
attribute is SN1-PDIF-MIP-Required. These attributes need to be
returned in a AAA response message or the mobile IP call fails,
although there might be an option for simple IP call setup. See the Sample
Deployments section for more information on attribute messaging.
IPv6 Support
This section
describes the level of IPv6 support. All known restrictions are
shown in Engineering Restrictions. Configuration examples are shown
in Configuration.
Native IPv6 supports
configuration of interfaces and routes with IPv6 (128-bit) addressing.
PDIF supports IPv6 for communication with Diameter servers over SCTP.
Using the Diameter proxy mechanism, each PSC needs a unique IPv6
address. Multiple IPv6 interfaces per context are supported.
Native IPv6 interfaces
communicate with the Diameter servers. PDIF supports the configuration
of 32 IPv6 Ethernet interfaces and 32 IPv6 loopback interfaces per
context:
- One configured (CIDR
global or site-local) IPv6 address per interface.
- Support for auto-configuration
of link-local address based on an assigned MAC address. If the MAC
address changes, the link-local addresses are updated accordingly.
If a virtual MAC address is configured, it uses that MAC address
for the link-local IFID. Note that this is distinct from the manual
configuration of IPv6 addresses described below.
IPv6 Neighbor Discovery
IPv6 Neighbor
Discovery protocol is used to dynamically discover the directly
attached devices on IPv6 interfaces. It facilitates the mapping
of MAC addresses to IPv6 Addresses. PDIF supports a subset of IPv6
Neighbor Discovery as defined by [RFC 2461] as
follows:
- Uses IPv6 Neighbor
Discovery to learn the Ethernet link-layer addresses of the directly
connected next-hop gateway.
- Supports configuration
of static IPv6 neighbors.
- Adds link-local addresses
to Ethernet type interfaces automatically.
- Performs Unsolicited
Neighbor Advertisement on line card switchover.
- Responds to neighbor
discovery requests for the PDIF IPv6 addresses.
IPv6 Static Routing
Native IPv6
routing allows the forwarding of IPv6 packets between IPv6 networks.
The forwarding lookup is based on destination IPv6 address longest
prefix match.
PDIF supports configuration
of static routes including a default route. If a default route is
configured, all IPv6 traffic is forwarded to the configured next-hop defined
by the default route.
Port-Switch-On-L3-Fail
for IPv6
IPv4 port failover
redundancy if L3 connectivity is lost is extended to support IPv6
addresses.
For more information
on configuring port-switch-on-l3-fail, see Ethernet Interface
Configuration Commands in the CDMA Command Line Interface Reference and Creating and Configuring
Ethernet Interfaces and Ports in the System Element Configuration
Procedures section of the System Administration Guide.
IKEv2 Keep-Alive
(Dead Peer Detection (DPD))
PDIF supports
DPD protocol messages originating from both the MS and the PDIF/FA.
DPD is configured on a per-PDIF-service basis. The administrator
can also disable DPD and the PDIF/FA does not initiate
DPD exchanges with the MS when disabled. However, the PDIF/FA
always responds to DPD availability checks initiated by the MS regardless
of the PDIF/FA idle timer configuration.
IMPORTANT:
For a number of failure
scenarios involving Dead Peer Detection, refer to the Troubleshooting chapter.
Congestion Control
and Overload Disconnect
Congestion control
is an operator-configurable facility. When the PDIF chassis reaches
certain limits (based on CPU utilization, port utilization, and
other controls) the system enters a congested state. When in a congested
state, existing calls are not impacted but new calls are potentially
restricted.There is a separate subscriber-level configuration to
enable/disable the feature on a per-subscriber basis. There
is also a subscriber-level configurable for inactivity-time and connect-time thresholds
to remove some old and abandoned calls from the system.
The disconnection scenario
is as follows:
- If only idle-time-threshold is
configured, sessions exceeding this threshold would be selected
for disconnection.
- If only connect-time-threshold is
configured, sessions exceeding this threshold would be selected
for disconnection.
- If both idle-time-threshold and connect-time-threshold are
configured, sessions with an idle-time greater than the idle-time
threshold and a connect-time greater than the connect-time-threshold
would be selected for disconnection.
- If neither idle-time-threshold nor connect-time-threshold is
configured, sessions are sorted based on the idle-timer, and sessions
with a longer idle-timer are deleted first.
SCTP (Stream Control
Transmission Protocol) Support
PDIF provides
support for SCTP (Stream Control Transmission Protocol) for use
in communicating with Diameter peers over IPv6.
Diameter/SCTP
connections are set up for administratively enabled Diameter peers
whenever the system configuration is loaded. In the event of certain
card or task-level failures, SCTP connections are torn down and
re-established (but note that the Diameter state will still be maintained).
SCTP complies with
the description in [RFC 2960 Section 5.1.1] for
how to handle the case where the peer is incapable of supporting
all of the outbound streams that the endpoint wants to configure.
Specifically, PDIF does not abort the session but instead adjusts
the association's number of outbound streams to match the number
of inbound streams advertised by the peer (in the event that the
number sent is less).
X.509 Digital Trusted
Certificate Support
A digital certificate
is an electronic credit card that establishes one's credentials
when doing business or other transactions on the Web. Some digital
certificates conform to ITU-T standard X.509 for a Public Key Infrastructure
(PKI) and Privilege Management Infrastructure (PMI). X.509 specifies,
among other things, standard formats for public key certificates,
certificate revocation lists, attribute certificates, and a certification
path validation algorithm.
The PDIF generates
an SNMP notification when the certificate is within 30 days of expiration
and approximately once a day until a new certificate is provided.
The operator needs to generate a new certificate and then configure
the new certificate using the CLI. The certificate is then used
for all new sessions.
IMPORTANT:
For more configuration
information, refer to Global
Configuration in the CDMA
Command Line Interface Reference.
2048-bit Certificate
Key Functionality
This enhancement
supports PDIF session setup when a PDIF certificate includes an
RSA key size of 2048 bits. This includes:
- 2048-bit private key
configuration in Global Configuration mode
- Certificate configuration
that includes 2048-bit public keys
- The calculation of
the AUTH payload in the first IKE_AUTH response from the
PDIF using the 2048-bit private key
- Transporting the PDIF
certificates with 2048-bit RSA public key length from the PDIF to
the MS
- The validation of
the AUTH payload using the 2048-bit RSA public key
- Dynamically applying
a new 2048-bit certificate to 1024-bit or 2048-bit certificates
with no service interruption to in-process calls
- The PDIF forwarding
the first IKE_AUTH response with the CERT payload to the
IPMS server (as it currently does), and the IPMS server decoding
the message (if the proper IKE SA key is available)
- Collocation of certificates
with 1024-bit keys and 2049-bit keys
- Fragmented packets
are visible in external system output
Collocation of
Certificate with 1024-bit Key and 2048-bit Key
Currently available
dual-mode Wi-Fi handsets can only process certificates with 1024-bit key
length. Future handsets will support 2048-bit key length only. During
the transition period, it is possible that two different types of
certificates must be configured in the same PDIF chassis:
- 1024-bit key only
handset (abbreviated as 1024-bit MS)
- 2048-bit key only
handset (abbreviated as 2048-bit MS)
PDIF is informed as
to which certificate the MS will receive.
Distinguishing
Between 1024-bit and 2048-bit Key Certificates
Certificates
are configured in Global Configuration mode and bound to a crypto
template. The crypto template is mapped to each PDIF service. The
MS uses different PDIF services depending on which key length it
can support.
The MS first resolves
the IP address of the PDIF service with a pre-configured FQDN. As
shown in the following figure, two different FQDNs may be configured
to initiate session setup with two different PDIF services.
Figure 7. Distinguishing Between
1024-bit and 2048-bit Key Certificates
Custom DNS Handling
By default,
the PDIF always returns a DNS address in the CP payload if one is
received from the configuration or the HA. A new CLI has been added
defining an alternate series of supported behaviors depending on
the number of INTERNAL_IP4_DNS. These include,
but are not limited to, the following:
- Provides a mechanism
whereby the DNS address present in configurations will be sent to
the MS in the CP payload only if the MS requests one.
- The address 0.0.0.0
is treated as invalid and not included.
IMPORTANT:
For more information
including full definitions for each of the trigger behaviors, see Configuring Crypto
Template in Configuration,
and also see the CDMA
Command Line Interface Reference.
Gx+ and
Gy Interface Support via HA
To provide secure
WiFi access between the MS and the PDIF via PMIPv4 (Proxy Mobile
IP version 4), this feature enables the PDIF and the FA (Foreign
Agent) to run on the same chassis and enables the PDIF/FA
to forward the following three attribute-value pairs (AVPs) to the
HA in a PMIP RRQ (Proxy MIP Registration Request) message:
- Location information
for the WiFi access point in the form of a BSID (Base Station Identifier)
per 3GPP2.
- RAT (Radio Access Type)
of WiFi per RFC 5563.
- User identity in the
form of an NAI (Network Access Identifier) per RFC 2486.
After receiving these
AVPs from the PDIF/FA, the HA forwards the AVPs over the
Gx+ or Gy interface to the PCRF (Policy Charging and Rules
Function) or OCS (Online Charging System). Optionally, this feature
allows the co-location of the PDIF/FA and HA on one chassis.
The following call
flow shows how this feature supports secure WiFi access between
the MS and the PDIF via PMIPv4.
Figure 8. Gx+ and
Gy Interface Support
Table 4. Gx+ and
Gy Interface Support
Step |
Description |
1.
|
The MS sets up an IKEv2/IPSec
tunnel by sending an IKE_SA_INIT Request message
to the PDIF. The MS includes SA, KE, Ni, and NAT-DETECTION Notify
payloads in the IKEv2 exchange.
|
2.
|
The PDIF processes
the IKE_SA_INIT Request message for the appropriate
PDIF service (bound by the destination IP address in the message).
The PDIF responds with
an IKE_SA_INIT Response message with SA, KE, Nr,
and NAT-Detection Notify payloads. The PDIF starts the IKEv2 setup
timer upon sending the IKE_SA_INIT Response message.
|
3.
|
Upon receiving a successful
IKE_SA_INIT Response message from the PDIF, the
MS sends an IKE_ AUTH Request message for EAP-AKA authentication.
The MS includes an IDi payload, which contains the NAI, SA, TSi,
TSr, and CP (requesting an IP address and DNS address) payloads.
The MS does not include an AUTH payload to indicate that it will
use EAP methods.
|
4.
|
Upon receiving an IKE_AUTH
Request message from the MS, the PDIF sends a DER (Diameter EAP
Request) message to the Diameter AAA server. AAA servers are selected
based on domain profile, default subscriber template, or default
domain configurations. The PDIF includes a Multiple-Auth-Support
AVP and EAP-Payload AVP with EAP-Response/Identity in the
DER message. The PDIF starts the session setup timer upon receiving
an IKE_AUTH Request message from the MS.
|
5.
|
The PDIF receives a
DEA (Diameter EAP Accept) message with a Result-Code AVP indicating
that EAP authentication should continue.
|
6.
|
The PDIF takes the
contents of the EAP-Payload AVP and sends an IKE_ AUTH
Response message back to the MS in the EAP payload. The PDIF will
optionally include IDr and CERT payloads (depending upon the configuration).
The PDIF allows IDr and CERT configurations in the PDIF service.
The PDIF optionally includes an AUTH payload in the IKE_AUTH
Response message (if the PDIF service is configured to do so). The
MS receives the IKE_AUTH Response message from the PDIF.
|
7.
|
Upon receiving the
IKE_AUTH Response message from the PDIF, the MS processes
the exchange and sends a new IKE_AUTH Request message with
an EAP payload.
|
8.
|
The PDIF receives the
new IKE_AUTH Request message from the MS and sends a DER message
to the AAA server. This DER message contains the EAP Payload AVP
with an EAP AKA Challenge Response and Challenge Received from the
MS.
|
9.
|
The AAA server sends
the DEA message back to the PDIF with a Result-Code AVP of Success.
The EAP Payload AVP message also contains an EAP result code of
Success. The DEA message also contains the IMSI for the user, which
is included in the Callback-Id AVP. The PDIF uses this IMSI for
all subsequent session management functions, such as duplicate session
detection. The PDIF also receives the MSK from the AAA server, which
is used for further key computation.
|
10.
|
The PDIF sends the
IKE_AUTH Response message back to the MS with the EAP payload.
|
11.
|
The MS sends the final
IKE_AUTH Request message with the AUTH payload computed
from the keys. The PDIF processes the AUTH Request message and responds
with an IKE_AUTH Response message with the AUTH payload
computed from the MSK.
|
12.
|
The PDIF does not assign
any IP address for the MS and initiates a Proxy-MIP Registration Request
(RRQ) message to the HA if “proxy-mip-required” is
enabled. And if "mobile-ip send bsid" and “mobile-ip send
access-technology” are enabled, the PDIF includes the additional
attributes RAT and BSID in the PMIP RRQ message. The user ID is
already include in the PMIP RRQ as the NAI. The HA address may be
received from the AAA server in the Access Accept or may be locally configured.
The PDIF may also remember the HA address from the authentication
received in the final DEA message. If proxy-mip-required is disabled,
PDIF will assign the IP address from the local pool. Detailed changes
in the RRQ NAI attribute are sent as before under the attribute Username,
but no changes are made to this attribute.
|
13.
|
The HA returns a Proxy-MIP
Registration Reply (RRP) message to the PDIF.
|
14.
|
The PDIF sends a final
IKE_AUTH Response message to the MS.
|
15.
|
An IKE_SA
CHILD_SA gets established between the MS and the PDIF.
|
To enable this feature
on the PDIF, from the system CLI, in Subscriber Configuration Mode, you
issue the following two commands:
-
mobile-ip send bsid
-
mobile-ip send access-technology
For command descriptions,
see the CDMA Command
Line Interface Reference.
Features and Functionality
- Licensed Enhanced Feature Support
This section
covers any feature not covered by the base PDIF software and is
licensed either separately or in a customized bundle of feature
licenses.
IMPORTANT:
Contact your local
Sales or Support representative for information on how to obtain
a license.
This section describes
the following features:
PDIF Service
The PDIF service
and the processes associated with it define the PDIF itself. The
PDIF service enables mobile stations to interface with the PDIF.
The PDIF service configuration
includes the following:
-
The IPv4 address for
the service: This is the PDIF IP address to which the MS tries
to connect. The MS sends IKEv2 messages to this IP address and this
address must be a valid address in the context. PDIF service will
not be up and running if this IP address is not configured.
-
The name of the crypto
template for IKEv2: A crypto template is used to configure an
IKEv2 PDIF IPSec policy. It includes most of the IPSec parameters
and IKEv2 parameters for keep-alive, lifetime, NAT-T and cryptographic
and authentication algorithms. There must be one crypto template
per PDIF service. The PDIF service will not be up and running without
a crypto-template configuration.
-
The EAP profile name: This
profile defines the EAP authentication methods.
-
Multiple authentication
support: The multiple authentication configuration is a part
of the crypto template.
-
IKEv2 and IPSec transform
sets: These define the negotiable algorithms for IKE SA and
CHILD SA setup to connect calls to the PDIF/FA.
-
Configure the setup
timeout value: The MS connection attempt is terminated if the
MS does not establish a successful connection within the configured
value.
-
Mobile IP foreign agent
context and foreign agent service: This defines the system context
where mobile IP foreign agent functionalities are configured.
-
Max-sessions: The
maximum number of subscriber sessions allowed by this PDIF service.
-
PDIF supports a domain
template for storing domain related configuration: The domain
name is taken from the received NAI and searched in the domain template database.
-
3GPP2 serving PCF address: This
configurable specifies what value in the RADIUS attribute when sending
authentication and accounting messages.
-
Duplicate session detection
parameters: PDIF supports either NAI (first phase authentication)
or IMSI to be used for duplicate session detection. This configuration
specifies whether duplicate session detection is based on IMSI or
NAI. The default is NAI.
When the PDIF service
is configured in the system with the IP address, crypto template,
etc., the PDIF is ready to accept IKEv2 control packets for establishing
IKEv2 PDIF sessions.
There is a limit to
the number of CHILD SAs supported by each PDIF service. Traditionally, other
Cisco services limit this to the number of subscriber sessions.
The PDIF treats this as the number of CHILD SAs. This means that
if each subscriber establishes only a single CHILD SA, the limit
will be equal to the number of subscriber sessions. During CHILD
SA rekeying, for a small duration of time, there are two CHILD SAs
in the system. This is to make sure that transient packets for the
old CHILD SA are still processed (not dropped).
Multiple PDIF Services
The PDIF supports
multiple PDIF services running simultaneously on the same chassis.
This feature enables operators to configure PDIF services with different
crypto templates to support multiple subscriber handsets and to
set per-service maximum session limits. The total number of sessions
for all PDIF services running simultaneously on the same chassis
must fall under the PDIF session counting license limit.
Lawful Intercept
The Cisco Lawful
Intercept feature is supported on the PDIF. Lawful Intercept is
a license-enabled, standards-based feature that provides telecommunications
service providers with a mechanism to assist law enforcement agencies
in monitoring suspicious individuals for potential illegal activity.
For additional information and documentation on the Lawful Intercept
feature, contact your Cisco account representative.
Diameter Authentication
Failure Handling
Diameter EAP
failure handling defines error handling for both Session Termination
Requests and for EAP Requests.
Specific actions (continue,
retry-and-terminate, or terminate) can be associated with each possible
result-code. EAP failure handling is flexible enough that wide ranges
of result codes can be defined with the same action, or actions
can be bound on a per-result-code basis.
A failure does not
necessarily mean a summary termination of a call.
diameter authentication
<failure-handling>
session-termination-request
diameter result-code 5001-5005 action continue
configures result codes
5001, 5002, 5004 and 5005 to mean the session could continue regardless
of the error,
and
diameter authentication
<failure-handling>
session-termination-request
diameter result-code 5003 action terminate
configures result code
5003 to mean terminate the session immediately.
In this scenario, the
PDIF receives the DEA from an HSS with the failure code 5003 to terminate
the IKE setup for the session. The PDIF sends the IKE_AUTH
Response containing a Notify Payload with the type as AUTH_FAILED
plus the EAP payload if one was received in the DEA.
When the PDIF received
the last DEA message with AVPs that are not in the dictionary, and with
the M-bit set to 1, the PDIF disconnects the session.
IMPORTANT:
For more information on
Diameter specific configuration, refer to the Configuring Diameter
Authentication Failure Handling section in the AAA and GTPP Interface
Administration and Reference.
Online Upgrade
The customer
has the benefits of upgrading software from a fully redundant device
without the expense of maintaining a fully loaded, fully redundant
ASR 5000 in a permanent state of standby.
The PDIF supports online
software upgrades with a single software version difference between
two chassis. For example, upgrading from Release 8.1 to 8.2 is supported.
Support for a chassis running greater differences in software versions
would be qualified by Cisco on an as-needed basis.
IMPORTANT:
Refer to the Maintenance chapter
in this guide for information on how to perform the upgrade.
The online upgrade
process calls for a spare ASR 5000 to temporarily perform the services currently
being provided by a live networked chassis and upgrade the software
with minimal service interruption. This model is called Active-Standby,
as one chassis is designated as active and the other as standby.
The standby chassis does not handle any new, incoming sessions because
the DNS allocating new sessions does not know about the backup chassis.
The backup is only required to handle sessions that were already
on the primary chassis when it was administratively disconnected
from the DNS server. Except for the data loss during the brief chassis
switch-over, the session information (accounting and timers) are
synchronized so that they are accurate when the backup becomes the
active PDIF.
IMPORTANT:
Online upgrade requires
miscellaneous internal processing that may result in intensive CPU utilization.
Up to 50% CPU utilization overhead should be expected during
the upgrade.
The Active-Standby
Upgrade Model
The Active-Standby
model is shown below:
Figure 9. Active-Standby
Online Upgrade Model
The active and standby
chassis are connected by an SRP redundancy link to monitor and control
the chassis state. Both active and standby chassis have SRP-activated
resources defined. Resources could mean loopback interfaces, broadcast
interfaces, or IP pools, depending on the installation. For this
example, use loopback interfaces.
These resources are
the same between the active and standby PDIF. Loopback IP addresses in
ingress and egress contexts, and IP pools in egress contexts, are
usually SRP-activated resources. The result is that only the currently
active chassis enables the SRP-activated resources. The activate
command is srp-activate.
IMPORTANT:
Ingress and egress
contexts could be the same context. The SRP context must be a separate context.
In the network diagram
below, each ingress context has loopback interface A defined, which is
SRP-activated. PDIF service A is bound to this interface. The standby
chassis has the same interface and PDIF service defined. Both interface
and service can only be enabled on the active chassis. Similarly,
interface B is defined in the egress context, which can be activated
only in the active chassis.
When the active chassis
switches over, the standby chassis becomes active and enables all SRP-activated
IP interfaces and IP pools so that it can function as a mirror image
of the former primary PDIF.
Figure 10. Loopback Interface Configuration
Operation Over a
Common IPv4 Network
The PDIF supports
L2 switching to enable carriers not using dynamic routing between
the core nodes to perform an online upgrade.
In the example below,
the SRP virtual MAC address is configured for the SRP-activated
loopback address for the subnet. This allows the standby chassis
to seamlessly assume the active role in the network after a switchover.
Attached devices continue to send to the same SRP virtual MAC address
and the currently active chassis responds to ARP requests for the
shared loopback IP address. This scheme allows fast standby-to-active
transitions, since the SRP virtual MAC address does not change during
the switchover.
When the ASR 5000 transitions
from backup to primary, the PDIF sends Gratuitous ARPs to update
the port-MAC table of the adjacent switch.
Figure 11. Switchover Example
for Common IPv4 Subnet
Operation Over a
Common IPv6 Network
For AAA context
with Diameter/SCTP/IPv6 configuration, multiple
loopback IPv6 addresses are configured as Diameter endpoints. The
customer can SRP-activate these loopback addresses and, upon SRP
switchover, the HSS/SLF still sees the same Diameter peer
endpoint. No new Diameter peer configuration to the HSS/SLF
is required.
With SRP switchover
operation in effect, the PDIF shuts down all the SCTP connections
to the HSS/SLF. Then the former backup PDIF immediately
creates new SCTP connections with the HSS/SLF. In this
reestablishment process, the backup chassis sends an Unsolicited
Neighbor Advertisement message to the adjacent switch, which is
then used to overwrite its port MAC address table as shown in the
diagram below.
Figure 12. Switchover Example
for a Common IPv6 Subnet
Other Devices
The following
table summarizes how other network devices see two ASR 5000s chassis
during online upgrade. The table below assumes that a SRP-activated
loopback address is configured in the source (toward the MS), the
destination (toward the HA), and the AAA contexts (Diameter and
RADIUS).
Table 5. The Chassis as seen
from Other Network Devices During Upgrade
Network
Entity |
Consideration
in Two-Chassis Configuration |
L3
switch (MS ~ PDIF) |
This
L3 switch sees two chassis as a single entity. Only the physical
port in the switch changes due to the switchover operation by G-ARP.
The rest of the ASR 5000 information (IP address and MAC address)
remain the same. |
L3
switch (PDIF ~ HA) |
This
L3 switch sees two chassis as a single entity. Only the physical
port in the switch changes due to the switchover operation by G-ARP.
The rest of the ASR 5000 information (IP address and MAC address)
remains the same. |
Diameter
Server |
The
MS sees two PDIFs as the same entity. However, upon switchover the
SCTP connection is disconnected and then a new SCTP connection with
ASR 5000 is established immediately.If an L3 switch exists between
the PDIF and Diameter server, it sees two chassis as a single entity.
Only the physical port in the switch changes due to the switchover operation
by IPv6 Unsolicited Neighbor Advertisement. The rest of the ASR
5000 information (IP address and MAC address) remains the same. |
RADIUS
Server |
This
L3 switch sees these two chassis as a single entity. Only the physical
port in the switch changes due to the switchover operation by G-ARP.
The rest of the chassis information (IP address and MAC address)
remains the same.If there should be an L3 switch between the PDIF
and a RADIUS server, it sees two chassis as a single entity. Only the
physical port in the switch changes due to the switchover operation by
G-ARP, and the rest of the ASR 5000 information (IP address and MAC
address) remains the same. |
IPMS
Server |
Each
chassis is connected to an independent IPMS Server. When a switchover
takes place, the new IPMS Server continues to capture and store
the call logs (signaling messages and events). |
O&M
Device |
Each
chassis is connected to an independent O&M Device. When a switchover
takes place, the new O&M Device continues to perform the function
as the original device was configured. |
Session Recovery
Support
The session
recovery feature provides seamless failover and almost instantaneous
reconstruction of subscriber session information in the event of
a hardware or software fault within the same chassis, preventing
a fully connected user session from being dropped.
Session recovery is
performed by mirroring key software processes (the session manager
and the AAA manager, for example) within a single PDIF. These mirrored processes
remain in an idle state (in standby mode), wherein they perform
no processing, until they may be needed in the case of a software
failure (a session manager task aborts, for example). The system
spawns new instances of standby mode sessions and AAA managers for
each active Control Processor (CP) being used.
Additionally, other
key system-level software tasks such as VPN manager are performed
on a physically separate Packet Services Card (PSC/PSC2)
to ensure that a double software fault (the session manager and
the VPN manager fail at same time on same card, for example) cannot
occur. The PSC used to host the VPN manager process is in active
mode and is reserved by the operating system for this sole use when
session recovery is enabled.
The additional hardware
resources required for session recovery include a standby System Management
Card (SMC) and a standby PSC.
There are two modes
for session recovery.
-
Task recovery mode:
Wherein one or more session manager failures occur and are recovered
without the need to use resources on a standby PSC. In this mode,
recovery is performed by using the mirrored standby-mode session
manager tasks running on active PSCs. The standby-mode task is renamed,
made active, and is then populated using information from other
tasks such as AAA manager.
-
Full PSC recovery mode:
Used when a PSC hardware failure occurs, or when a PSC migration
failure happens. In this mode, the standby PSC is made active and
the standby-mode session manager and AAA manager tasks on the newly-activated
PSC perform session recovery.
Session/call
state information is saved in the peer AAA manager task because
each AAA manager and session manager task is paired together. To
ensure task recovery, these pairs are started on physically different
PSCs.
IMPORTANT:
For more information
on session recovery support, refer to Session Recovery in
this guide.
IPSec/IKEv2
IKEv2 and IPSec
transform sets configured in the crypto template define the negotiable
algorithms for IKE SA and CHILD SA setup to connect calls to the
PDIF/FA by creating two secure tunnels. The first, called
the Tunnel Inner Address (TIA) is for signaling traffic, but in
some cases it can be used for user traffic which can then use the
TIA IP address. The second IPSec SA connects the MS to an HA for
a mobile IP call.
Refer to Sample Deployments for
a full description of how a variety of calls are successfullyset
up (and torn down) in a variety of network scenarios.
At the beginning of
IKEv2 session setup, the PDIF and MS exchange capability for multiple authentication.
Multiple authentication is configured in the crypto template of
the PDIF service. When multiple authentication is enabled in the
PDIF service, the PDIF will include MULTIPLE_AUTH_SUPPORTED
Notify payload in the initial IKEv2 setup response.
The MS first sends
an NAI for the device authentication, in which EAP-AKA is used.
After the successful EAP-AKA transaction between the MS and the
HSS, the HSS is expected to return the IMSI number for this subscriber.
The PDIF uses the authorized IMSI number for session management.
Once the device authentication
is successful, the MS notifies the PDIF of its intention to continue
subscriber authentication only if the PDIF indicates it has multiple
authentication support during the initial IKEv2 exchanges. The MS
sends the second NAI that may be different from the first one used
during the device authentication. The subscriber authentication
is completed either using EAP-MD5 or EAP-GTC. Upon successful authentication,
the PDIF continues proxy MIP registration before granting its access
to the network.
Even if the PDIF sends
the MULTIPLE_AUTH_SUPPORTED capability in the
initial IKEv2 setup response, the MS may not support multiple authentication
and hence may not include MULTIPLE_AUTH_SUPPORTED
Notify payload in the subsequent IKEv2 AUTH exchange. In this case,
the MS may only go through the first authentication (which is EAP-AKA authentication).
After EAP-AKA authentication, if proxy-mip-required is configured
for the session (either through the domain or the default subscriber
or the corresponding Diameter AVP), the PDIF will establish a proxy
mobile IP session with the HA. The assigned IP address is normally
done by the HA and the PDIF receives this address through proxy
mobile IP RRP. The PDIF will pass this address back to the MS through
the final IKE_AUTH exchange. On the other hand, if proxy-mip-required
configuration is not present or disabled, then the PDIF will continue the
simple IP session setup by allocating the IP address for the MS
from the locally configured pool.
When the MS sends MULTI_AUTH_SUPPORTED
Notify payload in subsequent IKE_ AUTH exchanges, the PDIF
knows the MS wants to do the second authentication. After the first successful
EAP-AKA authentication, the MS will indicate to the PDIF regarding
the second authentication (through ANOTHER_AUTH_FOLLOWS
Notify payload in the final IKEv2 AUTH request). Please note that
the IP address of the MS will not be assigned during the first authentication
if the second authentication is to happen. The MS will then initiate
the second authentication IKEv2 exchanges. In some networks, this
second authentication uses the RADIUS AAA interface. The proxy-mip-required
attribute will normally be present in the subscriber profile (or
in the domain or default subscriber template) through a RADIUS attribute
in the Access Accept message. After successful authentication, if
proxy-mip-required is enabled, the PDIF will setup a proxy mobile
IP session with the HA, and the HA assigns an IP address to the MS.
If proxy-mip-required is disabled (or not present in the subscriber/domain
profile), the PDIF establishes a simple IP session and routes traffic
using the direct IP interface.
Simple IP Fallback
Network operators
with handsets that are mobile IP capable may want the MS to be connected
to the network and capable of doing data transfer even though the
mobile IP registration process might fail under certain situations.
If the mobile IP registration failures are due to HA reachability
issues or any authentication problems, the MS should still be able
to connect to the network using a simple IP connection, assuming
that simple IP fallback is enabled in the PDIF configuration. See Simple IP and Simple IP Fallback in
this chapter for a full description of this type of network configuration.
Simple IP
Simple IP is
a solution for network providers whose subscribers fall primarily
within a limited set of requirements. It provides the following:
- A mobility solution
for subscribers who do not typically roam outside their immediate
coverage area.
- An appropriate level
of service for users who do not use the network in such as way as
to need constant service between coverage areas. For example, subscribers
who do not perform large file downloads.
- A mechanism to complete
a call even if the proxy-mip-required or mip-required attributes are
not configured in the subscriber or domain profile.
Proxy Mobile IP
Proxy mobile
IP has the following benefits:
- Allows an MS that does
not support mobile IP to have the same roaming benefits of one that
does.
- The PDIF communicates
with the HA and acts as if the PDIF itself were the handset.
- Proxy mobile IP is
configured through the proxy-mip-required configuration,
or the corresponding Diameter AVP or RADIUS Access Accept messages.
If neither are present, the PDIF establishes a simple IP session
and the PDIF routes the call to the Internet or corporate network.
Proxy mobile IP provides
a mobility solution for subscribers whose mobile nodes do not support
mobile IP protocol. The PDIF sets up the mobile IP tunnel with the
HA and the PDIF proxies or acts on behalf of the handset as if it
were the handset. The subscriber receives an IP address from either
the service provider or from their home network. As the subscriber
roams through the network as if it were using a full mobile IP connection,
the IP address is maintained providing the subscriber with the opportunity
to use IP applications that require seamless mobility such as transferring
files.
IMPORTANT:
Refer to Proxy Mobile-IP in
the System Administration
Guide for more information.
Multiple Authentication
in a Proxy Mobile IP Network
Multiple authentication
requires authenticating both the device and the subscriber.
At the beginning of
the IKEv2 session setup, the PDIF and the MS exchange capability
for multiple authentication. Multiple authentication is configured
in the PDIF service as part of the crypto template where it is associated
with an EAP profile. The EAP profile defines the authentication
mode and method. If multiple authentication is enabled in the crypto template,
the PDIF includes a MULTIPLE_AUTH_SUPPORTED Notify
payload in the initial IKEv2 setup response.
IMPORTANT:
Even if the PDIF confirms
MULTIPLE_AUTH_SUPPORTED capability in the initial IKEv2
setup response, the MS may not support multiple authentication and
hence may not include a MULTIPLE_AUTH_SUPPORTED
Notify payload in the subsequent IKEv2 AUTH exchange. In this case,
the MS may only go through the first-phase (EAP-AKA) of device authentication.
During initial IKEv2/IPSec
security setup exchanges, the MS undergoes both device authentication
and subscriber authentication. This is because even if the device
is fully authenticated, a PDIF may not be able to tell which service
profile is applicable for the MS, nor the correct IP address to
assign.
IMPORTANT:
First-phase authentication
refers to device authentication, and second-phase authentication refers
to subscriber authentication.
AAA Group Selection
A maximum of
64 AAA groups is allowed on the ASR 5000. This could be spread across multiple
contexts or all groups can be configured within a single VPN context.
A maximum of 320 RADIUS
servers is allowed on the chassis.
When the aaa-large-configuration command
is issued, this number becomes 800 AAA groups and 1600 RADIUS servers
configured within the chassis.
The PDIF service allows
you to specify a different AAA group for each authentication phase.
A given AAA group supports either Diameter or RADIUS authentication,
but not both. In deployments where the NAI used in the first-phase
authentication is different from the NAI used in the second-phase
authentication, each NAI can point to different domain profiles
in the PDIF.
RADIUS Authentication
For more information
on AAA, RADIUS, and Diameter groups, refer to the AAA and GTPP Interface
Administration and Reference.
The second authentication
uses RADIUS for subscriber authentication. The PDIF supports EAP
termination mode during the second half of multiple authentication.
In this mode, EAP exchange takes place between the MS and the PDIF,
and the PDIF takes the information exchanged in the EAP payload
over IKEv2 into RADIUS attributes to support CHAP/PAP authentication
with the RADIUS server, and vice versa.
By default, the PDIF
initiates EAP-MD5 authentication and sends an EAP payload with an MD5-Challenge
to the MS. The MS returns an MD5-Challenge response in the EAP payload. Upon
receipt, the PDIF sends an RADIUS Access Request message which includes
an NAI, a CHAP-Password, a CHAP-challenge (derived from the EAP
payload), and an IMSI number (which is the calling station ID).
Once the AAA server returns an Access-Accept message, optional attributes
such as Framed-IP-Address and HA address are expected for the subsequent session
setup processing. The PDIF translates this Access-Accept message
into an EAP Success message, and returns this in an IKE_AUTH
Response message.
It is possible that
some MSs may not support CHAP authentication. In this case, the
MS is expected to return the EAP payload with a legacy-Nak message
when the PDIF sends an MD5-Challenge message. Upon receipt of the
legacy-Nak message, the PDIF initiates an EAP-GTC procedure. When
the MS returns EAP-GTC including its own password, the PDIF sends
a RADIUS Access Request message which includes an NAI, a password,
and an IMSI number. Once the AAA server returns an Access-Accept
message, attributes such as Framed-IP-Address and HA address are
expected for the subsequent session setup processing. The PDIF translates
the Access-Accept message as EAP success, and returns this in an
IKE_AUTH Response message.
If EAP-GTC is configured,
then the EAP-GTC method is used instead of the EAP-MD5 method.
The PDIF does the following
for IKEv2 and RADIUS authentication:
The PDIF terminates
EAP-MD5/GTC authentication. The PDIF understands the values
in the EAP payload, and maps them as RADIUS attributes for CHAP/PAP
authentication.
Upon request from the
MS, the PDIF performs EAP-GTC authentication instead of EAP-MD5.
Each domain profile
may be configured with two AAA groups, one for Diameter and the other
for RADIUS.
In deployments where
both NAI happen to be the same for both authentications, it will
point to the same AAA group and thereafter only one protocol (either
RADIUS or Diameter) is used.
There are cases where
the domain template may not be associated with a given NAI. In such cases,
the default AAA groups are used for authentication. Since authentication
happens in two phases, and each using Diameter and RADIUS AAA groups
respectively, there needs to be two default AAA groups (one for
Diameter authentication and one for RADIUS authentication) for multiple
authentication. The default AAA groups are configured in the PDIF service.
First-Phase Authentication
During first-phase
authentication, the HSS authenticates the device. The MS first sends
an NAI for device authentication. After the successful EAP-AKA transaction
between the MS and the HSS, the HSS is expected to return an IMSI
number for this subscriber. The PDIF takes this authorized IMSI
number for session management.
This authentication
method uses EAP between the MS and the AAA server, and the PDIF
acts as a pass-through agent.
IMPORTANT:
First-phase authentication
must use the EAP-AKA method.
Depending on the number
of HSSs in the network, it is possible that a Subscription Locator Function
(SLF) would be introduced into the network as a Diameter proxy or
relay agent. If deployed, the SLF would be the first point of contact
for the PDIF.
The protocol stack
between the PDIF and the HSS/SLF is Diameter over SCTP
over IPv6.
Second-Phase Authentication
Second-phase
authentication uses EAP-MD5 or EAP-GTC authentication with IKEv2
using a legacy RADIUS server, which does not understand or implement
EAP. This could be the same AAA server as those deployed in any
existing EV-DO network. In this case, EAP authentication happens
between the MS and the PDIF.
The protocol stack
between the PDIF and the AAA server is RADIUS over UDP over IPv4.
The two algorithms
for second-phase authentication are EAP-MD5 (which is the same as CHAP
authentication) and EAP-GTC (which is the same as PAP authentication).
When the MS sends the NAI to identify the subscriber, the PDIF initiates
the EAP-Request with a challenge. Once the MS returns the challenge
response, the PDIF maps it to a RADIUS ACCESS_REQUEST message
to complete CHAP authentication. There is an internal mechanism to
inform each peer if one method is not supported and to renegotiate
to use the other supported method.
In general, session
attributes during first-phase authentication are overwritten by
those from second-phase authentication, unless specified separately.
Exceptions to this include session-timeout and idle-timeout,
when the lower values are taken.
Termination
During session setup,
if there are any configuration mismatches or the PDIF cannot get
the required information, the session setup process is terminated
and appropriate log messages are generated.
If multiple-auth-supported is
not enabled on the PDIF, and the MS still sends a MULTIPLE_AUTH_SUPPORTED
Notify payload marked with the critical bit set, the PDIF returns
UNSUPPORTED_PAYLOAD. Otherwise, the PDIF ignores it and
processes the IKE packet as if the payload was never received. This
is non-standard MS behavior.
IMPORTANT:
The multiple authentication
process in a proxy mobile IP network is described in the Proxy-MIP
chapter in this guide.
Session Recovery
The session
recovery feature provides reconstruction of subscriber session information
in the event of a hardware or software fault within the system,
providing seamless failover andpreventing a fully connected user
session from being dropped.
In addition to maintaining
call state information, information is retained in order to:
- Recover IPSec manager
policies, all template maps, and all subscriber maps.
- Use the policies (including
templates) to recover CHILD SA tunnels, flow IDs, andstatistics.
- Recover or reconfigure
NPU flow IDs and data path handles.
- Recover and restore
the IKEv2 stack state for all tunnels.
- Supply the IKEv2 stack
with needed data statistics to determine rekey and DPD states.
- Recover Diameter session
information.
Recovery requires a
complex interaction between IPSec and session subsystems. The IPSec
subsystem also interacts with a Datapath that includes daughter
cards, daughter card managers, and the NPU. The session recovery
feature is disabled by default on the system, even when the feature
use key is present.
The IPSec controller
does not send an IPSec manager death notification to any subsystem. This
allows the daughter card to continue to receive and decrypt IPSec
tunnel data. It also allows both the session manager and daughter
card to continue carrying subscriber traffic using NPU flows and
IPSec SAs to transmit the data.
A session manager is
created on a PSC and a corresponding AAA manager is created on a different
PSC but is created with the same instance number. A session manager
saves (check-points) its Call Recovery Record (CRR) on the AAA manager
with an instance ID the same as its own. This pairs up the session
manager and the AAA manager and at the same time guarantees session
recovery in the event of a single PSC failure.
IPSec manager is also
created on a PSC. When a PDIF call request arrives, the IPSec manager
picks a session manager for this particular call using a demux library
on the same PSC. This means the IPSec manager is associated with
the session managers on the PSC.
The session subsystem
continues to use the AAA manager as its storage system for the PDIF because
AAA needs to provide other subscriber-related information to the
session manager. Now that the session manager and the IPSec manager
are paired on the same PSC, the IPSec manager is assured of data
recovery in case of PSC failure. This is because the session manager
saves its data on the AAA manager on a backup PSC.
IMPORTANT:
For more information,
refer to the PDIF Session
Recovery chapter in this guide.
Intelligent Packet
Monitoring System (IPMS)
The IPMS provides
a control-packet capture, database, and query facility. It provides
the functions to assist operators to analyze and investigate call-related
events at a later time.
IMPORTANT:
IPMS is described in
the IPMS System Administration Guide.
Multiple Traffic
Selectors
The PDIF can
be configured with multiple IPSec traffic classes, each containing
up to 128 traffic selectors, which are used during traffic selector
negotiation with UEs. Multiple traffic selectors allow the PDIF
to direct outbound traffic to selected IP addresses based on the
following protocols: IP, TCP, UDP, and ICMP. The PDIF can also direct
TCP and UDP traffic to selected IP addresses and port ranges.
IMPORTANT:
In this software release,
the PDIF supports IPv4 traffic selectors only.
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 selectors can be used to assure
that both endpoint SPDs are consistent and can aid in the dynamic
update of an SPD. Traffic selector payloads contain the selection
criteria for packets being sent over IPSec security associations (SAs).
During traffic selector
negotiation, each endpoint sends two traffic selector payloads in
the messages exchanged during the creation of an IPSec SA. The first
traffic selector payload is known as the TSi (Traffic Selector-initiator)
and the second is known as the TSr (Traffic Selector-responder).
Each traffic selector payload contains one or more traffic selectors,
and each traffic selector can contain an IP address range, a port
range, and an IP protocol ID. During traffic selector negotiation
between the UE and the PDIF, the UE assumes the role of the initiator
as it initiates an IPSec SA for its traffic, and the PDIF assumes
the role of the responder. The PDIF can use multiple traffic selectors
in its role as the responder.
Traffic selectors are
applied to calls via an AAA attribute. During call setup, the PDIF's AAA
manager selects the traffic class to use for a call based on the
Radius vendor-specific attribute (VSA) TrafficSelector-class, which
is received from the AAA server. The PDIF's Session Manager passes
the selected traffic class configuration from its AAA Manager to
its IPSec Manager, which then sends the traffic selectors to the
UE in the TSr for all CHILD SAs in the call. If no matching traffic
selector classes or traffic selectors have been configured on the
PDIF, or if the PDIF does not receive the TrafficSelector-class
attribute from the AAA server, or if the value of the received TrafficSelector-class
attribute is 0, the PDIF returns the default traffic selector to the
UE in the TSr, which allows all inbound traffic.
The PDIF saves the
traffic class configuration in each call during call setup. Configuration changes
made to the existing traffic class configuration will apply to new
calls only. There is no hard limit to the maximum number of allowed
traffic classes, but the recommended limit is 50.
When incoming traffic
from a UE does not match any of the configured traffic selectors,
the PDIF does not reject the traffic. Instead, the PDIF keeps a
per-call counter to record the number of packets that do not match
the configured traffic selectors. Outgoing traffic from the PDIF
to the UE is not subject to traffic selection or checking.
Selective Diameter
Profile Update Request Control
For mobile IP
calls, the Selective Diameter Profile Update Request Control feature
allows WiFi data-only sessions to co-exist with VoIP sessions on
the PDIF platform.
When the PDIF is accessed
by voice-enabled devices, it needs to interact with the HSS in order
for a subscriber session to access the IP core network. When the PDIF
is accessed by data-only devices, there is no need to interact with
the HSS.
This feature is used
to identify which subscriber sessions need to have the PDIF and
the HSS exchange Diameter Profile Update Request (PUR) and Profile
Update Answer (PUA) messages, and allows the PDIF to handle the
call setup for a data-only client without having to interact with the
HSS.
Selective PUR profiles
on the AAA server are mapped to subscribers during AAA authentication
via the Radius vendor-specific attribute (VSA) FMC-Type. FMC-Type
has these possible values: voice or data. When the AAA server sets
the FMC-Type value to voice, the PDIF and the HSS exchange PUR and
PUA messages. When the AAA server sets the FMC-Type value to data,
the PDIF and the HSS do not exchange PUR and PUA messages.
This feature is enabled
by default and requires no configuration.
Support of SHA2
Algorithms
In addition
to SHA1, the following algorithm variations, collectively known
as SHA2, are now supported in the Cisco ASR5000 IKEv2 stack: SHA-256,
SHA-384, and SHA-512. These algorthims provide an additional level
of security as authentication mechanisms for IKE and IKEv2 protocols.
The truncated variants,
known as Hash-based Message Authentication Mode (HMAC), are used
in conjunction with the with SHA-256, SHA-384, and SHA-512 algorithms
in IKE and IKEv2. The untruncated variants are known as Pseudo-Random Functions
(PRFs), also used with IKE and IKEv2.
The authentication
variants ensure that packets are authentic and cannot be modified
in transit. PRF variants provide secure pseudo-random functions
for generating keyed material and protocol-specific numeric quantities.
The following table
summarizes the sizes associated with the algorithms.
Table 6. Sizes Associated
with SHA2 Algorithms
Algorithm
ID |
Block
Size |
Output Length |
Truncated Length |
Key
Length |
Algorithm Type |
For Authentication
(with truncated output |
HMAC-SHA-256-128 |
512 |
256 |
128 |
256 |
Auth/integ |
HMAC-SHA-384-192 |
1024 |
384 |
192 |
384 |
Auth/inte |
HMAC-SHA-512-256 |
1024 |
512 |
256 |
512 |
Auth/inte |
For PRFs (with untruncated
output |
PRF-HMAC-SHA-256 |
512 |
256 |
None |
Variable |
PRF |
PRF-HMAC-SHA-384 |
1024 |
384 |
None |
Variable |
PRF |
PRF-HMAC-SHA-512 |
1024 |
512 |
None |
Variable |
PRF |