Cisco Prime Access Registrar 6.0.1 User Guide

Using WiMAX in Cisco Prime Access Registrar

Cisco Prime Access Registrar (Prime Access Registrar) supports Worldwide Interoperability for Microwave Access (WiMAX) technology. This feature support in Prime Access Registrar complies with the WiMAX forum NWG_R1_V1.3.1-Stage-3 specifications.

This chapter contains the following sections:

•WiMAX - An Overview

•WiMAX in Cisco Prime Access Registrar

WiMAX - An Overview

WiMAX is a standards-based wireless technology that offers high throughput broadband connections over long distances. WiMAX can be used for a number of applications, including "last mile" broadband connections, fixed and mobile cellular service, hotspots and cellular backhaul, and high-speed enterprise connectivity for business. WiMAX is based on the IEEE 802.16d standard for fixed wireless, and the 802.16e standard for mobile wireless. This standard is appealing to customers because it allows mass production of chipsets that reduce CPE costs, ensures multi-vendor interoperability, and reduces investment risk for operators.

The architectural framework of a WiMAX network consists of the Access Service Network (ASN), the Connectivity Service Network (CSN), and a AAA Server. An Access Service Network is a set of network functions that provide radio access to a WiMAX subscriber. The ASN typically provides functions such as network discovery and selection, connectivity service between the MSS and CSN, Radio Resource Management, Multicast and Broadcast Control, Intra-ASN mobility, Paging, and Location Management. The WiMAX architecture consists of both mobile and fixed subscribers, as well as the ASN and CSN.

A CSN is defined as a set of network functions that provide IP connectivity services to the WiMAX subscribers. CSN might comprise network elements such as Routers, Home Agent, AAA proxy/servers, user databases, Policy Servers, Content Service Gateways, Service Selection Gateways, and interworking gateway devices.

The Access Service Network is connected to a home network HCSN (Home Connectivity Service Network) via at least one visited network (Visited Connectivity Service Network VCSN) or intermediate network.

The Visited CSN plays the role of a AAA proxy. During all AAA interaction the VCSN AAA server acts as a RADIUS proxy transporting RADIUS packets between the ASN and the HCSN.

Figure 10-1 describes the network reference model of a typical WiMAX scenario.

Figure 10-1 WiMAX Network Reference Model

WiMAX in Cisco Prime Access Registrar

Prime Access Registrar uses the Extensible Authentication Protocol (EAP) to enable the WiMAX feature. It also caches the IP attributes and Mobility Keys that are generated during network access authentication. To enable caching of the WiMAX attributes, you must configure the respective resource managers. See Configuring the Resource Manager for WiMAX, for information on configuring resource manager. Figure 10-2 shows the WiMAX workflow in Prime Access Registrar.

Figure 10-2 WiMAX Workflow

The WiMAX workflow in Prime Access Registrar includes:

•Direct interaction between the ASN GW and Prime Access Registrar

•Interaction between the ASN GW and Prime Access Registrar through the HA

This section contains the following topics:

•Direct Interaction Between the ASN GW and Cisco Prime Access Registrar

•Interaction Between ASN GW and Cisco Prime Access Registrar Through HA

•Prepaid and Hot-Lining

Direct Interaction Between the ASN GW and Cisco Prime Access Registrar

When the mobile node (MN) sends a RADIUS request to the ASN GW, it forwards this request to the CSN. If it is VCSN, the VAAA proxies the request with Visited HA address in the Access Request to HAAA. The HAAA initiates an authentication using the EAP serivce, for example, eap-ttls. The initial Access-Request containing the WiMAX capability and NAS-Port-Type (Type:61) attributes indicate that the specified flow is for a WiMAX request from ASN GW. Prime Access Registrar redirects this request to the WiMAX service that you configure. The WiMAX service redirects the request to the EAP-based Wimax-Authentication-Service for authentication. Upon successful authentication, the WiMAX service redirects the request to Wimax-Session-Manager to allocate the home agent. Subsequently, Prime Access Registrar generates the appropriate keys based on the Extended Master Session Key (EMSK) and records the generated keys in the session cache resource manager as configured, before sending Access-Accept to the ASN GW.

