idnits 2.17.1 draft-blair-rt-mobileipv6-seamoby-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1568 lines 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 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 8 instances of too long lines in the document, the longest one being 71 characters in excess of 72. ** There are 15 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 899: '...in the ticket MUST be equal to mobilei...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 923 has weird spacing: '...caching can u...' == Line 983 has weird spacing: '...nsigned integ...' == Line 1003 has weird spacing: '...nsigned integ...' == Line 1033 has weird spacing: '...nsigned integ...' == Line 1063 has weird spacing: '...nsigned integ...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8562 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: 'RFC 1510' is mentioned on line 545, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Missing Reference: 'IAKERB' is mentioned on line 804, but not defined -- Looks like a reference, but probably isn't: '3' on line 1156 -- Looks like a reference, but probably isn't: '2' on line 1153 -- Looks like a reference, but probably isn't: '5' on line 1164 -- Looks like a reference, but probably isn't: '8' on line 1168 -- Looks like a reference, but probably isn't: '4' on line 1159 -- Looks like a reference, but probably isn't: '9' on line 1172 -- Looks like a reference, but probably isn't: '1' on line 1150 == Missing Reference: 'XXX' is mentioned on line 1199, but not defined == Missing Reference: 'AR1' is mentioned on line 1392, but not defined == Missing Reference: 'MN' is mentioned on line 1407, but not defined == Missing Reference: 'AR2' is mentioned on line 1404, but not defined == Unused Reference: 'COPS2' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 ** Obsolete normative reference: RFC 1510 (ref. 'KRB1') (Obsoleted by RFC 4120, RFC 6649) Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Dana Blair 2 INTERNET-DRAFT Alex Tweedly 3 Michael Thomas 4 Jonathan Trostle 5 Michael Ramalho 6 Cisco Systems 8 File: draft-blair-rt-mobileipv6-seamoby-00.txt November 2000 9 Expires: June 2000 11 Realtime Mobile IPv6 Framework 13 Status of this Memo 15 This document is an Internet Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, its and working groups. Note that other 20 groups may also distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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 draft develops terminology, an architectural framework, a list of 36 objectives, and a proposed solution for Realtime Mobile IPv6. 37 Realtime Mobile IPv6 seeks to deliver realtime application data to 38 IPv6 capable Mobile Nodes while minimizing the impact of handoff on 39 realtime applications. 41 1. Introduction 43 The convergence of wireless networking and IP networking requires 44 solutions for transporting realtime application data to mobile devices. 45 Current IP mobility solutions tend to focus primarily on best effort 46 data transport to and from a mobile device. To support realtime 47 applications, security, admission control, and QoS need to be examined 48 concurrently with mobility to facilitate smooth transitions from one 49 access link to another while minimizing the impact on realtime 50 applications. 52 This draft assumes IPv6 because the proliferation of mobile devices 53 will require the use of IPv6 addresses to support the number of attached 54 devices. Without the larger IPv6 address space, the end-to-end 55 transparent Internet model will be broken up and made much more complex 56 by the use of private IP addressing and result in the inclusion of 58 Network Address Translators, Application Layer Gateways, and Protocol 59 Translators. Also, use of private IP addressing is not practical when 60 the end device functions as an application server such as Voice over IP. 62 1.1 Problem Description 64 Mobility solutions require that packets be redirected to the current 65 location of a mobile device. The Mobile IPv6 Binding Update [MIPv6] is 66 sufficient to accomplish this for best effort traffic. However, 67 realtime applications require coordination of admission control, 68 security associations, and Quality of Service guarantees to minimize 69 packet loss and jitter to satisfy the expectations of realtime 70 applications. 72 Considered independently, admission control, Security Associations, 73 Quality of Service signaling, and Binding Updates could significantly 74 delay the transition from one access link to another, thus degrading the 75 performance of realtime applications. 77 This draft develops terminology, an architectural framework, a list of 78 objectives, and a proposed solution for Realtime Mobile IPv6. 80 2. Terminology 82 Subscripted Elements 84 In this draft we will have occasion to reference the "present" element 85 of a given type and the "next" element of that same type with indices 86 "n" and "n+1", respectively. For example, we will reference the first 87 access link (AL) as AL1, the next as AL2, and so on. We will use 88 this indexing methodology as shorthand for any element (e.g., ALn+1, 89 ARn, vPDPn. We do not intend that the actual "present" index "n" to 90 be identical across element type (e.g., the present ALn could be AL9, 91 while the present vPDPn could be vPDP2). 93 The sample network diagram of Figure 1 below is used to illustrate the 94 terminology used in this draft. This figure will be used to describe 95 the operation of the proposed handoff mechanisms by means of the 96 specific network topology example shown in this figure. 98 +--------------------------+ 99 | HN | 100 | | 101 | +----+ +----+ +-----+ | +-----+ +-----+ 102 | |HA | |HKDC| | hPDP| | |cNode| |AKDC | 103 | | | | | | | | | | | | 104 | +----+ +----+ +-----+ | +-----+ +-----+ 105 +--------------------------+ 107 +-----+ 108 |vPDP | 109 +-----+ 111 +------------------------------+ +-----------------+ 112 | TD1 | | TD2 | 113 | +----+ +----+ | | +----+ | 114 | | AR1| | AR2| | | | AR3| | 115 | | | | | | | | | | 116 | +----+ +----+ | | +----+ | 117 | | | | | | | 118 +------|-----------------|-----+ +--------|--------+ 119 \ | / 120 \ | AL2 / AL3 121 \ AL1 | / 122 \ +----+ / 123 \------| MN |---------/ 124 +----+ 126 Figure 1: Sample Network Diagram showing AR1 and AR2 in a particular 127 trust domain and AR3 in a different trust domain. 128 Common Terms 130 Mobile Node (MN) 132 Device which supports IPv6 mobility according to [MIPv6]. 133 A MN may be a host or a router. 135 Home Agent (HA) 137 Device that supports the Home Agent function described in [MIPv6]. 139 Correspondent Node 141 A peer node with which a mobile node is communicating. Defined in 142 [MIPv6]. 144 Home Address (hAddr) 146 An IP address assigned to a MN as defined in [MIPv6]. 148 Care-of-Address (CoA) 150 An IP address assigned to a MN as defined in [MIPv6] 152 New CoA (NCoA) means that CoA on ALn+1 is different than CoA on ALn. 153 Same CoA (SCoA) means that CoA on ALn+1 is the same as CoA on ALn. 155 Access Router (AR) 157 An IP router between an Access Network and one or more access links. 159 Access Network (AN) 161 An IP network which includes one or more Access Routers. 163 Policy Decision Point (PDP) 165 A network service that is responsible for handling policy decisions 166 (e.g. access authorization, qos authorization, etc.) and also 167 billing and settlement issues. Defined in [COPS1] 169 Home PDP (hPDP) is the policy decision point used by the 170 Home Network. 172 Visited (vPDP) is the policy decision point used by the visited 173 network. 175 Key Distribution Center (KDC) 177 A network service that supplies tickets and temporary session keys. 178 Defined in [KRB1]. 180 The Home KDC (HKDC) provides security credentials for the MN to 181 register with the Home Agent. 183 Trust Domain (TD) 185 A set of access routers within a particular network that have direct 186 trust relationships between all ARs in that set. In the figure above 187 TD1 is comprised by the set {AR1, AR2} and TD2 is the set {AR3}.. 189 Access Link (AL) 191 A link layer connection between MN and AR. Multiple Access Routers 192 may share the same access link. An AL consists one downlink or 193 one uplink or both. 195 Downlink communication flows from AR to MN. 197 Uplink communication flows from MN to AR. 199 Handoff Trigger 201 A Handoff Trigger initiates a Handoff Decision. The MN or an 202 element within the AN may create a Handoff Trigger. The result of 203 the handoff decision may create a Handoff Command. 205 Example sources of a Handoff Trigger are MN detects a stronger 206 signal for a different AL, or AN detects that a MN is moving and a 207 new AL would provider better transmission. Many other sources of 208 Handoff Trigger exists. 210 This draft does not discuss events that result in a Handoff Trigger. 212 Handoff Decision 214 A Handoff Decision is an algorithm which decides whether or not to 215 issue a Handoff Command based on one or more Handoff Triggers. 217 This draft does not propose algorithms for the Handoff Decision. 219 Handoff Command 221 The Handoff Command initiates a Handoff Sequence. The MN or an 222 element within the AN may issue a Handoff Command. The Handoff 223 Trigger and Handoff Command may be created by different network 224 components or the same network component. 226 Handoff Sequence 228 A Handoff Sequence is a series of steps executed by various network 229 components to attempt a handoff. A Handoff Sequence may be 230 successful in establishing ALn+1. However, establishment of ALn+1 231 does not guarantee communication with a cNode. Since IP is 232 connectionless, a Handoff Sequence cannot rely on IP or link layer 233 indications to verify that the MN can communicate with a cNode over 234 ALn+1. 236 The solutions section of this draft contains an abstract Handoff 237 Sequence proposal. Detailed Handoff Sequences are in the appendix. 239 Initialization Sequence 241 An Initialization Sequence is a series of steps executed by various 242 network components to establish communication over an AL for the 243 first time. 245 Wake-up Sequence 247 A Wake-up Sequence is a series of steps executed by various network 248 components to establish an AL while a MN is in sleep mode. Sleep 249 mode means the device is in a lower power state with no uplink, and 250 a limited downlink capability. 252 Handoff Delay 254 Handoff delay is the time between when the handoff command is issued 255 and when ALn+1 is established. 257 Handoff Types 259 Make-Before-Break Downlink Handoff (MBBDH) 261 ALn+1 downlink is established before removing ALn downlink. 262 Duration of simultaneous ALn and ALn+1 downlink connections is 263 not bounded. 265 Make-Before-Break Uplink Handoff (MBBUH) 267 ALn+1 uplink is established before removing ALn uplink. Duration 269 of simultaneous ALn and ALn+1 uplink connections is not bounded. 271 Break-Before-Make Downlink Handoff (BBMDH) 273 The MN stops receiving on ALn before being able to receive on 274 ALn+1. 276 Break-Before-Make uplink Handoff (BBHDH) 278 The MN stops transmitting on ALn before being able to transmit on 279 ALn+1. 281 Handoff Control 283 Handoff Control may be performed by various network elements. Any 284 Handoff Sequence should be analyzed to determine which control 285 methods are used. Some control methods may be preferable depending 286 access network technology or administration preference. 288 Mobile Controlled 290 A MN may create any number of access links without a-prior 291 knowledge of any other access link. The MN generates the Handoff 292 Trigger, performs the Handoff Decision, and issues 293 the Handoff Command. 295 Mobile Assisted 297 The MN generates the Handoff Trigger, the network performs the 298 Handoff Decision and issues a Handoff Command to the MN. 300 Network Assisted 302 The network generates a Handoff Trigger. If the network 303 performs the Handoff Decision, the network issues a Handoff 304 Command to the MN. If the MN performs the Handoff Decision, the 305 MN issues a Handoff Command to itself. 307 Network Controlled. 309 The network generates the Handoff Trigger, performs the Handoff 310 Decision, and issues the Handoff Command. The MN must execute a 311 Handoff Sequence to maintain an AL. 313 3. Objectives 315 Items to consider when analyzing a Handoff Sequence. 317 3.1 Handoff Objectives 319 Minimize Handoff Delay 321 Minimize packet drops during Handoff Delay 323 Realtime applications have a relatively low tolerance for packet 324 drops. Packet drops are more likely during BBMDH and BBMUH. 326 Minimize packet latency 328 Minimize misadaptations of adaptive jitter buffers due to handoff. 330 Link Layer Handoff Independence 332 A Realtime Mobile IPv6 Handoff Sequence must not depend on any 333 particular link layer handoff mechanisms but may exploit layer 2 334 information. 336 Handoff link failure behavior 338 A Realtime Mobile IPv6 Handoff Sequence should consider behavior when 339 ALn+1 cannot be established during the Handoff Sequence. 341 Handoff addressing, either SCoA or NCoA, is an important consideration 342 when analyzing or creating a Handoff Sequence. For example, SCoA does 343 not require MN re-registration but may not be possible between Trusted 344 Domains. 346 Handoff Control is an important policy consideration of some access 347 networks. For example, A Handoff Sequence may not be acceptable for a 348 given access network or network policy if the sequence is not Network 349 Assisted or Network Controlled. 351 3.2 Security 353 Fast smooth handoffs must take into account access networks which 354 require both authentication and authorization of mobile users in order 355 to gain access to best effort traffic as well as any other services 356 such as enhanced quality of service, etc. 358 User authentication may be done directly on the access 359 network or via proxied authentication through a third party where the 360 access network provider and the third party have a trust relationship. 361 The latter arrangement allows for a settlement model where a mobile node 362 does not need to have a direct arrangement with the visited service 363 provider, but instead is authenticated with the third party, but 364 settled between the third party and the access service provider. 366 The initial authentication and authorization state should be captured by 367 the access service provider router in a way which allows the 368 authorization state to be forwarded to other access routers within the 369 same Trust Domain. This allows access routers the option of not needing 370 to perform authentication or authorization back to the authoritative 371 authorization source. The advantage of caching this authorization state 372 at the edges is that potentially expensive round trips to the 373 authorizing source can be avoided. 375 The MN should consider requiring mutual authentication. Mutual 376 authentication prevents an intruder from pretending to be an AR and 377 gathering credentials from the MN. 379 3.3 Quality of Service 381 The handoff mechanism should consider the re-establishment of QoS 383 instantiated in ALn when handing off to Aln+1. This should 384 include either intserv or signaled diffserv techniques. 386 4. Handoff Behavior 388 The following is an abstraction of events that may be required before 389 and during handoff. Not all steps are required for all handoff nor are 390 they necessarily executed in the sequence presented. A Handoff Sequence 391 will define a set of steps and protocols required to attempt a handoff. 393 4.1 Initialization Events 395 The Initialization Events allow a MN to establish connectivity with one 396 or more cNodes before attempting to handoff. Although Initialization 397 Events are not part of a Handoff Sequence some parts of initialization 398 may be reused during a Handoff Sequence to simplify operation within 399 the MN. 401 1. Obtain credentials to allow use of the visited network, if 402 necessary. 404 2. Obtain access to and through a visited network. Use credentials 405 from 1., if needed. 407 3. Obtain credentials to allow MN to register with the Home Agent. 409 4. Obtain credentials to be used when establishing Quality of Service 410 for application flows, if necessary. 412 5. Establish security association with the Home Agent using 413 credentials from 3. 415 6. Mobile Node registers with the Home Agent as defined in [MIPv6]. 417 7. Establish zero or more application flows over the first access 418 link, AL1, to one ore more cNodes. QoS credentials from 4. may be 419 used to authorize Quality of Service via a PDP for a specific 420 application flow. 422 4.2 Handoff Events 424 The Handoff Events allow a MN to attempt to move packet forwarding and 425 receiving from ALn to ALn+1. Some events may not be required, or may 426 not be executed in the order presented when applied to a Handoff 427 Sequence. 429 1. Obtain credentials, if necessary, to allow use of ALn+1. 431 2. Obtain access to and through the visited network. If necessary, use 432 credentials from 1. 434 3. QoS signaling for 0 or more application flows. If necessary, use 435 QoS credentials obtained during initialization. 437 4. Establish tunneling and/or forwarding from ARn to MN using ALn+1. 439 5. If New CoA (NCoA), MN re-registers with Home Agent as defined in 440 [MIPv6]. 442 6. If NCoA and if desired, MN notifies cNodes NCoA. 444 7. If possible, Remove ALn when it is no longer needed. 446 4.3 Application of Handoff Objectives. 448 4.3.1 Minimize Handoff Delay 450 Authorization state transfer may be pulled from ARn to ARn+1 or pushed 451 from ARn to ARn+1. 453 Minimize the number of required transactions before MN may send and 454 receive packet to and from a cNode over ALn+1. 456 Minimize the number of home roundtrip transactions required before MN 457 may send or receive a packet to or from a cNode over ALn+1. 459 Minimize the size of all packets transmitted and received before MN 460 may send or receive a packet to or from a cNode over ALn+1. 462 4.3.2 Minimize Packet Drops 464 Limit packet drops by forwarding packets from ARn to MN over ALn+1. 466 4.3.3 Minimize packet latency 468 For NCoA handoff, re-register with HA and cNodes as soon as possible. 470 For SCoA handoff, minimize the delay of forwarding path convergence. 472 4.3.4 Security 474 If ALn and ALn+1 are on different routers, ARn and ARn+1, then: 476 A. ARn and ARn+1 may have a pre-established trust relationship, 477 or 478 B. ARn and ARn+1 may be able to create a dynamic trust relationship, 479 or 480 C. ARn and ARn+1 will never have a trust relationship. 482 4.3.5 Quality of Service 484 Maintain quality of service by establishing acceptable QoS over ALn+1. 485 QoS credentials may be needed. 487 5. References 489 [MIPv6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6", 490 draft-ietf-mobileip-ipv6-12.txt, April 2000. 492 [KRB1] Kohl, J., Neuman, c., "The Kerberos Network Authentication 493 Service (V5)", RFC 1510, September 1993. 495 [COPS1] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 496 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 497 RFC 2748, January 2000. 499 [COPS2] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 500 Sastry, A., "COPS usage for RSVP", RFC 2749, January 2000. 502 [RSVP1] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, 503 January 2000. 505 [RSVP2] Baker, F., Lindell, B., Talwar, M., "RSVP Cryptographic 506 Authentication", RFC 2747, January 2000. 508 Authors Information 510 Dana Blair - dblair@cisco.com 511 Alex Tweedly - agt@cisco.com 512 Michael Thomas - thomasm@cisco.com 513 Jonathon Trostle - jtrostle@cisco.com 514 Michael Ramalho - mramalho@cisco.com 516 Appendix A: Make Before Break Handoff Sequence using RSVP, Kerberos, 517 and COPS. 519 This is Handoff Sequence is a work in progress. No reader should assume 520 that this is complete or covers all required handoff scenarios. 522 Authorizing PDP (aPDP) is a policy decision point, which is trusted 523 by the hPDP. 525 Authorizing KDC provides credentials and authorizes use of the Home KDC 527 Access Service Request is a message which initiates handoff. 529 INITIALIZATION SEQUENCE 531 The MN is hard-configured with Home Address and prefix length, and 532 either shared secret with the Home Agent, Authorizing KDC, or 533 certificate. 535 1. Obtain sufficient access over AL1 to reach Authorizing KDC (AKDC). 537 The AKDC may be separate from the Home Network. 539 2. Obtain ticket for Authorizing Policy Decision Point (APDP) from 540 AKDC. 542 One of the requirements of any successful scheme is the need for 543 authentication and authorization for the large number of mobile 544 hosts. This requires a scalable authentication mechanism. The 545 prime candidates are Kerberos V5 [RFC 1510] and public key based 546 mechanisms. 548 The desire to achieve fast handoff, assuming relatively limited 549 computing power on the mobile hosts, argue against any 550 scheme involving public key computations in the handoff phase. 551 Furthermore, the revocation checking that is required for most 552 existing public key based mechanisms would cause additional 553 delays. Therefore the scheme discussed proposes Kerberos for 554 authentication. Kerberos still allows for some of the main 555 benefits of a public key based approach since Kerberos includes 556 extensions for public key authentication. At the same time, the 557 speed of Kerberos secret key authentication is leveraged during 558 the handoff. 560 3. Obtain sufficient access over AL1 to contact Home KDC (HKDC). 562 4. Obtain ticket from HKDC for HA. 564 5. Using Home Agent Discovery defined in [MIPv6], find the address 565 the HA which the MN will use. 567 HANDOFF SEQUENCE 569 6. Access Service Request (ASR) 571 The Access Service request is sent from MN to AR1. 572 The ASR contains the following: 574 - description of the qos signaling mechanism in use 575 - some description of the type/level of service being requested 576 (e.g. RSVP flowspec) 577 - flag whether tunneling is desired. A MN-AR1 key may be needed 578 if tunneling is desired. 579 - address and ticket for PDP 580 - address and BU for the HA. 582 If the MN has an application which uses RSVP, then RSVP [RSVP1] is 583 proposed as the ASR for a variety of reasons. 584 A layer three admission control mechanism is needed to provide 585 both a means to access the network as well as a means of signaling 586 that a handoff operation is desired. If enhanced quality of 587 service is required for some flows, as may be the case with 588 real time applications, a common admission control scheme for 589 both basic network access and admission of quality of service 590 flows is desirable. Modeling best effort traffic as a subset 591 of all qualities of service leads to the possibility of using 592 RSVP as the signaling protocol. 594 RSVP also has some other advantageous properties. RSVP already 595 has the means of carrying credentials in the form of policy 596 objects [RSVP2] which can be sent to a remote policy decision 597 point. RSVP already has the concept of soft state. Soft state in 598 the context of mobility is quite important as there needs to be 599 some means of clearing stale state in interior network elements 600 without explicit signaling. 602 RSVP's major advantage, however, comes when it is used with 603 enhanced quality of service flows. Since it is likely that 604 real time traffic in some important situations will require 605 explicit admission control to deal with scarce bandwidth, a 606 fast, smooth handoff cannot be considered complete until the 607 quality of service on the new access router and beyond is 608 installed. While RSVP messages could be sent in addition to an 609 ASR, a single message which requests the flow at the attachment 610 point along with the necessary credentials would be more 611 economical. The message could also carry the request for any 612 forward tunneling desired for a smooth handoff. 614 Additions to RSVP would include a handoff object and changes 615 to support Best Effort, non-flow based admission control. 617 6a. Authorization 619 6a-1. AR1 determines whether it can make the authorization decision on 620 its own. If AR1 cannot authorize on its own, continue with 6a-2. 622 6a-2. AR1 takes the level of service request, and hPDP info, and 623 forwards those to its own PDP, the visited PDP1 (vPDP1). The 624 vPDP1 may then decide it can authorize (or deny) service. 625 Otherwise, continue with 6a-3. 627 COPS [COPS1] is proposed as the admission control policy 628 protocol. COPS and RSVP are well integrated via RFC 2749. As for 629 RSVP, a single admission control mechanism for both best effort 630 and enhanced quality of service is desirable. COPS has been 632 specifically designed for enhanced quality of service admission 633 control and could be easily extended, if needed, to support 634 admission of best effort traffic. As with RSVP, COPS has the 635 desirable property of allowing for policy objects which can be 636 used for authentication of a MN. Also, COPS supports cascaded 637 policy decision points to allow a visited PDP to authorize with 638 a home PDP. 640 6a-3. vPDP1 forwards the credential to hPDP for a decision, and/or 641 settlement/billing decision between PDPs or via 3rd party 642 broker, or other means. 644 The result whether local to AR1 or from vPDP1 is a boolean decision 645 to allow access of MN through AR1. 647 6b. If tunneling is desired, get new key for MN/AR1 649 If necessary, vPDP1 sends to hPDP the ticket and address for MN, 650 type/level of service, etc. 6a may have already done this through 651 interaction with the hPDP. However if not, this step 652 is required. 654 hPDP replies to vPDP1 with a new credential for use between MN 655 and AR1. 657 6a and 6b may occur in parallel. However, 6c and 6d must wait for a 658 successful result from 6a to reach AR1. 660 6c. QoS signaling 662 If using RSVP - send the RSVP packet towards HA. 663 If no QoS signaling, then AR1 simply imposes DiffServ policing if 664 needed. 666 6d. Send Binding Update (BU) [MIPv6] to HA. 668 The BU may be attached as a routing header on the ASR or imbedded in 669 an object within the ASR. If the BU is embedded in an object within 670 the ASR, the BU must be in the form of a complete IP packet including 671 IPSEC encapsulation. 673 If the BU is in an embedded object, AR1 extracts the BU and sends it 674 on to HA. 676 End of 6: The MN may now communicate with the HA including proper 677 level of QoS assuming RSVP was successful. 679 As long as the neither MN nor the AN requires a handoff, no more steps 680 are required. 682 7. MN attempts to handoff to AR2. 684 The Handoff Trigger may occur because MN heard a beacon from AR2 685 and decided AL2 was a better connection, or because the network 686 containing AR1 determined that the MN should moved to AL1. There are 687 many other possibilities as well. 689 7a. MN acquires suitable local address by either stateless or stateful 690 address configuration. This may be either SCoA or NCoA. 692 8. MN sends an ASR to AR2. 694 The ASR is sent from MN to AR2, contains: 695 - QoS : description of the qos signaling mechanism in use 696 - QoS : description of the type/level of service being requested 697 (e.g. RSVP flowspec) 698 - Security : flag whether tunneling back to AR1 is desired (i.e. is 699 a MN-AR2 key needed) 700 - Security : one or more tuples of 701 < vPDP, ticket vPDP, address/name of hPDP, ticket hPDP > 702 - Mobility : [if New-CoA] address and embedded (authenticated) BU 703 for the HA. 704 - Mobility : [optional] address and BU for the previous AR 706 Note that this allows multiple tuples of PDP address + ticket. These 707 will be considered in turn, with AR2 deciding whether or not to trust 708 the vPDPn-1. Thus, if MN has recently been accessing the network via 709 AR1, and has successfully established a key for use with AR1, then MN 710 may (will?, must?) make the first tuple be , 711 and the second tuple be <*, hPDP, ticket from 1a>. 713 Thus in the authorization step AR2 will consider each of these tuples 714 for a possible authorization decision in turn. 716 Otherwise, this should be just same as the sub-steps of 2 above, with 717 the addition of (optionally) AR2 sending a BU to AR1. Also, if using 718 Same-Coa, AR2 will kick off the routing update / convergence. 720 Note - if RSVP is the protocol to be used here, it most likely is 721 addressed to HA, but will be intercepted by AR2, and the following steps 722 taken before the packet is allowed to continue on its way to HA. But 723 if it is some new "Access Service Request", then it can simply be 724 destined to AR2. 726 Therefore : 728 8a. Authorization 730 8a-1. AR2 determines whether it can make the authorization decision 731 on its own. If AR2 does not authorize on its own, continue with 732 8a-2. 734 8a-2. AR2 tries first PDP address + PDP ticket tuple where the PDP 735 address is the address of AR1. If AR2 trusts AR1, then AR2 736 will treat AR1 as a vPDP by asking AR1 to authorize the Access 737 Service Request. 739 AR1 may then decide it can authorize (or deny) service, based on 740 having previously done so. Otherwise, continue with .. 742 8a-3. AR2 tries second PDP address + PDP ticket tuple where PDP 743 address may be *. 745 The vPDP specified is null (blank), so AR2 uses his own, normal vPDP. 747 AR2 forwards hPDP info to vPDP2, and vPDP2 forwards the credential to 748 hPDP for a decision, and/or settlement/billing decision between PDPs or 749 via 3rd part broker, or other means. 751 8b. If tunneling is desired, get new key for MN/AR2 753 vPDP sends to hPDP the ticket and address for MN, type/level of 754 service, etc. In general, step 8a above would include doing this, but 755 in the case where it did not, they need to be send on to hPDP anyway. 757 hPDP replies to vPDP with a new credential for use between MN and AR2. 758 This used the pre-existing trust between vPDP2-hPDP and between 759 MN-hPDP to generate this new credential. vPDP2 sends this on to AR2 760 and to MN. 762 8a and 8b may occur in parallel. 8c and 8d must wait for a successful 763 result from 8a to reach AR2. 765 8c. QoS Signaling 767 If using RSVP - send the RSVP packet towards HA. 768 If no QoS signaling, then AR2 simply imposes DiffServ policing, if 769 required. 771 8d. If the optional BU for AR1 is included, AR2 sends the BU, which 772 was IPSEC encapsulated using the key derived in 6b, to AR1. MN is 773 responsible for the construction of this BU, and therefore MN 774 determines whether SCoA or NCoA is used. 776 For SCoA, the BU will cause AR1 to tunnel to AR2 where AR2 will 777 forward the packet to MN. 779 For NCoA, the BU will cause AR1 to tunnel directly to CoA2 781 Note that AR2 or AR1 omit or reject this step if either AR2 or AR1 782 determines that this step violates network policy. 784 8e. MN sends BU to HA. 786 AR2 extracts the embedded BU and sends this on to HA. 788 8f. If SCoA, then AR2 (and also AR1 based on step 4d) will initiate 789 routing convergence to reflect the new attachment point for the 790 CoA. 792 All subsequent handoffs (e.g. ALn+1 to ALn+2) occur in like manner 793 beginning with step 7. 795 Appendix B: Handoff Sequence using Kerberos and Radius/Diameter 797 This Handoff Sequence is a work in progress. No reader should assume 798 that this is complete or covers all required handoff scenarios. 800 1. INITIALIZATION SEQUENCE 802 Initially, the MN obtains a ticket granting ticket (TGT) using either a 803 password or X.509 certificate in an AS exchange with a KDC in its home 804 realm using IAKERB [IAKERB]. Subsequently, the MN mutually authenticates 805 with the AR in order to obtain network access using IAKERB. 806 An IPSEC SA is also established with the user's home agent. The IPSEC 807 SA key management protocol could be IKE or any of the IPSEC key management 808 protocols. 810 2. HANDOFF SEQUENCE 812 The proposal in this appendix specifies the use of Kerberos [3] for 813 providing authentication, key establishment, and authorization for 814 Mobile IPv6 [2,5] fast handoffs. 816 ARn detects the network prefix of the ARn+1. ARn sends a Neighbor 817 Discovery Redirect Message (ND Redirect) over ALn with a list of network prefixes for ARn+1. Upon receipt of this message, the MN configures a 818 new CoA. 820 We define new suboptions for the ND Redirect Message to include 821 a negotiation flag, and the NR principal name and realm. The negotiation 822 flag indicates whether to pass security state from the PR, which we call 823 local authentication, or local authentication followed by global 824 authentication (which may include an exchange with a Kerberos KDC 825 server), or global authentication. The MN then sends a Previous Router 826 Notification Message to 827 the ARn which uses the IPSEC AH header and is keyed using the existing 828 security association between the MN and the PR; this message informs the 829 PR of the MN's new CoA. We define a new suboption for this message that 830 includes a negotiation flag (the MN will choose a flag that is the same 831 or more strict than the negotiation flag value sent to it from the PR in 832 the Notification Message), and a suboption for including a Kerberos 833 message. 835 The value of the negotiation flag that was sent from the MN to the ARn 836 will help determine what steps occur next. If local authentication was 837 selected, then the ARn will pass secret cryptographic key information as 838 well as other state information to ARn+1, using an encrypted channel 839 between ARn and the ARn+1. This data will be sent 841 in an unsolicited message (message TBD) from ARn to ARn+1. The MN 842 established ALn+1 to ARn+1. 843 The MN and ARn+1 will exchange ND solicitation and advertisement 844 messages over ALn+1 prior to exchange of application data. The MN and 845 the ARn will use the shared secret keys to establish IPSEC SA's between 846 themselves after the initial handoff operations. 848 If the value of the negotiation flag that was sent from the MN to ARn+1 849 was local authentication followed by global authentication, then the 850 same steps as in the local case occur, except subsequently (after 851 application data is flowing), Kerberos mutual authentication with 852 additional key establishment occurs. We have defined new suboptions for 853 the Neighbor Discovery Solicitation 854 and Advertisement [8] for inclusion of Kerberos messages to achieve 855 global authentication. Two ND solicitation and advertisement exchanges 856 will be needed to encapsulate the three Kerberos messages in this case. 858 If the negotiation flag value that was sent by the MN is global 859 authentication, then the Previous Router Notification message will 860 contain a ticket granting ticket (TGT) as described in the minimal 861 messages subprotocol from IAKERB [4]. A typical exchange in this case 862 would be: 864 ND Redirect (with prefixes) 865 ARn -------------------------------------------> MN 866 suboption with principal name, realm 867 suboption with global authentication flag 869 Previous Router Notification (with new CoA) 870 ARn <------------------------------------------- MN 871 suboption with global authentication flag 872 suboption with TGT 874 Layer 2 Establishment 875 MN -------------------------------------------> ARn+1 877 ND Solicit 878 MN <------------------------------------------- ARn+1 879 suboption with encapsulated Kerberos AP_REQ 881 ND Advertisement 882 MN -------------------------------------------> ARn+1 883 suboption with encapsulated Kerberos AP_REP 885 application data flow 886 MN <------------------------------------------> ARn+1 888 Figure 1: Global Authentication for Fast Handoffs 890 Before forwarding the AP_REQ to the MN, ARn+1 will send a message to its 891 local AAA server with authorization data from the Kerberos service 892 ticket extension. The reply from the local AAA server will contain 893 the updated and massaged authorization data. ARn+1 will cache the 894 authorization data and use it once the MN has authenticated to ARn+1. 895 The protocol between ARn+1 and the local AAA server could be either 896 Radius or Diameter. Upon receipt of the AP_REQ from the ARn+1, the MN 897 will perform the normal Kerberos validation steps. In addition, the 898 service principal identifier component of the client principal name 899 in the ticket MUST be equal to mobileip. If not, the MN will fail 900 the request by sending a KRB_ERROR message to the NR with the error 901 code KRB_ERR_GENERIC. 903 Note that the AP_REQ will have the mutual authentication flag set. Thus, 904 the MN is required to authenticate to the ARn+1 which it does by sending 905 the AP_REP message to the ARn+1. 907 Subsequently, the MN sends any BCU's to its home agent (HA) and 908 correspondent nodes (CN's). The MN may also send a router solicitation 909 message to the ARn+1 910 with a new suboption asking for the reverse ticket (IAKERB [4]) and list 911 of adjacent realms to be sent back in the router advertisement. The 912 reverse ticket is constructed by the ARn+1 and is targeted at the ARn+1 913 from the MN. It allows fast subsequent authentications from the MN to 914 the ARn+1. The list of adjacent realms can be used by the MN to 915 precache crossrealm TGT's targeted at adjacent realms (as a background 916 task). This performance optimization allows subsequent global 917 authentications for adjacent realms to skip exchanges 918 with the remote user's KDC. Instead, a local KDC will be used. 920 Kerberos authentication uses the subprotocols from IAKERB [4]. In 921 particular, the minimal messages subprotocol (which uses user-user authentication) is used 922 for the global authentication exchange (illustrated in Figure 1). 923 Precaching can use either standard Kerberos or standard IAKERB. Initial 924 logon (which occurs before the first roam) should use standard IAKERB 925 exchanges with an 926 IAKERB proxy. As a result of initial logon, the MN user will obtain an 927 initial TGT, as well as a service ticket targeted at the initial access 928 router which acts as an IAKERB proxy. Initial logon can use public key certificates as described in pkinit [9]. 930 For a break before make case, the MN may have to establish layer 2 with 931 the ARn+1 without the benefit of the ND Redirect and Previous Router 932 Notification messages. In this case, the security data from the ND 933 Redirect message (in the above figure) will be placed in the router 934 advertisement message sent from the ARn+1 to the MN in response to the 935 MN's router solicitation 936 message. The MN then sends a ND solicitation with the authentication 937 flag and optionally, the TGT, if global authentication has been 938 selected. In the global authentication case, the ARn+1 responds with a ND advertisement that includes the AP_REQ message. In this case the flow 939 becomes: 941 Layer 2 Establishment 942 MN -------------------------------------------> ARn+1 944 Router Solicitation 945 MN -------------------------------------------> ARn+1 946 negotiation flag suboption, TGT suboption 948 Router Advertisement 949 MN <------------------------------------------- ARn+1 950 negotiation flag suboption, and optionally, 951 suboption with encapsulated Kerberos AP_REQ 953 ND Solicitation 954 MN ------------------------------------------->ARn+1 955 suboption with Kerberos AP_REP message (if 956 global authentication has been negotiated) 958 ND Advertisement 959 MN <------------------------------------------ ARn+1 961 application data flow 962 MN <------------------------------------------> ARn+1 964 Figure 2: Global Authentication: Break Before Make 966 3. Neighbor Discovery Solicitation, Advertisement, Redirect Suboptions, 967 and Previous Router Notification Suboption. 969 The following suboption contains the principal name and realm: 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | Length | Kerberos Principal Name ... / 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Kerberos Principal Realm ... / 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 Fields: 981 Type Message type. To be assigned. 983 Length 8-bit unsigned integer. The length in bytes 984 of the option (including the type and length 985 fields). 987 Principal Name Kerberos Principal Name 989 Principal Realm Kerberos Principal Realm 991 The following suboption contains the negotiation flag: 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Type | Length |L|B|G| Reserved | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Fields: 1001 Type Message type. To be assigned. 1003 Length 8-bit unsigned integer. The length in bytes 1004 of the option (including the type and length 1005 fields). 1007 Flags L - local authentication 1008 B - local authentication followed by global 1009 authentication 1010 G - global authentication 1012 The requestor sets one of the above flags and the 1013 responder sends the same suboption with either the 1014 same flag or a more strict flag. The flags increase 1015 in strictness from L to B to G. We note that an 1016 attacker can cause at most a denial of service attack 1017 by manipulating these flags in transit. 1019 The following suboption contains a Kerberos protocol message: 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Type | Length | Kerberos Message ... / 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1026 | / 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 Fields: 1031 Type Message type. To be assigned. 1033 Length 8-bit unsigned integer. The length in bytes 1034 of the option (including the type and length 1035 fields). 1037 Kerberos Kerberos protocol message as defined in [3] 1038 Message 1040 Any of the above suboptions can be included in any of the neighbor 1041 discovery solicitation, advertisement, or redirect messages, as well as 1042 the previous router notification message. The principal name/realm 1043 suboption and the negotiation flag suboption can also occur in a router advertisement message. 1045 4. Router Solicitation and Advertisement Options 1047 The following router solicitation message suboption is used to request 1049 that the access router return a list of adjacent realms in its router 1050 advertisement. The access router may also return a Kerberos message 1051 suboption with a reverse ticket. 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Type | Length | Reserved | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 Fields: 1061 Type Message type. To be assigned. 1063 Length 8-bit unsigned integer. The length in bytes 1064 of the option (including the type and length 1065 fields). 1067 The following router advertisement message suboption is used to return 1068 a list of adjacent realms in the router advertisement: 1070 0 1 2 3 1071 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 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Type | Length | Realm 1... / 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 / Realm 2... / 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 / ... Realm n... / 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 Fields: 1082 Type Message type. To be assigned. 1084 Length 8-bit unsigned integer. The length in bytes 1085 of the option (including the type and length 1086 fields). 1088 Realm i The realm name of the ith geographically 1089 adjacent Kerberos realm. 1091 The following router solicitation message suboption is used to request 1092 that the access router return the principal name/realm suboption and 1093 the negotiation flag suboption (as described above). It is used in 1094 break before make handoff cases. 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type | Length | Reserved | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Fields: 1104 Type Message type. To be assigned. 1106 Length 8-bit unsigned integer. The length in bytes 1107 of the option (including the type and length 1108 fields). 1110 5. Authorization 1112 We propose the following approach to authorization for the global case 1113 (in the local case, authorization state is passed from the previous 1114 router to the new router). 1116 The NR's KDC will map authorization data in the user's Kerberos ticket to 1117 local authorization attributes which will be placed in a ticket extension 1118 of the issued ticket. 1120 Here we propose a new Kerberos authorization data type: 1122 AD-MOBILEIP-ATTRIBUTES TBD 1124 The data is the ASN.1 OCTET STRING encoding of the following: 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Length | Alg ID | Signature / 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 / TLV's / 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 Fields: 1136 Length 8-bit unsigned integer. The length in bytes 1137 of the option (including the type and length 1138 fields). 1140 AlgID Algorithm Identifier 1142 Signature Digital signature over TLV's. 1144 TLV's Authorization attributes in TLV form 1146 We also propose a new ticket extension type: 1148 TE-MOBILEIP-ATTRIBUTES 9 1150 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1151 Levels", BCP 14, RFC 2119, March 1997. 1153 [2] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) 1154 Specification", RFC 2460, December 1998. 1156 [3] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 1157 (V5)", RFC 1510, September 1993. 1159 [4] Swift, M., Trostle, J., "Initial Authentication and Pass Through 1160 Authentication Using Kerberos V5 and the GSS-API (IAKERB)", 1161 Internet draft (work in progress), draft-ietf-cat-iakerb-04.txt, 1162 July 2000. 1164 [5] Johnson, D. and Perkins, C., "Mobility Support in IPv6", Internet 1165 draft (work in progress), draft-ietf-mobileip-ipv6-12.txt, April 1166 2000. 1168 [8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1169 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 1170 Internet Engineering Task Force, December 1998. 1172 [9] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 1173 J., Trostle, J., "Public Key Cryptography for Initial 1174 Authentication in Kerberos", Internet draft (work in progress), 1175 draft-ietf-cat-kerberos-pk-init-11.txt, April 2000. 1177 Appendix C 1179 This appendix shows a fully integrated RSVP/COPS/Kerberos 1180 solution. It is very similar to Appendix A, and will be 1181 merged at a later date. 1183 Abbreviations: 1185 PO: RSVP/COPS policy object 1186 TR: Ticket Relay Object: an object which relays a shared 1187 secret back to the initiator and relay initiator. This 1188 subject deserves a great deal more discussion, and will 1189 be added in future versions of this draft. 1190 HO: Handoff Object: an object which requests a handoff to 1191 occur between AR1 and AR2 with optional forward tunneling 1192 from AR1 to AR2. If handoff objects desire forward tunneling, 1193 they must contain an embedded handoff object 1194 EBU: Embedded Binding Update: an embedded binding update 1195 is a normal IPv6 mobility binding update message which 1196 is encapsulated in a wrapper which proves MN's identity 1197 as well as proving freshness, etc. EBU's may be embedded 1198 in RSVP and COPS messages. 1199 tick[XXX]: a Kerberos ticket for which the server half of 1200 the ticket is encrypted in XXX's key. MN is always assumed 1201 to be in the client half of the ticket. 1203 Initial Access 1205 When the mobile node initially desires access, it must go through 1206 a full initial access flow. This flow assumes that MN does not 1207 have any valid Kerberos tickets cached. If it does, it may omit 1208 the interactions with the appropriate KDC's. 1210 The goal of this flow is to just obtain best effort access from 1211 AR1. As such, the RSVP request is directed at AR1. 1213 MN AR1 AR2 vPDP aPDP aKDC hKDC hA 1214 ======================================================================== 1216 <=========> 1217 L2 estab 1219 -----------------------------------------------------> 1220 AS-REQ to get service ticket for aPDP 1222 <----------------------------------------------------- 1223 AS-REP w/ tick[aPDP] 1225 ---------------------------------------------------------------> 1226 AS-REQ to get service ticket for hA 1228 <--------------------------------------------------------------- 1229 AS-REP w/ tick[hA] 1231 ---------> 1232 RSVP PATH w/ PO(tick[aPDP]) 1234 --------------------> 1235 COPS REQ w/ PO(tick[aPDP]) 1237 ----------------------> 1238 COPS REQ w/ PO(tick[aPDP]) 1240 <--------------------- 1241 COPS DEC w/ TR(tick[vPDP]) 1243 <-------------------- 1244 COPS DEC w/ TR(tick[AR1]) 1246 <-------- 1247 RSVP RESV w/ TR(tick[MN]) 1249 ~ 1250 MN is now admitted at AR1 and shares a secret with AR1 from the TR 1251 ~ 1253 MN AR1 AR2 vPDP aPDP aKDC hKDC hA 1254 ======================================================================== 1256 ---------------------------------------------------------------------> 1257 KINK CREATE SA w/ tick[hA] 1259 <--------------------------------------------------------------------- 1260 KINK REPLY 1262 ---------------------------------------------------------------------> 1263 BU 1265 <--------------------------------------------------------------------- 1266 BU ACK 1268 ~ 1269 The home agent's binding cache is now updated with forward tunneling 1270 established. 1272 Note: if the MN is already in possession of valid tickets to the aPDP 1273 or hA, the AS-REQ and AS-REP's in the flow can be omitted. 1274 ~ 1276 Intra Trust Domain Fast/Smooth Handoff 1278 It is assumed that AR1 and AR2 have a pre-existing security 1279 association. 1280 If they do not, a security association between the two would need to be 1281 established using normal IPsec keying mechanisms. 1283 This flow assumes that the MN is capable of transmitting and receiving 1284 on AR2. It may or may not still have connectivity to AR1. It is also 1285 assumed that AR1 and AR2 are with in the same trust domain where AR1 1286 can act as a PDP for AR2. 1288 MN AR1 AR2 vPDP aPDP aKDC hKDC hA 1289 ======================================================================== 1291 <=========> 1292 L2 estab 1294 -----------------------> 1295 RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU (AR1)) 1297 <------------ 1298 COPS REQ w/ PO(tick[AR1]), HO(AR1, AR2, EBU(AR1)) 1300 ------------> 1301 COPS DEC w/ TR(tick [AR2]), EBU(ACK) 1303 <----------------------- 1304 RSVP RESV w/ TR(tick [MN]) 1306 ~ 1307 At this point, AR1 will forward any packets destined for MN's old 1308 CoA to AR2 and as such any packets in flight will still reach MN. 1310 The following two steps only occur if the MN's CoA changed 1311 ~ 1312 ---------------------------------------------------------------------> 1313 BU 1314 <--------------------------------------------------------------------- 1315 BU ACK 1317 Intra Trust Domain Fast/Smooth Handoff to a cNode with QoS 1319 This flow describes a fast/smooth handoff with a cNode with an 1320 established QoS flow. It is assumed that cNode and MN already 1321 have established keys between them. How they are initially 1322 established is outside of the scope of this document. 1324 It is assumed that AR1 and AR2 have a pre-existing security 1325 association. 1326 If they do not, a security association between the two would need to be 1327 established using normal IPsec keying mechanisms. 1329 This flow assumes that the MN is capable of transmitting and receiving 1330 on AR2. It may or may not still have connectivity to AR1. It is also 1331 assumed that AR1 and AR2 are with in the same trust domain where AR1 1332 can act as a PDP for AR2. 1334 MN AR1 AR2 vPDP aPDP aKDC hKDC cN 1335 ======================================================================== 1337 <=========> 1338 L2 estab 1340 -----------------------> 1341 RSVP PATH PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU (AR1)), 1342 EBU(CN) 1344 <------------ 1345 COPS REQ w/ PO(tick[AR1]), HO(AR1, AR2, EBU(AR1)) 1347 ------------> 1348 COPS DEC w/ TR(tick [AR2]), EBU(ACK) 1350 ~ 1351 At this point, AR1 will forward any packets destined for MN's old 1352 CoA to AR2 and as such any packets in flight will still reach MN. 1353 ~ 1355 -----------------------------------------------> 1356 RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), EBU(CN) 1358 ~ 1359 At this point, the cNode would receive the new binding and 1360 know that it would need to adjust any reservations toward 1361 MN as well. These RSVP messages are not shown here. 1362 ~ 1364 <---------------------------------------------- 1365 RSVP RESV from cNode EBU(ACK) 1367 <----------------------- 1368 RSVP RESV w/ TR(tick [MN]), EBU(ACK) 1370 Inter Trust Domain Handoff 1372 In the case where AR1 and AR2 do not trust another domain's 1373 cached policy decisions, it will necessitate another authoritative 1374 policy decision. Note that the MN is at liberty to send as many 1375 policy objects as it feels may be needed to expedite the decision. 1376 Also: if the MN has local credentials it may send them as well 1377 which would also result in a fast though not necessarily smooth 1378 handoff. 1380 Note that this flow is nearly identical to the initial access 1381 flow. The only difference is that the MN sends a PO and HO for AR1. 1382 Because AR2 and AR1 are not within the same trust domain, AR2 1383 ignores that policy object since it is not a trusted PDP. 1385 MN AR1 AR2 vPDP aPDP aKDC hKDC hA 1386 ======================================================================== 1388 <=========> 1389 L2 estab 1391 -----------------------> 1392 RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU) 1394 ---------> 1395 COPS REQ w/ PO(tick[aPDP]) 1397 --------------> 1398 COPS REQ w/ PO(tick[aPDP]) 1400 <-------------- 1401 COPS DEC w/ TR(tick[vPDP]) 1403 <--------- 1404 COPS DEC w/ TR(tick[AR2]) 1406 <----------------------- 1407 RSVP RESV w/ TR(tick[MN]) 1409 ---------------------------------------------------------------------> 1410 BU 1412 <--------------------------------------------------------------------- 1413 BU ACK 1415 ~ 1416 At this point, AR1 will forward any packets destined for MN's old 1417 CoA to AR2 and as such any packets in flight will still reach MN. 1419 The following two steps only occur if the MN's CoA changed 1420 ~ 1421 ---------------------------------------------------------------------> 1422 BU 1423 <--------------------------------------------------------------------- 1424 BU ACK