Internet Engineering Task Force Dana Blair INTERNET-DRAFT Alex Tweedly Michael Thomas Jonathan Trostle Michael Ramalho Cisco Systems File: draft-blair-rt-mobileipv6-seamoby-00.txt November 2000 Expires: June 2000 Realtime Mobile IPv6 Framework Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, its and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft develops terminology, an architectural framework, a list of objectives, and a proposed solution for Realtime Mobile IPv6. Realtime Mobile IPv6 seeks to deliver realtime application data to IPv6 capable Mobile Nodes while minimizing the impact of handoff on realtime applications. 1. Introduction The convergence of wireless networking and IP networking requires solutions for transporting realtime application data to mobile devices. Current IP mobility solutions tend to focus primarily on best effort data transport to and from a mobile device. To support realtime applications, security, admission control, and QoS need to be examined concurrently with mobility to facilitate smooth transitions from one access link to another while minimizing the impact on realtime applications. This draft assumes IPv6 because the proliferation of mobile devices will require the use of IPv6 addresses to support the number of attached devices. Without the larger IPv6 address space, the end-to-end transparent Internet model will be broken up and made much more complex by the use of private IP addressing and result in the inclusion of Network Address Translators, Application Layer Gateways, and Protocol Translators. Also, use of private IP addressing is not practical when the end device functions as an application server such as Voice over IP. 1.1 Problem Description Mobility solutions require that packets be redirected to the current location of a mobile device. The Mobile IPv6 Binding Update [MIPv6] is sufficient to accomplish this for best effort traffic. However, realtime applications require coordination of admission control, security associations, and Quality of Service guarantees to minimize packet loss and jitter to satisfy the expectations of realtime applications. Considered independently, admission control, Security Associations, Quality of Service signaling, and Binding Updates could significantly delay the transition from one access link to another, thus degrading the performance of realtime applications. This draft develops terminology, an architectural framework, a list of objectives, and a proposed solution for Realtime Mobile IPv6. 2. Terminology Subscripted Elements In this draft we will have occasion to reference the "present" element of a given type and the "next" element of that same type with indices "n" and "n+1", respectively. For example, we will reference the first access link (AL) as AL1, the next as AL2, and so on. We will use this indexing methodology as shorthand for any element (e.g., ALn+1, ARn, vPDPn. We do not intend that the actual "present" index "n" to be identical across element type (e.g., the present ALn could be AL9, while the present vPDPn could be vPDP2). The sample network diagram of Figure 1 below is used to illustrate the terminology used in this draft. This figure will be used to describe the operation of the proposed handoff mechanisms by means of the specific network topology example shown in this figure. +--------------------------+ | HN | | | | +----+ +----+ +-----+ | +-----+ +-----+ | |HA | |HKDC| | hPDP| | |cNode| |AKDC | | | | | | | | | | | | | | +----+ +----+ +-----+ | +-----+ +-----+ +--------------------------+ +-----+ |vPDP | +-----+ +------------------------------+ +-----------------+ | TD1 | | TD2 | | +----+ +----+ | | +----+ | | | AR1| | AR2| | | | AR3| | | | | | | | | | | | | +----+ +----+ | | +----+ | | | | | | | | +------|-----------------|-----+ +--------|--------+ \ | / \ | AL2 / AL3 \ AL1 | / \ +----+ / \------| MN |---------/ +----+ Figure 1: Sample Network Diagram showing AR1 and AR2 in a particular trust domain and AR3 in a different trust domain. Common Terms Mobile Node (MN) Device which supports IPv6 mobility according to [MIPv6]. A MN may be a host or a router. Home Agent (HA) Device that supports the Home Agent function described in [MIPv6]. Correspondent Node A peer node with which a mobile node is communicating. Defined in [MIPv6]. Home Address (hAddr) An IP address assigned to a MN as defined in [MIPv6]. Care-of-Address (CoA) An IP address assigned to a MN as defined in [MIPv6] New CoA (NCoA) means that CoA on ALn+1 is different than CoA on ALn. Same CoA (SCoA) means that CoA on ALn+1 is the same as CoA on ALn. Access Router (AR) An IP router between an Access Network and one or more access links. Access Network (AN) An IP network which includes one or more Access Routers. Policy Decision Point (PDP) A network service that is responsible for handling policy decisions (e.g. access authorization, qos authorization, etc.) and also billing and settlement issues. Defined in [COPS1] Home PDP (hPDP) is the policy decision point used by the Home Network. Visited (vPDP) is the policy decision point used by the visited network. Key Distribution Center (KDC) A network service that supplies tickets and temporary session keys. Defined in [KRB1]. The Home KDC (HKDC) provides security credentials for the MN to register with the Home Agent. Trust Domain (TD) A set of access routers within a particular network that have direct trust relationships between all ARs in that set. In the figure above TD1 is comprised by the set {AR1, AR2} and TD2 is the set {AR3}.. Access Link (AL) A link layer connection between MN and AR. Multiple Access Routers may share the same access link. An AL consists one downlink or one uplink or both. Downlink communication flows from AR to MN. Uplink communication flows from MN to AR. Handoff Trigger A Handoff Trigger initiates a Handoff Decision. The MN or an element within the AN may create a Handoff Trigger. The result of the handoff decision may create a Handoff Command. Example sources of a Handoff Trigger are MN detects a stronger signal for a different AL, or AN detects that a MN is moving and a new AL would provider better transmission. Many other sources of Handoff Trigger exists. This draft does not discuss events that result in a Handoff Trigger. Handoff Decision A Handoff Decision is an algorithm which decides whether or not to issue a Handoff Command based on one or more Handoff Triggers. This draft does not propose algorithms for the Handoff Decision. Handoff Command The Handoff Command initiates a Handoff Sequence. The MN or an element within the AN may issue a Handoff Command. The Handoff Trigger and Handoff Command may be created by different network components or the same network component. Handoff Sequence A Handoff Sequence is a series of steps executed by various network components to attempt a handoff. A Handoff Sequence may be successful in establishing ALn+1. However, establishment of ALn+1 does not guarantee communication with a cNode. Since IP is connectionless, a Handoff Sequence cannot rely on IP or link layer indications to verify that the MN can communicate with a cNode over ALn+1. The solutions section of this draft contains an abstract Handoff Sequence proposal. Detailed Handoff Sequences are in the appendix. Initialization Sequence An Initialization Sequence is a series of steps executed by various network components to establish communication over an AL for the first time. Wake-up Sequence A Wake-up Sequence is a series of steps executed by various network components to establish an AL while a MN is in sleep mode. Sleep mode means the device is in a lower power state with no uplink, and a limited downlink capability. Handoff Delay Handoff delay is the time between when the handoff command is issued and when ALn+1 is established. Handoff Types Make-Before-Break Downlink Handoff (MBBDH) ALn+1 downlink is established before removing ALn downlink. Duration of simultaneous ALn and ALn+1 downlink connections is not bounded. Make-Before-Break Uplink Handoff (MBBUH) ALn+1 uplink is established before removing ALn uplink. Duration of simultaneous ALn and ALn+1 uplink connections is not bounded. Break-Before-Make Downlink Handoff (BBMDH) The MN stops receiving on ALn before being able to receive on ALn+1. Break-Before-Make uplink Handoff (BBHDH) The MN stops transmitting on ALn before being able to transmit on ALn+1. Handoff Control Handoff Control may be performed by various network elements. Any Handoff Sequence should be analyzed to determine which control methods are used. Some control methods may be preferable depending access network technology or administration preference. Mobile Controlled A MN may create any number of access links without a-prior knowledge of any other access link. The MN generates the Handoff Trigger, performs the Handoff Decision, and issues the Handoff Command. Mobile Assisted The MN generates the Handoff Trigger, the network performs the Handoff Decision and issues a Handoff Command to the MN. Network Assisted The network generates a Handoff Trigger. If the network performs the Handoff Decision, the network issues a Handoff Command to the MN. If the MN performs the Handoff Decision, the MN issues a Handoff Command to itself. Network Controlled. The network generates the Handoff Trigger, performs the Handoff Decision, and issues the Handoff Command. The MN must execute a Handoff Sequence to maintain an AL. 3. Objectives Items to consider when analyzing a Handoff Sequence. 3.1 Handoff Objectives Minimize Handoff Delay Minimize packet drops during Handoff Delay Realtime applications have a relatively low tolerance for packet drops. Packet drops are more likely during BBMDH and BBMUH. Minimize packet latency Minimize misadaptations of adaptive jitter buffers due to handoff. Link Layer Handoff Independence A Realtime Mobile IPv6 Handoff Sequence must not depend on any particular link layer handoff mechanisms but may exploit layer 2 information. Handoff link failure behavior A Realtime Mobile IPv6 Handoff Sequence should consider behavior when ALn+1 cannot be established during the Handoff Sequence. Handoff addressing, either SCoA or NCoA, is an important consideration when analyzing or creating a Handoff Sequence. For example, SCoA does not require MN re-registration but may not be possible between Trusted Domains. Handoff Control is an important policy consideration of some access networks. For example, A Handoff Sequence may not be acceptable for a given access network or network policy if the sequence is not Network Assisted or Network Controlled. 3.2 Security Fast smooth handoffs must take into account access networks which require both authentication and authorization of mobile users in order to gain access to best effort traffic as well as any other services such as enhanced quality of service, etc. User authentication may be done directly on the access network or via proxied authentication through a third party where the access network provider and the third party have a trust relationship. The latter arrangement allows for a settlement model where a mobile node does not need to have a direct arrangement with the visited service provider, but instead is authenticated with the third party, but settled between the third party and the access service provider. The initial authentication and authorization state should be captured by the access service provider router in a way which allows the authorization state to be forwarded to other access routers within the same Trust Domain. This allows access routers the option of not needing to perform authentication or authorization back to the authoritative authorization source. The advantage of caching this authorization state at the edges is that potentially expensive round trips to the authorizing source can be avoided. The MN should consider requiring mutual authentication. Mutual authentication prevents an intruder from pretending to be an AR and gathering credentials from the MN. 3.3 Quality of Service The handoff mechanism should consider the re-establishment of QoS instantiated in ALn when handing off to Aln+1. This should include either intserv or signaled diffserv techniques. 4. Handoff Behavior The following is an abstraction of events that may be required before and during handoff. Not all steps are required for all handoff nor are they necessarily executed in the sequence presented. A Handoff Sequence will define a set of steps and protocols required to attempt a handoff. 4.1 Initialization Events The Initialization Events allow a MN to establish connectivity with one or more cNodes before attempting to handoff. Although Initialization Events are not part of a Handoff Sequence some parts of initialization may be reused during a Handoff Sequence to simplify operation within the MN. 1. Obtain credentials to allow use of the visited network, if necessary. 2. Obtain access to and through a visited network. Use credentials from 1., if needed. 3. Obtain credentials to allow MN to register with the Home Agent. 4. Obtain credentials to be used when establishing Quality of Service for application flows, if necessary. 5. Establish security association with the Home Agent using credentials from 3. 6. Mobile Node registers with the Home Agent as defined in [MIPv6]. 7. Establish zero or more application flows over the first access link, AL1, to one ore more cNodes. QoS credentials from 4. may be used to authorize Quality of Service via a PDP for a specific application flow. 4.2 Handoff Events The Handoff Events allow a MN to attempt to move packet forwarding and receiving from ALn to ALn+1. Some events may not be required, or may not be executed in the order presented when applied to a Handoff Sequence. 1. Obtain credentials, if necessary, to allow use of ALn+1. 2. Obtain access to and through the visited network. If necessary, use credentials from 1. 3. QoS signaling for 0 or more application flows. If necessary, use QoS credentials obtained during initialization. 4. Establish tunneling and/or forwarding from ARn to MN using ALn+1. 5. If New CoA (NCoA), MN re-registers with Home Agent as defined in [MIPv6]. 6. If NCoA and if desired, MN notifies cNodes NCoA. 7. If possible, Remove ALn when it is no longer needed. 4.3 Application of Handoff Objectives. 4.3.1 Minimize Handoff Delay Authorization state transfer may be pulled from ARn to ARn+1 or pushed from ARn to ARn+1. Minimize the number of required transactions before MN may send and receive packet to and from a cNode over ALn+1. Minimize the number of home roundtrip transactions required before MN may send or receive a packet to or from a cNode over ALn+1. Minimize the size of all packets transmitted and received before MN may send or receive a packet to or from a cNode over ALn+1. 4.3.2 Minimize Packet Drops Limit packet drops by forwarding packets from ARn to MN over ALn+1. 4.3.3 Minimize packet latency For NCoA handoff, re-register with HA and cNodes as soon as possible. For SCoA handoff, minimize the delay of forwarding path convergence. 4.3.4 Security If ALn and ALn+1 are on different routers, ARn and ARn+1, then: A. ARn and ARn+1 may have a pre-established trust relationship, or B. ARn and ARn+1 may be able to create a dynamic trust relationship, or C. ARn and ARn+1 will never have a trust relationship. 4.3.5 Quality of Service Maintain quality of service by establishing acceptable QoS over ALn+1. QoS credentials may be needed. 5. References [MIPv6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, April 2000. [KRB1] Kohl, J., Neuman, c., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [COPS1] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [COPS2] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., Sastry, A., "COPS usage for RSVP", RFC 2749, January 2000. [RSVP1] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [RSVP2] Baker, F., Lindell, B., Talwar, M., "RSVP Cryptographic Authentication", RFC 2747, January 2000. Authors Information Dana Blair - dblair@cisco.com Alex Tweedly - agt@cisco.com Michael Thomas - thomasm@cisco.com Jonathon Trostle - jtrostle@cisco.com Michael Ramalho - mramalho@cisco.com Appendix A: Make Before Break Handoff Sequence using RSVP, Kerberos, and COPS. This is Handoff Sequence is a work in progress. No reader should assume that this is complete or covers all required handoff scenarios. Authorizing PDP (aPDP) is a policy decision point, which is trusted by the hPDP. Authorizing KDC provides credentials and authorizes use of the Home KDC Access Service Request is a message which initiates handoff. INITIALIZATION SEQUENCE The MN is hard-configured with Home Address and prefix length, and either shared secret with the Home Agent, Authorizing KDC, or certificate. 1. Obtain sufficient access over AL1 to reach Authorizing KDC (AKDC). The AKDC may be separate from the Home Network. 2. Obtain ticket for Authorizing Policy Decision Point (APDP) from AKDC. One of the requirements of any successful scheme is the need for authentication and authorization for the large number of mobile hosts. This requires a scalable authentication mechanism. The prime candidates are Kerberos V5 [RFC 1510] and public key based mechanisms. The desire to achieve fast handoff, assuming relatively limited computing power on the mobile hosts, argue against any scheme involving public key computations in the handoff phase. Furthermore, the revocation checking that is required for most existing public key based mechanisms would cause additional delays. Therefore the scheme discussed proposes Kerberos for authentication. Kerberos still allows for some of the main benefits of a public key based approach since Kerberos includes extensions for public key authentication. At the same time, the speed of Kerberos secret key authentication is leveraged during the handoff. 3. Obtain sufficient access over AL1 to contact Home KDC (HKDC). 4. Obtain ticket from HKDC for HA. 5. Using Home Agent Discovery defined in [MIPv6], find the address the HA which the MN will use. HANDOFF SEQUENCE 6. Access Service Request (ASR) The Access Service request is sent from MN to AR1. The ASR contains the following: - description of the qos signaling mechanism in use - some description of the type/level of service being requested (e.g. RSVP flowspec) - flag whether tunneling is desired. A MN-AR1 key may be needed if tunneling is desired. - address and ticket for PDP - address and BU for the HA. If the MN has an application which uses RSVP, then RSVP [RSVP1] is proposed as the ASR for a variety of reasons. A layer three admission control mechanism is needed to provide both a means to access the network as well as a means of signaling that a handoff operation is desired. If enhanced quality of service is required for some flows, as may be the case with real time applications, a common admission control scheme for both basic network access and admission of quality of service flows is desirable. Modeling best effort traffic as a subset of all qualities of service leads to the possibility of using RSVP as the signaling protocol. RSVP also has some other advantageous properties. RSVP already has the means of carrying credentials in the form of policy objects [RSVP2] which can be sent to a remote policy decision point. RSVP already has the concept of soft state. Soft state in the context of mobility is quite important as there needs to be some means of clearing stale state in interior network elements without explicit signaling. RSVP's major advantage, however, comes when it is used with enhanced quality of service flows. Since it is likely that real time traffic in some important situations will require explicit admission control to deal with scarce bandwidth, a fast, smooth handoff cannot be considered complete until the quality of service on the new access router and beyond is installed. While RSVP messages could be sent in addition to an ASR, a single message which requests the flow at the attachment point along with the necessary credentials would be more economical. The message could also carry the request for any forward tunneling desired for a smooth handoff. Additions to RSVP would include a handoff object and changes to support Best Effort, non-flow based admission control. 6a. Authorization 6a-1. AR1 determines whether it can make the authorization decision on its own. If AR1 cannot authorize on its own, continue with 6a-2. 6a-2. AR1 takes the level of service request, and hPDP info, and forwards those to its own PDP, the visited PDP1 (vPDP1). The vPDP1 may then decide it can authorize (or deny) service. Otherwise, continue with 6a-3. COPS [COPS1] is proposed as the admission control policy protocol. COPS and RSVP are well integrated via RFC 2749. As for RSVP, a single admission control mechanism for both best effort and enhanced quality of service is desirable. COPS has been specifically designed for enhanced quality of service admission control and could be easily extended, if needed, to support admission of best effort traffic. As with RSVP, COPS has the desirable property of allowing for policy objects which can be used for authentication of a MN. Also, COPS supports cascaded policy decision points to allow a visited PDP to authorize with a home PDP. 6a-3. vPDP1 forwards the credential to hPDP for a decision, and/or settlement/billing decision between PDPs or via 3rd party broker, or other means. The result whether local to AR1 or from vPDP1 is a boolean decision to allow access of MN through AR1. 6b. If tunneling is desired, get new key for MN/AR1 If necessary, vPDP1 sends to hPDP the ticket and address for MN, type/level of service, etc. 6a may have already done this through interaction with the hPDP. However if not, this step is required. hPDP replies to vPDP1 with a new credential for use between MN and AR1. 6a and 6b may occur in parallel. However, 6c and 6d must wait for a successful result from 6a to reach AR1. 6c. QoS signaling If using RSVP - send the RSVP packet towards HA. If no QoS signaling, then AR1 simply imposes DiffServ policing if needed. 6d. Send Binding Update (BU) [MIPv6] to HA. The BU may be attached as a routing header on the ASR or imbedded in an object within the ASR. If the BU is embedded in an object within the ASR, the BU must be in the form of a complete IP packet including IPSEC encapsulation. If the BU is in an embedded object, AR1 extracts the BU and sends it on to HA. End of 6: The MN may now communicate with the HA including proper level of QoS assuming RSVP was successful. As long as the neither MN nor the AN requires a handoff, no more steps are required. 7. MN attempts to handoff to AR2. The Handoff Trigger may occur because MN heard a beacon from AR2 and decided AL2 was a better connection, or because the network containing AR1 determined that the MN should moved to AL1. There are many other possibilities as well. 7a. MN acquires suitable local address by either stateless or stateful address configuration. This may be either SCoA or NCoA. 8. MN sends an ASR to AR2. The ASR is sent from MN to AR2, contains: - QoS : description of the qos signaling mechanism in use - QoS : description of the type/level of service being requested (e.g. RSVP flowspec) - Security : flag whether tunneling back to AR1 is desired (i.e. is a MN-AR2 key needed) - Security : one or more tuples of < vPDP, ticket vPDP, address/name of hPDP, ticket hPDP > - Mobility : [if New-CoA] address and embedded (authenticated) BU for the HA. - Mobility : [optional] address and BU for the previous AR Note that this allows multiple tuples of PDP address + ticket. These will be considered in turn, with AR2 deciding whether or not to trust the vPDPn-1. Thus, if MN has recently been accessing the network via AR1, and has successfully established a key for use with AR1, then MN may (will?, must?) make the first tuple be , and the second tuple be <*, hPDP, ticket from 1a>. Thus in the authorization step AR2 will consider each of these tuples for a possible authorization decision in turn. Otherwise, this should be just same as the sub-steps of 2 above, with the addition of (optionally) AR2 sending a BU to AR1. Also, if using Same-Coa, AR2 will kick off the routing update / convergence. Note - if RSVP is the protocol to be used here, it most likely is addressed to HA, but will be intercepted by AR2, and the following steps taken before the packet is allowed to continue on its way to HA. But if it is some new "Access Service Request", then it can simply be destined to AR2. Therefore : 8a. Authorization 8a-1. AR2 determines whether it can make the authorization decision on its own. If AR2 does not authorize on its own, continue with 8a-2. 8a-2. AR2 tries first PDP address + PDP ticket tuple where the PDP address is the address of AR1. If AR2 trusts AR1, then AR2 will treat AR1 as a vPDP by asking AR1 to authorize the Access Service Request. AR1 may then decide it can authorize (or deny) service, based on having previously done so. Otherwise, continue with .. 8a-3. AR2 tries second PDP address + PDP ticket tuple where PDP address may be *. The vPDP specified is null (blank), so AR2 uses his own, normal vPDP. AR2 forwards hPDP info to vPDP2, and vPDP2 forwards the credential to hPDP for a decision, and/or settlement/billing decision between PDPs or via 3rd part broker, or other means. 8b. If tunneling is desired, get new key for MN/AR2 vPDP sends to hPDP the ticket and address for MN, type/level of service, etc. In general, step 8a above would include doing this, but in the case where it did not, they need to be send on to hPDP anyway. hPDP replies to vPDP with a new credential for use between MN and AR2. This used the pre-existing trust between vPDP2-hPDP and between MN-hPDP to generate this new credential. vPDP2 sends this on to AR2 and to MN. 8a and 8b may occur in parallel. 8c and 8d must wait for a successful result from 8a to reach AR2. 8c. QoS Signaling If using RSVP - send the RSVP packet towards HA. If no QoS signaling, then AR2 simply imposes DiffServ policing, if required. 8d. If the optional BU for AR1 is included, AR2 sends the BU, which was IPSEC encapsulated using the key derived in 6b, to AR1. MN is responsible for the construction of this BU, and therefore MN determines whether SCoA or NCoA is used. For SCoA, the BU will cause AR1 to tunnel to AR2 where AR2 will forward the packet to MN. For NCoA, the BU will cause AR1 to tunnel directly to CoA2 Note that AR2 or AR1 omit or reject this step if either AR2 or AR1 determines that this step violates network policy. 8e. MN sends BU to HA. AR2 extracts the embedded BU and sends this on to HA. 8f. If SCoA, then AR2 (and also AR1 based on step 4d) will initiate routing convergence to reflect the new attachment point for the CoA. All subsequent handoffs (e.g. ALn+1 to ALn+2) occur in like manner beginning with step 7. Appendix B: Handoff Sequence using Kerberos and Radius/Diameter This Handoff Sequence is a work in progress. No reader should assume that this is complete or covers all required handoff scenarios. 1. INITIALIZATION SEQUENCE Initially, the MN obtains a ticket granting ticket (TGT) using either a password or X.509 certificate in an AS exchange with a KDC in its home realm using IAKERB [IAKERB]. Subsequently, the MN mutually authenticates with the AR in order to obtain network access using IAKERB. An IPSEC SA is also established with the user's home agent. The IPSEC SA key management protocol could be IKE or any of the IPSEC key management protocols. 2. HANDOFF SEQUENCE The proposal in this appendix specifies the use of Kerberos [3] for providing authentication, key establishment, and authorization for Mobile IPv6 [2,5] fast handoffs. ARn detects the network prefix of the ARn+1. ARn sends a Neighbor 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 new CoA. We define new suboptions for the ND Redirect Message to include a negotiation flag, and the NR principal name and realm. The negotiation flag indicates whether to pass security state from the PR, which we call local authentication, or local authentication followed by global authentication (which may include an exchange with a Kerberos KDC server), or global authentication. The MN then sends a Previous Router Notification Message to the ARn which uses the IPSEC AH header and is keyed using the existing security association between the MN and the PR; this message informs the PR of the MN's new CoA. We define a new suboption for this message that includes a negotiation flag (the MN will choose a flag that is the same or more strict than the negotiation flag value sent to it from the PR in the Notification Message), and a suboption for including a Kerberos message. The value of the negotiation flag that was sent from the MN to the ARn will help determine what steps occur next. If local authentication was selected, then the ARn will pass secret cryptographic key information as well as other state information to ARn+1, using an encrypted channel between ARn and the ARn+1. This data will be sent in an unsolicited message (message TBD) from ARn to ARn+1. The MN established ALn+1 to ARn+1. The MN and ARn+1 will exchange ND solicitation and advertisement messages over ALn+1 prior to exchange of application data. The MN and the ARn will use the shared secret keys to establish IPSEC SA's between themselves after the initial handoff operations. If the value of the negotiation flag that was sent from the MN to ARn+1 was local authentication followed by global authentication, then the same steps as in the local case occur, except subsequently (after application data is flowing), Kerberos mutual authentication with additional key establishment occurs. We have defined new suboptions for the Neighbor Discovery Solicitation and Advertisement [8] for inclusion of Kerberos messages to achieve global authentication. Two ND solicitation and advertisement exchanges will be needed to encapsulate the three Kerberos messages in this case. If the negotiation flag value that was sent by the MN is global authentication, then the Previous Router Notification message will contain a ticket granting ticket (TGT) as described in the minimal messages subprotocol from IAKERB [4]. A typical exchange in this case would be: ND Redirect (with prefixes) ARn -------------------------------------------> MN suboption with principal name, realm suboption with global authentication flag Previous Router Notification (with new CoA) ARn <------------------------------------------- MN suboption with global authentication flag suboption with TGT Layer 2 Establishment MN -------------------------------------------> ARn+1 ND Solicit MN <------------------------------------------- ARn+1 suboption with encapsulated Kerberos AP_REQ ND Advertisement MN -------------------------------------------> ARn+1 suboption with encapsulated Kerberos AP_REP application data flow MN <------------------------------------------> ARn+1 Figure 1: Global Authentication for Fast Handoffs Before forwarding the AP_REQ to the MN, ARn+1 will send a message to its local AAA server with authorization data from the Kerberos service ticket extension. The reply from the local AAA server will contain the updated and massaged authorization data. ARn+1 will cache the authorization data and use it once the MN has authenticated to ARn+1. The protocol between ARn+1 and the local AAA server could be either Radius or Diameter. Upon receipt of the AP_REQ from the ARn+1, the MN will perform the normal Kerberos validation steps. In addition, the service principal identifier component of the client principal name in the ticket MUST be equal to mobileip. If not, the MN will fail the request by sending a KRB_ERROR message to the NR with the error code KRB_ERR_GENERIC. Note that the AP_REQ will have the mutual authentication flag set. Thus, the MN is required to authenticate to the ARn+1 which it does by sending the AP_REP message to the ARn+1. Subsequently, the MN sends any BCU's to its home agent (HA) and correspondent nodes (CN's). The MN may also send a router solicitation message to the ARn+1 with a new suboption asking for the reverse ticket (IAKERB [4]) and list of adjacent realms to be sent back in the router advertisement. The reverse ticket is constructed by the ARn+1 and is targeted at the ARn+1 from the MN. It allows fast subsequent authentications from the MN to the ARn+1. The list of adjacent realms can be used by the MN to precache crossrealm TGT's targeted at adjacent realms (as a background task). This performance optimization allows subsequent global authentications for adjacent realms to skip exchanges with the remote user's KDC. Instead, a local KDC will be used. Kerberos authentication uses the subprotocols from IAKERB [4]. In particular, the minimal messages subprotocol (which uses user-user authentication) is used for the global authentication exchange (illustrated in Figure 1). Precaching can use either standard Kerberos or standard IAKERB. Initial logon (which occurs before the first roam) should use standard IAKERB exchanges with an IAKERB proxy. As a result of initial logon, the MN user will obtain an initial TGT, as well as a service ticket targeted at the initial access router which acts as an IAKERB proxy. Initial logon can use public key certificates as described in pkinit [9]. For a break before make case, the MN may have to establish layer 2 with the ARn+1 without the benefit of the ND Redirect and Previous Router Notification messages. In this case, the security data from the ND Redirect message (in the above figure) will be placed in the router advertisement message sent from the ARn+1 to the MN in response to the MN's router solicitation message. The MN then sends a ND solicitation with the authentication flag and optionally, the TGT, if global authentication has been 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 becomes: Layer 2 Establishment MN -------------------------------------------> ARn+1 Router Solicitation MN -------------------------------------------> ARn+1 negotiation flag suboption, TGT suboption Router Advertisement MN <------------------------------------------- ARn+1 negotiation flag suboption, and optionally, suboption with encapsulated Kerberos AP_REQ ND Solicitation MN ------------------------------------------->ARn+1 suboption with Kerberos AP_REP message (if global authentication has been negotiated) ND Advertisement MN <------------------------------------------ ARn+1 application data flow MN <------------------------------------------> ARn+1 Figure 2: Global Authentication: Break Before Make 3. Neighbor Discovery Solicitation, Advertisement, Redirect Suboptions, and Previous Router Notification Suboption. The following suboption contains the principal name and realm: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Kerberos Principal Name ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kerberos Principal Realm ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Principal Name Kerberos Principal Name Principal Realm Kerberos Principal Realm The following suboption contains the negotiation flag: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L|B|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Flags L - local authentication B - local authentication followed by global authentication G - global authentication The requestor sets one of the above flags and the responder sends the same suboption with either the same flag or a more strict flag. The flags increase in strictness from L to B to G. We note that an attacker can cause at most a denial of service attack by manipulating these flags in transit. The following suboption contains a Kerberos protocol message: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Kerberos Message ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Kerberos Kerberos protocol message as defined in [3] Message Any of the above suboptions can be included in any of the neighbor discovery solicitation, advertisement, or redirect messages, as well as the previous router notification message. The principal name/realm suboption and the negotiation flag suboption can also occur in a router advertisement message. 4. Router Solicitation and Advertisement Options The following router solicitation message suboption is used to request that the access router return a list of adjacent realms in its router advertisement. The access router may also return a Kerberos message suboption with a reverse ticket. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). The following router advertisement message suboption is used to return a list of adjacent realms in the router advertisement: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Realm 1... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Realm 2... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... Realm n... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Realm i The realm name of the ith geographically adjacent Kerberos realm. The following router solicitation message suboption is used to request that the access router return the principal name/realm suboption and the negotiation flag suboption (as described above). It is used in break before make handoff cases. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). 5. Authorization We propose the following approach to authorization for the global case (in the local case, authorization state is passed from the previous router to the new router). The NR's KDC will map authorization data in the user's Kerberos ticket to local authorization attributes which will be placed in a ticket extension of the issued ticket. Here we propose a new Kerberos authorization data type: AD-MOBILEIP-ATTRIBUTES TBD The data is the ASN.1 OCTET STRING encoding of the following: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Alg ID | Signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / TLV's / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). AlgID Algorithm Identifier Signature Digital signature over TLV's. TLV's Authorization attributes in TLV form We also propose a new ticket extension type: TE-MOBILEIP-ATTRIBUTES 9 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [3] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [4] Swift, M., Trostle, J., "Initial Authentication and Pass Through Authentication Using Kerberos V5 and the GSS-API (IAKERB)", Internet draft (work in progress), draft-ietf-cat-iakerb-04.txt, July 2000. [5] Johnson, D. and Perkins, C., "Mobility Support in IPv6", Internet draft (work in progress), draft-ietf-mobileip-ipv6-12.txt, April 2000. [8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [9] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., Trostle, J., "Public Key Cryptography for Initial Authentication in Kerberos", Internet draft (work in progress), draft-ietf-cat-kerberos-pk-init-11.txt, April 2000. Appendix C This appendix shows a fully integrated RSVP/COPS/Kerberos solution. It is very similar to Appendix A, and will be merged at a later date. Abbreviations: PO: RSVP/COPS policy object TR: Ticket Relay Object: an object which relays a shared secret back to the initiator and relay initiator. This subject deserves a great deal more discussion, and will be added in future versions of this draft. HO: Handoff Object: an object which requests a handoff to occur between AR1 and AR2 with optional forward tunneling from AR1 to AR2. If handoff objects desire forward tunneling, they must contain an embedded handoff object EBU: Embedded Binding Update: an embedded binding update is a normal IPv6 mobility binding update message which is encapsulated in a wrapper which proves MN's identity as well as proving freshness, etc. EBU's may be embedded in RSVP and COPS messages. tick[XXX]: a Kerberos ticket for which the server half of the ticket is encrypted in XXX's key. MN is always assumed to be in the client half of the ticket. Initial Access When the mobile node initially desires access, it must go through a full initial access flow. This flow assumes that MN does not have any valid Kerberos tickets cached. If it does, it may omit the interactions with the appropriate KDC's. The goal of this flow is to just obtain best effort access from AR1. As such, the RSVP request is directed at AR1. MN AR1 AR2 vPDP aPDP aKDC hKDC hA ======================================================================== <=========> L2 estab -----------------------------------------------------> AS-REQ to get service ticket for aPDP <----------------------------------------------------- AS-REP w/ tick[aPDP] ---------------------------------------------------------------> AS-REQ to get service ticket for hA <--------------------------------------------------------------- AS-REP w/ tick[hA] ---------> RSVP PATH w/ PO(tick[aPDP]) --------------------> COPS REQ w/ PO(tick[aPDP]) ----------------------> COPS REQ w/ PO(tick[aPDP]) <--------------------- COPS DEC w/ TR(tick[vPDP]) <-------------------- COPS DEC w/ TR(tick[AR1]) <-------- RSVP RESV w/ TR(tick[MN]) ~ MN is now admitted at AR1 and shares a secret with AR1 from the TR ~ MN AR1 AR2 vPDP aPDP aKDC hKDC hA ======================================================================== ---------------------------------------------------------------------> KINK CREATE SA w/ tick[hA] <--------------------------------------------------------------------- KINK REPLY ---------------------------------------------------------------------> BU <--------------------------------------------------------------------- BU ACK ~ The home agent's binding cache is now updated with forward tunneling established. Note: if the MN is already in possession of valid tickets to the aPDP or hA, the AS-REQ and AS-REP's in the flow can be omitted. ~ Intra Trust Domain Fast/Smooth Handoff It is assumed that AR1 and AR2 have a pre-existing security association. If they do not, a security association between the two would need to be established using normal IPsec keying mechanisms. This flow assumes that the MN is capable of transmitting and receiving on AR2. It may or may not still have connectivity to AR1. It is also assumed that AR1 and AR2 are with in the same trust domain where AR1 can act as a PDP for AR2. MN AR1 AR2 vPDP aPDP aKDC hKDC hA ======================================================================== <=========> L2 estab -----------------------> RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU (AR1)) <------------ COPS REQ w/ PO(tick[AR1]), HO(AR1, AR2, EBU(AR1)) ------------> COPS DEC w/ TR(tick [AR2]), EBU(ACK) <----------------------- RSVP RESV w/ TR(tick [MN]) ~ At this point, AR1 will forward any packets destined for MN's old CoA to AR2 and as such any packets in flight will still reach MN. The following two steps only occur if the MN's CoA changed ~ ---------------------------------------------------------------------> BU <--------------------------------------------------------------------- BU ACK Intra Trust Domain Fast/Smooth Handoff to a cNode with QoS This flow describes a fast/smooth handoff with a cNode with an established QoS flow. It is assumed that cNode and MN already have established keys between them. How they are initially established is outside of the scope of this document. It is assumed that AR1 and AR2 have a pre-existing security association. If they do not, a security association between the two would need to be established using normal IPsec keying mechanisms. This flow assumes that the MN is capable of transmitting and receiving on AR2. It may or may not still have connectivity to AR1. It is also assumed that AR1 and AR2 are with in the same trust domain where AR1 can act as a PDP for AR2. MN AR1 AR2 vPDP aPDP aKDC hKDC cN ======================================================================== <=========> L2 estab -----------------------> RSVP PATH PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU (AR1)), EBU(CN) <------------ COPS REQ w/ PO(tick[AR1]), HO(AR1, AR2, EBU(AR1)) ------------> COPS DEC w/ TR(tick [AR2]), EBU(ACK) ~ At this point, AR1 will forward any packets destined for MN's old CoA to AR2 and as such any packets in flight will still reach MN. ~ -----------------------------------------------> RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), EBU(CN) ~ At this point, the cNode would receive the new binding and know that it would need to adjust any reservations toward MN as well. These RSVP messages are not shown here. ~ <---------------------------------------------- RSVP RESV from cNode EBU(ACK) <----------------------- RSVP RESV w/ TR(tick [MN]), EBU(ACK) Inter Trust Domain Handoff In the case where AR1 and AR2 do not trust another domain's cached policy decisions, it will necessitate another authoritative policy decision. Note that the MN is at liberty to send as many policy objects as it feels may be needed to expedite the decision. Also: if the MN has local credentials it may send them as well which would also result in a fast though not necessarily smooth handoff. Note that this flow is nearly identical to the initial access flow. The only difference is that the MN sends a PO and HO for AR1. Because AR2 and AR1 are not within the same trust domain, AR2 ignores that policy object since it is not a trusted PDP. MN AR1 AR2 vPDP aPDP aKDC hKDC hA ======================================================================== <=========> L2 estab -----------------------> RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU) ---------> COPS REQ w/ PO(tick[aPDP]) --------------> COPS REQ w/ PO(tick[aPDP]) <-------------- COPS DEC w/ TR(tick[vPDP]) <--------- COPS DEC w/ TR(tick[AR2]) <----------------------- RSVP RESV w/ TR(tick[MN]) ---------------------------------------------------------------------> BU <--------------------------------------------------------------------- BU ACK ~ At this point, AR1 will forward any packets destined for MN's old CoA to AR2 and as such any packets in flight will still reach MN. The following two steps only occur if the MN's CoA changed ~ ---------------------------------------------------------------------> BU <--------------------------------------------------------------------- BU ACK