If there is no VCSN, then the HAAA will send the Access-Accept to ASNGW. Otherwise, the HAAA sends the Access-Accept to VAAA. The VAAA then generates the visited HA-RK Key with SPI and Lifetime and sends the access-accept to ASNGW.

The authentication methods followed by Prime Access Registrar are:

•User-only

•Device-only

•Single-EAP Device or User authentication

Note Prime Access Registrar 4.2 does not support Double-EAP authentication.

Prime Access Registrar uses the following values to identify the service-type:

•Framed—for initial authentication

•Authenticate-Only—for reauthentication

•Authorize-Only—for prepaid request

Note Prepaid attributes can also be sent in the initial authentication.

The attributes contained in this flow are listed in Table 10-1. For detailed information on the attributes refer to the WiMAX forum NWG_R1_V1.3.1-Stage-3 specifications document.

Prime Access Registrar generates a few more attributes upon sucessfull authentication. These attributes are described in Table 10-2.

Note A policy engine can parse the NAI decoration and conclude the type of authentication method for the incoming access-request for passing on to WiMAX service.

Interaction Between ASN GW and Cisco Prime Access Registrar Through HA

After Prime Access Registrar returns the Access-Accept to the ASN GW, the mobile node, which initially sent the request, sends a registration request to the ASN GW. The ASN GW receives this request and sends an Access-Request to the HA. A Query-Request will be sent to the Prime Access Registrar by HA to receive the security context for authenticating the FA.

Prime Access Registrar identifies the request as HA query request, if:

•the WiMAX mobility attribute is present

•the NAS-Port-Type attribute is absent

Prime Access Registrar checks for a valid session in the session cache based on NAI and sends an Access-Accept to the HA.

Note Prime Access Registrar responds with the correct keys back to the HA based on the NAI in User-Name attribute. Prime Access Registrar returns an Access-Reject if it does not find a valid session for the NAI during the user authentication and authorization or if there are other errors.

Prepaid and Hot-Lining

Prime Access Registrar supports prepaid and hot-lining flows for WiMAX. These are supported by the existing mechanisms.

Configuring WiMAX in Cisco Prime Access Registrar

A new service type named wimax will be used for the WiMAX feature in Prime Access Registrar. aregcmd command is used to configure WiMAX in Prime Access Registrar. WiMAX service contains—Session Manager (with a session-cache resource manager and HA resource manager), Query Service that is connected to the session manager configured for this service, and Prepaid Service, which are required to connect all the flows appearing in Prime Access Registrar for WiMAX. This service will be used as a container for the new key generation modules and the existing modules such as EAP services.

Configuring WiMAX in Prime Access Registrar involves configuration of:

•Resource Manager for WiMAX

•Session Manager for WiMAX

•Query Service for WiMAX

•WiMAX properties

This section contains the following topics:

•Configuring the Resource Manager for WiMAX

•Configuring the Session Manager for WiMAX

•Configuring the Query Service for WiMAX

•Configuring WiMAX

•Configuring WiMAX

Configuring the Resource Manager for WiMAX

You must configure the following two Resource Managers:

•HA (home-agent or home-agent-ipv6)

•HA Cache (session-cache)

The HA Resource Manager must contain the IP ranges covering all the HA IP addresses that are to be assigned in round-robin. You must configure the HA Cache Resource Manager to cache the mobility keys (Table 10-3).

Note The HA Resource Manager allocates the IP addresses to the HA. If you do not configure the HA Resource Manager properly, Prime Access Registrar will not generate some of the keys, which result in an Access-Reject by the NAS.

The following shows the sample configuration for HA:

