Terminating IP Registrations

This chapter discusses how the Cisco Mobile Wireless Home Agent terminates IP registrations and how to configure the Home Agent to perform this function.

Mobile IPv4 Registration Revocation

Basic Mobile IP resource revocation is an IS-835-C initiative that defines the methods by which a mobility agent (one that provides Mobile IP services to a mobile node) can notify the other mobility agent of the termination of a registration due to administrative reasons or MIP handoff.

This feature is similar to the Cisco MobileIP Bind Update feature. When a mobile changes its point of attachment (FA), or needs to terminate the session administratively, the HA sends a registration revocation message to the old FA. The old FA tears down the session and sends a registration revocation acknowledgement message to the HA. Additionally, if the PDSN/FA needs to terminate the session administratively, the FA sends a registration revocation message to the HA. The HA deletes the binding for the mobile, and sends a registration revocation acknowledgement to FA.

An HA configured to support registration revocation in Mobile IPv4 includes a revocation support extension in all MIP RRP for the associated MIP RRQ from the PDSN that contained a valid registration revocation extension. A registration for which the HA received a revocation support extension, and responded with a subsequent revocation support extension, is considered revocable by the HA.

The following sample call flow illustrates Mobile IP Resource Revocation (Registration phase):

Step 2

The PDSN/FA has been configured to advertise MIPv4 registration revocation support. The PDSN/FA sends advertisement with MIPv4 Registration revocation support bit "X" set.

Step 3

The PDSN/FA receives MIP RRQ from MN, includes STC attribute set to 2 in access-request during FA-CHAP. While forwarding the RRQ to the HA, the revocation support extension is appended after the MHAE. The I-bit in the revocation support extension will be set to 1 indicating that the MS would get an explicit notification on revocation of the binding whenever necessary.

Step 4

The HA, upon receiving the MIP RRQ containing a revocation extension, will send back the MIP RRP including a revocation support extension and setting the I-bit equal to the value received in the MIP RRQ. In case of HA-CHAP (MN-AAA authentication), the STC attribute, with a value of 2, will be included in the access-request sent to AAA.

Step 5

The PDSN receives the MIP RRP containing a revocation support extension, and the data flow is considered to be revocable.

The following sample call flow illustrates Mobile IP Resource Revocation (HA initiated):

Step 2

PDSN/FA (1) appends a registration revocation support extension to the mobile registration request and forwards it to the HA.

Step 3

In response, the HA appends the registration revocation support extension to a registration reply, and send it to PDSN/FA (1).

Step 4

PDSN-to-PDSN handoff occurs, and the Mobile re-starts a mobile IP data session with PDSN/FA (2).

Step 7

The HA sends a Mobile IP resource revocation message to the PDSN/FA (1).

Step 8

PDSN/FA (1) sends a Mobile IP resource revocation acknowledgement to the HA, and terminates the mobile IP data session for the mobile.

The following sample call flow illustrates a Mobile IP Resource Revocation (FA initiated revocation):

Step 2

The PDSN/FA appends the registration revocation support extension to the mobile registration request, and forwards it to the HA.

Step 3

In response, the HA appends the registration revocation support extension to a registration reply, and sends it to the PDSN/FA.

Step 4

Some event occurs in the PDSN/FA, and the PDSN/FA decides to close the session.

Step 6

The HA sends a Mobile IP resource revocation acknowledgement to the HA. The HA clears the binding and the PDSN/FA clears the session.

I-bit Support

During the registration revocation phase, the I (Inform) bit notifies the mobile node (MN) of the revoked data service in cases where the mobile node has more than one MobileIP flow. If, during the registration phase, this bit is set to 1 by a mobility agent in the revocation support extension in the RRQ/RRP, it indicates that the agent supports the use of the "I" bit in revocation messages.

