Cisco ASR 5000 series Product Overview page 492

▀ How the PDG/TTG Works
Step Description
2. The TTG processes the IKE_SA_INIT Request for the appropriate PDG service (bound by the destination IP address in the
IKEv2 INIT Request). The TTG responds with an IKE_SA_INIT Response with the SA, KE, and Nr payloads, and NAT-
Detection Notify payloads.
The TTG will start the IKEv2 setup timer when sending the IKE_SA_INIT Response. With the IKEv2 SA INIT exchanges,
the WLAN UE negotiates cryptographic algorithms, exchanges the nonce, and performs a Diffie-Hellman exchange.
3. Upon receiving a successful IKE_SA_INIT Response from the TTG, the UE sends an IKE_ AUTH Request for the first
EAP-AKA authentication.
The UE also includes an IDi payload, which contains the NAI, SA, TSi, TSr, CP (requesting an IP address and DNS
address) payloads. The IDr payload is the requested W-APN. The UE does not include AUTH payload to indicate that it
will use the EAP method. The NAI can either be the IMSI or a pseudonym.
4. Upon receiving the IKE_AUTH Request from UE, the TTG sends an Authentication Request (RADIUS Access Request or
DER) message to the AAA server. The TTG sends the Authentication Request message with an EAP (Identity Response)
AVP to the AAA server, including the user identity and W-APN. The W-APN information is included in the called-station-
id RADIUS attribute in all Access-Request messages towards the AAA server. The TTG includes a parameter indicating
that the authentication is being performed for tunnel establishment. This helps the AAA server to distinguish between
authentications for WLAN access and authentications for tunnel setup.
The TTG starts the session setup timer upon receiving the IKE_AUTH Request from the UE. Note that the TTG sends the
W-APN received in the IDr payload in IKEv2 messages as is to the AAA server. This helps the AAA server to look up the
authorization database based on the W-APN name. When sending messages to the HLR (or HSS), the AAA server maps
the W-APN name into the real APN configured in the HLR (or HSS).
5. The AAA server initiates the authentication challenge. The user identity is not requested again, as in a normal
authentication process, because there is the certainty that the user identity received in the EAP Identity Response message
has not been modified or replaced by any intermediate node. This is because the user identity is received via an IKEv2
secure tunnel which can only be decrypted and authenticated by the end points (the TTG and the WLAN UE). The TTG
receives a DEA with a Result-Code AVP specifying to continue EAP authentication. For RADIUS, this is an access
challenge message. The TTG accepts the EAP-Payload AVP contents.
6. The TTG sends an IKE_ AUTH Response back to the UE in the EAP payload. Depending upon the configuration, the TTG
can include IDr (TTG-ID) and CERT payloads. The TTG allows IDr and CERT configurations in the PDG service. If the
PDG service is configured to do so, the TTG can also include an AUTH payload in the IKE_AUTH Response. The UE
receives the IKE_AUTH Response from TTG.
7. Upon receiving the IKE_AUTH Response from the TTG, the UE processes the exchange and sends a new IKE_AUTH
Request with an EAP payload. The TTG receives the new IKE_AUTH Request from the UE.
8. The TTG sends a DER (or RADIUS AR) message to the AAA server. This DER message contains the EAP-Payload AVP
with an EAP-AKA challenge or EAP-SIM challenge response and challenge received from the UE.
▄ Cisco ASR 5000 Series Product Overview
PDG/TTG Overview
OL-22938-02