- 1 - Internet Engineering Task Force John Penners INTERNET DRAFT U S WEST Advanced Technologies draft-penners-mobileip-smip-00.txt Yakov Rekhter T.J. Watson Research Center, IBM Corp. September 1993 Simple Mobile IP (SMIP) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. "This document has been presented to, and is being evaluated by, the "Mobile IP" working group of the IETF. This document is being published as an Internet Draft in order to allow the general IETF community the opportunity to gain a wider understanding of the issues involved in mobile IP routing, as well as to understand the specific solution proposed in this document. This document has not received any formal endorsement from the Mobile IP working group. 1 Introduction There have been several proposals for supporting mobility at the network layer (e.g. [1], [2], [3], [4], [5]). While all these proposals differ from each other in a number of features, all of them also exhibit certain commonalities with each other. The proposal described in this document is an attempt to extract and exploit this commonality. Its goal is to provide a simple, but solid foundation Expiration Date March 1994 [Page 1] - 2 - upon which additional optional features can be introduced in a backward compatible fashion. The simplicity of the proposed scheme is also expected to positively impact manageability and security aspects associated with supporting mobility. It is our premise that the following factors will be key to widespread usage: 1. Adequate Security - Customers are not going to use Mobile-IP (portable) if it does not provide adequate security protection. These include masquarading as the mobile host, unwilling disclosure of MH location, and potentially privacy. 2. Ability to run traditional applications - It is not clear how well existing transport protocols will deal with transients introduced by mobility. We also don't know many aspects associated with mobility (e.g. its dynamics). Therefore, it is likely that some of the problems would not be discovered until the actual deployment and usage. Likewise, what may be perceived as a problem today, may turned out to be a non- problem in the operational environment. 3. Manageability - The mobile system must be easy to manage or system administrators won't want to deploy them. 4. Rapid Wide Spread Deployment - Systems are more likely to be deployed if there is already an established base. This argues for simple, easy to install and manage systems. 5. Mobility - It is quite possible that most of the requirements in today's environment can be satisfied with portability. In the long term, on-line mobility may not be sufficient -- off- line mobility may be required. However, it is unlikely that the off-line mobility can be solved at the network layer. 2 Elements The scheme is described in terms of four components, Stationary Host (SH), Mobile Host (MH), Home Register (MR), and Visiting Register (VR). The VR and HR could be colocated within a single physical entity which may or may not have traditional router functionality. Expiration Date March 1994 [Page 2] - 3 - - Stationary Host (SH) : This is a host that may or may not be stationary but is viewed as stationary. - Home Register (HR) : This machine acts as an agent for the Mobile Host. It keeps track of its location and provide a service that relays the incoming message to the Mobile Host. - Visiting Register (VR) : This machine provides the Care-of service for the Mobile Host. It issues a c/o address to the mobile host and receives message from the MH's HR and forwards them to the MH. - Mobile Host (MH) : This is the mobile host. It requires some new protocols to handle it's mobility. All communication to this host (but not from this host) is through the Home Register (HR) of the Mobile Host (MH). 3 Data and Control Flows There are only three flows - two are data and one is a control The two data flows are as follows: (1) SH to MH => SH -> HR -> VR -> MH (2) MH to SH => MH -> VR -> SH The proposal doesn't preclude future data traffic flow from SH to MH that would bypass the HR. Expiration Date March 1994 [Page 3] - 4 - The only control flow which originates and terminates at the MH is as follows: MH VR HR | | | | MH Hello | | |------------------------->| Location Update Request | | |---------------------------->| | | | | | Location Update Confirm | | |<----------------------------| | VR Confirm | | |<-------------------------| | Since this model has four elements the following matrix can be used to illustrate the information content that flow between elements. This matrix contains both data and control flows. \ Receiver \ MH VR HR SH | Sender |-------|-------|-------|-------| MH | N/A | 1 | 2 | 3 | |-------|-------|-------|-------| VR | 4 | OP | 5 | OP | |-------|-------|-------|-------| HR | 6 | 7 | N/A | 8 | |-------|-------|-------|-------| SH | 10 | OP | 9 | N/A | |-------|-------|-------|-------| OP - could be an option. They increase the complexity of the protocol and are not discussed in this proposal. VR -> VR could be used if there was handoff between VRs. This could create a security problem. N/A - Not applicable The content of new packets is indicated with [ ] below. We assume that the link layer will contain both the destination and source physical addresses. Expiration Date March 1994 [Page 4] - 5 - 1) MH -> VR - Notify VR and acquire c/o Address - Provide MH's permanent address to VR - Provide authentication for VR to pass to HR [ VR IP Addr, HR IP Addr, Sequence, MH/HR specific data (auth)] MH/HR specific data and interpretation by the VR is not required. It is likely to contain auth key and time stamp. 2) MH -> HR This is an indirect flow of information (through the VR) - Authentication and location info transmitted via VR Info contained in MH -> VR data packet 3) MH -> SH - Data via straight path (but flows through the VR serving the MH) Info contained in normal IP packet 4) VR -> MH - Provide or refuse c/o on request - Forward received messages to MH - Notify MH of HR refusal to serve [MH addr, VR addr, Sequence, Attachment Accepted or Refused] 5) VR -> HR Expiration Date March 1994 [Page 5] - 6 - - Confirm MH location (possible after authentication) - Delivery Status (i.e. unable to deliver message) - Participate in tunnel Setup and teardown (detailed mgmt provided by tunneling mechanism) [ HR IP Addr, VR IP Addr, MH IP Addr, Sequence, MH/HR specific data] 6) HR -> MH This is an indirect flow (passes through VR) - Forward Data packets Provided via HR -> VR 7) HR -> VR - Tunnelled data - Participate in tunnel Setup and teardown (detailed mgmt provided by tunneling mechanism) [ VR addr, HR addr, MH addr, Sequence, c/o address, Accepted or Refused, HR/VR data] HR/VR data includes tunnel specific and service accept info that is also used to generate VR -> MH packet 8) HR -> SH - Nothing special ( SH doesn't know the difference ) - Ping responses on behalf of MH if MH is reachable (optional) 9) SH -> HR - Nothing special ( doesn't know the difference ) Expiration Date March 1994 [Page 6] - 7 - 10) SH -> MH - Nothing special ( doesn't know the difference ) 4 Element Functions The functions that each element must perform are indicated below. SH - Nothing new HR - Authenticate MH - Advertises direct network layer reachability for MHs associated (served) with the HR - Encapsulate packets - Maintain location of MHs - Processes tunnel control messages generated by VR intended for HR. Normal tunnel control handled by tunnel protocol. MH - Request and receive c/o address - Provide authentication information to VR for HR - Provide permanent address to VR - Provide normal processing of data packets VR - Provide c/o address - Keep track of visiting MH Expiration Date March 1994 [Page 7] - 8 - - De-encapsulation of messages. - Provide error notification to the HR if necessary. - Return packets to HR after MH moved. 5 Registration and Location Update Registration and Location Update is initiated by a MH (MH-controlled) and is executed each time the MH wants to change its association with VRs (acquire a new VR and dissolve an association with an old VR). It is also executed periodically (timer driven) to refresh information. The VR can refuse reregistration for local reasons such as over utilization. In this approach the VR informs the HR of the MH's location. The VR can not register a MH without the MHs authentication information. This is done indirectly through the VR. In order to update the HR the following must occur 1. The VR agrees to serve the MH 2. The HR agrees to that VR can serve MH 3. The HR agrees to serve MH Therefore the following sequences can occur: 1st possible sequence: - MH sends a message to VR with MH-HR authentication info - VR informs MH of refusal to service MH Failure at 1). 2nd possible sequence: Expiration Date March 1994 [Page 8] - 9 - - MH sends a message to VR with MH-HR authentication info - VR agrees to service MH - VR sends message to HR with MH authentication info - HR informs VR of refusal to use VR's service - VR informs MH of HR's refusal to use VR's service Failure at 2). 3rd possible sequence: - MH sends a message to VR with MH-HR authentication info - VR agrees to service MH - VR sends message to HR with MH authentication info - HR informs VR of refusal to serve MH - VR informs MH of HRs refusal to serve MH Failure at 3). 4th possible sequence: - MH sends a message to VR with MH-HR authentication info - VR agrees to service MH - VR sends message to HR with MH authentication info - HR informs VR of willingness to serve VR and MH - VR informs MH of willingness to serve Success. The Registration and Location Update protocol is implemented over UDP. Expiration Date March 1994 [Page 9] - 10 - 6 Tunneling Tunneling mechanism could be the same as used elsewhere in the Internet. (i.e. mbone) There are no special requirements for tunnelling, so any tunnelling scheme will do the job but only one scheme should be adopted. 7 Security Privacy - Privacy of data can be achieved by encryption at the application level. - Privacy of location is ensure by routing through HR Authentication - Authentication of the MH doesn't require trusting third parties. The only entities that have knowledge of the authentication keys are the MH and it's HR. 8 Draft of Management Information Manageability - Few elements - constrained elements should be easier to manage. - Well defined flows should allow easier tracking of information - Common tunneling mechanism should make management easier. Management Information Bases MH MIB Expiration Date March 1994 [Page 10] - 11 - - Available VR c/o addrs - Sequence of previous VRs c/o addrs - Basis for termination - Duration of attachment - VRs that refused service - Basis for refusal VR MIB - MHs being served - Associated HRs - Sequence of MHs previously served - Associated HRs - Basis for termination - Duration of attachment - MHs refused service - Basis for refusal - List of MHs willing to serve (optional - default is all) - Statistics of packets returned to HR HR MIB - VRs serving MH - present VR - previous VRs Expiration Date March 1994 [Page 11] - 12 - - Refused MHs - authentication - unacceptable VR - MH user profile - entities that may know MH location - Acceptable VRs SH MIB - Nothing new 9 Pseudo-code for Colocated HR/VR The following pseudocode describes handling packets by a colocated HR/VR. Suppression of packet looping due to transients or stale information is always done at the HR. Looping is suppressed (by dropping packet) only when the HR can't make any further progress (it has the same COA as the previous one in the loop). VR in absence of the ability to deliver locally, sends packet to HR associated with the destination address. The pseudo code uses the following abbreviations: - encap-src-addr -- source address in the outer header - encap-dst-addr -- destination address in the outer header - src-addr -- source address in the inner header - dst-addr -- destination address in the inner header - COA(addr) returns Care of Address associated with addr Expiration Date March 1994 [Page 12] - 13 - if packet destined to HR/VR { /* acting as either VR or T-HR */ if encapsulation { /* received data packet*/ strip encapsulation; if local delivery possible /* encapsulator has correct info */ do local delivery; else { swap(dst-addr, encap-dst-addr); /* send back to HR */ submit to normal forwarding; } } else { /* SMIP control packets follow this path */ if packet is a SMIP control packet perform_SMIP_processing(packet); else submit for normal local processing; } } else { if dst-addr != HR's client /* acting as a router */ submit to normal forwarding; else { /* acting as HR */ if encapsulation { /* packet went at least once through HR */ swap(dst-addr, encap-dst-addr); if COA(dst-addr) != NULL && COA(dst-addr) != encap-dst-addr { encap-src-addr = encap-dst-addr = COA(dst-addr); submit to normal forwarding; } else discard the packet; } else { /* packet came from the source, just re-address it */ if (COA(dst-addr) != NULL) { encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else { /* no forwarding information available */ if local subnet delivery is possible submit to normal forwarding; else discard the packet; } } } } Expiration Date March 1994 [Page 13] - 14 - /* * The following pseudo code describe processing of SMIP control * packets by VR/HR */ perform_SMIP_processing(packet) { if MH Hello packet { if VR or T-HR capable if MH already registered if MH IP addr already register if LinkLayer (registered MH IP addr) = LinkLayer (new MH IP addr) if acting as T-HR for MH if MH authenticates convert to VR confirm set confirm bit dst addr = MH addr src addr = T-HR addr submit to normal forwarding else /* failed auth at T-HR */ covert to VR confirm /* confirmation refuse */ clear confirm bit dst addr = MH addr src addr = T-HR addr submit to normal forwarding note MH addr and failed authentication else /* acting as VR for MH */ convert MH Hello into Location Update dst addr = HR addr src addr = VR addr submit to normal forwarding else /* Different Link Layer Address for MH IP addr /* note as security suspicious else /* MH not registered */ temporarily register MH (MH addr, HR addr, Sequence) convert MH Hello into Location Update dst addr = HR addr src addr = VR addr submit to normal forwarding else /* Not VR so should not receive MH Hello packet */ drop packet /* Not beaconing so no need to send error message */ } else { if Loc Update Req packet if acting as a HR or T-HR Expiration Date March 1994 [Page 14] - 15 - if MH authenticates convert Loc Update Req to Loc Update Confirm auth key = MH public key set confirm bit dst addr = VR addr src addr = HR add submit to normal forwarding register MH at VR else convert Loc Update Req to Loc Update Confirm clear confirm bit dst addr = HR addr src addr = VR addr submit to normal forwarding note MH addr and failed authentication else drop packet /* Not an HR */ else { if Loc Update Conf packet if confirm bit set convert Loc Update Conf to VR confirm dst addr = MH addr src addr = VR addr submit to normal forwarding convert temp registration to permenant registration save public authentication key else /* authentication failed */ convert Loc Update Conf to VR confirm dst addr = MH addr src addr = VR addr submit to normal forwarding eliminate temp registration make note of failed authentication else /* not a VR */ drop packet } } } Expiration Date March 1994 [Page 15] - 16 - 10 Acknowledgment We would like to express our thanks to Kannan Alagappan (DEC), and Steve Deering (XEROX) for their review and constructive comments. Appendix A A.1 Future Enhancements and Associated Issues We describe possible enhancements that can be added to the base proposal. The enhancements can be added in an incremental fashion. A.1.1 Cascading of Systems In order to cascade systems a VR needs to have some HR functionality. As indicated earlier a VR and HR can be colocated. A VR functioning similar to HR is called a T-HR. A T-HR is slightly different than a HR. For example, unlike the HR, a T-HR does not advertise direct network layer reachability to MHs served by the T-HR. The following sequence of events illustrate how cascading can occur - The MH request VR service - The VR with T-HR capability provides the HR with the standard information and informs the HR of it's T-HR capability. - The HR agrees to allow the VR to serve the MH and also passed a public authentication key to the VR. - The VR lets the MH know that the attachment is successful and the VR is T-HR capable. - When the MH moves to a new VR it tells the new VR of the T-HR location and passes an authentication key that the T-HR uses to Expiration Date March 1994 [Page 16] - 17 - authenticate it. As a fall-back position the new VR can always go to the HR. - The T-HR agrees to serve as the HR and the new VR acts as if were part of the baseline system. This would result in the following new data flow: SH==>MH: SH->HR->T-HR->VR->MH PSEUDO CODE FOR CASCADING OF SYSTEMS IN COLOCATED HR/VR if packet destined to HR/VR { /* acting as either VR or T-HR */ if encapsulation { /* received data packet*/ strip encapsulation; if local delivery possible /* encapsulator has correct info */ do local delivery; else { /* packet already traversed through HR */ /* * Acting as T-HR and have non-null COA */ if HR/VR is T-HR capable && dst-addr == T-HR's client && COA(dst-addr) != NULL { encap-dst-addr = COA(dst-addr); submit to normal forwarding; } else { /* encapsulator has stale info, send to HR */ if encap-src-addr != encap-dst-addr { /* packet came from T-HR */ swap(encap-src-addr, encap-dst-addr); } swap(dst-addr, encap-dst-addr); /* send back to HR */ submit to normal forwarding; } } } else { /* SMIP control packets follow this path */ if packet is a SMIP control packet perform SMIP processing; else submit for normal local processing; } } else { if dst-addr != HR's client /* acting as a router */ Expiration Date March 1994 [Page 17] - 18 - submit to normal forwarding; else { /* acting as HR */ if encapsulation { /* packet went at least once through HR */ swap(dst-addr, encap-dst-addr); if COA(dst-addr) != NULL && COA(dst-addr) != encap-dst-addr { send Location Update information to src-addr; encap-src-addr = encap-dst-addr = COA(dst-addr); submit to normal forwarding; } else { if COA(dst-addr) == encap-dst-addr mark COA(dst-addr) as "suspicious"; discard the packet; } else { /* packet came from the source, just re-address it */ if (COA(dst-addr) != NULL) { send Location Update information to src-addr; encapsulate with encap-src-addr = encap-dst-addr = COA(dst-addr); submit to normal forwarding; } else { /* no forwarding information available */ if local subnet delivery is possible submit to normal forwarding; else discard the packet; } } } } A.1.2 Elimination of Triangular Routing The elimination of Triangular Routing creates a security problem without an infrastructure that provides a trusted third party to handle the processing of authentication keys. Triangular routing may not be as big a problem as some think. Triangular routing is relatively efficient in the following cases Expiration Date March 1994 [Page 18] - 19 - - The SH is close to the HR while MH is not. - The MH is close to the HR while SH is not - The HR is between the SH and the MH. Both the first and the second cases may be reasonable assumptions while the third case is random. Possible solution: - Allow MH and/or HR to send Location Update Request messages to MH's peer. COLOCATED HR/VR PSEUDO CODE FOR ELIMINATING TRIANGULAR ROUTING WITHOUT CASCADING if packet destined to HR/VR { /* acting as either VR */ if encapsulation { /* received data packet*/ strip encapsulation; if local delivery possible /* encapsulator has correct info */ do local delivery; else { swap(dst-addr, encap-dst-addr); submit to normal forwarding; } } else { /* SMIP control packets follow this path */ if packet is a SMIP control packet perform SMIP processing; else submit for normal local processing; } } else { if dst-addr != HR's client /* acting as a router */ submit to normal forwarding; else { /* acting as HR */ if encapsulation { swap(dst-addr, encap-dst-addr); if encap-src-addr == src-addr { /* packet didn't traverse through HR */ Expiration Date March 1994 [Page 19] - 20 - if encap-dst-addr == FA(dst-addr) {/* HR may have stale information */ mark FA(dst-addr) as "suspicious"; discard the packet; } else { /* src has stale info */ if FA(dst-addr) != NULL { send Location Update information to src-addr; encap-src-addr = encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else discard the packet; } } else { /* packet went at least once through HR */ if FA(dst-addr) != NULL && FA(dst-addr) != encap-dst-addr { send Location Update information to src-addr; encap-src-addr = encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else { if FA(dst-addr) == encap-dst-addr mark FA(dst-addr) as "suspicious"; discard the packet; } } } else { /* packet came from the source, just re-address it */ if (FA(dst-addr) != NULL) { send Location Update information to src-addr; encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else { /* no forwarding information available */ if local subnet delivery is possible submit to normal forwarding; else discard the packet; } } } } Expiration Date March 1994 [Page 20] - 21 - A.1.3 Combined Elimination of Triangular Routing and Cascading of Systems PSEUDO CODE FOR ELIMINATION OF TRIANGULAR ROUTING AND CASCADING OF SYSTEMS IN COLOCATED HR/VR if packet destined to HR/VR { /* acting as either VR or T-HR */ if encapsulation { /* received data packet*/ strip encapsulation; if local delivery possible /* encapsulator has correct info */ do local delivery; else { if encap-src-addr == src-addr { /* packet didn't traverse through HR */ /* * Acting as T-HR and have non-null FA */ if HR/VR is T-HR capable && dst-addr == T-HR's client && FA(dst-addr) != NULL { encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else { /* encasulator has stale info, send to HR */ swap(dst-addr, encap-dst-addr); submit to normal forwarding; } } else { /* packet already traversed through HR */ /* * Acting as T-HR and have non-null FA */ if HR/VR is T-HR capable && dst-addr == T-HR's client && FA(dst-addr) != NULL { encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else { /* encasulator has stale info, send to HR */ if encap-src-addr != encap-dst-addr { /* packet came from T-HR */ swap(encap-src-addr, encap-dst-addr); } swap(dst-addr, encap-dst-addr); /* send back to HR */ submit to normal forwarding; } } } Expiration Date March 1994 [Page 21] - 22 - } else { /* SMIP control packets follow this path */ if packet is a SMIP control packet perform SMIP processing; else submit for normal local processing; } } else { if dst-addr != HR's client /* acting as a router */ submit to normal forwarding; else { /* acting as HR */ if encapsulation { swap(dst-addr, encap-dst-addr); if encap-src-addr == src-addr { /* packet didn't traverse through HR */ if encap-dst-addr == FA(dst-addr) {/* HR may have stale information */ mark FA(dst-addr) as "suspicious"; discard the packet; } else { /* src has stale info */ if FA(dst-addr) != NULL { send Location Update information to src-addr; encap-src-addr = encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else discard the packet; } } else { /* packet went at least once through HR */ if FA(dst-addr) != NULL && FA(dst-addr) != encap-dst-addr { send Location Update information to src-addr; encap-src-addr = encap-dst-addr = FA(dst-addr); submit to normal forwarding; } else if FA(dst-addr) == encap-dst-addr mark FA(dst-addr) as "suspicious"; discard the packet; } } else { /* packet came from the source, just re-address it */ if (FA(dst-addr) != NULL) { send Location Update information to src-addr; encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr); Expiration Date March 1994 [Page 22] - 23 - submit to normal forwarding; } else { /* no forwarding information available */ if local subnet delivery is possible submit to normal forwarding; else discard the packet; } } } } A.1.4 Multicasting The HR or a T-HR can be used to aid in multicasting of packets to and from the MH. A.1.5 Off-line Mobility Off-line Mobility is an important problem that is unlikely to be solved at the network layer alone. References [1] Carlberg, K., "A Routing Architecture That Supports Mobile End Systems", Proceedings of IEEE MILCOM, October 1992 [2] Cohen, D., Postel, J., Rom, R., "IP Addressing and Routing in a Local Wireless Network", INFOCOM 1992, pp. 5A.3.1--5A.3.7 [3] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. "IP-Based protocols for mobile internetworking", Proceedings of SIGCOMM'91, ACM, September, 1991, pp. 235--245. [4] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro, "A Network Architecture Providing Host Migration Transparency", Proceedings of SIGCOMM'91, ACM, September, 1991, pp. 209-220 Expiration Date March 1994 [Page 23] - 24 - [5] Hiromi Wada, Tatsuya Ohnishi, and Brian Marsh, "Packet Forwarding for Mobile Hosts", work in progress Security Considerations Security issues are not discussed in this memo. Authors' Addresses John Penners U S WEST Advanced Technologies 4001 Discovery Drive Boulder, CO 80303 Phone:(303) 541-6106 email: jpenners@atqm.advtech.uswest.com Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: (914) 945-3896 email: yakov@watson.ibm.com Expiration Date March 1994 [Page 24]