idnits 2.17.00 (12 Aug 2021) /tmp/idnits42149/draft-ng-nemo-aaa-use-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: ---------------------------------------------------------------------------- == 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 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: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (3)Intermediate nodes MUST not be able to learn any information which may enable them to reconstruct and reuse the credentials. -- 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 (October 2002) is 7158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 17 looks like a reference -- Missing reference section? '2' on line 45 looks like a reference -- Missing reference section? '3' on line 84 looks like a reference -- Missing reference section? '4' on line 84 looks like a reference -- Missing reference section? '5' on line 84 looks like a reference -- Missing reference section? '6' on line 84 looks like a reference -- Missing reference section? '7' on line 84 looks like a reference -- Missing reference section? '8' on line 112 looks like a reference -- Missing reference section? '9' on line 128 looks like a reference -- Missing reference section? '10' on line 176 looks like a reference -- Missing reference section? '11' on line 194 looks like a reference -- Missing reference section? '12' on line 194 looks like a reference -- Missing reference section? '13' on line 195 looks like a reference -- Missing reference section? '14' on line 197 looks like a reference -- Missing reference section? '15' on line 197 looks like a reference -- Missing reference section? '16' on line 249 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft C. W. Ng 3 Document: draft-ng-nemo-aaa-use-00.txt Panasonic Singapore Labs 5 T. Tanaka 6 Matsushita Communications 7 Industrial 9 Expires: April 2003 October 2002 11 Usage Scenario and Requirements for AAA in Network Mobility Support 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo set out the basic Authentication, Authorization, and 36 Accounting (AAA) model for Network Mobility Support (NEMO), and 37 described various usage scenarios. From the scenarios, a set of AAA 38 requirements in NEMO is drawn. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC-2119 [2]. 46 Table of Contents 48 1. Introduction...................................................2 49 1.1. Terms Used................................................3 50 1.2. Assumptions...............................................3 51 2. Overview of Operation..........................................4 52 2.1. Overview of Visiting Mobile Nodes Operation...............4 53 2.2. Resources Needed for NEMO Operation.......................4 54 2.3. Overview of AAA Operation.................................4 55 2.3.1. AAA Operation between MR and Access Router...........5 56 2.3.2. AAA Operation between VMN and MR.....................6 57 2.4. Home Resources vs Foreign Resources.......................7 58 3. Usage Scenario.................................................7 59 3.1. Scenario 1................................................8 60 3.1.1. Example..............................................8 61 3.1.2. AAA Operations.......................................9 62 3.2. Scenario 2................................................9 63 3.2.1. Examples............................................10 64 3.2.2. AAA Operations for MR...............................10 65 3.2.3. AAA Operations for MNNs.............................10 66 3.3. Scenario 3...............................................11 67 3.3.1. Examples............................................11 68 3.3.2. AAA Operations......................................12 69 3.4. Scenario 4...............................................12 70 3.4.1. Examples............................................12 71 3.4.2. AAA Operations......................................13 72 3.5. Scenario 5...............................................13 73 3.5.1. Examples............................................14 74 3.5.2. AAA Operations......................................14 75 4. AAA Requirements..............................................14 76 5. Security Considerations.......................................16 77 6. Acknowledgement...............................................17 78 References.......................................................17 79 Author's Addresses...............................................18 81 1. Introduction 83 The problem of Network Mobility Support (NEMO) is identified in 84 various previous works [3,4,5,6,7]. This document attempts to 85 explore the usage scenarios and requirements for Authentication, 86 Authorization, and Accounting (AAA) in the NEMO problem space. Since 87 NEMO entails various mobile devices accessing the Internet using 88 network resources that are in different administrative domains, AAA 89 is an important consideration for a NEMO solution. 91 In this document, we focus mainly on access control in NEMO. Since 92 NEMO infrastructure is by and large wireless in nature, access 93 control is a critical aspect for large-scale deployment of support 94 for NEMO. Such large-scale NEMO deployments are usually found in 95 commercial applications, where Internet Service Providers (ISP) erect 96 fixed and mobile access routers and allow subscribers to attach 97 devices to the access routers for Internet connection. Examples of 98 such commercial applications include providing Internet access in 99 trains, ships, and aircrafts. 101 Access control is needed in these networks in order to protect the 102 interest of the paying subscribers. If there is no access control, 103 significant portions of the network resources may be used by 104 unauthorized users, thereby affecting the quality of service provided 105 to other legitimate subscribers. 107 The need for access control exists in all networks that allow unknown 108 devices to connect to the network, and to identify itself to gain 109 access to services and resources provided in the network. Access 110 control function is usually provided by a gateway or router device, 111 generally known as a Network Access Server (NAS). Excellent work on 112 requirements for NAS can be found in [8]. It is not the objective of 113 this document to duplicate previous effort in defining NAS 114 requirements. Instead, this document explores specific requirements 115 that arise due to characteristics that are unique to a network in 116 motion. To this end, this document first presents the overview of 117 operations in a network in motion. Since a NEMO solution does not 118 exits (yet), this document assumes the operation to be based on a 119 reverse tunneling link between the mobile router in a mobile network 120 and the home agent in the home domain of the mobile router. 121 Following this, we describe possible usage scenarios of mobile 122 networks. From the usage scenarios, basic AAA requirements are drawn 123 out. 125 1.1. Terms Used 127 It is assumed that readers are familiar with the NEMO terminology 128 described in [9]. 130 1.2. Assumptions 132 In this document, the following assumptions are made: 133 1. There exist an entity in the NEMO solution that resides in the 134 home domain of the mobile network node which provide 135 functionality similar to the home agent in the Mobile IP 136 specification. 138 2. This document assumes there is no need for local fixed nodes 139 (LFN) and local mobile nodes (LMN) to be authenticated by the 140 mobile router they attached to. This is because the LFNs and 141 LMNs belongs to the same administrative domain as their MR, and 142 are always attached to the same mobile network. 144 2. Overview of Operation 146 2.1. Overview of Visiting Mobile Nodes Operation 148 Access control of NEMO depends very much on the resources required 149 for NEMO solution. To identify the resources required, we have to 150 model the general sequence of operation. This model is applicable 151 whether the node is a mobile host or a mobile router. We will use 152 the term Visiting Mobile Node (VMN) to meant both host and router. 153 The sequence of operation is as follows: 155 (1) VMN starts up and performs auto-configuration to use a link- 156 local address. 157 (2) VMN obtains a global Care-of-Address (CoA) through router 158 solicitation, or Dynamic Host Configuration Protocol (DHCP) 159 [10]. 160 (3) VMN discovers its Home Agent (HA) at its home domain. 161 (4) VMN sends the HA the appropriate binding updates. 163 2.2. Resources Needed for NEMO Operation 165 AAA is required in NEMO for two basic reasons: 166 (1) to control the access of and to account for the use of network 167 resources in the foreign domain, and 168 (2) to control the access of and to account for the use of network 169 resources in the home domain. 171 Network resources in the foreign domain that a VMN requires includes 172 a CoA, and the access to the wireless network channel. AAA for the 173 use of foreign resources is generally performed in a "link-local" 174 manner, utilizing access protocols such as IEEE 802.1x [11] to gain 175 access to the wireless network channel, and protocols such as DHCP 176 [10] to get a CoA. Since the link-layer and pool of IPv6 addresses 177 generally belongs to the same administrative domain, AAA for the 178 allocation of CoA is usually not required after granting access to 179 the link-layer network. 181 Network resources in the home domain that a VMN requires are the use 182 of HA, and the network bandwidth it consumes at the home domain for 183 the support of NEMO. Since the lowest layer where the VMN can 184 connect to the home network is at the IP layer, AAA operations for 185 the use network resources in the home domain must be carried out in 186 the IP layer. 188 2.3. Overview of AAA Operation 190 A plausible scenario for AAA operations is that two types of AAA 191 protocols will be used: a "link-local" AAA protocol, and a "global" 192 AAA protocol. The "link-local" AAA protocol is usually employed at 193 link-layer, and usually takes place over a single network hop. 194 Examples include IEEE 802.1x [11], PANA [12], or other EAP-variant 195 protocols [13]. The "global" AAA protocol is normally employed at 196 the IP layer, and usually takes place over multiple network hops. 197 Examples include Diameter [14], or RADIUS [15]. 199 There are two main elements in AAA for NEMO. The first is the MR 200 performing AAA negotiations with the access router, and the second is 201 the MR handling AAA negotiations from a VMN. We will describe them 202 separately in the following sub-sections. 204 2.3.1. AAA Operation between MR and Access Router 206 Generally, a MR will initiate an access request by sending relevant 207 messages to the access router it attached to in the foreign domain 208 using a "link-local" AAA protocol. The access router can then 209 contact the AAA server in the same domain to check the credentials 210 provided by the MR. The AAA server in the foreign domain may or may 211 not have enough information to verify the credentials. If the AAA 212 server in the foreign network does not have sufficient information, 213 it can contact the AAA server in the home domain of the MR to 214 complete the verification process. Since the two AAA servers are 215 located in different domains, a "global" AAA protocol will have to be 216 used for the communications between them. This is depicted in Figure 217 1 below. 219 +------+ 220 | | 221 | MR | <---------+ "link-local" 222 | | | AAA Protocol 223 +------+ | 224 +-----|---------------------+ 225 | V | "global" 226 | +---------+ +---------+ | AAA Protocol 227 | | Access | | AAA |<--------------+ 228 | | Router | | Server | | | 229 | +---------+ +---------+ | | 230 | Foreign Domain | | 231 +---------------------------+ | 232 | +-------|------+ 233 /-------------\ | V | 234 /----| |---\ | +--------+ | 235 | | | | AAA | | 236 /---/ Internet |------| | Server | | 237 | | | +--------+ | 238 \--------| |----/ | Home Domain | 239 \------------/ +--------------+ 241 Figure 1: AAA Operation between MR and Access Router. 243 2.3.2. AAA Operation between VMN and MR 245 When a MR allows a VMN to attach to its local mobile network based on 246 some access control policy, the MR is essentially behaving as a 247 Network Access Server, or NAS. As such, we basically model the 248 mobile router as NAS in this document, and draw heavily from work 249 done in IETF NASREQ Working Group [16]. 251 The VMN will first initiate an access request by sending relevant 252 messages to the MR it attached to using a "link-local" AAA protocol. 253 The MR will normally not have enough information to verify the 254 credentials of the VMN. Thus it will have to contact an external AAA 255 server to perform the actual authentication and authorization. This 256 external AAA server can be located anywhere in the global Internet. 257 Hence, the communications carried out between the MR and the AAA 258 server will employ one of the "global" AAA protocol. This is 259 depicted in Figure 2 below. 261 +----------+ +---------+ 262 | | | | 263 | VMN |<--------------->| MR | 264 | | "link-local" | |<------+ 265 +----------+ AAA protocol +---------+ \ 266 | \ "global" 267 | \ AAA protocol 268 /-------------\ \ 269 /----| |---\ +-----|----------+ 270 | | | V | 271 /---/ Internet | | +--------+ | 272 | |----| AAA | | 273 | | | | Server | | 274 \--------| |----/ | +--------+ | 275 \------------/ | ^ Home Domain | 276 | | | of MR | 277 | +--|-------------+ 278 +----------|---------+ + 279 | V | / "global" 280 | +---------+ | / AAA Protocol 281 | | AAA |<-------+ 282 | | Server | | 283 | +---------+ | 284 | Home Domain of VMN | 285 +--------------------+ 287 Figure 2: AAA Operation between VMN and MR. 289 2.4. Home Resources vs Foreign Resources 291 The previous discussion only illustrates the access request for 292 foreign resources. To gain access to home resources, the MR/VMN will 293 typically has to discover its HA in the home domain, and send binding 294 updates to its HA. Access control on the use of home resources can 295 then be carried out by the HA after the reception of the binding 296 updates. This can be done with the HA consulting an AAA server. 297 Since the main operation of access control of home resources is not 298 carried out by the nodes in the mobile network, we will focus on the 299 access control of foreign resources in the remaining sections of this 300 document. 302 3. Usage Scenario 304 In this section, we describe several usage scenarios of NEMO. In our 305 descriptions, we will focus more on the AAA aspects of NEMO rather 306 than the routing solution. A total of five scenarios are presented, 307 classified according to the administrative domains of the access 308 routers (ARs), top-level mobile routers (TLMRs), nested visiting 309 mobile router (VMR), and mobile network nodes (MNNs), as shown in 310 Table 1 below. AD-1 and AD-2 are used to differentiate distinct 311 administration domains controlled by different Internet Service 312 Providers (ISP) or companies, and USER refers to the domain of 313 individual subscribers (or roaming subscribers) to AD-1. 315 Table 1: Administrative Domains (AD) in Different Scenarios 317 AR TLMR VMR MNN 318 ---------- ---------- ---------- ---------- 319 Scenario 1 AD-1 AD-1 None USER 320 Scenario 2 AD-2 AD-1 None USER 321 Scenario 3 AD-1 USER None USER 322 Scenario 4 AD-1 AD-1 USER USER 323 Scenario 5 AD-2 AD-1 USER USER 325 In scenarios 1 and 2, the subscribers are individual VMH attached to 326 MR in a foreign domain. The difference between scenarios 1 and 2 is 327 that in the first scenario, the MR and the AR it attached to belong 328 to the same administrative domain, while in scenario 2 they belong to 329 distinct administrative domains. 331 In scenarios 3, 4, and 5, the subscribers are moving networks 332 themselves. The difference between these scenarios is that in 333 scenario 3, the subscribers attach directly to fixed AR, while in 334 scenarios 4 and 5 the subscribers attach to a MR. For scenario 4, 335 the MR and the AR it attached to belong to the same administrative 336 domain, while in scenario 5 they belong to distinct administrative 337 domains. 339 Each scenario is described in greater details in the following sub- 340 sections. Examples of each scenario, and the AAA operations required 341 are also presented. 343 3.1. Scenario 1 345 In this scenario, subscribers are using their mobile devices to 346 connect to MRs that belongs to an Internet Service Provider (ISP). 347 The MRs have their points of attachment to the Internet via an AR 348 that belongs to the same ISP. Two distinct types of administrative 349 domains are present: one for the AR and MRs, and one for each mobile 350 network nodes (MNN). This is illustrated in Figure 3 below. 352 +-------------------------------+ +---------------+ 353 | | | | 354 | +------+ +------+ | | +-------+ | 355 | | | | | | | | | | 356 Internet <-----| AR |---------| MR |----------| VMN | | 357 | | | | | | | | | | 358 | +------+ +------+ | | +-------+ | 359 | | | | 360 | Administrative Domain 1 | | USER | 361 +-------------------------------+ +---------------+ 363 Figure 3: Scenario 1 365 3.1.1. Example 367 An example of such scenario will be the train network. A railway 368 company may collaborate with an ISP to provide each cabin of the 369 trains with a MR. Along the routes of the trains, the same ISP could 370 erect fixed ARs for the MRs of the train to connect to the Internet. 371 Passengers can then access the Internet via the MRs in the cabins. 372 Thus, each cabin (or possibly the entire train) can be treated as a 373 single mobile network. 375 In this case, the ISP/railway company owns both the ARs and the MRs. 376 The access devices of the subscribers (i.e. the passengers) are then 377 the MNNs. 379 3.1.2. AAA Operations 381 Since the MR for each mobile network belongs to the service provider 382 of the AR, the access authentication of the MR by the access routers 383 is straightforward. Each handover of the MR between the ARs may 384 require access authentication. No special consideration for NEMO is 385 necessary. 387 However, the MNNs (i.e. subscribers) will have to be authenticated by 388 the MR. Two different possibilities arise: (1) the MNN is a 389 subscriber with the service provider of the train network, and (2) 390 the MNN is a roaming subscriber with another ISP. 392 For the first case where the MNN is a subscriber of the local ISP, 393 the AAA process would typically be the following: 395 - The MNN makes a "link-local" access request to the MR. 396 - The MR consults the local AAA server to check the credentials 397 of the subscriber. 398 - The MR replies the request. 400 For the second case where the MNN is a roaming subscriber, the AAA 401 process would typically be the following: 403 - The MNN makes a "link-local" access request to the MR. 404 - The MR consults the local AAA server to check the credentials 405 of the subscriber. 406 - The local AAA server consults the home AAA server of the MNN to 407 check the credentials of the subscriber. 408 - Response is passed back from home AAA server, to local AAA 409 server, to MR back to the subscriber. 411 3.2. Scenario 2 413 This scenario is an extension of the previous one where the MRs may 414 not belong to the same administration domain as the ARs. In this 415 case, 3 distinct types of administrative domains are present: an 416 administrative domain for the ARs, an administrative domain for MRs, 417 an administrative domain for each MNNs. This illustrated in Figure 4 418 below. 420 +--------------+ +--------------+ +---------------+ 421 | | | | | | 422 | +------+ | | +------+ | | +-------+ | 423 | | | | | | | | | | | | 424 Internet <------| AR |----------| MR |----------| VMN | | 425 | | | | | | | | | | | | 426 | +------+ | | +------+ | | +-------+ | 427 |Administrative| |Administrative| | | 428 | Domain 2 | | Domain 1 | | USER | 429 +--------------+ +--------------+ +---------------+ 431 Figure 4: Scenario 2 433 3.2.1. Examples 435 An example of this scenario is again the train illustration. Here, 436 the train may travel along a route where the available ARs belong to 437 a different ISP. Other examples include ships and planes. 439 3.2.2. AAA Operations for MR 441 Since the AR and MR belong to different administrative domains, each 442 handover of MR between different ARs may require AAA request/response 443 negotiations. Such negotiations may employ standard mobile IP type 444 operations. A typical AAA negotiation will be: 446 - The MR makes a "link-local" access request to AR. 447 - The AR consults the local AAA server to check credentials of 448 MR. 449 - The local AAA server consults the home AAA server of the MR to 450 check credentials of MR. 451 - Response is passed back to the local AAA server, AR and MR in 452 that order. 454 3.2.3. AAA Operations for MNNs 456 For the MNN, there are again two possibilities: a subscribing MNN or 457 a roaming MNN. For both cases of MNN, it needs only be authenticated 458 by the MR once when the MNN first attaches to the MR. 460 For the first case where the MNN is a subscriber of the train 461 network, the AAA process would typically be the following: 463 - The MNN makes a "link-local" access request to the MR. 464 - The MR consults the local AAA server to check the credentials 465 of the subscriber. 466 - The MR replies the AAA request. 468 For the second case where the MNN is a roaming subscriber, the AAA 469 process would typically be the following: 471 - The MNN makes a "link-local" access request to the MR. 472 - The MR consults the local AAA server to check the credentials 473 of the subscriber. 474 - The local AAA server consults the home AAA server of the MNN to 475 check the credentials of the subscriber. 476 - Response is passed back from home AAA server, to local AAA 477 server, to MR back to the subscriber. 479 3.3. Scenario 3 481 This scenario is the case where the mobile network belongs to a 482 single administrative domain, but its access to the Internet via an 483 AR in a foreign domain. The mobile network does not allow VMNs to 484 attach to its mobile router. (In this document, we shall refer to 485 such mobile network as a private network). This is illustrated in 486 Figure 5 below. 488 +----------------+ +---------------------------------+ 489 | | | | 490 | +------+ | | +------+ | 491 | | | | | | | | 492 Internet <-------| AR |------------| MR |---> private network | 493 | | | | | | | | 494 | +------+ | | +------+ | 495 | Administrative | | | 496 | Domain 1 | | USER | 497 +----------------+ +---------------------------------+ 499 Figure 5: Scenario 3 501 3.3.1. Examples 503 One example of this scenario is the car network, where sensors, 504 laptops, and navigation systems are fixed nodes on the mobile car 505 network. The vehicle would have a MR to roam through the AR provided 506 by the ISP along major streets. 508 Another common example is the Wireless Personal Area Network (W-PAN). 509 The equipment used by a person formed a bluetooth-based mobile 510 network, with the 802.11b-enabled laptop/PDA, or a GPRS-enabled 511 handphone acting as the MR. 513 3.3.2. AAA Operations 515 For this scenario, there is no need for AAA between the MR and the 516 MNNs. The MR simply assumes that any node on the sub-net is an 517 authorized node of the network. (Here, we ignore the situation of a 518 nearby third-party node trying to sneak in an unauthorized access.) 519 The only requirements that are relevant are the AAA negotiations 520 between the AR and MR, and this will be similar to the previous 521 scenario (scenario 2). 523 A typical AAA negotiation will be: 525 - The MR makes a "link-local" access request to AR. 526 - The AR consults the local AAA server to check credentials of 527 MR. 528 - The local AAA server consults the home AAA server of the MR to 529 check credentials of MR. 530 - Response is passed back to the local AAA server, AR and MR in 531 that order. 533 3.4. Scenario 4 535 This scenario is the nested extension of Scenario 1 plus Scenario 3. 536 Here, a mobile network attaches itself to a higher level mobile 537 network (NEMO-1). The higher level MR (MR-1) and the AR belongs to a 538 single administrative domain, and the lower level mobile network 539 (NEMO-2) belongs to a single subscriber. This is illustrated in 540 Figure 6 below. 542 +-------------------------+ +------------------------+ 543 | | | | 544 | +------+ +------+ | | +-------+ | 545 | | | | | | | | | | 546 Internet <----| AR |-----| MR |--------| VMR |---> private | 547 | | | | | | | | | network | 548 | +------+ +------+ | | +-------+ | 549 | | | | 550 | Administrative Domain 1 | | USER | 551 +-------------------------+ +------------------------+ 553 Figure 6: Scenario 4 555 3.4.1. Examples 557 One example of this scenario is again the train. Here the MR-1 are 558 installed on the trains and the ARs belong to the same railway 559 company or ISP. The passenger, however, may bring in a W-PAN network 560 onto the train. Thus the W-PAN forms the NEMO-2, which attaches 561 itself to NEMO-1, the mobile network in the cabin of the train. 563 3.4.2. AAA Operations 565 In this scenario, there are two distinct administrative domains: one 566 encompassing the ARs and MR-1, and the other encompassing NEMO-2. 567 Since MR-1 for each NEMO-1 belongs to the service provider of the AR, 568 the access authentication of the MR by the AR is straightforward (as 569 in Scenario 1). Each handover of the MR between the AR may require 570 access authentication. In addition, there is no need for AAA 571 negotiations within NEMO-2, since this is usually a privately owned 572 network (eg. WPAN). Thus the only case we have to consider is the 573 AAA negotiations between MR-1 and MR-2. 575 A typical AAA negotiation will be: 577 - The MR-2 makes a "link-local" access request to MR-1. 578 - The MR-1 consults its home AAA server to check credentials of 579 MR-2. 580 - The home AAA server of MR-1 consults the home AAA server of MR- 581 2 to check credentials of MR-2. 582 - Response is passed back to the home AAA server of MR-1, MR-1 583 and MR-2 in that order. 585 3.5. Scenario 5 587 This scenario is the nested extension of Scenario 2 plus Scenario 3. 588 Here, a mobile network attaches itself to a higher level mobile 589 network (NEMO-1). The higher level mobile router (MR-1) and the AR 590 belongs to different administrative domains, and the lower level 591 mobile network (NEMO-2) belongs to a single subscriber. This is 592 illustrated in Figure 7 below. 594 +--------------+ +--------------+ +----------------------+ 595 | | | | | | 596 | +------+ | | +------+ | | +-------+ | 597 | | | | | | | | | | | | 598 Internet <-----| AR |---------| MR |-------| VMR |--> private | 599 | | | | | | | | | | | network | 600 | +------+ | | +------+ | | +-------+ | 601 |Administrative| |Administrative| | | 602 | Domain 2 | | Domain 1 | | USER | 603 +--------------+ +--------------+ +----------------------+ 605 Figure 7: Scenario 5 606 3.5.1. Examples 608 One example of this scenario is again the train. Here the MRs on the 609 trains and the access routers belong to different railway companies 610 or ISP. The passenger bring in a wireless PAN network onto the 611 train. Thus the W-PAN is the lower level mobile network (NEMO-2), 612 the cabin of the train is the higher level mobile network (NEMO-1). 614 3.5.2. AAA Operations 616 In this scenario, there are 3 different types of administrative 617 domains: one for the AR, one for NEMO-1, and one for each NEMO-2. 618 Again, no AAA negotiation is necessary within NEMO-2 as it is solely 619 owned by a single administrative agent. 621 AAA negotiations between AR and MR-1 is similar to those depicted in 622 Scenario 3. A typical AAA negotiation will be: 624 - The MR-1 makes a "link-local" access request to AR. 625 - The AR consults the local AAA server to check credentials of 626 MR-1. 627 - The local AAA server consults the home AAA server of MR-1 to 628 check credentials of MR-1. 629 - Response is passed back to the local AAA server, AR and MR-1 in 630 that order. 632 When MR-2 first enters the influence of NEMO-1, it will have to 633 perform AAA negotiation with MR-1. This is similar to scenario 4. A 634 typical AAA negotiation will be: 636 - The MR-2 makes a "link-local" access request to MR-1. 637 - The MR-1 consults its home AAA server to check credentials of 638 MR-2. 639 - The home AAA server of MR-1 consults the home AAA server of MR- 640 2 to check credentials of MR-2. 641 - Response is passed back to the home AAA server of MR-1, MR-1 642 and MR-2 in that order. 644 4. AAA Requirements 646 From the usage scenario, we can identify the set of requirements 647 described below. It must be noted that the requirements specified 648 are by no means exhaustive. Since a NEMO solution has yet to be 649 specified, these requirements are merely spelt out to generate 650 further discussion within the NEMO working group. When a NEMO 651 solution is eventually specified, AAA requirements by NEMO can be 652 rapidly generated by building on top of this document. 654 (1)The AAA servers MUST be able to share, or dynamically establish 655 security associations with external authorities that are able 656 to verify the credentials provided by the client. 658 This requirement is a direct induction from the need for AAA 659 servers of ARs/MRs to consult home AAA servers of mobile 660 network nodes for verifications of client's credentials. Since 661 these AAA servers usually belong to different administrative 662 domains, it is necessary for AAA operations to provide a 663 mechanism for AAA servers in two different domains to establish 664 a security relationship between each other. 666 (2)The VMN or MR MUST be able to provide complete, unforgeable 667 credentials without having to contact its home agent. 669 Since VMN or the MR would initiate network connectivity from a 670 foreign domain, it is necessary for it to be able to provide 671 credentials without having first granted access to NEMO 672 resources. Thus it has to be able to provide credentials 673 sufficient for verifications without the ability to contact any 674 other nodes in its home domain. 676 (3)Intermediate nodes MUST not be able to learn any information 677 which may enable them to reconstruct and reuse the credentials. 679 This requirement protects the AAA servers from replay attacks. 680 It is necessary for the ARs/MRs to be able to process the 681 credentials provided by the MRs/VMNs and yet unable to 682 reconstruct the credentials independently at a later time, so 683 that malicious AR/MR cannot use the credentials to launch a 684 replay attack against the home AAA server. It also serves to 685 protect the MRs/VMNs from the visited NEMO. 687 In addition, to the above requirements, the following security 688 requirements need to be considered. 690 (4)AAA request and response operations between the ARs/MRs and the 691 respective AAA servers MUST prevent eavesdropping. 693 Any AAA operations MUST prevent the confidential information 694 passed between the AR/MR and the corresponding AAA server from 695 being known by eavesdroppers in the network. This is 696 especially needed since NEMO typically operates in a wireless 697 environment. 699 (5)AAA request and response operations between the ARs/MRs and the 700 respective AAA servers MUST NOT be vulnerable to denial-of- 701 service attack. 703 Since AAA operations typically entail cryptographic 704 computations in the nodes involved, it is necessary to consider 705 denial of service attacks by consuming CPU and memory resources 706 to process illegitimate AAA requests, thereby preventing 707 authentication of a legitimate mobile network node. 709 (6)AAA request and response operations between the ARs/MRs and the 710 respective AAA servers MUST NOT be vulnerable to man-in-the- 711 middle attack. 713 Since AAA operations may involve more than two nodes and 714 operate over multiple hops, it MUST prevent communications 715 between two legitimate nodes from being spoofed by an attacker 716 in the middle. 718 The following are the set of requirements for NEMO in considerations 719 to AAA operations. 721 (7)MR that supports attachment of VMN on its internal link SHOULD 722 implement AAA client capability to be able to contact MR's home 723 AAA server to check on credentials provided by the visiting 724 nodes. 726 It is generally not expected for MR to implement a full AAA 727 server for scalability reasons. However, MR should be 728 configured to consult an AAA server (possibly an AAA server 729 from the MR's home domain) for verifications of credentials 730 from the VMN. 732 (8)MR that support attachment of VMN on its internal links SHOULD 733 NOT change its AAA policy for the said VMNs during a continuous 734 session, even when the MR has undergone a handover between AR 735 of different administrative domains. 737 It is expected for handover of MR should be transparent to VMNs 738 behind the MR. Thus, a change in administrative domain of the 739 AR should not be propagated to nodes behind the MR. 741 5. Security Considerations 743 This document illustrates the usage scenarios of NEMO AAA operations, 744 and specifies the NEMO AAA requirements. Because AAA is security 745 driven, security considerations are spelt out in the requirements. 747 6. Acknowledgement 749 The authors wish to express their sincere gratitude to Thierry Ernst 750 and Keisuke Uehara of the WIDE Project for their constructive 751 comments to the initial draft of this document. 753 References 755 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 756 9, RFC 2026, October 1996. 758 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 759 Levels", BCP 14, RFC 2119, March 1997 761 3 Soliman, H., and Ernst, T., "NEMO (NEwork Mobility) Charter", 762 http://www.nal.motlabs.com/nemo/nemo-charter.txt. 764 4 Soliman, H., and Pettersson, M., "Mobile Networks (MONET) Problem 765 Statement and Scope", Internet Draft, draft-soliman-monet- 766 statement-00.txt, Feb 2002, Work In Progress. 768 5 Ernst, T., and Lach, H., "Network Mobility Support Requirements", 769 Internet Draft, draft-ernst-monet-requirements-00.txt, Feb 2002, 770 Work In Progress. 772 6 Lach, H. et. al., "Mobile Networks Scenarios, Scope and 773 Requirements", Internet Draft, draft-lach-monet-requirements- 774 00.txt, Feb 2002, Work In Progress. 776 7 Kniventon, T. J., and Yegin, A. E., "Problem Scope and 777 Requirements for Mobile Networks Working Group", Internet Draft, 778 draft-kniventon-monet-requiremetns-00.txt, Feb 2002, Work In 779 Progress. 781 8 Mitton, D., and Beadles, M., "Network Access Server Requirements 782 Next Genreration (NASREQNG) NAS Model", IETF RFC 2881, July 2000. 784 9 Ernst, T., and Lach, H., "Network Mobility Support Terminology", 785 Internet Draft, draft-ernst-monet-terminology-01.txt, Jul 2002, 786 Work In Progress. 788 10 Droms, R., et. al., "Dynamic Host Configuration Protocol for Ipv6 789 (DHCPv6)", Internet Draft, draft-ietf-dhc-dhcpv6-25.txt, Jun 2002, 790 Work In Progress. 792 11 IEEE 802.1 Working Group, "Port-Based Network Access Control", 793 IEEE 802.1x Standard, June 2001. 795 12 Patil, B. et. al., "Charter of Protocol for Carrying 796 Authentication for Network Access", IETF PANA WG Charter, May 797 2002. 799 13 Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 800 Protocol", IETF RFC 2284, March 1998. 802 14 Calhoun, P. R. et. al., "Diameter Base Protocol", Internet Draft, 803 draft-ietf-aaa-diameter-12.txt, July 2002, Work In Progress. 805 15 Rigney, C. et. al., "Remote Authentication Dial In User Service 806 (RADIUS)", IETF RFC 2865, June 2000. 808 16 IETF NASREQ WG, "Network Access Server Requirements Working Group 809 Charter", http://www.ietf.org/html.charters/nasreq-charter.html. 811 Author's Addresses 813 Chan-Wah Ng 814 Panasonic Singapore Laboratories Pte Ltd 815 Blk 1022 Tai Seng Ave #04-3530 816 Tai Seng Industrial Estate 817 Singapore 534415 818 Phone: (+65) 6554 5420 819 Email: cwng@psl.com.sg 821 Takeshi Tanaka 822 Wireless Solution Laboratories 823 Matsushita Communication Industrial Co Ltd 824 5-3, Hikarinooka, Yokoshuka-shi, Kanagawa 825 239-0847, Japan 826 Phone: +81-468-40-5494 827 Email: Takeshi.Tanaka@yrp.mci.mei.co.jp