idnits 2.17.1 draft-malinen-mobileip-regreg6-01.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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 946 has weird spacing: '...allenge cited...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- No information found for draft-ietf-mobileip-regtun - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- No information found for draft-koodli-rhoc-hcompr6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- Unexpected draft version: The latest known version of draft-koodli-mobileip-smoothv6 is -00, but you're referring to -02. (However, the state information for draft-koodli-rhoc-hcompr6 is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-krishnamurthi-mobileip-ipv6buf - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-03 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Jari T. Malinen 2 INTERNET DRAFT Franck Le 3 2 March 2001 Charles E. Perkins 4 Category: Standards Track Nokia Research Center 6 Mobile IPv6 Regional Registrations 7 draft-malinen-mobileip-regreg6-01.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-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 25 any 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 document describes Mobile IPv6 regional registration as an 36 optional extension to Mobile IPv6. Regional registration introduces 37 visited-domain mobility agent functionality for proxying a public 38 care-of-address which remains the same while the mobile node 39 moves in the visited domain. This reduces the binding update 40 signaling latency for the mobile node and signaling load outside the 41 visited domain. The protocol defines regional mobility capability 42 negotiation, regional binding update signaling, and regional-aware 43 data routing through a hierarchy of visited-domain mobility agents. 44 The protocol allows for an arbitrary point in the visited-domain 45 hierarchy to distribute the connection-state maintenance between 46 several mobility agents. IPSec AH is used for securing the protocol 47 as in basic Mobile IPv6. 49 Contents 51 Status of This Memo 1 53 Abstract 1 55 1. Introduction 3 57 2. Terms 4 59 3. Protocol Operation Overview 5 60 3.1. Movement to a new Link . . . . . . . . . . . . . . . . . 7 61 3.2. Visited-domain capability discovery . . . . . . . . . . . 8 62 3.3. Regional Registrations signaling . . . . . . . . . . . . 8 63 3.4. Regional-Aware Data Routing . . . . . . . . . . . . . . . 10 65 4. Protocol Extensions 11 66 4.1. Router Advertisement modifications . . . . . . . . . . . 12 67 4.2. Regional CoA Extension . . . . . . . . . . . . . . . . . 12 68 4.3. Regional Binding Update . . . . . . . . . . . . . . . . . 14 69 4.4. Previous Access Router Sub-Option . . . . . . . . . . . . 14 71 5. New requirements for IPv6 Nodes 15 72 5.1. Visited Domain Router Requirements . . . . . . . . . . . 16 73 5.2. Mobile Node Requirements . . . . . . . . . . . . . . . . 16 75 6. IANA Considerations 16 77 7. Security Considerations 16 79 A. Changes to the previous version 18 81 B. Regional Registrations Security 19 82 B.1. Trust delegation . . . . . . . . . . . . . . . . . . . . 20 83 B.2. Key distribution principles . . . . . . . . . . . . . . . 20 84 B.3. The full per -mobile trust delegation model . . . . . . 21 85 B.3.1. Regional Registrations Key Distribution . . . . . 21 86 B.3.2. Anti replay attacks . . . . . . . . . . . . . . . 21 87 B.3.3. Key Material Destination Option . . . . . . . . . 22 88 B.4. "trust delegated to edge routers" security model . . . . 23 89 B.4.1. Security Association Acquisition from AAA . . . . 23 90 B.4.2. Movement to a new Link . . . . . . . . . . . . . 25 91 B.4.3. Anti replay attacks . . . . . . . . . . . . . . . 25 92 B.5. Forwarding Modes and comparison of these different modes from 93 a security point of view . . . . . . . . . . . . . . . 26 95 Addresses 28 96 1. Introduction 98 Mobile IPv6 regional registration reduces the binding update 99 signaling latency and the signaling load for a mobile node moving 100 within the same visited domain. The latency is reduced by localizing 101 binding updates to the visited domain and the signaling load is 102 reduced by using a regional-aware router for a proxy care-of-address, 103 as seen by hosts outside the visited domain. The protocol re-uses 104 the general idea of regional registrations for Mobile IPv4 [3], but 105 is a different IPv6-specific protocol. 107 The regional care-of address can be in an arbitrary node in the 108 visited domain, not just in an edge router or the gateway mobility 109 agent highest in the hierarchy. The selection of a particular 110 regional care-of address is done by the mobile node from a list of 111 addresses advertised by the access router. 113 The regional binding update is transported over an arbitrary-depth 114 tree hierarchy of regional-aware routers up to the closest possible 115 router in the hierarchy. This router is the crossover between the 116 old path from the gateway router to the previous access router and 117 from the gateway router to the new access router. The protocol 118 supports network-controlled selection of the crossover router 119 which hides the inner structure of the hierarchy and enables 120 constant-length signaling independent of the depth of the hierarchy. 122 The regional registration protocol does not require modifications 123 to any network elements other than the mobile node and the 124 regional-aware routers. These modifications are optional additions 125 to basic Mobile IPv6. Non-regional-aware routers, hosts, home 126 agents, and mobile nodes can interoperate with regional-aware 127 entities without change. 129 The added routing state maintenance in the visited domain is minimal. 130 It does not involve the routing tables at all; all per-mobile state 131 is kept in the regional binding cache. This data structure is 132 internal to the regional mobility agent and can re-use the existing 133 binding cache. 135 Security is provided with the same signaling protection extensions as 136 in the basic Mobile IP. However, for an efficient MN-visited domain 137 signaling security, dynamic security association acquisition and 138 usage is discussed Appendix B. 140 A special anycast address represents the visited domain and the 141 visited-domain part of the obtained key material is propagated within 142 the anycast group. 144 This protocol defines the regional registration signaling for IPv6 145 and it can be used in combination with other components of the 146 general smooth hand-over framework [6] for gaining cost-efficient 147 signaling. In such a combination, the mobile node sends the message 148 over the wireless interface encapsulated with the state transfer SHIN 149 option up to the access router. The encapsulating header may carry 150 e.g. buffering [7] or header compression [5] state transfer signaling 151 needed for smooth and efficient handovers. 153 2. Terms 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [2]. 159 In addition, this document uses the following terms: 161 Access Router 162 The closest router to the mobile node in the visited 163 domain that the mobile node uses to access the network. 165 Crossover Router 166 When a mobile node is performing a regional registration, 167 the Crossover Router is the router where the old path 168 leading to a mobile node and the new path cross, i.e. 169 the regional router in the hierarchy where a connection 170 state change is needed to maintain an up-to-date 171 communication path to the mobile node. 173 Gateway Mobility Agent 174 The software module implementing regional registrations 175 in the gateway router. 177 Gateway Router 178 A router controlling the regional care-of-address of a 179 mobile node which may be located anywhere in the physical 180 hierarchy. 182 Highest Router 183 Router used in a visited domain as the root of a physical 184 hierarchy; The visible hierarchy for a mobile node is 185 thus rooted at the gateway router possibly below the 186 highest router. 188 Home Binding 189 The binding cache entry in a home agent used for storing 190 home registration state. 192 Home Registration 193 Sending a binding update to the home agent to create a 194 home binding. 196 Regional-aware Router 197 Router that supports regional registrations. 199 Regional Binding Cache 200 A conceptual data structure in regional-aware routers; 201 it is keyed on the home address of a mobile node and 202 contains the care-of-address, lifetime, flags, security 203 association, and network interface as data elements. All 204 regional routing state is contained in this entry. 206 Regional Care-of-address 207 A care-of-address, as seen from outside the visited 208 domain, used to locate a mobile node. Remains the same 209 while the mobile node does regional binding updates 210 within a visited domain. 212 Regional Mobility Agent 213 The software module implementing regional registrations 214 in a regional-aware router. 216 Visited Domain 217 A domain that is visited by the mobile node; a set of 218 subnets usually administered by one entity. In this 219 document, all routers in a visited domain are assumed to 220 have a security association with one another. 222 This terminology is intended to conform to those that have been 223 used in Mobile IP and other Internet protocols. Basic Mobile IPv6 224 terminology is used as defined in [4]. 226 3. Protocol Operation Overview 228 A foreign domain advertises its capability for regional registrations 229 with a newly defined router advertisement flag. When entering a 230 visited domain for the first time, the mobile node registers with its 231 home domain. During or after this registration, the mobile node can 232 perform a regional registration. 234 A regional registration establishes a regional care-of-address 235 that is seen from outside the visited domain as the mobile node's 236 primary care-of-address. This address is controlled by one of the 237 visited-domain routers and the mobile node obtains the address from a 238 list of Regional CoA extensions (Section 4.2), attached to the router 239 advertisement. 241 ________ 242 +------------+ / \ +--------------------+ 243 | Home Agent |------( Internet )----| Corresponding node | 244 +------------+ \________/ +--------------------+ 245 | 246 | regional \ 247 | care-of-address + 248 +------------------------+ | 249 | Gateway Mobility Agent | | 250 | (GMA) | | 251 +------------------------+ | 252 / \ | 253 1./ \ | 254 / \ | 255 +------------------+ +--------+ | 256 | Crossover Router | | Router | | 257 +------------------+ +--------+ \ 258 / \ \ Visited 259 1./ \ 2. / Domain 260 / \ / 261 +----------+ +--------+ | 262 | Previous | | New | | 263 | Access | | Access | | 264 | Router | | Router | | 265 +----------+ +--------+ | 266 ^ ^ | 267 |1. |2. | 268 | | | 269 +-+ +-+ (on-link) primary | 270 | | ---> | | care-of-address | 271 +-+ +-+ + 272 Mobile Mobile / 273 Node Node 275 Figure 1: Hierarchy of regional-aware routers 277 After obtaining a regional care-of-address, the mobile node stores 278 the current visited domain identity, and sends binding updates to 279 its home agent and corresponding nodes. The mobile node uses the 280 regional care-of-address as the alternate care-of-address when 281 sending basic Mobile IPv6 binding updates to nodes outside the 282 visited domain. 284 While staying within the visited domain, the mobile node MAY send 285 regional binding updates for the duration of its home binding. The 286 mobile node may also send ordinary binding updates to the home agent 287 or to corresponding nodes at any time. 289 Figure 1 illustrates a typical regional registration scenario. The 290 mobile node sends a regional binding update to the crossover router 291 which updates its connection state from the old path to the new path. 292 The gateway router is the crossover router during the first regional 293 registration (signal 1). After this (signal 2), the crossover may 294 exist lower in the hierarchy. 296 The regional binding update is a modified Binding Update destination 297 option. It updates the regional binding cache entries of a mobile 298 node in regional-aware router hierarchy. The binding update also 299 enables the visited domain to decide the crossover router. The 300 mobile node attaches additional information to this binding update 301 such that a regional-aware router can decide from it whether it is a 302 crossover router. 304 The regional binding cache is used for regional data routing, 305 forwarding of encapsulated or source-routed Mobile IPv6 data packets 306 to the mobile node. The binding cache entries are deleted by timeout 307 or by de-registration. The semantics of this is identical to that in 308 basic Mobile IPv6. 310 3.1. Movement to a new Link 312 When entering a new foreign link, with the same or another visited 313 domain, the mobile node performs movement detection and uses router 314 discovery to discover new routers as defined in Mobile IPv6. The 315 mobile node may also receive a handover indication from the link 316 layer and consequently send a router solicitation. Similarly, 317 the mobile node may receive an unsolicited router advertisement 318 containing the indication that handover is imminent. 320 The mobile node also performs visited domain detection as an 321 additional part of the movement detection of basic Mobile IPv6. 322 The mobile node uses as visited domain identity a ``visited 323 domain routers'' anycast address. This is derived from the 324 selected regional care-of-address in the router advertisement 325 option (Section 4.1) and used for detecting movement to a new visited 326 domain. This identity MUST be unique. 328 The anycast address is formed from the prefix in the regional 329 care-of-address extension and a host number 0 (TBD). The prefix 330 can e.g. be shorter than the actual prefix of the regional 331 care-of-address in the gateway router. Such a shorter prefix can 332 thus contain many regional care-of-addresses in the same visited 333 domain. 335 When the mobile node changes its regional care-of-address, or 336 when the selected regional care-of-address is not in the router 337 advertisement of the new access router, the mobile node SHOULD behave 338 as if it arrived to a new visited domain. This avoids the situation 339 where the crossover router would be beyond the GMA in the hierarchy. 341 The mobile node then selects its primary care-of-address, which 342 is on the same link as is the access router, as defined in Mobile 343 IPv6. The address is co-located to the mobile node together with its 344 routing identity, its home address, and used as the target for local 345 communication between the visited domain and the mobile node. The 346 mobile node MAY also use this address as the care-of-address in its 347 binding updates for corresponding nodes within the visited domain. 349 3.2. Visited-domain capability discovery 351 The router advertisement from a regional-aware router contains flags 352 to indicate the supported capabilities. The supported capability 353 flag for regional registrations is the `I' bit in the Reserved1 field 354 of the Mobile IPv6 Modified Router Advertisement Message's Modified 355 Prefix Information Option [4]. 357 If the `I' bit is set, the mobile node SHOULD make use of regional 358 registration. In this case, the mobile node selects its regional 359 care-of-address from the one or more regional care-of-address 360 extensions in the router advertisement. 362 3.3. Regional Registrations signaling 364 When entering the visited domain, the mobile node performs a home 365 registration in combination with the first regional binding update. 366 The regional binding update MAY be an outer encapsulator around the 367 home registration binding update. 369 The regional binding update is a modified Mobile IPv6 binding update 370 destination option. It propagates upwards hop-by-hop through a 371 hierarchy of regional-aware routers to a router controlling the 372 selected regional care-of-address. There may be regional-unaware 373 routers between adjacent regional-aware routers in a hierarchy. 375 The regional care-of-address can be an address of the visited domain 376 router or an address from a pool of regional care-of-addresses 377 controlled by a router. Association between such a care-of-address 378 and a router within the visited domain, selected as target of the 379 first regional binding update, is implementation-specific. 381 The destination address in the IP header of the regional binding 382 update at the sending mobile node is the ``visited domain routers'' 383 anycast address. It MAY also be the IP address of the access router. 384 A packet sent to this address is first received by the regional-aware 385 access router. There MUST be a home address destination option in 386 the IPv6 packet carrying the regional binding update as with basic 387 Mobile IPv6. 389 The regional binding update is then propagated to the next-higher 390 regional-aware router by encapsulation. The encapsulating header 391 around the regional binding update or around the returned binding 392 acknowledgement MAY carry key material within the anycast group as 393 described in Appendix B. 395 When the regional binding update is re-sent from the receiving router 396 up to the next higher router, each regional-aware router establishes 397 or updates its regional binding cache entry for the mobile node. 398 The key to the entry is the home address, and the care-of-address 399 is the source address of the regional binding update received from 400 the next lower regional-aware router. In the access router, the 401 care-of-address is the sending link address of the mobile node. 402 Implementation of the regional binding cache can reuse the basic 403 Mobile IPv6 binding cache entry with a new `I' flag set. 405 Since the network controls the crossover router selection, the 406 responding visited domain target router is not known to the mobile 407 node. It sends the packet to the anycast address or the unicast 408 address of the router. The packet is received by the router 409 from which the mobile node received the router advertisement. 410 The regional care-of-address MUST be inserted as a alternate 411 care-of-address sub-option of the regional binding update. The `A' 412 bit MUST be set and the `H' bit MUST NOT be set. 414 The mobile node appends the previous access router sub-option (Section 4.4) 415 to the regional binding update. This sub-option identifies the 416 previous access router so that each router can locally decide whether 417 it is the crossover router. When the signal is propagated upwards, 418 the first router that has the previous access router among its 419 descendants is the crossover router. When this sub-option is absent, 420 the regional binding update propagates up to the gateway mobility 421 agent. To know its descendants, a regional-aware router maintains a 422 list of all of its descendants. How this list is configured is out 423 of the scope of this protocol; it can be statically configured from a 424 parameter file, for example. Alternatively, a mobile router can set 425 the 'R' bit in the regional binding update to join the hierarchy as 426 a leaf router. Then, a descendant list entry is established with a 427 lifetime, and the mobile router marks the upper regional router as a 428 father router. 430 After a successful regional binding update, a basic Mobile IPv6 431 binding acknowledgement is returned to the mobile node back through 432 the hierarchy. In case of signaling where anycast address is 433 used all the way through the hierarchy, a binding acknowledgement 434 SHOULD be sent to the MN and to the anycast address. A successful 435 regional registration is denoted by a new success status value 436 1. This denotes regional-aware success; status value 0 denotes 437 regional-unaware success. In the latter case, the receiving node 438 accepted the binding update as any corresponding node would. The 439 mobile node can thus send regional binding updates to any node and 440 recognize regional-awareness of the other end from this status 441 value. This gives the protocol robustness against mis-configured 442 regional-aware routers. 444 The mobile node SHOULD NOT send binding updates with the regional 445 care-of-address to regular nodes until it has received the 446 regional-aware success status value 1. If the regional-aware 447 router fails to accept the regional registration, it returns a 448 Reason Unspecified status value 128 in the binding acknowledgement. 449 However, if the mobile node does not receive status value 1 from 450 the gateway mobility agent, the mobile node MUST re-send a binding 451 updates with the primary care-of-address. 453 A regional-aware mobile node MAY support mobile multi-homing, 454 i.e. the mobile node MAY register more than one home address 455 simultaneously with one or more home agents. Operation of these 456 addresses occur independently, i.e. as if there were multiple mobile 457 nodes within the same physical host. The mobile node MUST NOT 458 register more than one care-of-address for each home address. 460 If regional-aware propagation uses unicast addresses, the regional 461 binding update is re-generated in each intermediate router. If the 462 first target is anycast address, the propagation MAY change into 463 unicast-based inside visited domain or it MAY remain anycast-based. 464 A discussion on differencies with these modes is in Appendix B 466 3.4. Regional-Aware Data Routing 468 Since the regional care-of-address is in the visited domain, packets 469 targeted to it go through the regional-aware routing hierarchy from 470 the GMA towards the mobile node. The other direction is not affected 471 by regional registrations. 473 When a corresponding node sends data packets to a mobile node to 474 which it does not yet have an entry in its binding cache, these 475 packets are intercepted by the home agent and encapsulated to 476 the registered care-of-address mobile node, as specified in the 477 basic Mobile IPv6. However, this care-of-address is the regional 478 care-of-address. 480 For tunneled packets, the regional care-of-address of the mobile node 481 is selected as the target for the outer encapsulation header. The 482 router which controls that regional care-of-address decapsulates the 483 tunneled packets. The destination of the encapsulated packet is the 484 home address of the mobile node. 486 If there is an entry in the regional binding cache for this home 487 address, the router SHOULD re-encapsulate these packets to the 488 corresponding lower care-of-address. This is in the next lower 489 regional-aware router or in the mobile node if the forwarder is the 490 access router. Thus, the data packets SHOULD get re-capsulated at 491 each regional-aware router on their way down the hierarchy. 493 If the lower regional-aware router is at link-distance from the 494 forwarding regional-aware router, or a routing protocol maintains 495 host-based routes between regional-aware routers, the router 496 MAY forward these packets simply by using host-based routes. 497 The forwarding MAY also use other methods such that the packet 498 propagation occurs as with the above methods. A method of forwarding 499 is local to a router in a way that multiple methods of forwarding can 500 be used in a visited domain without a negotiation mechanism. 502 4. Protocol Extensions 504 The following protocol extensions are defined: 506 - A modification to the Modified Router Advertisement Message 507 to indicate whether the visited domain supports regional 508 registrations (the `I' bit) (Section 4.1). 510 - A regional care-of-address extension to the router 511 advertisement (Section 4.2). 513 - A modification to the Binding Update destination option to 514 indicate whether the option is a Regional Binding Update (the `I' 515 bit) (Section 4.3). 517 - An previous access router sub-option for the binding 518 update (Section 4.4). 520 4.1. Router Advertisement modifications 522 The router advertisement, as defined in the basic Mobile IPv6, 523 contains additionally the `I' bit and the visited domain identity in 524 the Modified Prefix Information Option of the Router Advertisement 525 Message. The format of the new Modified Prefix Information Option is 526 the following: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | Prefix Length |L|A|R|I|Rsrvd1 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Valid Lifetime | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Preferred Lifetime | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Reserved2 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 + + 541 | | 542 + Prefix + 543 | | 544 + + 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 2: The Modified Prefix Information Option 550 I Indicates regional registrations support. 552 The Rsvrd1 field is here a 4-bit field instead of the 5 bits 553 Reserved1 prior to adding the `I' bit. Other fields are as described 554 in the Mobile IPv6 and the Neighbor Discovery [8] documents. 556 4.2. Regional CoA Extension 558 The router advertisement may contain one or more visited-domain 559 care-of-addresses from which the mobile node chooses a regional 560 care-of-address. Each such address is advertised in a Regional CoA 561 Extension of the modified Router Advertisement. 563 The format of the regional CoA extension is the following : 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | Prefix Length | Index | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Lifetime | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | 573 | Regional Care-of-Addresses | 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 3: Regional CoA extension 579 Type 6, TBD (skippable) 581 Length 8-bit unsigned integer. The length of the option 582 (including the type and length fields) in units of 8 583 octets. This field MUST be 3. 585 Lifetime The time the advertised CoA is valid in the visited 586 domain. 588 Prefix Length 590 An 8 bit unsigned integer. This denotes prefix length 591 of the ``visited domain routers'' anycast address where 592 the prefix is taken from the regional care-of-address 593 and the host number is 0 (TBD). One of these options 594 MUST identify the visited domain. Prefix length fields 595 in the other regional CoA options in the same router 596 advertisement MUST be zero. 598 Index Index describing which of the global prefixes can be 599 used with this address. 1 denotes the first prefix in 600 the advertisement. Special value 0 denotes that this 601 address applies to all prefixes. The options SHOULD be 602 ordered so that regional CoA extensions associated with 603 a given prefix are immediately after that prefix. 605 Regional Care-of-Address 607 The advertised address, which MUST be a global IPv6 608 address from the visited domain. 610 4.3. Regional Binding Update 612 The Regional Binding Update is a Mobile IP Binding Update with the 613 following modifications. In the Reserved field after the flags 614 field, there will be the following additional bit. 616 Description of extensions to the BU option: 618 I Indicates regional registrations support. This implies 619 that the receiving router will use the BU information to 620 establish or maintain a regional binding cache entry. The 621 bit is the first bit from the Reserved field of the Mobile 622 IPv6 Binding Update destination option. 624 Previous Access Router Sub-Option 626 A sub-option for determining the crossover router. 628 4.4. Previous Access Router Sub-Option 630 The previous access router sub-option is used by the network 631 to determine the crossover router. A crossover router address 632 is obtained from the IP header source address of the router 633 advertisement. The mobile node remembers this for the previous 634 router and uses it to create an previous access router sub-option. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Length | PathId | PathCount | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | 642 | Previous access router | 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Figure 4: Previous Access Router Sub-option 648 Type 5, TBD (skippable) 650 Length 8-bit unsigned integer. The length of the sub-option 651 (including the type and length fields) in units of 8 652 octets. 654 PathId 8-bit unsigned integer. This optional field identifies 655 a route for one mobile node with multiple routes within 656 a visited domain from the edge router to GMA.ix from 657 the 659 PathCount 8-bit unsigned integer. Identifies the number of path 660 branches on the path of a regional binding update. 661 This optional field is also used for multiple routes 662 support. A crossover functionality can e.g. propagate 663 regional binding updates to the GMA if the PathCount is 664 greater than one. 666 Previous access router 668 The IP address of the previous access router as seen by 669 the mobile node. 671 There is no requirement for alignment of the Previous Access Router 672 sub-option. 674 The previous access router sub-option is valid in the Binding Update 675 destination option. The previous access router contains the IPv6 676 address of the access router as seen by the mobile node. It is used 677 to identify the crossover router in the visited domain regional 678 router graph. This is done by comparing the previous access router 679 to the known descendants when the regional binding update gets 680 forwarded upward in the tree of regional-aware routers. When the 681 router finds the previous access router in its list of descendants, 682 it is the crossover router. 684 5. New requirements for IPv6 Nodes 686 The presented option requires modifications to the visited-domain 687 routers and to the mobile node. The option does pose no new 688 requirements to the home agent, to correspondent nodes, or to other 689 network elements than to the regional-aware routers in the visited 690 domain. 692 5.1. Visited Domain Router Requirements 694 The support of the protocol is optional to basic Mobile IPv6; 695 elements can function in both regional-aware and regional-unaware 696 visited domains. Introducing regional-aware routers to a visited 697 domain does not mandate the use of regional registrations. 699 The regional-aware access router MUST be capable of advertising 700 regional registration support. The router MUST be capable of 701 maintaining regional binding cache entries based on regional 702 binding updates. These routers MUST route the data packets to the 703 regional-registered mobile nodes so that a mobile node can recognize 704 the use of route optimization from the presence of a routing header, 705 as described in Section 3.4. 707 5.2. Mobile Node Requirements 709 A regional non-aware mobile node can operate in a regional-aware 710 network. The regional-aware mobile node SHOULD select a regional 711 care-of-address and send a regional binding update accordingly. 713 6. IANA Considerations 715 The presented protocol does require the addition of one skippable 716 option type to the router advertisement [8] and one skippable 717 sub-option type to the Binding Update destination option. 719 Also, the protocol requires two modifications from the Modified 720 Router Advertisement Message`s Prefix Information Option, one bit in 721 its Reserved1 field, from the format specified in the basic Mobile 722 IPv6 [4]. The protocol also needs one new bit from the Reserved 723 field of the Mobile IPv6 Binding Update option. 725 The Binding Acknowledgement would need one new regional-aware success 726 code, with a proposed value of 1 to be added to the list of known 727 status field values. 729 A host number for the ``visited domain routers'' anycast address 730 would be needed. The value 0 is suggested. 732 7. Security Considerations 734 The regional-aware mobile node SHOULD use a mobile-visited-domain key 735 for authentication. The IPSec authentication header (AH) is used for 736 security as in basic Mobile IPv6. In regional signaling, the mobile 737 node and visited domain share a security association, in form of a 738 mobile-visited-domain key for IPSec. The mobile-visited-domain key 739 is obtained when entering the visited domain and transported to the 740 visited domain routers and to the mobile node. 742 The protocol in this document assumes that the routers have a way to 743 authenticate messages based on anycast security associations. The 744 usage of AAAL as a source of unique SPIs among all visited domain 745 routers, as explained in Appendix A, is utilized to enable the use 746 of anycast address -based security association identification. As 747 long as the visited domain anycast address -based SPD entries are 748 not created by means other than specified, this allows for the 749 use of anycast security association in this particular case. A 750 challenge-response -based replay service for aycast in this case is 751 also introduced. 753 References 755 [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for 756 IPv6 Network Access (work in progress). Internet Draft, Internet 757 Engineering Task Force, March 2000. 759 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 760 Levels. Request for Comments (Best Current Practice) 2119, 761 Internet Engineering Task Force, March 1997. 763 [3] Eva Gustafsson, A. Jonsson, and C. Perkins. Mobile IP Regional 764 Registration. draft-ietf-mobileip-regtun-03.txt, July 2000. 765 (work in progress). 767 [4] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 768 progress). Internet Draft, Internet Engineering Task Force, 769 November 2000. 771 [5] R. Koodli, M. Tiwari, and C. Perkins. Header Compression 772 State Relocation in IP Mobile Networks (work in 773 progress). Internet Draft, Internet Engineering Task 774 Force. draft-koodli-rhoc-hcompr6-00.txt, July 2000. 776 [6] Rajeev Koodli and Charles E. Perkins. A Framework for 777 Smooth Handovers with Mobile IPv6 (work in progress). 778 Internet Draft, Internet Engineering Task Force. 779 draft-koodli-mobileip-smoothv6-02.txt, November 2000. 781 [7] G. Krishnamurthi, R. Chalmers, and C. Perkins. Buffer 782 Management for Smooth Hand-Overs in Mobile IPv6 (work in 783 progress). Internet Draft, Internet Engineering Task Force. 784 draft-krishnamurthi-mobileip-ipv6buf-00.txt, July 2000. 786 [8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 787 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 788 Internet Engineering Task Force, December 1998. 790 [9] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys for 791 Mobile IP (work in progress). 792 draft-ietf-mobileip-aaa-key-03.txt, September 2000. 794 A. Changes to the previous version 796 This version introduces an anycast address to represent the 797 visited domain as a distributed network endpoint in addition to 798 supporting the unicast-based approach of the previous version. A 799 one message-exchange multi-level signaling is efficient e.g. when 800 the mobile node needs to communicate both with the access router 801 and the gateway mobility agent (GMA). The other changes address 802 problems mentioned in earlier working group minutes, in security and 803 in providing uniqueness of the visited domain identity. 805 - This version distributes the network endpoint of communication 806 identifying it with an anycast address. A common security 807 association per mobile node can be used in the visited domain 808 when key material received from AAAv6 is propagated to members of 809 the anycast group, as described in Appendix B. This change also 810 preserves the cost-efficiency of having a single message exchange 811 with the deep hierarchy while now providing a fully specified 812 security option. 814 - The regional forwarding now is based on encapsulation or 815 host-based routes. Other methods specified elsewhere may also be 816 used. The earlier regional forwarding of route-optimized packets 817 is now separated into another draft. 819 - The router advertisement now also uniquely identifies the 820 visited domain with the special ``visited domain routers'' 821 anycast address. This address is formed using prefix of the 822 regional care-of-address and a host number 0 (TBD). Thus, no 823 visited domain identifier is used in this version from the 824 prefix information option. The same anycast address is used 825 by the mobile node to send the regional binding update to the 826 distributed endpoint, the destination IP address of the regional 827 binding update. 829 - The unicast address of the advertising router can also be used 830 as a destination of a regional binding update. Internally this 831 means a different propagation of the regional binding update 832 but does not require any extra negotiation between the mobile 833 node and the access router. The mobile node can now send the 834 regional binding update to either to the unicast or to the 835 anycast address. 837 - A security appendix now describes a temporary security 838 association acquisition and propagation mechanisms with 839 alternative regional binding update propagation schemes. These 840 give the visited domain builder several configuration options 841 while remaining transparent to the mobile node. 843 B. Regional Registrations Security 845 Mobile IPv6 Regional Registrations signaling is secured using 846 Authentication Header using binding updates as with Mobile IPv6 home 847 registration binding updates. However, since the communicating 848 parties in sending regional binding updates are the mobile node 849 and regional routers, a static security association can not be 850 assumed between mobile node and each visited domain in a scalable 851 solution. Regional registrations security considers scalable 852 acquisition of the needed security association(s) and their use with 853 Authenitcation Header -based security. This document specifies 854 mechanisms and extensions to the Mobile IP Binding Update, and 855 binding acknowledgements messages that can be used to distribute such 856 security information to the mobile node and visited domain. 858 B.1. Trust delegation 860 A mobile-visited domain security association can be obtained in a 861 multiple ways, depending on availability of mechansims and policy 862 requirements of the visited domain. The visited domain can also 863 provide open access. 865 A regional-aware visited domain can view trust delegation in 866 two distinct ways. A full per-mobile trust delegation from an 867 authorization center provides trust from a key distribution center 868 in form of per-mobile session key material to every regional-aware 869 router which participates to regional signaling. This can be 870 used when propagating a regional binding update unmodified to the 871 crossover router. 873 A model with trust propagated to the edge routers of a visited domain 874 can be used with a policy where the more static intra-visited-domain 875 security associations are used for protecting the propagated regional 876 binding update. In this case the regional signals are re-transmitted 877 from intermediate regionals routers using new authentication header. 878 A benefit is that the visited domain does not need to have per-mobile 879 security associations in all routers making the visited domain more 880 scalable for a very large number of mobile nodes. 882 B.2. Key distribution principles 884 Security credentials for mobile-visited domain security associations 885 can be obtained in a multiple ways. One way is to assume an 886 AAA-based key distribution and use mechanisms like AAA registration 887 keys for Mobile IP [9]. The latter provides two key distribution 888 schemes for getting temporary session keys for the mobile node and a 889 router. 891 If trust is delegated to the edge routers, and no per-mobile key 892 distribution inside the visited domain is desired, a regional 893 binding update is propagated by recreating it with authentication 894 headers used between adjacent regional routers. The regional binding 895 acknowledgement is then propagated in a similar way back to the edge 896 router which finally re-sends the binding acknowledgement to the 897 mobile node using the mobile-visited-domain security association. 899 An intra-visited-domain key distribution mechanism may be applied 900 with regional signaling, if full per-mobile trust delegation is 901 desired. A regional binding update is propagated with its original 902 authentication header to the crossover router, encapulated with an 903 outer IP header and a key distribution option. 905 The two modes have the same signaling behavior seen from the mobile 906 node. Thus the visited domain administrator can locally configure 907 either of the modes without it being visible to mobile nodes. 909 B.3. The full per -mobile trust delegation model 911 B.3.1. Regional Registrations Key Distribution 913 A regional-aware gateway router with the selected regional 914 care-of-address MAY communicate with the AAAv6 local authority 915 during the first regional binding update into a visited domain, 916 depending on the local requirements for authorizing network access. 917 The visited domain MAY provide temporary access rights for regional 918 registrations while the AAA infrastructure is generating a reply to 919 the authorization request. When the AAA has granted access, the 920 access to the visited domain is decisively granted. 922 AAAv6 is expected to provide temporary key material for the mobile 923 node and the visited domain to be used in subsequent regional 924 authentications. As mentioned previously, many solutions currently 925 exist like AAA registration keys for Mobile IP IP [9]. This material 926 is provided for the mobile node in combination with a Binding 927 Acknowledgement, and also for the visited domain. The latter is then 928 propagated together with regional registration signaling in a key 929 material destination option. This option is inserted to the outer 930 encapsulation header when propagating subsequent regional binding 931 updates or binding acknowledgements inside the visited domain. It 932 can be protected with IPsec using intra-visited-domain security 933 associations. 935 Or as an alternative, the intermediate routers retrieve the user 936 specific session key from the AAA-L which also stores it. 938 B.3.2. Anti replay attacks 940 Anti replay attacks can not be provided by the Sequence number 941 specified in the Authentication Header protocol since this requires 942 all the intermediate routers to have synchronized counters which is 943 difficult. 945 Instead, nonces SHOULD be used to provide anti replay attacks: The 946 mobile node takes the Local Challenge citedraft-ietf-perkins-aaav6, 947 sent in Router advertisements messages, as an input to the 948 authentication data computation of the regional binding update 949 message. The Local challenge is then included in the Regional 950 Binding Update and the access router first ensures the freshness of 951 the message by verifying that the Local Challenge carried in the 952 Binding Update message is a recent one. This Local Challenge is also 953 encapsulated with the Regional Binding Update message until the cross 954 over router which ensures freshness of the message by verifying that 955 the authentication data takes into account the recent Local Challenge 956 carried in the message. 958 The mobile node SHOULD also generate a Host Challenge that is also 959 included in the Binding Update message as a destination option and 960 encapsulated until the cross over router which tales that Host 961 Challenge as an imput when computing the authentication data of the 962 Binding Acknowledgement message. The Host Challenge is then sent 963 back in the Binding Acknowledgement message and the mobile node 964 can thus verify the freshness of the reply from the access router 965 by making sure the authentication data computationtook this Host 966 Challenge into consideration. 968 B.3.3. Key Material Destination Option 970 This is a possible extension to carry the user specific key between 971 the intermediate routers. The message carrying this extension should 972 be encrypted and intergrity protected by using intra domain security 973 (e.g. IPsec) 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | Alg | Key Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | SPI | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Key... 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 Figure 5: Key Material Destination Option 987 Type TBD (skippable), one for key request, one for key reply 989 Length 8-bit unsigned integer. The length of the option 990 (including the type and length fields) in units of 8 991 octets. 993 Alg 8-bit algorithm indication as specified for the 994 Authentication Header. 996 Key Length 998 8-bit unsigned integer. The length of the key in 999 units of 4 octets. 1001 SPI 32-bit Security Parameter Index value. 1003 Key Encrypted key material of at most 1024 octets. 1005 As an alternative, the intermediate routers can retrieve the user 1006 specific session key fro the AAA-L: this requires only security 1007 associations between intermediate routers and AAA-L whereas the 1008 propagation of the user keys requires security associations between 1009 all the intermediate routers. 1011 B.4. "trust delegated to edge routers" security model 1013 This section describes another alternative of a security model where 1014 Regional Registration could deployed securely. This solution is 1015 more scalable requiring only user specific security association 1016 between the MN and the Access routers and then relying on intra 1017 domain security to authenticate the regional binding update within 1018 the visited domain. 1020 B.4.1. Security Association Acquisition from AAA 1022 When entering a visited domain, the mobile node performs a home 1023 registration in combination with the first regional binding update: 1025 The mobile node computes some authentication data (e.g. from a 1026 Local challenge sent to the Hosts in Router advertisments messages, 1027 from a Home Challenge generated by the Home domain for anti replay 1028 attacks [1], and using the Long term key shared between the mobile 1029 node and its Home domain), and adds a Regional Registration key 1030 request in the regional binding update. 1032 The destination address in the IP header of the regional binding 1033 update at the sending mobile node is the source address of the router 1034 advertisement containing the selected regional care-of-address or the 1035 anycast address identifying the visited domain. 1037 The receiving Access Router, due to the presence of the 1038 authentication extension, forwards the message to the AAA-L, which 1039 invokes the AAA-H for entity authentication: the serving system 1040 wants to make sure the user is a valid one before giving him access 1041 to its network resources. If the Home agent is in the home network, 1042 this AAA invocation to the Home domain may include the Home Binding 1043 Update [1] to the Home Agent. If Home agent is dynamically assigned 1044 in the home network, AAA-H assigns the Home agent and sends a Binding 1045 update to the assigned Home agent. These are possible optimizations 1046 to save round trips between the visited and home domain reducing time 1047 delay and load over the network. In such cases, the home binding 1048 update may indicate the regional care of address as the alternate 1049 care-of-address and if regional registration fails (e.g. RcoA is not 1050 valid), the mobile node will update the Home agent. 1052 Once authentication succeeded, thanks to the keying material, AAA-L 1053 can compute a regional registration key K wich is specific to the 1054 mobile node. AAA-L sends it to the Access Router with the keying 1055 material destined to the mobile node for it to be able to derive K. 1057 The access router then sends the Binding Acknowledgement with some 1058 extension carrying the keying material to the mobile node which will 1059 derive K and create a regional binding update authenticated using K. 1061 As another optimization, since in wireless networks, radio resources 1062 are limited, the Access router, on receipt of the network access 1063 authorization from AAA-L, knows the mobile node is valid and can 1064 perform regional registration thus saving one additional round trip 1065 over the air interface. 1067 The access router sends a new binding update to the next-hop cross 1068 over router to create the binding between the mobile node home 1069 address and the access router care of address. This binding update 1070 is authenticated using a intra domain security association: Access 1071 Router and Cross over router share a key which can be set up in 1072 different ways and is operator dependant. This key is not user 1073 specific. 1075 The Cross over router propagates the binding update until the GMA 1076 using as previously intra domain security. Thus, only Access routers 1077 needs to maintain user specific security asociations which is more 1078 scalable than having user specific security associations up to the 1079 GMA requiring the GMA to maintain the security associations for all 1080 the users it is serving. 1082 B.4.2. Movement to a new Link 1084 When entering a new foreign link within the same domain, the mobile 1085 node sends a regional binding update authenticated using K. The 1086 receiving access router can either retrieves the key from the 1087 previous access router indicated by the mobile node or from the 1088 AAA-L. The latter option only requires security association between 1089 access router and AAA-L whereas the first option also needs security 1090 association between Access routers. 1092 The access router then verifies the authenticity of the binding 1093 update message and if succeeded, it sends binding update messages up 1094 to the crossover router using intra domain security. Alternatively, 1095 if so wished by trust delegation policy, the binding update can be 1096 propagated to the crossover router with the original authentication 1097 header, and with an outer encapsulation containing a key material 1098 destination option (Section B.3.3) with the distributed key encrypted 1099 using intra domain security. Each router decapsulating this option 1100 inserts it to its security policy database prior to using it for 1101 authenticating the regional binding update. 1103 B.4.3. Anti replay attacks 1105 Between the mobile node and the access router, since the access 1106 router creates the binding acknowledgement message to the mobile 1107 node, replay protection can be provided by various methods: 1109 Timestamps: The MN and the access router verify the freshness of the 1110 messages by making sure that the timestamp used is the current one. 1112 Sequence number: Authentication header has a Sequence number to 1113 provide anti replay service. This counter is one possibility and in 1114 such cases, when mobile node moves to a new link, the new serving 1115 access router when retrieving the user specific key K, also needs to 1116 retrieve the value of this sequence number from the previous access 1117 router. 1119 Nonces: The mobile node can take the Local challenge [1] sent in 1120 Router Advertisements messages as an input to the AH authentication 1121 data of regional binding update messages. The access router 1122 ensures freshness of binding update message from the mobile node 1123 by verifying that the local challenge included in the Request is a 1124 recent one. The mobile also generates a Host Challenge that will 1125 be included in the authentication data of the Binding update and 1126 binding acknowledgement messages. This way, the host can verify the 1127 freshness of the reply from the access router. 1129 B.5. Forwarding Modes and comparison of these different modes from a 1130 security point of view 1132 First, as described in the security models in the previous section, 1133 the Access Router can either re-create new binding update message 1134 or encapsulate the mobile node's binding update message to perform 1135 regional registration within the visted domain. 1137 The trust model is different but in both cases, the MN needs to 1138 rely on the intra domain security of the visted domain: Either 1139 to re-create binding update message in the "trust delegated to 1140 edge routers model" or to distribute the keys to the different 1141 intermediate routers in the "full per-mobile trust delagation model". 1143 These two models also differ on a scalability point of view: the 1144 "trust delegated to edge routers model" only requires user specific 1145 security associations between mobile nodes and access routers whereas 1146 the "full per-mobile trust delegation model" requires user specific 1147 security associations between all the intermediate routers from the 1148 Access router serving the MN up to the GMA. This may requires many 1149 security associations to be maintained in particularly for the GMA 1150 and thus may have some scalability issues. 1152 In addition, a visited domain can be administratively configured 1153 to different forwarding schemes. The visited domain can forward 1154 the regional binding update and acknowledgement by receiving and 1155 re-sending them between intermediate regional routers. This can 1156 take place when the mobile node initially sends the regional binding 1157 update either to the advertising router's unicast or to the anycast 1158 address. Also, the regional binding update, sent to the anycast 1159 address can be forwarded unmodified to the crossover router. 1161 In the case of RBU re-sending, the key distribution principle of 1162 delegation to the edge routers is used. This enables two different 1163 modes of key propagation where a session key is acquired either from 1164 the previous access router or from the AAAL. Session keys are not 1165 propagated deeper into the visited domain so the state space for 1166 a large number of mobile nodes is smaller than in the full trust 1167 delegation mode. Also, network topology is not revealed in this 1168 case since the binding acknowledgements seem to come from the edge 1169 routers. 1171 In the full trust delegation mode we use the anycast-based unmodified 1172 RBU forwarding. This provides direct mobile node authentication in 1173 the crossover with a fast forwarding of the unmodified RBU. It also 1174 results in propagating the key material, either in-line with the key 1175 material destination option, or by asking the key from the AAAL in 1176 each router. This can be considered inefficient in a large visited 1177 domain. Since the mobile node in this case directly gets replies 1178 from crossover routers, the visited domain topology is revealed. 1180 Addresses 1182 The working group can be contacted via the current chairs: 1184 Basavaraj Patil Phil Roberts 1185 Nokia Corporation Motorola 1186 6000 Connection Drive 1501 West Shure Drive 1187 M/S M8-540 1188 Irving, Texas 75039 Arlington Heights, IL 60004 1189 USA USA 1190 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1191 Fax : +1 972-894-5349 1192 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com 1194 Questions about this memo can also be directed to the authors: 1196 Jari T. Malinen Charles E. Perkins 1197 Communications Systems Lab Communications Systems Lab 1198 Nokia Research Center Nokia Research Center 1199 313 Fairchild Drive 313 Fairchild Drive 1200 Mountain View, California 94043 Mountain View, California 94043 1201 USA USA 1202 Phone: +1-650 625-2355 Phone: +1-650 625-2986 1203 E-mail: jmalinen@iprg.nokia.com E-mail: charliep@iprg.nokia.com 1204 Fax: +1 650 625-2502 Fax: +1 650 625-2502