In the current implementation, if MobileIP RRQ is received with I bit set in the revocation support extension, then the HA also sets the I-bit to 1, and the I-bit can be used during the revocation phase. When the HA initiates revocation (and if the I bit was negotiated), it sets the I bit to 1 in the Revocation message if a binding is administratively released, and sets it to 0 if a inter- PDSN handoff is detected by the HA. When revocation is initiated by the PDSN, and the revocation message has I-bit set to 1, then the HA also sets the I-bit to 1 in the revocation ACK message.

Configuring MIPv4 Registration Revocation

To enable MIPv4 Registration Revocation feature on HA, perform the following tasks in global configuration mode:


	Command	Purpose
Step 1	Router(config)# ip mobile home-agent revocation	Enables support for MIPv4 Registration Revocation on the HA.
Step 2	Router(config)# ip mobile home-agent revocation timeout 5 retransmit 6	(Optional) Sets the retransmit count and timeout value for revocation messages.

Mobile IPv4 Resource Revocation Restrictions

The following list identifies the restrictions for Mobile IPv4 Resource Revocation feature for the current release:

•

The STC attribute received in access-accept during HA-CHAP (MN-AAA authentication) is ignored, and the feature configuration on the Home Agent will take precedence.

•

The Revocation message, Revocation ACK message, and Revocation support extension (not protected by either FHAE or IPSec) will not be discarded, but will be processed. We recommend that you configure an FA-HA security association on the Home Agent, or that an IPSec tunnel exists between the FA and the HA.

•

Resource Revocation and Bind Update cannot be enabled simultaneously. Both are mutually exclusive of each other.

•

The Home Agent MIB is not updated with the Registration revocation information.

Simultaneous Bindings

•

When multiple flows are established for the same NAI, a different IP address is assigned to each flow. Therefore, simultaneous binding is not required because its function is to maintain more than one flow to the same IP address.

Radius Disconnect

Radius Disconnect (or Packet of Disconnect (PoD)) is a mechanism that allows the RADIUS server to send a Radius Disconnect Message to the HA to release resources. Resources may be released for administrative purposes, and are mainly Mobile IP bindings on the HA.

Support for Radius Disconnect on the Cisco Home Agent conforms with RFC 3576. The HA communicates its resource management capabilities to the Home AAA server in an Access Request message that is sent for authentication/authorization procedure by including a 3GPP2 Vendor Specific Session Termination Capability (STC) VSA. The value communicated in the STC VSA is obtained from configuration. The HA includes a NAS-Identifier attribute that contains its Fully Qualified Domain Name (FQDN) in the Access Request when the radius-server attribute 32 include-in-access-req format command is configured.

Step 2

If the Framed-IP-Address attribute is received in the Disconnect Request, terminate the binding with corresponding to the address.

Step 3

If Framed-IP-Address is not received in the Disconnect Request, terminate all bindings for the user (NAI).

Configuring RADIUS Disconnect Client

Perform the following tasks to configure RADIUS disconnect for clients and the associated keys:


Command	Purpose
Router(config)# aaa pod server [clients ipaddr1 [ipaddr2] [ipaddr3] [ipaddr4]] [port port number] [auth-type {any \| all \| session-key}] [ignore session-key] {ignore server-key \| server-key string}	Required to enable Packet of Disconnect (POD) services at AAA subsystem level in Cisco IOS. Enables inbound user sessions to be disconnected when specific session attributes are presented.
Router(config)#ip mobile radius disconnect	Enables the functionality of processing RADIUS disconnect messages on the HA.
Router(config)#radius-server attribute 32 include-in-access-req	This command is required to include the optional NAS-Identifier attribute in Access-Request to the home AAA.
Router# debug aaa pod	Displays debug information for Radius Disconnect message processing at AAA subsystem level.

Restrictions for RADIUS Disconnect

Support for Binding Synch and Deletion

In the current implementation of Home Agent redundancy, bindings that are deleted on the active HA in active-standby mode (or on any peer in a peer to peer mode), due to receipt of a revocation message or a RADIUS disconnect message, are not synched to the standby HA or the peer HA. Also, the additional extensions and attributes for Revocation and Radius Disconnect are not relayed to the standby. Registration Revocation and Radius Disconnect (using the clear ip mobile binding command) are supported with HA redundancy. The following list identifies the benefits of this support:

•

Bindings on the active HA that are deleted by trigger (for example, receipt of a Revocation message, or a Radius Disconnect message) will be synched to the Standby HA.

•

Bindings that are deleted due to commands that unconfigure (for example, ip mobile host, etc.), will not be synched.

•

Bindings that are deleted on the standby HA will not be synched to the active in case of active-standby mode.

•

Additional extensions (Revocation Support Extension) and attributes (STC attribute) for Revocation and Radius Disconnect will be relayed to the standby HA.

•

Bindings that are deleted on any of the peers by trigger (for instance, a receipt of Revocation message or a Radius Disconnect message), will be synched to the other peer.

•

Bindings that are deleted due to commands that unconfigure (for example, ip mobile host, etc.) will not be synched.

•

Additional extensions (Revocation Support Extension) and attributes (STC attribute) for Revocation and Radius Disconnect will be relayed to the peer HA.

Binding Synch

The following call flow shows the sequences and message exchange among various network entities used to bring up the Mobile IP flow and synch the information to the standby Home Agent.

The PDSN receives a MIP RRQ from the MN and authenticates the MN by FA-CHAP. The STC VSA with the appropriate value (2 or 3) is included in the Access-request message to the AAA. After successful authentication, the PDSN forwards the RRQ to the HA and includes the revocation support extension after the MHAE.

The HA, upon receiving the MIP RRQ containing a revocation extension, includes a revocation support extension in the MIP RRP sent back to PDSN. During HA-CHAP to authenticate the MS, the STC VSA with appropriate value (2 or 3) is included in the Access-request message sent to the AAA. The binding at the HA is now considered revocable.

The PDSN receives the MIP RRP containing a revocation extension. The binding at the PDSN is revocable as the MIP RRP contained a revocation extension

Since the Home Agent is configured in redundant mode, a Bind Update message is sent to the standby with the additional information (revocation support extension and STC NVSE).

The standby Home Agent regenerates the binding using the information received in the Bind Update message, and sends back a Bind Update Ack message with code "accept" on successful creation of a binding on the standby.

Binding Deletion

As part of this support, two new messages —"Bind Delete Request" and "Bind Delete Ack"—are introduced that are exchanged between the redundant HAs when a binding is deleted. The following sample call flow illustrates when a binding gets deleted on the active Home Agent due to receipt of Revocation message, and the deletion of binding is synched to the standby Home Agent.

The MS originates a call, a PPP session is up and a Mobile IP flow is setup on the active Home Agent with Registration revocation capability enabled and negotiated. The same is synched to the standby Home Agent.

When a user issues administrative clear command, the PDSN sends a Revocation message to the active Home Agent, deletes the visitor entry, and associated resources are cleared.

The active HA, upon receiving the MIP Revocation message, identifies the binding to be deleted. On identifying the binding, a Bind Delete Request message is sent out to the standby HA.

After a Bind Delete Request is sent out, the active HA cleans up the resources associated with the binding for the Revocation message that arrived, and sends back a MIP Revocation Ack message to the PDSN.

The standby HA, on receipt of Bind Delete Request message, identifies the binding to be deleted, and sends back a Bind Delete Ack message with code as "accept".

If a Bind Delete Ack message is not received within a configured time on the active HA, then a Bind Delete Request message is retransmitted. This process is repeated for the max retransmit count.

During binding synch, the extensions (Revocation Support Extension) and attributes for Revocation and Radius Disconnect (STC attribute) are synched from active HA to the standby. In scenarios when the active HA goes down and the standby becomes active, the now active HA is capable of deleting bindings on receipt of a RADIUS Disconnect message. For revocation, the bindings on the now active HA are revocable, and the HA can now send and receive revocation messages.

Table Of Contents