Packet Data Interworking Function Overview
▀ Features and Functionality - Licensed Enhanced Feature Support
▄ Cisco ASR 5000 Series Product Overview
OL-22938-02
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
Содержание ASR 5000 Series
Страница 1: ......
Страница 26: ......
Страница 48: ...New In Release 10 0 SCM Features Cisco ASR 5000 Series Product Overview OL 22938 02 ...
Страница 50: ......
Страница 58: ......
Страница 67: ...Product Service and Feature Licenses Default Licenses Cisco ASR 5000 Series Product Overview OL 22938 02 ...
Страница 68: ......
Страница 126: ......
Страница 138: ......
Страница 146: ......
Страница 218: ......
Страница 236: ......
Страница 356: ......
Страница 374: ......
Страница 422: ......
Страница 496: ......
Страница 572: ......
Страница 654: ......
Страница 700: ......
Страница 726: ......
Страница 784: ......
Страница 816: ......
Страница 839: ...Network Address Translation Overview How NAT Works Cisco ASR 5000 Series Product Overview OL 22938 02 ...
Страница 841: ...Network Address Translation Overview How NAT Works Cisco ASR 5000 Series Product Overview OL 22938 02 ...
Страница 844: ......
Страница 906: ......
Страница 926: ......
Страница 942: ......
Страница 943: ...Cisco ASR 5000 Series Product Overview OL 22938 02 Chapter 30 Technical Specifications ...
Страница 966: ......
Страница 967: ...Cisco ASR 5000 Series Product Overview OL 22938 02 Chapter 31 Safety Electrical and Environmental Certifications ...
Страница 972: ......