Internet Engineering Task Force Gabriel Montenegro INTERNET DRAFT Sun Microsystems, Inc. January 5, 1996 Bi-directional Tunneling for Mobile IP draft-montenegro-tunneling-00.txt Status of This Memo This document is a submission to the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted either to the author, or to the mobile-ip@SmallWorks.COM mailing list. Distribution of this memo is unlimited. 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 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Mobile IP specification uses tunneling from the home agent to the mobile node, but not in the reverse direction. Instead, a mobile node sends its packets through a router in the foreign net, and relies on routing to be done independently of source address. When this assumption is not true, or when other considerations dictate it, it is convenient to establish bi-directional tunnels between the home agent and the mobile node's care-of address. This document proposes backwards-compatible extensions to Mobile IP in order to support bi-directional tunnels. Montenegro Expires July 5, 1996 [Page 1] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 1. Introduction The Mobile IP specification specifies tunneling from the home agent to the mobile node, but not in the reverse direction. This reverse tunneling is deemed unnecessary because of the following assumption from section 1.3 of the Mobile IP draft [1]: It is assumed that IP unicast datagrams are routed based on the destination address in the datagram header (i.e., not by source address). Because of security concerns (e.g. IP spoofing attacks), and in accordance with the CERT advisory to this effect [3], routers and firewalls that break this assumption are increasingly more common. Use of bi-directional tunnels eliminates the above constraint. Multicast routing also breaks the above assumption. It requires that a mobile node send packets that originate at a topologically significant address. This implies a bi-directional tunnel unless the mobile node owns another address (or has temporarily acquired one) for use as a care-of address. However, this option is limited by foreign agents that set the 'R' ("registration required") bit. Other benefits are: a) Bi-directional tunnels applied to mobile routers obviate the need for recursive tunneling [1]. b) Location Privacy: the outer addresses of the reverse tunnel (the care-of address and home agent address) shield the inner mobile node address from examination by intermediate routers, specially if using an encrypted tunnel. 1.1. Terminology The discussion below uses terms defined in the Mobile IP specification. Additionally, it uses the following terms: Forward Tunnel A tunnel that shuttles packets towards the mobile node. It starts at the home agent, and ends at the mobile node's care-of address. Reverse Tunnel A tunnel that starts at the mobile node's care-of address and Montenegro Expires July 5, 1996 [Page 2] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 terminates at the home agent. Pop-up A mobile node whose care-of address is an address associated to one of its own interfaces. This address may be a temporary address acquired dynamically (e.g. by means of DHCP or PPP's IPCP), or through manual intervention. It may also be a permanent address assigned to one of the mobile node's interfaces (e.g. a permanent PPP address). Since pop-ups do not require a separate foreign agent, they can operate in foreign nets that lack Mobile IP support. 1.2. Assumptions The bi-directional tunnels considered here are symmetric, that is, the reverse tunnel uses the same configuration (encapsulation method, IP address endpoints) as the forward tunnel. IP in IP encapsulation [2] is assumed unless stated otherwise. Route optimization [4] introduces forward tunnels initiated at a correspondent host. Since a mobile node cannot know if the correspondent host can decapsulate packets, bi-directional tunnels in this context are not discussed here. 1.3. Justification Given that it is easy to encapsulate packets, why not let the mobile node do the encapsulation itself? There are several reasons: a) It is only possible if the mobile node is in pop-up mode, but one of the primary objectives of the Mobile IP draft is to not *require* this mode of operation. NOTE: Strictly speaking, even in the separate foreign agent case, the mobile node could encapsulate packets and use the foreign agent's address (or some other topologically valid address) as the source address of the tunnel. However, this is an instance of IP spoofing, and as such is likely to create more problems than it solves (e.g. IP header identification field conflicts, mobile node authentication failures in the context of a home agent/foreign agent security association or raising security alarms). b) It complicates the mobile node implementation on some platforms, as it would probably require kernel code, whereas Montenegro Expires July 5, 1996 [Page 3] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 a pure mobile node implementation does not. c) The mobile node, perhaps a portable battery-operated device, is better served if it can offload this extra processing to the potentially more powerful foreign agent. 2. New Packet Formats Support for bi-directional tunnels on mobile nodes operating as pop-ups does not requires changing the Mobile Service Extension in agent advertisements, only the registration request and reply packets. On the other hand, if the mobile node's care-of address belongs to a separate foreign agent, bi-directional tunneling benefits from having the proper support in the agent advertisements as well. 2.1. Agent Advertisements: Mobile Service Extension 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|V|T| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | The only change to the Mobile Service Extension [1] is the additional 'T' bit: T Agent offers bi-directional tunneling. Using this information, an mobile node is able to choose a foreign agent that supports bi-directional tunnels. Notice that if a mobile node does not understand this bit, it will simply ignore it. 2.2. Registration Request Bi-directional tunneling support is added directly into the registration request by using one of the "rsvd" bits. Notice that if a foreign or home agent that does not support bi-directional tunnels receives a request with the 'T' bit set, the registration request fails. Foreign agents deny the request with status code 70, Montenegro Expires July 5, 1996 [Page 4] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 and home agents with status code 134. 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 |S|B|D|M|G|T|rsv| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- The only change to the Registration Request packet is the additional 'T' bit: T If the 'T' bit is set, the mobile node asks its home agent to use a bi-directional tunnel. 2.3. New Registration Reply Codes Foreign and home agent replies must convey if the bi-directional tunnel request failed. Two new reply codes are defined. Their use is preferred over code 70 for foreign agents and code 134 for home agents: Service denied by the foreign agent: 74 requested bi-directional tunnel unavailable and Service denied by the home agent: 137 requested bi-directional tunnel unavailable 3. Changes in Protocol Behavior Bi-directional tunnels must be handled appropriately by the different mobility entities. Differences in protocol behavior with Montenegro Expires July 5, 1996 [Page 5] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 respect to the Mobile IP specification are: 3.1. Mobile Node Considerations A mobile node sets the 'T' bit in its registration to request a bi-directional tunnel. Possible outcomes are: - The foreign agent returns a registration denial. Depending on the reply code and following the error checking guidelines in [1], the mobile node MAY try zeroing the 'T' bit and issuing a new registration. - The home agent returns a registration denial. Depending on the reply code and following the error checking guidelines in [1], the mobile node MAY try zeroing the 'T' bit and issuing a new registration. - The home agent returns a registration reply indicating that the service will be provided. In this last case, the mobile node has succeeded in establishing a bi-directional tunnel between its care-of address and its home agent. If the mobile node is operating as a pop-up, it SHOULD encapsulate all outgoing data such that the destination address of the outer header is the home agent. Not doing so does not necessarily preclude data transmission, but it defeats the purpose of the bi-directional tunnel. If the care-of address belongs to a separate foreign agent, the mobile node SHOULD designate it as its default router. Not doing so will not guarantee encapsulation of all the mobile node's outgoing traffic, and defeats the purpose of the bi-directional tunnel. 3.2. Foreign Agent Considerations A foreign agent that receives a registration reply with the 'T' bit set MAY either: - Return a registration reply denying the request. Valid return codes are: requested bi-directional tunnel unavailable (74) or poorly formed request (70). - Verify the packet according to [1] and then relay it to the home agent. Upon receipt of a Registration Reply that satisfies validity checks, it MUST update its visitor list, including indication that this Montenegro Expires July 5, 1996 [Page 6] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 mobile node has been granted a bi-directional tunnel. While this visitor list entry is in effect, any incoming traffic from the mobile node must be encapsulated and tunnelled from the care-of address to the home agent's address. 3.3. Home Agent Considerations A home agent that receives a registration request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1]. As a result, it determines if it can accomodate the forward tunnel request. As a last check, the home agent verifies that it can support a reverse tunnel with the same configuration. If it can, the home agent sends back a registration reply with code 0 or 1. A registration denial should send back code 137 or 134. After a successful registration, the home agent will receive encapsulated packets addressed to it. For each such packet it must search for a mobility binding whose care-of address is the source of the outer header, and whose mobile node address is the source of the inner header. The home agent MUST decapsulate, recover the original packet, and then forward it on behalf of its sender (the mobile node) to the destination address (the correspondent host). 4. Security Considerations The extensions outlined in this document are subject to the security considerations outlined in the Mobile IP specification [1]. Essentialy, creation of both forward and reverse tunnels involves an authentication procedure, which reduces the risk for attack. However, once the tunnel is set up, a malicious user could hijack it to inject packets into the network. Reverse tunnels might exacerbate this problem, because upon reaching the end of the tunnel packets are forwarded beyond the local network. References [1] C. Perkins. IP Mobility Support. Internet Draft -- work in progress, December 1995. [2] C. Perkins. IP Encapsulation within IP. Internet Draft -- Montenegro Expires July 5, 1996 [Page 7] INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996 work in progress, October 1995. [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP -- work in progress, November 1995. Author's Address Gabriel E. Montenegro Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMPK14-305 Mountain View, California 94043-1100 Tel: (415)786-6288 Fax: (415)786-6445 gabriel.montenegro@Eng.Sun.COM Montenegro Expires July 5, 1996 [Page 8]