Internet Engineering Task Force S. F. Foo INTERNET DRAFT K. C. Chua National University of Singapore November 1998 Regional Aware Foreign Agent (RAFA) for Fast Local Handoffs Status of This Memo This document is a submission to the MobileIP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@smallworks.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document proposes an extension to the Mobile IP base protocol. The purpose of this extension is to solve the distant registrations, handoff latency, and key management problems among mobility agents. It provides a easy and robust solution for secure ubiquitous deployment of IP mobility while still maintaining interoperability with the base protocol. Chua and Foo Expires April 1999 [Page i] Internet Draft November 1998 Contents Abstract ............................................................ i 1. Introduction ..................................................... 1 1.1. Requirements ................................................ 2 1.2. Architectural Entities ...................................... 2 1.3. Terminology ................................................. 3 2. Protocol Overview ................................................ 3 2.1. Network Topology ............................................ 4 2.2. Agent Discovery ............................................. 4 2.3. Registration Process ........................................ 4 2.3.1 Processing of Registration Packets at LFA ............. 5 2.3.2 Processing of Registration Packets at RAFA ............ 5 2.4. Typical Handoff Scenarios ................................... 5 2.4.1 MN handoffs from FA/HA to LFA ......................... 6 2.4.2 MN handoffs from LFA to FA/HA ......................... 6 2.4.3 MN handoffs from LFA to LFA ........................... 7 2.5. Datagram Routing ............................................ 7 2.6. Interoperability with the Base Protocol ..................... 8 2.7. Key Management/Distribution Scheme .......................... 8 3. Local Foreign Agent Considerations ............................... 9 3.1. Configuration and Registration Tables ....................... 9 3.2. Receiving Registration Request .............................. 9 3.3. Receiving Registration Reply ................................ 10 3.4. Routing of Datagrams ........................................ 10 4. Regional Aware Foreign Agent Considerations ...................... 10 4.1. Configuration and Registration Tables ....................... 11 4.2. Receiving Registration Request .............................. 11 4.3. Receiving Registration Reply ............................... 12 4.4. Routing of Datagrams ........................................ 12 4.5. Access Control (Authorization)/ Non-Repudiation/ Billing for Foreign Network ............................................. 12 4.6. Solving Inherent Functionality Problem of Mobile IP ......... 13 4.7. Simultaneous Bindings ....................................... 14 4.8. Autonomous Operation ........................................ 14 4.9. Multicast Datagram Routing Using the RAFA Model ............. 14 4.10.Other Capabilities .......................................... 15 4.11.Load Balancing .............................................. 15 5. Message Format and Extension ..................................... 15 5.1. De-registration Request ..................................... 15 5.2. Get Shared Key Notification Extension ....................... 16 5.3. RAFA-LFA Authentication Extension ........................... 17 5.4. HA-RAFA Authentication Extension ............................ 18 Chua and Foo Expires April 1999 [Page ii] Internet Draft November 1998 6. Fast Handoff Considerations ...................................... 18 6.1. LFA Considerations .......................................... 19 6.1.1 Sending Agent Advertisement ........................... 19 6.2. MN Considerations ........................................... 19 6.2.1 Receiving Agent Advertisement ......................... 20 6.3. RAFA Considerations ......................................... 20 Reference ........................................................... 20 Acknowledgement ..................................................... 21 Authors's Address ................................................... 21 Chua and Foo Expires April 1999 [Page iii] Internet Draft November 1998 1. Introduction The base Mobile-IP scheme [1] provides a scalable mechanism for node mobility within the Internet. However, there still exist some problems. Firstly, it requires that a mobile node's home network be notified of every change of location. As Perkins [2] addresses in the hierarchical foreign agent model and M.C.Chuah [3] in the DREMIP model, in cases where the home agent is far away, it may become too expensive or even impossible to complete these frequent registrations. Furthermore, it also adds more traffic to the wide-area portion of the internetwork. Thus the current Mobile IP does not extend well to large numbers of mobile nodes moving frequently between small wireless subnets. Secondly, the key management between the home and foreign agents, and between the foreign agents and the mobile node is still a problem. Mobile IP currently requires that registration messages between HA and its MN be authenticated. Registration messages between an HA and an FA, or between an MN and an FA, may be optionally authenticated. As more of the networks MNs visit become wireless nets which are subject to eavesdropping and unable to control actual attachment via physical controls, authentication between FAs and HAs and between FAs and MNs become mandatory for Mobile IP to succeed commercially. Thirdly, the Mobile-IP standard specifies a general handoff protocol for both wired and wireless network. It incurs an intrinsic loss of data up to a few seconds during handoff even in overlapping wireless subnets due to the fact that the mobile node will only register with a new agent if it fails to receive another advertisement from the current agent within the specified lifetime. This often results in degraded throughput which causes the handoff to be not as seamless. Thus, for mobile nodes moving frequently between small wireless subnets, performance of future IP applications such as IP telephony will be seriously affected. Fourthly, the base protocol does not require the mobile node to inform the former foreign agent of the movement of the mobile node when it moves from one foreign network to another. Thus, any correspondent node in the former foreign network will not be able to route datagrams to the mobile node until the registration lifetime of the binding has expired which may take hundreds of seconds. In this draft document, we propose a new regional aware foreign agent model as an extension to the base Mobile IP protocol to solve these problems. Our proposed extension provides advantages over existing base Mobile IP scheme while still maintaining interoperability. In particular, our proposed extension can a) reduce frequent distant registrations during handoffs. b) reduce the number of trusted entities in the network and hence enable us to minimise the key management problem. c) provide seamless handoff especially for small overlapping wireless cells to support multimedia data. Chua and Foo Expires April 1999 [Page 1] Internet Draft November 1998 d) provide access control (authorization) in a foreign network and prevent an illegal mobile node from stealing services in a routing domain, and other services which may be very important for service providers so that gradual adoption is possible and might help in a more widespread deployment of Mobile-IP. e) solve the inherent routing problem of the former foreign agent network as mentioned above when the MN moves to a new foreign agent network. Importantly, the above advantage can be obtained without requiring any changes in the base protocol implemented at the MN. 1.1. Requirements Any of the entities in the base protocol should be able to interoperate with the new and enhanced entities in this regional aware foreign agent (RAFA) model. 1.2. Architectural Entities The RAFA model introduces the following new architectural entities. Regional Aware Foreign Agent (RAFA) A host or router on a MN's visited routing domain which provides local registration service for an MN during handoff. It cooperates with the local foreign agents to allow the HA to have incomplete knowledgement of the MN's true point of attachment. It may be the tunnel endpoint of datagrams from the HA. It either extracts the datagrams and then tunnels datagrams to the local foreign agent for delivery to the MN or just acts as a simple router within a large routing domain. It therefore provides tunneling, registration and routing services to the MN while registered. Local Foreign Agent (LFA) It has the same functionality as the FA in the base protocol. It is a router on a MN's visited network which provides routing service to the MN while registered. It extracts and forwards datagrams to the MN. It has a security association with the regional aware foreign agent, and there is a slight modifications in the way it relays registration packets from the base protocol. Chua and Foo Expires April 1999 [Page 2] Internet Draft November 1998 1.3. Terminology In addition to all the terminology in the base mobile-IP specification, this document frequently uses the following terms: Anonymous Mobile Node A standard RFC2002 MN. However, with respect to the regional aware foreign agent, it is anonymous if the regional aware foreign agent does not have the information of the registration key shared between MN and HA. Registered Mobile Node A standard RFC2002 MN. However, with respect to the regional aware foreign agent, it is registered if the regional aware foreign agent has the information of the registration key shared between MN and HA. Enhanced Mobile Node A enhanced IETF base MN which is able to operate in two modes - IETF base mode and enhanced mode. Enhanced handoff feature is added to provide seamless handoff. Regionally Registered This means that the MN is a registered MN. It has a binding with the regional aware foreign agent. Datagrams from HA will be tunnelled to the regional aware foreign agent. Locally Registered This means that the MN is a anonymous MN. It has a binding with the local foreign agent. Datagrams from HA will be tunnelled to the local foreign agent. 2. Protocol Overview Using the proposed Regional-Aware Foreign Agent (RAFA) model, latency incurred by the Registration process when a handoff occurs is reduced as the MN would register with the regional aware foreign agent which is nearer instead of its HA which may be far away. HA would only know the regional aware foreign agent that is serving its MN. It does not know its MN's true point of attachment. Chua and Foo Expires April 1999 [Page 3] Internet Draft November 1998 2.1 Network Topology The network topology is shown in Fig 1 which consists of the Home Agent (HA), Regional Aware Foreign Agent (RAFA), Local Foreign Agent (LFA), Foreign Agent (FA) and Mobile Nodes (MN). Note that the HA, FA and MN (base mode) are the entities in the base protocol, and we only add two new entities - RAFA and LFA. Home Agent | +------------------------------------------+ | Internet Cloud | +------------------------------------------+ | | Regional Aware Foreign Agent Foreign Agent (Base Protocol) | +--------------------------------+ | Arbitrary Routers | +--------------------------------+ | | | Local Local Local Foreign Foreign Foreign Agent Agent Agent +-------------+ +-------------+ | Mobile Node | | Mobile Node | +-------------+ +-------------+ Fig 1 : Network Topology 2.2 Agent Discovery MN detects a local foreign agent when it receives an agent advertisement from it. This is equivalent to how the MN discovers an agent in the base protocol. 2.3 Registration Process Under the RAFA model, depending on the handoff scenarios which can take place between the networks of HA<->LFA, FA<->LFA and LFA<->LFA, the Registration Request will either be directly relayed to the HA via the local foreign agent if the MN is "locally registered" or via the regional aware foreign agent if the MN is "regionally registered". Likewise, the Registration Reply from the HA will be relayed to the MN either via the local foreign agent if the MN is "locally registered" or via regional aware foreign agent if the MN is "regionally registered". Chua and Foo Expires April 1999 [Page 4] Internet Draft November 1998 2.3.1 Processing of Registration Packets at LFA During handoff, when the MN is not under the visitor list of a local foreign agent, the local foreign agent will relay the first-time Registration Request of the MN to the regional aware foreign agent. When the local foreign agent receives a reply with the proper authentication extension from the regional aware foreign agent, it will treat that the MN is "regionally registered" with the regional aware foreign agent. On the other hand, if it receives a reply directly from the HA, it will treat the MN as "locally registered". In the case of re-registration, if the MN is "regionally registered and has a binding with the regional aware foreign agent, the local foreign agent will relay the Registration Request to the regional aware foreign agent. If the MN is "locally registered" and has a binding directly with its HA, the local foreign agent will relay the Registration Request to the HA just like in the base protocol. 2.3.2 Processing of Registration Packets at RAFA Before the regional aware foreign agent relays the Registration Request from a MN, it will check whether it has the information on the shared registration key of the MN and its HA. If it has, it will relay the MN's Registration Request to its HA. The care of address field of the Registration Request is that of its care-of-of address instead of the care-of-address of the LFA. The HA will then have a mobility binding with the regional aware foreign agent. Otherwise, the regional aware foreign agent just forwards the Registration Request to the HA. The HA would then have a mobility binding with the local foreign agent instead. 2.4 Typical Registration Scenarios Different registration scenarios arise depending on whether a) the regional aware foreign agent has the information of the shared registration key between HA and its MN b) the MN is in the local foreign agent's visitor list or not c) the MN handoffs from network of HA to LFA, FA to LFA, LFA to HA, LFA to FA or LFA to LFA Chua and Foo Expires April 1999 [Page 5] Internet Draft November 1998 2.4.1 MN handoffs from a FA network to a LFA network or MN handoffs from a HA network to a LFA network. A first-time registration process at the local foreign agent consists of: a) MN receives a Mobility Agent Advertisement from a LFA b) MN sends a Registration Request to the LFA c) LFA forwards the received Registration Request to RAFA d) Depending whether RAFA has the information on the shared key, it either forwards or relays the Registration Request to the MN's HA. If RAFA has the shared key information, it changes the care-of-address field to its own care-of-address and relays to the HA without modifying the registration lifetime. Else, it merely forwards the Registration Request to the HA. e) HA processes the Registration Request in a similar way to that of the base protocol. It either sends a Registration Reply to RAFA if the care-of-address field in the Request is that of RAFA or to LFA if the care-of-address is that of LFA. f) If RAFA receives the Registration Reply from the HA, it updates its visiting MN list and relays the Reply to the LFA serving the MN. The LFA in turn updates the MN in its visitor list as "regionally registered" and sends the Reply to the visiting MN. In the case if HA sends a Registration Reply to LFA, upon receiving the reply, LFA updates the MN in its visitor list as "locally registered" and sends the Reply to the visiting MN. For subsequent re-registration, a) For a "locally-registered MN", LFA relays the Registration Request to HA. HA will return a Registration Reply to the MN via LFA. b) For a "regionally-registered MN", LFA relays the Registration Request to HA via RAFA. HA will return a Registration Reply to the MN via RAFA and LFA 2.4.2 MN handoffs from a LFA network to a FA network. MN handoffs from a LFA network to a HA network. In this case, the Registration process follows that of the Registration process in the base protocol. Chua and Foo Expires April 1999 [Page 6] Internet Draft November 1998 2.4.3 MN handoffs from a LFA network to a new LFA network within the same domain of a RAFA A first-time registration process at the new LFA consists of: a) MN receives a Mobility Agent Advertisement from a new LFA b) MN sends a Registration Request to the new LFA c) The new LFA forwards the received Registration Request to the RAFA d) Depending on whether MN is in its visitor list or not, RAFA either forwards the Registration Request to the MN's HA if MN is not in its visitor list or processes the Registration Request if MN is in its visitor list. If the MN is in its vistor list, RAFA updates the binding of the MN to the care of address of the new LFA. It will also send a Registration Reply on behalf of HA to the MN via the new LFA using the information of the shared registration key between HA and its MN. e) When the new LFA receives the Registration Reply from either HA or RAFA, it updates its visiting MN list and sends the reply to the visiting MN. If it receives a Registration Reply from RAFA, the MN is "regionally registered". Else, the MN is "locally registered". For subsequent re-registration, a) For a "locally registered" MN, the new LFA relays the Registration Request directly to HA. HA will return a Registration Reply to the MN via the new LFA in a way similar to that in the base protocol. b) For "regionally registered" MN, the new LFA relays the Registration Request to HA via RAFA. HA will return a Registration Reply to the MN via RAFA and then the new LFA. 2.5 Datagram Routing Any packets addressed to the MN will be intercepted by its HA. The HA will tunnel the packets to the RAFA if the MN is "regionally registered". Otherwise, it will tunnel it to LFA/FA. Note that the registration process is transparent to the HA, and HA only tunnels datagrams to the MN according to the care-of-address of the MN's Registration Request as in the base protocol. If the MN is "regionally registered", upon receiving the packets, RAFA refers to its visitor list and tunnels the packets to the appropriate LFA which is serving the MN. The LFA in turn forwards the packets to the MN. Else, LFA which receives packets directly from the HA will just detunnel and forward packets as in the base protocol. Chua and Foo Expires April 1999 [Page 7] Internet Draft November 1998 2.6 Interoperability with the Base Protocol The RAFA model is fully compatible with the base protocol as there are no changes made in the MN and HA. Besides, it also supports all the other implementations (related to Mobile-IP) such as route optimization, simultaneous bindings at the HA etc. The network topology and operation of the regional aware foreign agent and local foreign agent is totally transparent to the MN and HA. 2.7 Key Management/Distribution Scheme The introduction of RAFA provides access control for the foreign network and reduces frequent distant registrations during handoff. It also reduces the number of trusted entities since the number of RAFA is much less than the number of mobility agents and hence reduces the severity of key management problem for Mobile-IP. In that sense, it is more scalable. However, it requires the information on the shared Registration key of HA and its MN. Note that even without the information, handoff can still take place at the base protocol level in our network topology. If the MN from some home network often visits a routing domain under the RAFA, then the effort of creating such a association will be worthwhile. Currently, besides manual configuration, there are many associated key management/distribution approaches to solve this problem, and we can do it either offline or dynamically. Doing it offline means that the information of the shared key is distributed before the registration process while doing it dynamically means that the information is distributed during the registration process. But this requires slight modification to the RAFA and LFA that we have described above, and the RAFA must have a agreement with the HA about the distribution process. Two of these approaches can be employed to distribute (either offline or dynamically) the shared Registration key of HA and MN to RAFA. They are : a) THE HA AS A KEY DISTRIBUTION CENTER (KDC) HA has a security association with RAFA. Using their shared key and encryption, HA distributes its shared Registration key with its MN to RAFA. b) USING RAFA'S PUBLIC KEY HA uses the public key of RAFA and encryption to distribute its shared Registration key with its MN to RAFA. RAFA can then use its private key to obtain the shared Registration key of HA and MN. MD5 can be used here for the purpose of transmitting registration keys and secure eavesdroppers. Chua and Foo Expires April 1999 [Page 8] Internet Draft November 1998 For offline distribution, RAFA and LFA work in the same way as described above. For dynamic distribution, this requires a bit of cooperation between the RAFA and LFA. When the RAFA receives a Registration Request, if it does not have the information of the shared key but has a agreement (security association) with the HA to distribute shared key information, it appends a Get Shared Key Notification extension in the Registration Request to be sent to the HA while notifying the LFA. The HA will then send the encrypted key to the RAFA using the agreed key distribution method with the RAFA, besides the normal Registration Reply to the LFA, which will treat the MN as "temporary locally registered". When RAFA receives the information of the shared key, it will notify the LFA, which will then send the next Registration Request from the MN to the RAFA. RAFA with the information of the shared key will then proceed as described in the section on protocol overview. Note that in our description of the handoff scenarios, we do not elaborate the key distribution/management scheme as it is not part of the draft. 3. Local Foreign Agent (LFA) Considerations The local foreign agent plays a mostly passive role just like the FA in the base Mobile-IP protocol. It functions almost exactly like the FA in the base protocol except the way it deals with Registration Request and Reply packets. It always sends the first Registration Request of a MN not in its visitor list to the regional aware foreign agent. It obtains the relevant information from the Registration Reply in order to decide whether to relay the subsequent Registration Request to the regional aware foreign agent or home agent. 3.1 Configuration and Registration Tables Each local foreign agent has a security association with a list of regional aware foreign agents. In addition to the information maintained for the base protocol in the visitor list entry, the following information is also included - whether the MN is "regionally registered" at the care-of-address of the regional aware foreign agent or "locally registered" at its own care-of-address. 3.2 Receiving Registration Request When the local foreign agent receives a Registration Request from an MN, it follows the base Mobile-IP protocol except when sending out the Registration Request. If the local foreign agent receives a Registration Request from a MN not in its visitor list, it will relay the first time Registration Request of the MN to the regional aware foreign agent instead of the HA as specified in RFC2002. If the MN is in its visitor list, it will check the list whether the MN is "regionally registered" Chua and Foo Expires April 1999 [Page 9] Internet Draft November 1998 at the care-of-address of the regional aware foreign agent or "locally registered" at its own care-of-address. If the MN is "regionally registered", the local foreign agent will relay the Registration Request packet to the regional aware foreign agent. Else, it will relay the Registration Request to the HA as specified in the base protocol. 3.3 Receiving Registration Reply When the local foreign agent receives a Registration Reply, besides following the base Mobile-IP protocol, it will check whether there is a RAFA-LFA authentication extension with type 0x3. If yes, this means that the MN is "regionally registered" at the care of address of the regional aware foreign agent and the authenticator value in the Registration Reply will be checked. The local foreign agent will update its visitor list with the appropriate information that the MN is "regionally registered" and will relay the Reply to the MN with all the Extensions after the Mobile-Home Authentication Extension being removed. If the authenticator is invalid, the local foreign agent will silently discard the Reply and log the event as security exception. The local foreign agent also will reject the MN's registration and send a Registration Reply to the MN with Code 68. If no, this means that the MN is "locally registered" at its own care-of-address. The local foreign agent will update its visitor lists entry for the MN to reflect that the MN is "locally registered" after doing the validity check and then it forwards the Reply to the MN as specified in the base protocol. 3.4 Routing of Datagrams If the MN is "locally registered", the local foreign agent will receive encapsulated datagrams from HA directly. Else, the local foreign agent will receive encapsulated datagrams from the HA via the regional aware foreign agent. The local foreign agent will decapsulate the datagrams and forward them to the MN in exactly the same way as the FA in the base protocol. Likewise, datagrams sent by the MN are generally delivered to their destination using the standard IP routing mechanisms, not necessarily passing through the regional aware foreign agent. 4. Regional Aware Foreign Agent (RAFA) Considerations The regional aware foreign agent plays a pro-active role in the registration process. It performs local registration during handoff. It is used to establish the local mobility binding of a MN. The local mobility binding will enable it to tunnel the datagrams to the respective local foreign agent which is serving the MN. Through the registration process, it provides access control (authorization) over the local foreign networks and prevent an illegal MN from stealing Chua and Foo Expires April 1999 [Page 10] Internet Draft November 1998 services in a wider routing domain. It determines the services that the foreign network will provide for the MN. 4.1 Configuration and Registration Table Each regional aware foreign agent must be configured with a list of the local foreign agents which are under its routing domain with security associations. It may have information of the secret key shared between the MN and HA. In addition, for each pending or current registration, the regional aware foreign agent must maintain a visitor list entry containing the following information obtained from the MN's Registration Request. - the IP Source Address (the mobile node's Home Address) - the IP Destination Address - the Home Agent address - the care-of-address of the local foreign agent - the Identification field - the requested registration Lifetime - the remaining Lifetime of the pending or current registration The regional aware foreign agent may configure a maximum number of pending registrations that it is willing to maintain and additional registrations should then be rejected with code 66 just like that in the base protocol. 4.2 Receiving Registration Request When the regional aware foreign agent receives a Registration Request packet from the local foreign agent, it will perform the same validity check as that of the local foreign agent. If the regional aware foreign agent receives a Registration Request from a MN (via local foreign agent) in its visitor list, it will send a positive Registration Reply to the MN via local foreign agent using the information of the secret key shared by MN and HA. The Registration Reply contains the basic codes to inform the MN about the status of its Request plus a RAFA-LFA authentication extension to inform the local foreign agent that the MN is "regionally registered" or "locally registered", along with the lifetime granted by the regional aware foreign agent, which must not be great enough to last longer than time at which the binding at the HA would expire, as determined by the original lifetime granted by the MN's home agent in the last Registration Request approved by the HA. It must also update its record of the MN's mobility binding of which the care-of-address of the MN is the new local foreign agent and the Registration Request will then be silently discarded without forwarding to the HA. If the regional aware foreign agent receives a Registration Request from a MN not in its visitor list, it will check whether it has the information of the secret key shared between the MN and HA, and the care-of-address field of the Request is one of the local foreign agent in its list. If there is information on the secret key and the Chua and Foo Expires April 1999 [Page 11] Internet Draft November 1998 care-of-address is one of the local foreign agent, the regional aware foreign agent will change the care-of-address field in the Registration Request to its own care-of-address with a new MD5 authenticator [4] being recomputed, and forward the Registration Request to the HA. It must also record the new pending Request for the MN. If there is no information of the secret key shared by MN and HA, the regional aware foreign agent will relay the original Registration Request to the HA without recording the pending Request if it allows services to an anonymous MN of its local foreign agent network. 4.3 Receiving Registration Reply When the regional aware foreign agent receives a Registration Reply message, it will search its visitor list for a pending Registration Request with the same MN's home address as indicated in the Reply. If no pending Request is found, the regional aware foreign agent will silently discard the Reply. Else, it will forward the valid Registration Reply to the local foreign agent after appending the RAFA-LFA authentication Extension to the Reply using implicitly its own care-of-address as the value for computed authenticator value. It then updates its visitor list and resets its timer of the lifetime of the registration to the lifetime granted in the Registration Reply like that of the FA in the base protocol. 4.4 Routing of Datagrams The regional aware foreign agent has a binding for the mobile node which shows that the MN is "regionally registered" at the care-of-address of the next local foreign agent. Thus, a datagram arriving from the home agent will be decapsulated and re-encapsulated at the regional aware foreign agent with a new tunnel endpoint which is the care-of-address of the local foreign agent which can deliver the datagram to the mobile node. The actual decapsulation need not occur at the regional aware foreign agent. Instead, the regional aware foreign agent can merely change the source and destination IP addresses of the encapsulating IP header. Note that the regional aware foreign agent is not involved in any datagrams routing for MN which is "locally registered" at the care-of-address of the local foreign agent. 4.5 Access Control (Authorization)/ Non-repudiation / Billing for Foreign Network The registration mechanism of which the local foreign agent always relays the first Registration Request from the MN during handoff to the regional aware foreign agent if MN is not in its visitor list provides access control (authorization) over the visiting MNs for the regional aware foreign agent. It can decide which MN is allowed visiting rights and what network resources may be used by the visiting MN, whether it is Chua and Foo Expires April 1999 [Page 12] Internet Draft November 1998 "regionally registered" or "locally registered". Priority can be given to the MN which is "regionally registered" than one which is "locally registered". Of course, the regional aware foreign agent can give equal priority to all MNs but a "regionally registered" MN (registered MN) will have better handoff performance than a "locally registered" MN (anonymous MN). It can also control the number of visiting anonymous MNs. If the traffic is low, the regional aware foreign agent may choose to provide services for more anonymous MNs. If the traffic is high, it may even choose to drop services for anonymous MN by sending a specific request to the local foreign agent so that it can provide MNs which are "regionally registered" with the scarce wireless network resources. Note that the concept here is similar to the access control level allowed for a host (anonymous login or user login) in any ftp session which is commonly used in the Internet. For MN which is "regionally registered", the regional aware foreign agent can also log some of its Requests so that the MN cannot falsely deny that it originated the Requests at a later time (non-repudiation). Likewise, it can log the Reply from the HA so that the HA cannot falsely deny that it originated the Reply. Nevertheless, it requires a trusted relationship between the HA and the RAFA. The RAFA model also makes it easy for billing purposes when an MN uses the precious wireless resources of a foreign network. Billing can be easily done on a per RAFA basis (under the same administrative domain) instead of per FA basis (may be under different administrative domain). Hence, the RAFA model offers some kinds of security features, access control and easy billing mechanisms that are especially important and useful for commercial service providers. These are necessary for the deployment of Mobile IP. 4.6 Solving Inherent Functionality Problem of Mobile IP The inherent functionality problem of any correspondent node in the old foreign agent network will not be able to route datagrams to the MN when it moves to a new foreign network until the registration lifetime of the binding has expired which may take hundreds of seconds can be easily solved in the RAFA model. The regional aware foreign agent may send an explicit de-registration (preferably after a few seconds so as to support simultanous bindings during the vulnerable period of handoff) to the former foreign agent network to inform about the movement of MN. This will enable the foreign agent to delete the MN's routing entry in the routing table or release any resources (such as radio channel reservations) consumed previously by an MN that is not in its network, rather than waiting for its registration lifetime to expire. Chua and Foo Expires April 1999 [Page 13] Internet Draft November 1998 4.7 Simultaneous Bindings The regional aware foreign agent can implicitly maintain multiple simultaneous bindings for an MN, so that a copy of each datagram will be tunneled to each active care-of-address of the local foreign agents during handoff to the MN. Note that this simultaneous registration done at the regional aware foreign agent (instead of HA in the base protocol) is feasible as the duplication problem is not that severe since the local foreign agents are normally just a few hops away from the regional aware foreign agent. 4.8 Autonomous Mode Operation The RAFA model offers the possibility of autonomous mode operation similar to that of the MOBITEX Network Architecture [5] if the link or network connectivity between the regional aware foreign agent and MN's HA is temporarily lost. This means that a MN can still communicate with another MN if they are under the same local foreign agent or regional aware foreign agent. The regional aware foreign agent can choose to reply temporarily on behalf of the HA so that all the routing entries in the local foreign agent and MN will remain intact for datagram routing to take place. For a MN communicating with another MN under the same local foreign agent, it will be able to do so as the route entry or network resource is still available. However, for a MN communicating with another MN under the same RAFA, LFA need to tunnel the packets from the MN to RAFA which will then de-capsulated and tunnel the packets to the appropriate LFA. 4.9 Multicast Data Routing Using the RAFA Model The RAFA model supports multicast services similar to the base protocol. MN can either join the multicast group via a (local) multicast router on the visited subnet or via a bi-directional tunnel to its home agent. However, the RAFA model can reduce the multicast backbone traffic compared to the base protocol. If more than one of its MNs which are served by different FAs join the same multicast group, then the HA needs only to send a single copy of the multicast to RAFA instead of multiple copies of the multicast to the foreign agents. The reduction in backbone traffic may be significant considering the fact that MNs of the same multicast group have a tendency to be served by different FAs since they may handoff to a foreign network frequently. Note that providing multicast services for MNs that handoff frequently may be easy to do so using the regional aware foreign agent as it is in charge of a larger routing domain. Chua and Foo Expires April 1999 [Page 14] Internet Draft November 1998 4.10 Other Capabilities The regional aware foreign agent can provide a mean for datagrams in flight to the MN's previous local foreign agent to be forwarded securely to its new local foreign agent. It can employ datagram buffering for critical data at the local foreign agent serving the MN before a handoff. It can then explicitly ask the local foreign agent to forward the datagrams to another local foreign agent in a secure manner so that there would be no loss of datagrams for the MN during handoff. Simulation [6] has shown that buffering and forwarding last few packets of the datagrams can significantly improve the TCP throughput during handoff. Another capability of the RAFA model is that NAT and IP Masquerading techniques in the RAFA model as the care-of-address of the local foreign agent need not be real. 4.11 Load balancing Each of the regional aware foreign agent can occasionally probe their regional aware foreign agent on the traffic load that each of them is supporting. If the traffic load is high, it can order the local foreign agent to forward new Requests to another regional aware foreign agent with the least traffic. 5. Message Format and Extensions There are a few new message formats and authentication Extensions in the RAFA model. 5.1. De-registration Request De-registration Request is sent by the regional aware foreign agent to the local foreign agent to delete the route entry of the MN when it moves to a new local foreign agent network. IP fields: Source Address - The IP address of the regional aware foreign agent Destination Address - The IP address of the local foreign agent UDP fields Source Ports - Variable Destination Port - 434 Chua and Foo Expires April 1999 [Page 15] Internet Draft November 1998 The UDP header is followed by the fields shown below 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +--------------------------------------------------------------+ | Type | Code | Time | +--------------------------------------------------------------+ | Care-of-address of RAFA | +--------------------------------------------------------------+ | | | Identification | | | +--------------------------------------------------------------+ | Extensions... | +--------------------------------------------------------------+ Type - 38 Code - 3 to indicate deletion Time - The interval (seconds) needed to delete the route entry after receiving a de-registration request Care-of-Address - IP address of the regional aware foreign agent Identification - A 64 bit number used for protecting against reply attacks of these messages Extension - This is followed by the RAFA-LFA authentication Extension 5.2. Get Shared Key Notification Extension This extension is appended in the Registration Request message by the RAFA so that the HA will send a encryted information of the shared key of HA and its MN to it. Note that this extension is only required if we want to support dynamic distribution of information of the shared key, and may not be part of the RAFA model. Chua and Foo Expires April 1999 [Page 16] Internet Draft November 1998 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +--------------------------------------------------------------+ | Type | Code | Lifetime | +--------------------------------------------------------------+ | RAFA's address | +--------------------------------------------------------------+ | | | Identification | | | +--------------------------------------------------------------+ | Extensions... | +--------------------------------------------------------------+ Type - 11 Code - 5 to indicate the key distribution algorithm Lifetime - time interval of which the Request is valid RAFA's Address - IP address of the regional aware foreign agent Identification - A 64 bit number used for protecting against reply attacks of these messages Extensions - followed by the HA-RAFA extension 5.3. RAFA-LFA Authentication Extension This extension is appended in the Registration Reply message by the RAFA so that the LFA will know that the MN is "regionally registered". The fields used are exactly the same as the base protocol except the shared secret key is that between the RAFA and the LFA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x3 Length 4 plus the number of bytes in the Authenticator. SPI Security Parameter Index (4 bytes). An opaque identifier Authenticator (variable length) Chua and Foo Expires April 1999 [Page 17] Internet Draft November 1998 5.4. HA-RAFA Authentication Extension This extension is appended in the Registration Request by the RAFA so that the HA will send a encrypted version of the information of the shared key to RAFA. It is required only if we want to distribute the information of the shared key dynamically, and is not neccesary required in the RAFA model. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x4 Length 4 plus the number of bytes in the Authenticator. SPI Security Parameter Index (4 bytes). An opaque identifier Authenticator (variable length) 6. Fast Handoff Considerations The Mobile-IP base protocol standard specifies a general handoff protocol for both wired and wireless networks. We believe that the handoff protocol is more suited to handle portability and global mobility (movement across different administrative domain) than local mobility (within the same administrative domains where handoffs are frequent like a network of wireless cells). In the Mobile-IP base protocol, a handoff even in overlapping wireless small cells is not seamless due to two main reasons - delay due to distant registration and operational procedure of MN when it hears a new agent advertisement (MN only registers with a new agent if it does not hear three consecutive advertisements from the old FA which incurs a average delay of 2.5 times the agent advertisement interval). Using the RAFA model, we can reduce the delay due to distant registration during handoff. To reduce the delay due to the operational procedures of MN, we can either reduce the agent advertisement interval or modify the handoff protocol of MN. We propose a slight modification to the handoff protocol to provide seamless handoff. However, it requires some minor changes in the LFA and MN. Note that the changes in MN is to solve the handoff latency and is not necessarily required in the RAFA model. Chua and Foo Expires April 1999 [Page 18] Internet Draft November 1998 Instead of waiting for three consecutive missing advertisements in the overlapping cells, the MN will immediately registers with the local foreign agent once it hears a new advertisement. Note that this slight modification is transparent to the HA and mobility agents in the base protocol. This simple modification combined with simultaneous bindings operation at the regional aware foreign agent will provide seamless handoff between the local foreign agent networks which are overlapping. Another option is to arrange the datagrams in flight when the MN moves to be forwarded to the new LFA which will provide more seamless handoff. In order to be interoperable with the base protocol, MN can operate in two modes - base or enhanced mode according to the agent advertisement it hears. 6.1 Local Foreign Agent (LFA) Considerations There is no modification to the way the LFA handles the Registration Request and Registration Reply. Only the format of the agent advertisement would be changed. 6.1.1 Sending Agent Advertisement A local foreign agent wishing to support the enhanced MN advertises its services using the Mobility Extension to ICMP Router Advertisement which is defined in the base Mobile-IP document. One bit (E) is added to the flag bits in the Agent Advertisement message to indicate its intention to support the enhanced MN with the modified handoff protocol. (all other fields not defined here are unchanged from the definition given in the base mobile-IP). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Lifetime |R|B|H|F|M|G|V|E| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | E If set, the local foreign agent is advertising its willingness to support the enhanced MN 6.2 MN considerations MN can operate in two modes - the base IETF mode and Enhanced Mode. By default, the MN is operating in the base mode. It would only switch to Enhanced mode if it receives an agent adevrtisement with the "E" bit set. Chua and Foo Expires April 1999 [Page 19] Internet Draft November 1998 6.2.1 Receiving Agent Advertisement When an MN receives an agent advertisement, it checks to see if the "E" bit is set or not. If yes, the mobile node will switch from normal base mode to Enhanced Mode. Instead of waiting for three missing consecutive advertisements from the old FA before it sends its first Registration Request, the MN will immediately send a Registration Request. 6.3 Regional Aware Foreign Agent Considerations The regional aware foreign agent should support simultaneous bindings if the local foreign agent supports the enhanced mode. A copy of each datagram will be tunneled to each active care-of-address of the local foreign agents to provide more seamless handoff to the MN. References [1] Charles Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996 [2] Charles Perkins, "Mobile-IP Local Registration with Hierachical Foreign Agents", Internet Draft, draft-perkins-mobileip-hierfa-00.txt, February 1996, Work in Progress [3] M.C. Chuah, Y. Li, "Distributed Registration Extension to Mobile IP", Internet Draft, draft-chuahli-mobileip-dremip-00.txt", October 1997 [4] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [5] Salkintzis, A.K. and Chamzas, C. "Mobile Packet Data Technology: An Insight into MOBILTEX Architecture", IEEE Personal Communications Mag, Feb 1997, pp. 10-18 [6] W. Woo, C.M Leung, "Handoff Enhancement in Mobile-IP Environment", Proceedings of ICUPC - 5th International Conference on Universal Personal Communications, 29 Sept. - 2 Oct. 1996 Chua and Foo Expires April 1999 [Page 20] Internet Draft November 1998 Acknowledgements Special thanks to K.M. Chan, C.C. Foo, K.J. Loh, Y.Z. Li and S.W. Gan for their advice. Special thanks to the Linux Community for their advice in the implementation of RAFA scheme. RAFA research and implemention is a Masters Project at the National University of Singapore. Author's Address Dr K. C. CHUA Deputy Director Centre for Wireless Communications Ph: +65 8729 030 20 Science Park Road DID: +65 8709 222 #02-34/37, Teletech Park Fax: +65 7795 441 Singapore Science Park II Singapore 117674 Email: eleckc@leonis.nus.edu.sg URL: www.cwc.nus.edu.sg S. F. Foo National University of Singapore Department of Electrical Engineering Lower Kent Ridge Cresent Singapore 119260 Email: engp7498@leonis.nus.edu.sg Ph: +65 8745 095 Chua and Foo Expires April 1999 [Page 21]