[ /Radius/ResourceManagers/HA ] 
Name = HA 
Description = 
Type = home-agent 
Home-Agent-IPAddresses/ 
Entries 1 to 1 from 1 total entries 
Current filter: <all> 
209.165.200.225-209.165.200.254/

The following shows the sample configuration for HA Cache in HAAA:

[ /Radius/ResourceManagers/HA-Cache ]

Name = HA-Cache

Description =

Type = session-cache

OverwriteAttributes = TRUE

QueryKey = User-Name

PendingRemovalDelay = 10

AttributesToBeCached/

        1. WiMax-Session-ID

        2. hHA-RK-Key

        3. hHA-RK-SPI

        4. MN-hHA-MIP4-Key

        5. hHA-RK-Lifetime

        6. MIP-RK

The following shows the sample configuration for HA Cache in VAAA:

[ /Radius/ResourceManagers/HA-Cache ]

Name = HA-Cache

Description =

Type = session-cache

OverwriteAttributes = TRUE

QueryKey = User-Name

PendingRemovalDelay = 10

AttributesToBeCached/

        1. vHA-RK-Key

        2. vHA-RK-SPI

        3. MN-vHA-MIP4-Key

        4. vHA-RK-Lifetime

When the OverwriteAttributes value is set as TRUE, the newly generated mobility keys will be cached with the session record. By default, the value is FALSE.

The HA-RK-Lifetime attribute type must be of type STRING instead of UINT32 under /Radius//advanced/attribute\ dictionary/vendor-Specific/vendors/wimAX/subAttribute\ Dictionary.

Note For generating RRQ-MN-HA key, we must configure MIP-RK in the AttributesToBeCached list.

Configuring the Session Manager for WiMAX

Before configuring WiMAX service, you must configure a session manager for WiMAX with a HA and session cache resource manager. The following shows an example configuration of a session manager with HA and session cache resource managers.

[ /Radius/SessionManagers/session-mgr-2 ]

    Name = session-mgr-2

    Description =

    IncomingScript =

    OutgoingScript =

    AllowAccountingStartToCreateSession = FALSE

    SessionTimeOut =

    PhantomSessionTimeOut =

    SessionKey =

    ResourceManagers/

    1. HA-Cache

    2. HA

Note If a default session manager is configured with the same key as that of the WiMAX session manager, the incoming WiMAX request will fail.

Configuring the Query Service for WiMAX

When you configure a query service for the WiMAX service in Prime Access Registrar, you must refer it to the WiMAX Session Manager that you created. While configuring WiMAX, you must refer the WiMAX-Query-Service parameter to a valid Query Service.

You must configure the Query key as the User-Name attribute, which contains the NAI. You must also configure the query service to return all the relevant mobility keys as described in Table 10-5.

The following shows a sample configuration for a WiMAX Query Service:

[../haQueryService ] 
Name = haQueryService 
Description = 
Type = radius-query 
IncomingScript~ = 
OutgoingScript~ = 
SessionManagersToBeQueried/ 
1. session-mgr-2 
AttributesToBeReturned/ 
1. WiMax-Session-ID 
2. HA-RK-Key

Note If AttributesToBeReturned is not configured, all the cached attributes will be returned.

Configuring WiMAX

When you configure the WiMAX service under /Radius/Services, you must set its type to wimax and provide the following configuration options:

