idnits 2.17.1 draft-becker-mobileip-ipm-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 473 has weird spacing: '...pecific acces...' == Line 475 has weird spacing: '...re able to un...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '11' is mentioned on line 315, but not defined == Unused Reference: '3' is defined on line 531, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2002 (ref. '2') (Obsoleted by RFC 3220) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-04 == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-03 == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-authent-07 == Outdated reference: A later version (-01) exists of draft-bpatil-mobileip-sec-guide-00 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Carey B. Becker 2 Category: Informational Basavaraj Patil 3 Title: Emad Qaddoura 4 Date: October 1999 Nortel Networks 6 IP Mobility Architecture Framework 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Today, the wireless network arena is made up of different types of 33 access (TDMA, CDMA, GSM, etc) and core network technologies (IS-41 34 and MAP over SS7, etc). The heterogeneous nature of today's 35 wireless and wireline packet data networks limits the scope of 36 mobility between these heterogeneous networks. However, as these 37 heterogeneous networks evolve, the mobility management provided by 38 them must evolve to ensure seamless roaming between the networks. 40 With the convergence of voice and data, networks of the future will 41 be built on IP packet switched technology, mostly due to inherent 42 advantages offered by the technology. 44 This document identifies several drivers that provide input for an 45 IP Mobility based network and also describes a high level IP 46 Mobility architecture that extends the current third generation 47 IMT2000 wireless architecture and builds on Mobile IP concepts. 49 Table Of Contents 51 1 Introduction............................................2 53 2 IP Mobility Architecture................................4 55 2.1 Network Reference Model...............................6 57 2.2 Home Network..........................................6 59 2.2.1 Home Network Mobility Components....................7 61 2.3 Foreign Network.......................................9 63 2.3.1 Foreign Network Mobility Components................10 65 2.4 Access Network.......................................11 67 2.5 IP Network...........................................11 69 2.6 Mobile Nodes.........................................11 71 2.7 User Identification..................................12 73 3 Conclusion.............................................12 75 4 Acknowledgements.......................................12 77 5 References.............................................13 79 6 Authors' Addresses.....................................14 81 1. Introduction 83 User mobility is an integral part of today's and future wireless 84 and wireline packet data networks. Today, the wireless network 85 arena is made up of different types of access (TDMA, CDMA, GSM, 86 802.11, etc) and core network technologies (IS-41 and MAP over SS7, 87 etc.). The heterogeneous nature of today's wireless and wireline 88 packet data networks limits the scope of mobility between these 89 heterogeneous networks. However, as these heterogeneous networks 90 evolve, the mobility management provided by them must evolve to 91 ensure seamless roaming between the networks. 93 With the convergence of voice networks and data networks, networks 94 of the future will be built on IP packet switched technology, 95 mostly due to inherent advantages offered by the technology (the 96 details of which are beyond the scope of this document). The change 97 from the current SS7 based wireless networks to IP centric wireless 98 networks is already happening. In the very near future, mobile 99 devices that support IP stacks will also proliferate. 101 The combination of these two concepts, the networks moving to IP 102 packet switched technology and the evolution of mobility management 103 to ensure seamless roaming, defines what we call IP Mobility. There 104 are several drivers that are paving the way for defining an 105 architecture that is IP Mobility enabled. Some of these are: 107 1. The network should allow for seamless roaming between 108 heterogeneous wireless and wireline networks. 110 2. The network infrastructure should be access independent. 112 As our wireless networks evolve, it will remain a fact of life 113 that we will need to support multiple types of wireless 114 accesses, e.g., CDMA, TDMA, etc. Users should be able to roam 115 between these different access types via a mobile device that 116 supports access specific interface cards which provide the 117 appropriate 'layer 2' access. However, the current networking 118 protocols that perform the mobility management functions 119 specific to the heterogeneous technologies can evolve into a 120 single protocol. 122 3. Mobility needs to be based on the users, not the device used 123 by the user. 125 GSM already supports the concept of mobility being based on a 126 user via the International Mobile Subscriber Identity (IMSI), 127 although the IMSI is not known by the user. In North American 128 Cellular systems, e.g., TDMA, CDMA, etc, a user is identified 129 via a Mobile Identification Number (MIN) that is specific to 130 the mobile device. This association needs to be separated. 131 Also, both of these concepts are based on users being assigned 132 'telephony' user IDs, which are solely based on digits. User 133 IDs should not be restricted to digit only identifiers or 134 restricted to the realm of telephony IDs. 136 4. A roaming user should only need a single subscription to 137 access a home network. 139 Within the scope of packet data services being defined for 140 CDMA systems, a user must have a subscription with a cellular 141 provider to gain access to the cellular network. After which 142 the user is authenticated, the user's mobile device is put on 143 a traffic channel to allow the user's mobile IP subscription 144 to be authenticated with the users home network. The multiple 145 subscriptions translate to multiple unwanted registrations and 146 a waste of radio resources for the second registration. 148 5. The network should support the removal of triangle routes 149 within the network. 151 Triangle routes (which contain routing anchor point) can be 152 established at two points, 1) at the home network as defined 153 in mobile IP [2] and 2) at the foreign network as proposed in 154 [4] and [5]. The network needs to support a mechanism, similar 155 to what is defined in [6], which can alleviate the problems 156 associated with anchor points. The network needs to support 157 policies that allow or disallow triangle routes, e.g., a 158 policy that wants to hide knowledge of where the user is 159 located. 161 6. Service providers would like to deploy the same network 162 infrastructure in both their wireline and wireless networks. 164 One of the major business drivers is to gain economies of 165 scale from deploying the same network infrastructure, e.g., 166 network operation, services platforms, etc, within the service 167 provider's networks that is independent of the access 168 networks. However, mechanisms should be provided that will 169 allow the networks to be optimized on the type of access 170 network. 172 None of the current packet data technologies, GPRS, Mobile IP and 173 CDPD, support all the concepts depicted in the above drivers. An 174 architecture must be defined that can provide the functions that 175 ensure true seamless roaming within a mobility enabled IP network. 177 2. IP Mobility Architecture 179 To be able to achieve a mobility enabled IP network that satisfies 180 the drivers stated in the previous section, an enhanced 181 architecture needs to be defined that extends the current third 182 generation IMT2000 wireless architecture and mobile IP. This 183 section defines such an architecture. 185 The intent of defining this architecture is to propose a strategy 186 and a framework for next generation networks that are mobility 187 enabled. The transition strategies required by the packet data 188 technologies to evolve to this architecture are outside the scope 189 of this document. However, it is an important item that should be 190 addressed as part of the work group discussions. 192 The architecture described in this draft is not complete but is 193 intended to provide a starting point for further enhancements and 194 development. It does not include some necessary concepts; one 195 example being brokers/proxies as described in [7] and [8]. However, 196 it does contain a substantial subset of what is needed to provide 197 mobility within IP networks. 199 2.1. Network Reference Model 201 The following figure depicts the logical view of the proposed 202 network architecture. 204 + -----------------------------------------------------------+ 205 | +-----+ +------+ +-----------+ +----------------+ | 206 | | DNS | | DHCP | | Unified | | Authentication | | 207 | +-----+ +------+ | Directory | | Server | | 208 | +-----------+ +----------------+ | 209 | | Home 210 | +------------+ +----------+ +------+ | Network 211 | | Mobility | | Security | | AAA+ | | 212 | | Mgmt (HA+) | | Gateway | +------+ | 213 | +------------+ +----------+ | 214 + -----------------------------------------------------------+ 215 | | IP network 216 | | 217 + -----------------------------------------------------------+ 218 | +------------+ +----------+ +------+ +------+ | 219 | | Mobility | | Security | | AAA+ | | DHCP | | Foreign 220 | | Mgmt (FA+) | | Gateway | +------+ +------+ | Network 221 | +------------+ +----------+ | 222 + -----------------------------------------------------------+ 223 || 224 || 225 + -----------------------------------------------------------+ 226 | +----------+ +-----------+ +-----------+ | 227 | | Location | | Cell Site | . . . | Cell Site | | Access 228 | | Tracking | +-----------+ +-----------+ | Network 229 | +----------+ | 230 + -----------------------------------------------------------+ 232 Figure 1: Network Reference Model 234 The following sections describe the functionality of the components 235 of the network reference model. 237 2.2. Home Network 239 The Home Network is very similar in concept to the home network 240 defined in [2] and the home network defined in the wireless 241 networks. Basically, the Home network is a combination of the two 242 with some extensions. 244 Some of the relevant functions of the Home Network as they relate 245 to mobility are: 247 * It is the home network that 'owns' the mobile user's 248 subscription. 250 * Maintains the mobile user's subscription and associated 251 subscriber profile. 253 * Provides mobility to subscribers on a 'larger' scale. It is 254 responsible for maintaining the current location of the mobile 255 user. 257 * Allocation of mobile node IP addresses 259 * Supports a 'unified' directory for subscriber profiles 260 independent of the access network type. 262 * Stores policies and profiles associated with mobile users. 264 * Provides Authorization functions associated with the mobile 265 user. 267 * May provide the Authentication functions required to 268 authenticate the mobile user. 270 * Support Service Level Agreements (SLA) with all Foreign 271 Networks it wants its users to roam in. 273 * Support a policy that allows 'hiding' the user's location. 274 This policy will mandate that the home be an anchor point for 275 datagrams sent to it's users while they are roaming. 277 2.2.1. Home Network Mobility Components 279 The following describes some functions associated with the 280 components of the Home network. 282 * Mobility Management (MM) 284 Mobility management is comprised of two high level concepts, 285 1) mobile user location tracking and 2) performing routing 286 update functions for mobile nodes. These functions are very 287 similar to what Home Agents do in [2] and what Home Location 288 Registers do in wireless networks, with some enhancements. The 289 location tracking function of the MM expects to receive a 290 single mobile user registration message from the foreign 291 networks that is independent of the access network used at the 292 foreign network. This is true for all messages sent from the 293 foreign networks to the home networks. The architecture 294 supports the concept of a centralized location tracking 295 function for the home network. However, the architecture does 296 not preclude the idea of having a distributed location 297 tracking function. 299 * AAA+ 301 The protocol used to send messages between a foreign network 302 and a home network is the AAA+ protocol, with extensions to 303 support mobility management (hence AAA+). Another important 304 concept used within the AAA+ framework is that the AAA+ 305 between a foreign network and a home network. This single 306 security association can be used to alleviate the need for 307 security associations between mobile IP FA and HA components 308 and dynamic session key establishment as suggested in [2] and 309 [4]. The AAA+ protocol and server may also interface with the 310 mobility agents in the network in order to assist in the 311 generation and transfer of session keys used in the network by 312 the mobile node and the network components in the serving and 313 home network for encryption and privacy as suggested in [10]. 314 It is suggested that the security framework be based on IPSec 315 as suggested in [11]. 317 * Authentication Server 319 The authentication server is a combination of certificate 320 authority, key management system, and digital signature 321 verification server. The authentication server receives 322 roaming mobile user authentication requests via the AAA+ and 323 authenticates the user. 325 * Unified Directory 327 The Unified Directory is the database that contains all the 328 home user's subscriber profiles, network policies, and any 329 other data that needs to be stored at the Home Network. The 330 subscriber profiles in the directory are independent of the 331 access network association. Access to data in the Unified 332 Directory from other components within the network is via a 333 single protocol, LDAP. 335 * DHCP 337 In the Home Network, the DHCP server may be used to assign IP 338 addresses to roaming mobile stations that do not have a 339 permanently configured IP. 341 * DNS 343 In the home network, Dynamic DNS is the protocol used to 344 update DNS with a roaming user's mobile node allocated IP 345 address. If the home network is responsible for allocating the 346 IP address, DNS is updated by DHCP. If the foreign network is 347 responsible for allocating the IP address, the home network 348 mobility manager will update DNS. 350 * Security gateway 352 The security gateway performs all the necessary 'firewall' 353 functions. 355 2.3. Foreign Network 357 The Foreign Network is very similar in concept to the foreign 358 network defined in [2] and the foreign network defined in the 359 wireless networks. Basically, the Foreign Network is a combination 360 of the two with some extensions. 362 Some of the relevant functions of the Foreign Network as they 363 relate to mobility are: 365 * It is the serving area network for one or more access 366 networks. 368 * It can support multiple Access Networks (AN), where each AN is 369 associated with a different technology, e.g. one AN may be a 370 CDMA RAN, another AN may be GSM RAN. 372 * Provides mobility management for mobility within the access 373 networks that it serves. 375 * Provides local services. 377 * Routes data to the mobile user via the access link that the 378 mobile node is currently attached to. 380 * Routes data that is sent by the mobile user. 382 * Allocates IP address to be used by the mobile nodes if allowed 383 by policy. 385 * Support for the establishment of Service Level Agreements 386 (SLA) with all Home Networks that want to allow their user to 387 roam within the foreign network. 389 * Support for user authentication to be provided by at the 390 foreign network after the user initially registers. 392 2.3.1. Foreign Network Mobility Components 394 The following describes some functions associated with the 395 components of the Foreign Network. 397 * Mobility Management (MM) 399 Foreign Network's mobility management is comprised to three 400 high level concepts, mobile user location tracking within the 401 foreign network, handoffs between foreign networks, and 402 performing routing update functions for datagram delivery to 403 the access network/mobile node. These functions are very 404 similar to what Foreign Agents do in [2], with some 405 enhancements. The location tracking function of the MM expects 406 to receive the same formatted mobile user registration message 407 from each of the heterogeneous access network. The 408 architecture supports the concept of a centralized location 409 tracking function within the foreign network. However, the 410 architecture does not preclude the idea of having a 411 distributed location tracking function. 413 * AAA+ 415 The protocol used to send messages between a foreign network 416 and a home network is the AAA protocol, with extensions to 417 support mobility management (hence AAA+). Another important 418 concept used within the AAA+ framework is that the AAA+ 419 between a foreign network and a home network. This single 420 security association can be used to alleviate the need for 421 security associations between mobile IP FA and HA components 422 and dynamic session key establishment. It is suggested that 423 the security framework be based on IPSec. 425 * DHCP 427 In the Foreign Network, the DHCP server may be used to 1) 428 assign co-located care of addresses to private network mobile 429 nodes and 2) if policies indicate, assign IP addresses to 430 roaming mobile stations that do not have a permanently 431 configured IP. 433 * Security Gateway 435 The security gateway performs all the necessary 'firewall' 436 functions. It supports ESP IPSec security associations with 437 other network security gateways. 439 2.4. Access Network 441 The Access Network defines the 'layer 2' access technology used by 442 a user to gain access to a Foreign Network. The access network can 443 be one of several types: 445 * North American Cellular and GSM radio access networks (and 446 their evolution to 3rd generation) 448 * 802.11 wireless LAN access 450 * 802.3 wireline LAN access 452 * Dial-up network access 454 Figure 1 above only depicts an access network associated with a 455 wireless network. 457 2.5. IP Network 459 The IP network provides the routing of datagrams between Home 460 Networks and Foreign Networks. The IP network can be the public 461 Internet or a closed network such as those defined in IMT2000 462 standards. 464 2.6. Mobile Nodes 466 It can be argued that all nodes in the future will be mobile, or at 467 least have the potential to be mobile. Stationary nodes, generally 468 called correspondent nodes in [2], will only have to be equipped 469 with the appropriate access specific PC card(s) and software that 470 can perform the network registration functions. 472 The mobile node's interface(I/F) cards provide the 'layer 2' 473 interface to the specific access network. For each of the access 474 network types, there is a layer 2 address associated with the I/F 475 card so the access network and mobile node are able to uniquely 476 address each other. Mobile node software will need to determine 477 when and which access networks are available and perform the 478 appropriate registration functions. 480 Both types of nodes will have to support tunneling, e.g., IP in IP 481 encapsulation [9], to a roaming mobile node's care-of addresses. 482 This will help alleviate the triangle routing (anchor points) 483 issue. 485 2.7. User Identification 487 The architecture suggests user identities be based the Network 488 Access Identifier (NAI) as defined in [1]. The NAI allows for a 489 highly flexible definition of a user which does not restrict user 490 identities to digits only. 492 3. Conclusion 494 The architecture defined in this document provides a foundation 495 that will allow true seamless roaming within a mobility enabled IP 496 network. 498 Some of the advantages provided by the architecture are: 500 * A user may have a single subscription with a home network that 501 allows for roaming within all foreign networks that have 502 service level agreements with the home network. 504 * Mobility being based on the user, not the device used by the 505 user. 507 * A single security framework based on IPSec and used by the 508 AAA+ server to minimize other security associations and the 509 use of dynamic session keys. 511 * The ability to alleviate routing anchor points and support for 512 policies that allow the hiding of users by allowing routing 513 anchor points. 515 * Users to truly roam seamlessly between heterogeneous access 516 networks. 518 4. Acknowledgements 520 The authors would like to thank Russ Coffin, Mary Barnes, and Lachu 521 Aravamudhan of Nortel Networks and John Myhre of ATT Wireless 522 Services for their useful discussion. 524 5. References 526 [1] B. Aboba, M. Beadles, "The Network Access Identifier" RFC 527 2486, January 1999. 529 [2] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. 531 [3] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address 532 Allocation Extension", draft-ietf-mobileip-home-addr-alloc- 533 00.txt, November 1998. 535 [4] P. Calhoun P, C. Perkins, "Mobile IP Foreign Agent 536 Challenge/Response Extension", draft-ietf-mobileip-challenge- 537 04.txt, October 1999. 539 [5] P. Calhoun, G. Zorn, P. Pan, H. Akhtar, "DIAMETER Framework", 540 Internet-Draft, draft-calhoun-diameter-framework-03.txt, 541 October 1999. 543 [6] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 544 Internet Draft, ietf-mobileip-optim-08.txt, February 1999. 546 [7] B. Aboba, et al, "Review of Roaming Implementations", RFC 547 2194, September 1997. 549 [8] P. Calhoun, W. Bulley, "DIAMETER Dial-up (Roamops) 550 Extensions", Internet-Draft, draft-calhoun-diameter-authent- 551 07.txt, October 1999 553 [9] W. Simpson, "IP in IP Tunneling", RFC 1853, October 1995. 555 [10] M. Khalil, R. Narayanan, E. Qaddoura, H. Akhtar, "Key Exchange 556 for Network Architectures (KENA)", Internet-draft, draft- 557 mkhalil-mobileip-kena-00.txt, October 1999 559 [10] B. Patil , R. Narayanan, E. Qaddoura, "Security 560 Requirements/Implementation Guidelines for Mobile IP Using IP 561 Security", Internet-draft, draft-bpatil-mobileip-sec-guide- 562 00.txt, June 1999 564 6. Authors' Addresses 566 Questions about this document can be directed to: 568 Carey B. Becker Basavaraj Patil 569 Nortel Networks Nortel Networks 570 2201 Lakeside Blvd. 2201 Lakeside Blvd. 571 Richardson, TX. 75082-4399 Richardson, TX. 75082-4399 573 Phone: 972-685-0560 Phone: 972-684-1489 574 email: becker@nortelnetworks.com email: bpatil@nortelnetworks.com 576 Emad Qaddoura 577 Nortel Networks 578 2201 Lakeside Blvd. 579 Richardson, TX. 75082-4399 581 Phone: 972-684-2705 582 email: emadq@nortelnetworks.com