Internet Engineering Task Force G. Montenegro INTERNET DRAFT Sun Microsystems, Inc. September 6, 1996 Bi-directional Tunneling for Mobile IP draft-montenegro-tunneling-01.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 rarely in the reverse direction. Usually, a mobile node sends its packets through a router in the foreign net, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish topologically correct 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 topologically correct bi-directional tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's Montenegro Expires March 11, 1997 [Page 1] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 care-of address. 1. Introduction Section 1.3 of the Mobile IP specification [1] lists the following assumption: 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 that break this assumption are increasingly more common. In the presence of such routers, the source and destination IP address in a packet must be topologically correct. The forward tunnel complies with this, as its endpoints (home agent address and care-of address) are properly assigned addresses for their respective locations. On the other hand, the source IP address of a packet transmitted by the mobile node does not correspond to the location from where it emanates. This document discusses topologically correct bi-directional tunnels. Mobile IP does dictate the use of bi-directional tunnels in the context of multicast datagram routing and mobile routers. However, the source IP address is set to the mobile node's home address, so these tunnels are not topologically correct. Notice that there are several uses for bi-directional tunnels regardless of their topological correctness: - Mobile routers: bi-directional tunnels obviate the need for recursive tunneling [1]. - Multicast: bi-directional tunnels enable a mobile node away from home to (1) join multicast groups in its home network, and (2) transmit multicast packets such that they emanate from its home network [1]. - The TTL of packets sent by the mobile node (particularly when it addresses other hosts in its home network) may be so low that they may expire before reaching their destination. A reverse tunnel solves the problem as it represents a TTL decrement of one [5]. Montenegro Expires March 11, 1997 [Page 2] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 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 terminates at the home agent. Light-weight mobile node A mobile node that relies on a separate foreign agent for tunneling services (i.e. the care-of address belongs to the foreign agent). Such a mobile node cannot operate with a care-of address associated to one of its own interfaces. 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 Mobility is constrained to one IP address space (e.g. the routing fabric between, say, the mobile node and the home agent is not partitioned into a "private" and a "public" network). This document does not attempt to solve the firewall traversal problem. Rather, it assumes one of the following is true: - There are no intervening firewalls along the path of the tunneled packets. - Any intervening firewalls share the security association Montenegro Expires March 11, 1997 [Page 3] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 necessary to process any authentication [6] or encryption [7] headers which may have been added to the tunneled packets. 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 that context are not discussed here. 1.3. Justification Why not let the mobile node itself initiate the tunnel to the home agent? This is indeed what it should do if it is already operating with a topologically significant co-located address. However, one of the primary objectives of the Mobile IP specification is to not *require* this mode of operation. The mechanisms outlined in this document are primarily intended for use by mobile nodes that rely on the foreign agent for forward tunnel support. It is desirable to continue supporting these "lightweight" mobile nodes, even in the presence of filtering routers. 1.4. Overview A light-weight mobile node arrives at a foreign net, listens for advertisements and selects a foreign agent that supports bi-directional tunnels. It requests this service when it registers through the selected foreign agent. Upon a successful registration, the mobile node designates the foreign agent as its default router. The latter is now able to intercept all outgoing traffic from the mobile node, and tunnel it to the home agent. DISCUSSION: An alternative suggested by Charlie Perkins is for the mobile node to encapsulate all its outgoing packets to the foreign agent. The foreign agent decapsulates and tunnels again, this time, directly to the home agent. This scheme might improve cpu Montenegro Expires March 11, 1997 [Page 4] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 usage time at the foreign agent, at the expense of processing time at the mobile node and additional use of bandwidth (larger packets on the potentially slow link between the mobile node and the foreign agent). 2. New Packet Formats Support for bi-directional tunnels on mobile nodes operating as pop-ups does not require changing the Mobile Service Extension in agent advertisements, only the Registration Request and reply packets. On the other hand, light-weight mobile nodes that use bi-directional tunnels benefit 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, a 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 simply ignores it. 2.2. Registration Request Bi-directional tunneling support is added directly into the Registration Request by using one of the "rsvd" bits. 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, and home agents with status code 134. Montenegro Expires March 11, 1997 [Page 5] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 Most home agents would not object to providing bi-directional tunnel support, because they "SHOULD be able to decapsulate and further deliver packets addressed to themselves, sent by a mobile node" [1]. In the case of topologically correct bi-directional tunnels, the packets are not sent by the mobile node as distinguished by its home address. Rather, the outermost (encapsulating) IP source address on such datagrams is the care-of address of the mobile node. Nevertheless, home agents probably already support the required decapsulation and further forwarding. 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 to the care-of address. 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 Montenegro Expires March 11, 1997 [Page 6] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 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 respect to the Mobile IP specification are: 3.1. Mobile Node Considerations A mobile node sets the 'T' bit in its Registration Request to petition 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 Request with the 'T' bit set MAY either: Montenegro Expires March 11, 1997 [Page 7] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 - Return a Registration Reply denying the request. Valid return codes are 74 (requested bi-directional tunnel unavailable) or 70 (poorly formed request). Code 74 is preferred. - 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 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 tunneled 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 (requested bi-directional tunnel unavailable) or 134 (poorly formed Request). Code 137 is preferred. After a successful registration, the home agent will receive encapsulated packets addressed to it. For each such packet it MAY 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. Support for Broadcast and Multicast Datagrams If a mobile node is operating in pop-up mode, broadcast and multicast datagrams are handled according to Sections 4.3 and 4.4 of the Mobile IP specification [1]. Light-weight mobile nodes MAY have their broadcast and multicast datagrams reverse-tunneled by the foreign agent. However, this requires special handling. The mobile node composes a broadcast or multicast datagram as if it were meant Montenegro Expires March 11, 1997 [Page 8] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 for local delivery, with the following exception:. - The link-layer destination address is set to the foreign agent's link-layer unicast address. Notice that this mechanism is also used in Section 3.6.1.1 of the Mobile IP specification [1]. This delivers the datagram only to the foreign agent. The latter then processes it as any other packet from the mobile node, namely, by reverse tunneling it to the home agent. 5. 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 tunnel exit point packets are forwarded beyond the local network. This concern is also present in the Mobile IP specification, as it already dictates the use of bi-directional tunnels for certain applications. References [1] C. Perkins. IP Mobility Support. Internet Draft -- work in progress, May 1996. [2] C. Perkins. IP Encapsulation within IP. Internet Draft -- work in progress, May 1996. [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, February 1996 [5] Manuel Rodriguez, private communication, August 1995. [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. Montenegro Expires March 11, 1997 [Page 9] INTERNET DRAFT Bi-directional Tunneling for Mobile IP September 1996 [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, August 1995. Author's Address Gabriel E. Montenegro Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMPK 15-214 Mountain View, California 94043-1100 Tel: (415)786-6288 Fax: (415)786-6445 gabriel.montenegro@Eng.Sun.COM Montenegro Expires March 11, 1997 [Page 10]