[ //localhost/Radius/Services/wimax ] 
Name = WiMAX 
Description = 
Type = WiMAX 
IncomingScript~ = 
OutgoingScript~ = 
OutagePolicy~ = RejectAll 
OutageScript~ =

HA-RK-Key = cisco112

HA-RK-LifeTime = 60 
WiMAX-Authentication-Service = None 
WiMAX-Session-Manager = None 
WiMAX-Query-Service = None 
WiMAX-Prepaid-Service = None

Allow-HAAA-To-Include-Keys = TRUE

Require-MSK = False

The syntax to generate the a WiMAX request from radclient is

simple_wimax_asn_test bob(username) bob(password)

WiMAX - OMA-DM Provisioning Support with BEK Key

In addition to WiMax subscriber authentication, the Prime Access Registrar generates and caches the Bootstrap Encryption Key (BEK) when it receives the authentication request from the unprovisioned WiMax subscriber/device. Prime Access Registrar can identify the unprovisioned device either by looking the special pattern in Access-Request or by performing explicit database lookup.

The BEK key derived from EMSK is calculated as follows:

BEK = the 16 most significant (leftmost) octets of HMAC-SHA256(EMSK, "bek@wimaxforum.org").

When Prime Access Registrar receives the accounting start packet for the unprovisioned device,

1. IP, MAC address, and BEK of the unprovisioned device notifies the OMA-DM server to initiate the provisioning.

2. Prime Access Registrar maintains the IP address to MAC address association using web-service until it receives the provisioning complete message from the OMA-DM server.

The Backend Portal queries the Prime Access Registrar web-service for this unprovisioned device MAC address by giving the device IP address and also the OMA-DM server request the Prime Access Registrar web-service to validate the MAC to IP address association

The communication between Prime Access Registrar and OMA-DM/Portal server is through web-service by using SOAP over HTTPS. It is assumed that the OMA-DM server (or a mediation function) will have a web-service using which AR can communicate.

Configuring the WiMax-Provisioning

To configure WiMax provisioning:

Step 1 Configure a script object, such as wimax-provision.

[ //localhost/Radius/Scripts/wimax-provision ]

Name = wimax-provision

Description =

Language = rex

--> set FileName to 'libProvisioning.so'

set FileName /cisco-ar/scripts/radius/rex/libProvisioning.so

--> set EntryPoint 'ProvisionedDeviceLookup'

set EntryPoint ProvisionedDeviceLookup

--> set InitEntryPoint 'InitializeProvisioning'

set InitEntryPoint InitializeProvisioning

--> set InitEntryPointArgs to 'ldap:wimax'

set InitEntryPointArgs ldap:wimax

ls

[ //localhost/Radius/Scripts/wimax-provision ]

Name = wimax-provision

Description =

Language = rex

Filename = /cisco-ar/scripts/radius/rex/libProvisioning.so

EntryPoint = ProvisionedDeviceLookup

InitEntryPoint = InitializeProvisioning

InitEntryPointArgs = ldap:wimax

The file libProvisioning.so is come up with Prime Access Registrar kit. You have to copy it into /cisco-ar/scripts/radius/rex path. Entrypoint ProvisionedDeviceLookup literally looks up a datastore to check if the user is provisioned. InitEntryPoint 'InitializeProvisioning' takes care of all initialization work for entry point. InitEntryPointArgs 'ldap-wimax' says the user look up to be performed against ldap datasotre. Oracle datastore can also be used wherein you have to give this property to 'oracle:wimax'.

Step 2 Configure the configured script object to the server's incoming scripting point.

set IncomingScript wimax-provsion

ls

[ //localhost/Radius ]

Name = Radius

Description =

Version = 5.0.0

IncomingScript~ = provision

OutgoingScript~ =

Step 3 Webclient setup

Create a script object which calls the Prime Access Registrar's wimax-provisioing webservice.

[ //localhost/Radius/Scripts/WebServicecall ]

Name = WebServicecall

Description =

Language = rex

Filename = libProvisioning.so

EntryPoint = WebServiceCall

InitEntryPoint =

InitEntryPointArgs =

Entry point should be set to WebServiceCall.

Step 4 Save the configuration:

save

Step 5 Reload the configuration:

reload

WiMax Lawful Interception (LI) Support in Prime Access Registrar

Prime Access Registrar provides support for Intercept Access Point (IAP) for receiving the intercept/monitoring request for the subscriber whose "Access Associated" Communications Identifying Information (AA CmII) is to be intercepted and delivered to a Law Interception Server (LIS).

Prime Access Registrar supports the following intercept request from LIS:

•ProvisionTarget - To start monitoring the target user

•DeprovisionTarget - To stop monitoring the target user

•LinkUpdate - To query the target user in monitored list

•ListTarget - To list all the users that are currently being monitored

Initiating Monitoring Process

When the "ProvisionTarget" request is received from LIS, Prime Access Registrar adds the respective user in monitoring list and starts monitoring the user events.

Table 10-7 lists the events of the target user that are reported to LIS:

Note The attribute with (M) represents mandatory, (O) represents optional, (C) represents conditionally available.

Stopping Monitoring Process

On receiving the DeprovisionTarget request from LIS, the target user is removed from the monitoring list.

Querying Target User Events

On receiving the LinkUpdate request on target user from LIS, the target user details are checked in the monitoring list and message is sent to LIS as listed below:

•If the specified user is not currently being monitored, a reply with reason-code indicating that the user is currently not targeted is sent.

•If the specified user is currently being targeted and is not logged into the network, a reply with status stating that the user is "inactive" in the network is sent.

•If the specified user is currently being targeted and is logged into the network, a reply with the following attributes is sent:

–Case Identity (M)

–IAP System Identity (M)

–Time Stamp (M)

–Subscriber Identity (M)

–Access Method (C)

–Network Access Node Identity (C)

–IP address (C)

–Access Session Identity (M)

–Access Session Characteristics (C)

–Location information (C)

–Protocol Signal (O)

Viewing Monitored Users

On receiving the ListTarget request from LIS, a list of users that are currently being monitored are sent to LIS. The reply will contain a surveillance-target-count attribute indicating the count of the number of users being targeted and multiple instances of surveillance-target-identifier attribute having the real identifiers.

Each request from the LIS contains a transaction-id which is copied on to the reply from Prime Access Registrar. For each request type there is an appropriate response type with appropriate return data. They are as follows:

•ProvisionTargetResult - an acknowledgement for the ProvisionTarget request with the same transaction id

•DeprovisionTargetResult - an acknowledgement for the DeprovisionTarget request with the same transaction id

•LinkUpdateResult - for LinkUpdate, see Querying Target User Events

•ListTargetResult - for ListTarget, see Viewing Monitored Users

Configuring WiMax-Lawful Intercept

Two scripts which are LawfulIntercept and RexLiScript are to be configured to run LawfulIntercept service in Prime Access Registrar. LawfulIntercept script should be configured in the server's incoming scripting point which is used to check the provisioned status of the user in the incoming access request. If the user is provisioned in the data store, Virtual-Server-Outgoing-Script will be executed after the server's outgoingscripting point.

InitEntryPoint of LawfulIntercept script writes the targeted list of users to a file while the server is stopping and reads the targeted users back to data store while the server is starting.

RexLiScript is configured in Virtual-Server-Outgoing-Script that sends events of the provisioned users to the LI service client.

Configuring the WiMax-Lawful Intercept

To configure WiMax-Lawful Intercept:

Step 1 Create the RexLiScript script object that will be set in Virtual-Server-Outgoing-Script point.

[ //localhost/Radius/Scripts/virtual ]

Name = virtual

Description =

Language = rex

Filename = libLiScript.so

EntryPoint = RexLiScript

InitEntryPoint = InitRexLiScript

InitEntryPointArgs =

Step 2 Create the LawfulIntercept script object.

[ //localhost/Radius/Scripts/LiScript ]

Name = LiScript

Description =

Language = Rex

Filename = libLiScript.so

EntryPoint = LawfulIntercept

InitEntryPoint = RexInitialize

InitEntryPointArgs = virtual

Step 3 set LawfulIntercept script object to ServerIncoming scripting point;

[ //localhost/Radius ]

IncomingScript~ = LiScript

Note The file 'libLiScript.so' comes up with Prime Access Registrar kit. You have to copy it into /cisco-ar/scripts/radius/rex/ path.

Step 4 Save the configuration:

save

Step 5 Reload the configuration:

reload