idnits 2.17.1 draft-chuafoo-mobileip-rafa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9294 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. F. Foo 2 INTERNET DRAFT K. C. Chua 3 National University of Singapore 4 November 1998 6 Regional Aware Foreign Agent (RAFA) for Fast Local Handoffs 7 9 Status of This Memo 11 This document is a submission to the MobileIP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@smallworks.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), 30 ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 31 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 This document proposes an extension to the Mobile IP base protocol. 36 The purpose of this extension is to solve the distant registrations, 37 handoff latency, and key management problems among mobility agents. 38 It provides a easy and robust solution for secure ubiquitous 39 deployment of IP mobility while still maintaining interoperability 40 with the base protocol. 42 Contents 44 Abstract ............................................................ i 46 1. Introduction ..................................................... 1 47 1.1. Requirements ................................................ 2 48 1.2. Architectural Entities ...................................... 2 49 1.3. Terminology ................................................. 3 51 2. Protocol Overview ................................................ 3 52 2.1. Network Topology ............................................ 4 53 2.2. Agent Discovery ............................................. 4 54 2.3. Registration Process ........................................ 4 55 2.3.1 Processing of Registration Packets at LFA ............. 5 56 2.3.2 Processing of Registration Packets at RAFA ............ 5 57 2.4. Typical Handoff Scenarios ................................... 5 58 2.4.1 MN handoffs from FA/HA to LFA ......................... 6 59 2.4.2 MN handoffs from LFA to FA/HA ......................... 6 60 2.4.3 MN handoffs from LFA to LFA ........................... 7 61 2.5. Datagram Routing ............................................ 7 62 2.6. Interoperability with the Base Protocol ..................... 8 63 2.7. Key Management/Distribution Scheme .......................... 8 65 3. Local Foreign Agent Considerations ............................... 9 66 3.1. Configuration and Registration Tables ....................... 9 67 3.2. Receiving Registration Request .............................. 9 68 3.3. Receiving Registration Reply ................................ 10 69 3.4. Routing of Datagrams ........................................ 10 71 4. Regional Aware Foreign Agent Considerations ...................... 10 72 4.1. Configuration and Registration Tables ....................... 11 73 4.2. Receiving Registration Request .............................. 11 74 4.3. Receiving Registration Reply ............................... 12 75 4.4. Routing of Datagrams ........................................ 12 76 4.5. Access Control (Authorization)/ Non-Repudiation/ Billing for 77 Foreign Network ............................................. 12 78 4.6. Solving Inherent Functionality Problem of Mobile IP ......... 13 79 4.7. Simultaneous Bindings ....................................... 14 80 4.8. Autonomous Operation ........................................ 14 81 4.9. Multicast Datagram Routing Using the RAFA Model ............. 14 82 4.10.Other Capabilities .......................................... 15 83 4.11.Load Balancing .............................................. 15 85 5. Message Format and Extension ..................................... 15 86 5.1. De-registration Request ..................................... 15 87 5.2. Get Shared Key Notification Extension ....................... 16 88 5.3. RAFA-LFA Authentication Extension ........................... 17 89 5.4. HA-RAFA Authentication Extension ............................ 18 91 6. Fast Handoff Considerations ...................................... 18 92 6.1. LFA Considerations .......................................... 19 93 6.1.1 Sending Agent Advertisement ........................... 19 94 6.2. MN Considerations ........................................... 19 95 6.2.1 Receiving Agent Advertisement ......................... 20 96 6.3. RAFA Considerations ......................................... 20 98 Reference ........................................................... 20 100 Acknowledgement ..................................................... 21 102 Authors's Address ................................................... 21 103 1. Introduction 105 The base Mobile-IP scheme [1] provides a scalable mechanism for node 106 mobility within the Internet. However, there still exist some problems. 107 Firstly, it requires that a mobile node's home network be notified of 108 every change of location. As Perkins [2] addresses in the hierarchical 109 foreign agent model and M.C.Chuah [3] in the DREMIP model, in cases 110 where the home agent is far away, it may become too expensive or even 111 impossible to complete these frequent registrations. Furthermore, it 112 also adds more traffic to the wide-area portion of the internetwork. 113 Thus the current Mobile IP does not extend well to large numbers of 114 mobile nodes moving frequently between small wireless subnets. 116 Secondly, the key management between the home and foreign agents, and 117 between the foreign agents and the mobile node is still a problem. 118 Mobile IP currently requires that registration messages between HA and 119 its MN be authenticated. Registration messages between an HA and an FA, 120 or between an MN and an FA, may be optionally authenticated. As more of 121 the networks MNs visit become wireless nets which are subject to 122 eavesdropping and unable to control actual attachment via physical 123 controls, authentication between FAs and HAs and between FAs and 124 MNs become mandatory for Mobile IP to succeed commercially. 126 Thirdly, the Mobile-IP standard specifies a general handoff protocol 127 for both wired and wireless network. It incurs an intrinsic loss of data 128 up to a few seconds during handoff even in overlapping wireless subnets 129 due to the fact that the mobile node will only register with a new agent 130 if it fails to receive another advertisement from the current agent 131 within the specified lifetime. This often results in degraded throughput 132 which causes the handoff to be not as seamless. Thus, for mobile nodes 133 moving frequently between small wireless subnets, performance of future 134 IP applications such as IP telephony will be seriously affected. 136 Fourthly, the base protocol does not require the mobile node to 137 inform the former foreign agent of the movement of the mobile node when 138 it moves from one foreign network to another. Thus, any correspondent 139 node in the former foreign network will not be able to route datagrams 140 to the mobile node until the registration lifetime of the binding has 141 expired which may take hundreds of seconds. 143 In this draft document, we propose a new regional aware foreign agent 144 model as an extension to the base Mobile IP protocol to solve these 145 problems. Our proposed extension provides advantages over existing base 146 Mobile IP scheme while still maintaining interoperability. 147 In particular, our proposed extension can 148 a) reduce frequent distant registrations during handoffs. 149 b) reduce the number of trusted entities in the network and hence 150 enable us to minimise the key management problem. 151 c) provide seamless handoff especially for small overlapping 152 wireless cells to support multimedia data. 154 d) provide access control (authorization) in a foreign network and 155 prevent an illegal mobile node from stealing services in a 156 routing domain, and other services which may be very important 157 for service providers so that gradual adoption is possible and 158 might help in a more widespread deployment of Mobile-IP. 159 e) solve the inherent routing problem of the former foreign agent 160 network as mentioned above when the MN moves to a new foreign 161 agent network. 162 Importantly, the above advantage can be obtained without requiring any 163 changes in the base protocol implemented at the MN. 165 1.1. Requirements 167 Any of the entities in the base protocol should be able to 168 interoperate with the new and enhanced entities in this regional aware 169 foreign agent (RAFA) model. 171 1.2. Architectural Entities 173 The RAFA model introduces the following new architectural entities. 175 Regional Aware Foreign Agent (RAFA) 177 A host or router on a MN's visited routing domain which provides 178 local registration service for an MN during handoff. It cooperates 179 with the local foreign agents to allow the HA to have incomplete 180 knowledgement of the MN's true point of attachment. 182 It may be the tunnel endpoint of datagrams from the HA. It either 183 extracts the datagrams and then tunnels datagrams to the local 184 foreign agent for delivery to the MN or just acts as a simple 185 router within a large routing domain. 187 It therefore provides tunneling, registration and routing services 188 to the MN while registered. 190 Local Foreign Agent (LFA) 192 It has the same functionality as the FA in the base protocol. It 193 is a router on a MN's visited network which provides routing 194 service to the MN while registered. It extracts and forwards 195 datagrams to the MN. 197 It has a security association with the regional aware foreign 198 agent, and there is a slight modifications in the way it relays 199 registration packets from the base protocol. 201 1.3. Terminology 203 In addition to all the terminology in the base mobile-IP 204 specification, this document frequently uses the following terms: 206 Anonymous Mobile Node 208 A standard RFC2002 MN. However, with respect to the regional aware 209 foreign agent, it is anonymous if the regional aware foreign agent 210 does not have the information of the registration key shared 211 between MN and HA. 213 Registered Mobile Node 215 A standard RFC2002 MN. However, with respect to the regional aware 216 foreign agent, it is registered if the regional aware foreign 217 agent has the information of the registration key shared between 218 MN and HA. 220 Enhanced Mobile Node 222 A enhanced IETF base MN which is able to operate in two modes - 223 IETF base mode and enhanced mode. Enhanced handoff feature is 224 added to provide seamless handoff. 226 Regionally Registered 228 This means that the MN is a registered MN. It has a binding with 229 the regional aware foreign agent. Datagrams from HA will be 230 tunnelled to the regional aware foreign agent. 232 Locally Registered 234 This means that the MN is a anonymous MN. It has a binding with 235 the local foreign agent. Datagrams from HA will be tunnelled to 236 the local foreign agent. 238 2. Protocol Overview 240 Using the proposed Regional-Aware Foreign Agent (RAFA) model, 241 latency incurred by the Registration process when a handoff occurs is 242 reduced as the MN would register with the regional aware foreign agent 243 which is nearer instead of its HA which may be far away. HA would only 244 know the regional aware foreign agent that is serving its MN. It does 245 not know its MN's true point of attachment. 247 2.1 Network Topology 249 The network topology is shown in Fig 1 which consists of the 250 Home Agent (HA), Regional Aware Foreign Agent (RAFA), Local Foreign 251 Agent (LFA), Foreign Agent (FA) and Mobile Nodes (MN). Note that the HA, 252 FA and MN (base mode) are the entities in the base protocol, and we only 253 add two new entities - RAFA and LFA. 255 Home Agent 256 | 257 +------------------------------------------+ 258 | Internet Cloud | 259 +------------------------------------------+ 260 | | 261 Regional Aware Foreign Agent 262 Foreign Agent (Base Protocol) 263 | 264 +--------------------------------+ 265 | Arbitrary Routers | 266 +--------------------------------+ 267 | | | 268 Local Local Local 269 Foreign Foreign Foreign 270 Agent Agent Agent 272 +-------------+ +-------------+ 273 | Mobile Node | | Mobile Node | 274 +-------------+ +-------------+ 276 Fig 1 : Network Topology 278 2.2 Agent Discovery 280 MN detects a local foreign agent when it receives an agent 281 advertisement from it. This is equivalent to how the MN discovers an 282 agent in the base protocol. 284 2.3 Registration Process 286 Under the RAFA model, depending on the handoff scenarios which can 287 take place between the networks of HA<->LFA, FA<->LFA and LFA<->LFA, the 288 Registration Request will either be directly relayed to the HA via the 289 local foreign agent if the MN is "locally registered" or via the 290 regional aware foreign agent if the MN is "regionally registered". 291 Likewise, the Registration Reply from the HA will be relayed to the MN 292 either via the local foreign agent if the MN is "locally registered" or 293 via regional aware foreign agent if the MN is "regionally registered". 295 2.3.1 Processing of Registration Packets at LFA 297 During handoff, when the MN is not under the visitor list of a local 298 foreign agent, the local foreign agent will relay the first-time 299 Registration Request of the MN to the regional aware foreign agent. When 300 the local foreign agent receives a reply with the proper authentication 301 extension from the regional aware foreign agent, it will treat that the 302 MN is "regionally registered" with the regional aware foreign agent. On 303 the other hand, if it receives a reply directly from the HA, it will 304 treat the MN as "locally registered". 306 In the case of re-registration, if the MN is "regionally registered 307 and has a binding with the regional aware foreign agent, the local 308 foreign agent will relay the Registration Request to the regional aware 309 foreign agent. If the MN is "locally registered" and has a binding 310 directly with its HA, the local foreign agent will relay the 311 Registration Request to the HA just like in the base protocol. 313 2.3.2 Processing of Registration Packets at RAFA 315 Before the regional aware foreign agent relays the Registration 316 Request from a MN, it will check whether it has the information on the 317 shared registration key of the MN and its HA. 319 If it has, it will relay the MN's Registration Request to its HA. The 320 care of address field of the Registration Request is that of its 321 care-of-of address instead of the care-of-address of the LFA. The HA 322 will then have a mobility binding with the regional aware foreign agent. 324 Otherwise, the regional aware foreign agent just forwards the 325 Registration Request to the HA. The HA would then have a mobility 326 binding with the local foreign agent instead. 328 2.4 Typical Registration Scenarios 330 Different registration scenarios arise depending on whether 332 a) the regional aware foreign agent has the information of the shared 333 registration key between HA and its MN 334 b) the MN is in the local foreign agent's visitor list or not 335 c) the MN handoffs from network of HA to LFA, FA to LFA, LFA to HA, 336 LFA to FA or LFA to LFA 338 2.4.1 MN handoffs from a FA network to a LFA network or 339 MN handoffs from a HA network to a LFA network. 341 A first-time registration process at the local foreign agent consists 342 of: 344 a) MN receives a Mobility Agent Advertisement from a LFA 345 b) MN sends a Registration Request to the LFA 346 c) LFA forwards the received Registration Request to RAFA 347 d) Depending whether RAFA has the information on the shared key, it 348 either forwards or relays the Registration Request to the MN's HA. 349 If RAFA has the shared key information, it changes the 350 care-of-address field to its own care-of-address and relays to the 351 HA without modifying the registration lifetime. Else, it merely 352 forwards the Registration Request to the HA. 353 e) HA processes the Registration Request in a similar way to that of 354 the base protocol. It either sends a Registration Reply to RAFA if 355 the care-of-address field in the Request is that of RAFA or to LFA 356 if the care-of-address is that of LFA. 357 f) If RAFA receives the Registration Reply from the HA, it updates 358 its visiting MN list and relays the Reply to the LFA serving the 359 MN. The LFA in turn updates the MN in its visitor list as 360 "regionally registered" and sends the Reply to the visiting MN. 362 In the case if HA sends a Registration Reply to LFA, upon 363 receiving the reply, LFA updates the MN in its visitor list as 364 "locally registered" and sends the Reply to the visiting MN. 366 For subsequent re-registration, 368 a) For a "locally-registered MN", LFA relays the Registration 369 Request to HA. HA will return a Registration Reply to the MN via 370 LFA. 372 b) For a "regionally-registered MN", LFA relays the Registration 373 Request to HA via RAFA. HA will return a Registration Reply to the 374 MN via RAFA and LFA 376 2.4.2 MN handoffs from a LFA network to a FA network. 377 MN handoffs from a LFA network to a HA network. 379 In this case, the Registration process follows that of the 380 Registration process in the base protocol. 382 2.4.3 MN handoffs from a LFA network to a new LFA network within the 383 same domain of a RAFA 385 A first-time registration process at the new LFA consists of: 387 a) MN receives a Mobility Agent Advertisement from a new LFA 388 b) MN sends a Registration Request to the new LFA 389 c) The new LFA forwards the received Registration Request to the RAFA 390 d) Depending on whether MN is in its visitor list or not, RAFA either 391 forwards the Registration Request to the MN's HA if MN is not in 392 its visitor list or processes the Registration Request if MN is in 393 its visitor list. 395 If the MN is in its vistor list, RAFA updates the binding of 396 the MN to the care of address of the new LFA. It will also send a 397 Registration Reply on behalf of HA to the MN via the new LFA 398 using the information of the shared registration key between HA 399 and its MN. 400 e) When the new LFA receives the Registration Reply from either HA 401 or RAFA, it updates its visiting MN list and sends the reply to 402 the visiting MN. If it receives a Registration Reply from RAFA, 403 the MN is "regionally registered". Else, the MN is "locally 404 registered". 406 For subsequent re-registration, 408 a) For a "locally registered" MN, the new LFA relays the 409 Registration Request directly to HA. HA will return a Registration 410 Reply to the MN via the new LFA in a way similar to that in the 411 base protocol. 413 b) For "regionally registered" MN, the new LFA relays the 414 Registration Request to HA via RAFA. HA will return a Registration 415 Reply to the MN via RAFA and then the new LFA. 417 2.5 Datagram Routing 419 Any packets addressed to the MN will be intercepted by its HA. The HA 420 will tunnel the packets to the RAFA if the MN is "regionally 421 registered". Otherwise, it will tunnel it to LFA/FA. Note that the 422 registration process is transparent to the HA, and HA only tunnels 423 datagrams to the MN according to the care-of-address of the MN's 424 Registration Request as in the base protocol. 426 If the MN is "regionally registered", upon receiving the packets, 427 RAFA refers to its visitor list and tunnels the packets to the 428 appropriate LFA which is serving the MN. The LFA in turn forwards the 429 packets to the MN. Else, LFA which receives packets directly from the HA 430 will just detunnel and forward packets as in the base protocol. 432 2.6 Interoperability with the Base Protocol 434 The RAFA model is fully compatible with the base protocol as there 435 are no changes made in the MN and HA. Besides, it also supports all the 436 other implementations (related to Mobile-IP) such as route optimization, 437 simultaneous bindings at the HA etc. The network topology and operation 438 of the regional aware foreign agent and local foreign agent is totally 439 transparent to the MN and HA. 441 2.7 Key Management/Distribution Scheme 443 The introduction of RAFA provides access control for the foreign 444 network and reduces frequent distant registrations during handoff. It 445 also reduces the number of trusted entities since the number of RAFA is 446 much less than the number of mobility agents and hence reduces the 447 severity of key management problem for Mobile-IP. In that sense, it is 448 more scalable. However, it requires the information on the shared 449 Registration key of HA and its MN. Note that even without the 450 information, handoff can still take place at the base protocol level in 451 our network topology. If the MN from some home network often visits a 452 routing domain under the RAFA, then the effort of creating such a 453 association will be worthwhile. 455 Currently, besides manual configuration, there are many associated 456 key management/distribution approaches to solve this problem, and we can 457 do it either offline or dynamically. Doing it offline means that the 458 information of the shared key is distributed before the registration 459 process while doing it dynamically means that the information is 460 distributed during the registration process. But this requires slight 461 modification to the RAFA and LFA that we have described above, and the 462 RAFA must have a agreement with the HA about the distribution process. 464 Two of these approaches can be employed to distribute (either offline 465 or dynamically) the shared Registration key of HA and MN to RAFA. They 466 are : 468 a) THE HA AS A KEY DISTRIBUTION CENTER (KDC) 470 HA has a security association with RAFA. Using their shared key and 471 encryption, HA distributes its shared Registration key with its MN to 472 RAFA. 474 b) USING RAFA'S PUBLIC KEY 476 HA uses the public key of RAFA and encryption to distribute its 477 shared Registration key with its MN to RAFA. RAFA can then use its 478 private key to obtain the shared Registration key of HA and MN. 480 MD5 can be used here for the purpose of transmitting registration 481 keys and secure eavesdroppers. 483 For offline distribution, RAFA and LFA work in the same way as 484 described above. For dynamic distribution, this requires a bit of 485 cooperation between the RAFA and LFA. When the RAFA receives a 486 Registration Request, if it does not have the information of the shared 487 key but has a agreement (security association) with the HA to distribute 488 shared key information, it appends a Get Shared Key Notification 489 extension in the Registration Request to be sent to the HA while 490 notifying the LFA. The HA will then send the encrypted key to the RAFA 491 using the agreed key distribution method with the RAFA, besides the 492 normal Registration Reply to the LFA, which will treat the MN as 493 "temporary locally registered". 495 When RAFA receives the information of the shared key, it will notify 496 the LFA, which will then send the next Registration Request from the MN 497 to the RAFA. RAFA with the information of the shared key will then 498 proceed as described in the section on protocol overview. Note that in 499 our description of the handoff scenarios, we do not elaborate the key 500 distribution/management scheme as it is not part of the draft. 502 3. Local Foreign Agent (LFA) Considerations 504 The local foreign agent plays a mostly passive role just like the FA 505 in the base Mobile-IP protocol. It functions almost exactly like the FA 506 in the base protocol except the way it deals with Registration Request 507 and Reply packets. It always sends the first Registration Request of a 508 MN not in its visitor list to the regional aware foreign agent. It 509 obtains the relevant information from the Registration Reply in order to 510 decide whether to relay the subsequent Registration Request to the 511 regional aware foreign agent or home agent. 513 3.1 Configuration and Registration Tables 515 Each local foreign agent has a security association with a list of 516 regional aware foreign agents. In addition to the information maintained 517 for the base protocol in the visitor list entry, the following 518 information is also included - whether the MN is "regionally registered" 519 at the care-of-address of the regional aware foreign agent or "locally 520 registered" at its own care-of-address. 522 3.2 Receiving Registration Request 524 When the local foreign agent receives a Registration Request from an 525 MN, it follows the base Mobile-IP protocol except when sending out the 526 Registration Request. If the local foreign agent receives a Registration 527 Request from a MN not in its visitor list, it will relay the first time 528 Registration Request of the MN to the regional aware foreign agent 529 instead of the HA as specified in RFC2002. If the MN is in its visitor 530 list, it will check the list whether the MN is "regionally registered" 531 at the care-of-address of the regional aware foreign agent or "locally 532 registered" at its own care-of-address. If the MN is "regionally 533 registered", the local foreign agent will relay the Registration Request 534 packet to the regional aware foreign agent. Else, it will relay the 535 Registration Request to the HA as specified in the base protocol. 537 3.3 Receiving Registration Reply 539 When the local foreign agent receives a Registration Reply, besides 540 following the base Mobile-IP protocol, it will check whether there is 541 a RAFA-LFA authentication extension with type 0x3. If yes, this means 542 that the MN is "regionally registered" at the care of address of the 543 regional aware foreign agent and the authenticator value in the 544 Registration Reply will be checked. The local foreign agent will update 545 its visitor list with the appropriate information that the MN is 546 "regionally registered" and will relay the Reply to the MN with all 547 the Extensions after the Mobile-Home Authentication Extension being 548 removed. 550 If the authenticator is invalid, the local foreign agent will 551 silently discard the Reply and log the event as security exception. The 552 local foreign agent also will reject the MN's registration and send a 553 Registration Reply to the MN with Code 68. If no, this means that the MN 554 is "locally registered" at its own care-of-address. The local foreign 555 agent will update its visitor lists entry for the MN to reflect that the 556 MN is "locally registered" after doing the validity check and then it 557 forwards the Reply to the MN as specified in the base protocol. 559 3.4 Routing of Datagrams 561 If the MN is "locally registered", the local foreign agent will 562 receive encapsulated datagrams from HA directly. Else, the local foreign 563 agent will receive encapsulated datagrams from the HA via the regional 564 aware foreign agent. The local foreign agent will decapsulate the 565 datagrams and forward them to the MN in exactly the same way as the FA 566 in the base protocol. Likewise, datagrams sent by the MN are generally 567 delivered to their destination using the standard IP routing mechanisms, 568 not necessarily passing through the regional aware foreign agent. 570 4. Regional Aware Foreign Agent (RAFA) Considerations 572 The regional aware foreign agent plays a pro-active role in the 573 registration process. It performs local registration during handoff. It 574 is used to establish the local mobility binding of a MN. The local 575 mobility binding will enable it to tunnel the datagrams to the 576 respective local foreign agent which is serving the MN. Through the 577 registration process, it provides access control (authorization) over 578 the local foreign networks and prevent an illegal MN from stealing 579 services in a wider routing domain. It determines the services that the 580 foreign network will provide for the MN. 582 4.1 Configuration and Registration Table 584 Each regional aware foreign agent must be configured with a list of 585 the local foreign agents which are under its routing domain with 586 security associations. It may have information of the secret key shared 587 between the MN and HA. In addition, for each pending or current 588 registration, the regional aware foreign agent must maintain a visitor 589 list entry containing the following information obtained from the MN's 590 Registration Request. 591 - the IP Source Address (the mobile node's Home Address) 592 - the IP Destination Address 593 - the Home Agent address 594 - the care-of-address of the local foreign agent 595 - the Identification field 596 - the requested registration Lifetime 597 - the remaining Lifetime of the pending or current registration 598 The regional aware foreign agent may configure a maximum number of 599 pending registrations that it is willing to maintain and additional 600 registrations should then be rejected with code 66 just like that in the 601 base protocol. 603 4.2 Receiving Registration Request 605 When the regional aware foreign agent receives a Registration Request 606 packet from the local foreign agent, it will perform the same validity 607 check as that of the local foreign agent. If the regional aware foreign 608 agent receives a Registration Request from a MN (via local foreign 609 agent) in its visitor list, it will send a positive Registration Reply 610 to the MN via local foreign agent using the information of the secret 611 key shared by MN and HA. The Registration Reply contains the basic codes 612 to inform the MN about the status of its Request plus a RAFA-LFA 613 authentication extension to inform the local foreign agent that the MN 614 is "regionally registered" or "locally registered", along with the 615 lifetime granted by the regional aware foreign agent, which must not be 616 great enough to last longer than time at which the binding at the HA 617 would expire, as determined by the original lifetime granted by the MN's 618 home agent in the last Registration Request approved by the HA. 620 It must also update its record of the MN's mobility binding of which 621 the care-of-address of the MN is the new local foreign agent and the 622 Registration Request will then be silently discarded without forwarding 623 to the HA. If the regional aware foreign agent receives a Registration 624 Request from a MN not in its visitor list, it will check whether it has 625 the information of the secret key shared between the MN and HA, and 626 the care-of-address field of the Request is one of the local foreign 627 agent in its list. If there is information on the secret key and the 628 care-of-address is one of the local foreign agent, the regional aware 629 foreign agent will change the care-of-address field in the Registration 630 Request to its own care-of-address with a new MD5 authenticator [4] 631 being recomputed, and forward the Registration Request to the HA. It 632 must also record the new pending Request for the MN. If there is no 633 information of the secret key shared by MN and HA, the regional aware 634 foreign agent will relay the original Registration Request to the HA 635 without recording the pending Request if it allows services to an 636 anonymous MN of its local foreign agent network. 638 4.3 Receiving Registration Reply 640 When the regional aware foreign agent receives a Registration Reply 641 message, it will search its visitor list for a pending Registration 642 Request with the same MN's home address as indicated in the Reply. If no 643 pending Request is found, the regional aware foreign agent will silently 644 discard the Reply. Else, it will forward the valid Registration Reply to 645 the local foreign agent after appending the RAFA-LFA authentication 646 Extension to the Reply using implicitly its own care-of-address as the 647 value for computed authenticator value. It then updates its visitor list 648 and resets its timer of the lifetime of the registration to the lifetime 649 granted in the Registration Reply like that of the FA in the base 650 protocol. 652 4.4 Routing of Datagrams 654 The regional aware foreign agent has a binding for the mobile node 655 which shows that the MN is "regionally registered" at the 656 care-of-address of the next local foreign agent. Thus, a datagram 657 arriving from the home agent will be decapsulated and re-encapsulated 658 at the regional aware foreign agent with a new tunnel endpoint which is 659 the care-of-address of the local foreign agent which can deliver the 660 datagram to the mobile node. The actual decapsulation need not occur at 661 the regional aware foreign agent. Instead, the regional aware foreign 662 agent can merely change the source and destination IP addresses of the 663 encapsulating IP header. Note that the regional aware foreign agent is 664 not involved in any datagrams routing for MN which is "locally 665 registered" at the care-of-address of the local foreign agent. 667 4.5 Access Control (Authorization)/ Non-repudiation / Billing for 668 Foreign Network 670 The registration mechanism of which the local foreign agent always 671 relays the first Registration Request from the MN during handoff to the 672 regional aware foreign agent if MN is not in its visitor list provides 673 access control (authorization) over the visiting MNs for the regional 674 aware foreign agent. It can decide which MN is allowed visiting rights 675 and what network resources may be used by the visiting MN, whether it is 676 "regionally registered" or "locally registered". Priority can be given 677 to the MN which is "regionally registered" than one which is "locally 678 registered". Of course, the regional aware foreign agent can give equal 679 priority to all MNs but a "regionally registered" MN (registered MN) 680 will have better handoff performance than a "locally registered" MN 681 (anonymous MN). 683 It can also control the number of visiting anonymous MNs. If the 684 traffic is low, the regional aware foreign agent may choose to provide 685 services for more anonymous MNs. If the traffic is high, it may even 686 choose to drop services for anonymous MN by sending a specific request 687 to the local foreign agent so that it can provide MNs which are 688 "regionally registered" with the scarce wireless network resources. Note 689 that the concept here is similar to the access control level allowed for 690 a host (anonymous login or user login) in any ftp session which is 691 commonly used in the Internet. For MN which is "regionally registered", 692 the regional aware foreign agent can also log some of its Requests so 693 that the MN cannot falsely deny that it originated the Requests at a 694 later time (non-repudiation). Likewise, it can log the Reply from the HA 695 so that the HA cannot falsely deny that it originated the Reply. 696 Nevertheless, it requires a trusted relationship between the HA and the 697 RAFA. 699 The RAFA model also makes it easy for billing purposes when an MN 700 uses the precious wireless resources of a foreign network. Billing can 701 be easily done on a per RAFA basis (under the same administrative 702 domain) instead of per FA basis (may be under different administrative 703 domain). 705 Hence, the RAFA model offers some kinds of security features, access 706 control and easy billing mechanisms that are especially important and 707 useful for commercial service providers. These are necessary for the 708 deployment of Mobile IP. 710 4.6 Solving Inherent Functionality Problem of Mobile IP 712 The inherent functionality problem of any correspondent node in the 713 old foreign agent network will not be able to route datagrams to the MN 714 when it moves to a new foreign network until the registration lifetime 715 of the binding has expired which may take hundreds of seconds can be 716 easily solved in the RAFA model. The regional aware foreign agent may 717 send an explicit de-registration (preferably after a few seconds so as 718 to support simultanous bindings during the vulnerable period of handoff) 719 to the former foreign agent network to inform about the movement of MN. 720 This will enable the foreign agent to delete the MN's routing entry in 721 the routing table or release any resources (such as radio channel 722 reservations) consumed previously by an MN that is not in its network, 723 rather than waiting for its registration lifetime to expire. 725 4.7 Simultaneous Bindings 727 The regional aware foreign agent can implicitly maintain multiple 728 simultaneous bindings for an MN, so that a copy of each datagram will be 729 tunneled to each active care-of-address of the local foreign agents 730 during handoff to the MN. Note that this simultaneous registration done 731 at the regional aware foreign agent (instead of HA in the base protocol) 732 is feasible as the duplication problem is not that severe since the 733 local foreign agents are normally just a few hops away from the regional 734 aware foreign agent. 736 4.8 Autonomous Mode Operation 738 The RAFA model offers the possibility of autonomous mode operation 739 similar to that of the MOBITEX Network Architecture [5] if the link or 740 network connectivity between the regional aware foreign agent and MN's 741 HA is temporarily lost. This means that a MN can still communicate with 742 another MN if they are under the same local foreign agent or regional 743 aware foreign agent. The regional aware foreign agent can choose to 744 reply temporarily on behalf of the HA so that all the routing entries in 745 the local foreign agent and MN will remain intact for datagram routing 746 to take place. For a MN communicating with another MN under the same 747 local foreign agent, it will be able to do so as the route entry or 748 network resource is still available. However, for a MN communicating 749 with another MN under the same RAFA, LFA need to tunnel the packets from 750 the MN to RAFA which will then de-capsulated and tunnel the packets to 751 the appropriate LFA. 753 4.9 Multicast Data Routing Using the RAFA Model 755 The RAFA model supports multicast services similar to the base 756 protocol. MN can either join the multicast group via a (local) multicast 757 router on the visited subnet or via a bi-directional tunnel to its home 758 agent. However, the RAFA model can reduce the multicast backbone traffic 759 compared to the base protocol. If more than one of its MNs which are 760 served by different FAs join the same multicast group, then the HA needs 761 only to send a single copy of the multicast to RAFA instead of multiple 762 copies of the multicast to the foreign agents. The reduction in backbone 763 traffic may be significant considering the fact that MNs of the same 764 multicast group have a tendency to be served by different FAs since they 765 may handoff to a foreign network frequently. Note that providing 766 multicast services for MNs that handoff frequently may be easy to do so 767 using the regional aware foreign agent as it is in charge of a larger 768 routing domain. 770 4.10 Other Capabilities 772 The regional aware foreign agent can provide a mean for datagrams in 773 flight to the MN's previous local foreign agent to be forwarded securely 774 to its new local foreign agent. It can employ datagram buffering for 775 critical data at the local foreign agent serving the MN before a 776 handoff. It can then explicitly ask the local foreign agent to forward 777 the datagrams to another local foreign agent in a secure manner so that 778 there would be no loss of datagrams for the MN during handoff. 779 Simulation [6] has shown that buffering and forwarding last few packets 780 of the datagrams can significantly improve the TCP throughput during 781 handoff. 783 Another capability of the RAFA model is that NAT and IP Masquerading 784 techniques in the RAFA model as the care-of-address of the local foreign 785 agent need not be real. 787 4.11 Load balancing 789 Each of the regional aware foreign agent can occasionally probe their 790 regional aware foreign agent on the traffic load that each of them is 791 supporting. If the traffic load is high, it can order the local foreign 792 agent to forward new Requests to another regional aware foreign agent 793 with the least traffic. 795 5. Message Format and Extensions 797 There are a few new message formats and authentication Extensions in 798 the RAFA model. 800 5.1. De-registration Request 802 De-registration Request is sent by the regional aware foreign agent 803 to the local foreign agent to delete the route entry of the MN when it 804 moves to a new local foreign agent network. 806 IP fields: 807 Source Address - The IP address of the regional aware foreign 808 agent 809 Destination Address - The IP address of the local foreign agent 811 UDP fields 812 Source Ports - Variable 813 Destination Port - 434 815 The UDP header is followed by the fields shown below 817 0 1 2 3 4 819 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 820 +--------------------------------------------------------------+ 821 | Type | Code | Time | 822 +--------------------------------------------------------------+ 823 | Care-of-address of RAFA | 824 +--------------------------------------------------------------+ 825 | | 826 | Identification | 827 | | 828 +--------------------------------------------------------------+ 829 | Extensions... | 830 +--------------------------------------------------------------+ 832 Type - 38 834 Code - 3 to indicate deletion 836 Time - The interval (seconds) needed to delete the route entry after 837 receiving a de-registration request 839 Care-of-Address - IP address of the regional aware foreign agent 841 Identification - A 64 bit number used for protecting against reply 842 attacks of these messages 844 Extension - This is followed by the RAFA-LFA authentication Extension 846 5.2. Get Shared Key Notification Extension 848 This extension is appended in the Registration Request message by the 849 RAFA so that the HA will send a encryted information of the shared key 850 of HA and its MN to it. Note that this extension is only required if we 851 want to support dynamic distribution of information of the shared key, 852 and may not be part of the RAFA model. 854 0 1 2 3 4 856 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 857 +--------------------------------------------------------------+ 858 | Type | Code | Lifetime | 859 +--------------------------------------------------------------+ 860 | RAFA's address | 861 +--------------------------------------------------------------+ 862 | | 863 | Identification | 864 | | 865 +--------------------------------------------------------------+ 866 | Extensions... | 867 +--------------------------------------------------------------+ 869 Type - 11 871 Code - 5 to indicate the key distribution algorithm 873 Lifetime - time interval of which the Request is valid 875 RAFA's Address - IP address of the regional aware foreign agent 877 Identification - A 64 bit number used for protecting against reply 878 attacks of these messages 880 Extensions - followed by the HA-RAFA extension 882 5.3. RAFA-LFA Authentication Extension 884 This extension is appended in the Registration Reply message by the 885 RAFA so that the LFA will know that the MN is "regionally registered". 886 The fields used are exactly the same as the base protocol except the 887 shared secret key is that between the RAFA and the LFA. 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type | Length | SPI .... 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 ... SPI (cont.) | Authenticator ... 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 Type 0x3 899 Length 4 plus the number of bytes in the Authenticator. 901 SPI Security Parameter Index (4 bytes). An opaque identifier 903 Authenticator 904 (variable length) 906 5.4. HA-RAFA Authentication Extension 908 This extension is appended in the Registration Request by the RAFA so 909 that the HA will send a encrypted version of the information of the 910 shared key to RAFA. It is required only if we want to distribute the 911 information of the shared key dynamically, and is not neccesary required 912 in the RAFA model. 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Type | Length | SPI .... 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | ... SPI (cont.) | Authenticator ... 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Type 0x4 924 Length 4 plus the number of bytes in the Authenticator. 926 SPI Security Parameter Index (4 bytes). An opaque identifier 928 Authenticator 929 (variable length) 931 6. Fast Handoff Considerations 933 The Mobile-IP base protocol standard specifies a general handoff 934 protocol for both wired and wireless networks. We believe that the 935 handoff protocol is more suited to handle portability and global 936 mobility (movement across different administrative domain) than local 937 mobility (within the same administrative domains where handoffs are 938 frequent like a network of wireless cells). In the Mobile-IP base 939 protocol, a handoff even in overlapping wireless small cells is not 940 seamless due to two main reasons - delay due to distant registration 941 and operational procedure of MN when it hears a new agent advertisement 942 (MN only registers with a new agent if it does not hear three 943 consecutive advertisements from the old FA which incurs a average delay 944 of 2.5 times the agent advertisement interval). 946 Using the RAFA model, we can reduce the delay due to distant 947 registration during handoff. To reduce the delay due to the 948 operational procedures of MN, we can either reduce the agent 949 advertisement interval or modify the handoff protocol of MN. We propose 950 a slight modification to the handoff protocol to provide seamless 951 handoff. However, it requires some minor changes in the LFA and MN. Note 952 that the changes in MN is to solve the handoff latency and is not 953 necessarily required in the RAFA model. 955 Instead of waiting for three consecutive missing advertisements in 956 the overlapping cells, the MN will immediately registers with the local 957 foreign agent once it hears a new advertisement. Note that this slight 958 modification is transparent to the HA and mobility agents in the base 959 protocol. This simple modification combined with simultaneous bindings 960 operation at the regional aware foreign agent will provide seamless 961 handoff between the local foreign agent networks which are overlapping. 962 Another option is to arrange the datagrams in flight when the MN moves 963 to be forwarded to the new LFA which will provide more seamless handoff. 964 In order to be interoperable with the base protocol, MN can operate in 965 two modes - base or enhanced mode according to the agent advertisement 966 it hears. 968 6.1 Local Foreign Agent (LFA) Considerations 970 There is no modification to the way the LFA handles the Registration 971 Request and Registration Reply. Only the format of the agent 972 advertisement would be changed. 974 6.1.1 Sending Agent Advertisement 976 A local foreign agent wishing to support the enhanced MN advertises 977 its services using the Mobility Extension to ICMP Router Advertisement 978 which is defined in the base Mobile-IP document. One bit (E) is added to 979 the flag bits in the Agent Advertisement message to indicate its 980 intention to support the enhanced MN with the modified handoff protocol. 981 (all other fields not defined here are unchanged from the definition 982 given in the base mobile-IP). 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Type | Length | Sequence Number | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Registration Lifetime |R|B|H|F|M|G|V|E| reserved | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | zero or more Care-of Addresses | 992 | ... | 994 E If set, the local foreign agent is advertising 995 its willingness to support the enhanced MN 997 6.2 MN considerations 999 MN can operate in two modes - the base IETF mode and Enhanced Mode. 1000 By default, the MN is operating in the base mode. It would only switch 1001 to Enhanced mode if it receives an agent adevrtisement with the "E" bit 1002 set. 1004 6.2.1 Receiving Agent Advertisement 1006 When an MN receives an agent advertisement, it checks to see if the 1007 "E" bit is set or not. If yes, the mobile node will switch from normal 1008 base mode to Enhanced Mode. Instead of waiting for three missing 1009 consecutive advertisements from the old FA before it sends its first 1010 Registration Request, the MN will immediately send a Registration 1011 Request. 1013 6.3 Regional Aware Foreign Agent Considerations 1015 The regional aware foreign agent should support simultaneous bindings 1016 if the local foreign agent supports the enhanced mode. A copy of each 1017 datagram will be tunneled to each active care-of-address of the local 1018 foreign agents to provide more seamless handoff to the MN. 1020 References 1022 [1] Charles Perkins, Editor, "IP Mobility Support", RFC 2002, October 1023 1996 1025 [2] Charles Perkins, "Mobile-IP Local Registration with Hierachical 1026 Foreign Agents", Internet Draft, 1027 draft-perkins-mobileip-hierfa-00.txt, February 1996, Work in 1028 Progress 1030 [3] M.C. Chuah, Y. Li, "Distributed Registration Extension to Mobile 1031 IP", Internet Draft, draft-chuahli-mobileip-dremip-00.txt", October 1032 1997 1034 [4] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", 1035 RFC 1321, April 1992. 1037 [5] Salkintzis, A.K. and Chamzas, C. "Mobile Packet Data Technology: An 1038 Insight into MOBILTEX Architecture", IEEE Personal Communications 1039 Mag, Feb 1997, pp. 10-18 1041 [6] W. Woo, C.M Leung, "Handoff Enhancement in Mobile-IP Environment", 1042 Proceedings of ICUPC - 5th International Conference on Universal 1043 Personal Communications, 29 Sept. - 2 Oct. 1996 1045 Acknowledgements 1047 Special thanks to K.M. Chan, C.C. Foo, K.J. Loh, Y.Z. Li and S.W. Gan 1048 for their advice. 1050 Special thanks to the Linux Community for their advice in the 1051 implementation of RAFA scheme. 1053 RAFA research and implemention is a Masters Project at the National 1054 University of Singapore. 1056 Author's Address 1058 Dr K. C. CHUA 1059 Deputy Director 1061 Centre for Wireless Communications Ph: +65 8729 030 1062 20 Science Park Road DID: +65 8709 222 1063 #02-34/37, Teletech Park Fax: +65 7795 441 1064 Singapore Science Park II 1065 Singapore 117674 1067 Email: eleckc@leonis.nus.edu.sg 1068 URL: www.cwc.nus.edu.sg 1070 S. F. Foo 1071 National University of Singapore 1072 Department of Electrical Engineering 1073 Lower Kent Ridge Cresent 1074 Singapore 119260 1076 Email: engp7498@leonis.nus.edu.sg Ph: +65 8745 095