Internet Engineering Task Force G. Montenegro INTERNET DRAFT Sun Microsystems, Inc. February 12, 1997 Reverse Tunneling for Mobile IP draft-ietf-mobileip-tunnel-reverse-01.txt Status of This Memo This document is a submission by the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 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 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign net, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. Montenegro Expires August 12, 1997 [Page 1] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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 IAB [8] and CERT [3] advisories to this effect, 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 reverse tunnels. Mobile IP does dictate the use of reverse 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 reverse tunnels regardless of their topological correctness: - Mobile routers: reverse tunnels obviate the need for recursive tunneling [1]. - Multicast: reverse 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 August 12, 1997 [Page 2] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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). 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 necessary to process any authentication [6] or encryption [7] headers which may have been added to the tunneled packets. The reverse tunnels considered here are symmetric, that is, they use 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, reverse tunnels in that context are not discussed here. Montenegro Expires August 12, 1997 [Page 3] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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 care-of 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. 2. Overview A light-weight mobile node arrives at a foreign net, listens for advertisements and selects a foreign agent that supports reverse tunnels. It requests this service when it registers through the selected foreign agent. At this time, and depending on how the mobile node wishes to deliver packets to the foreign agent, it also requests either the lightweight or the encapsulating style of delivery (section 5). In the lightweight delivery style, the mobile node designates the foreign agent as its default router and proceeds to send packets as usual. The foreign agent intercepts them, and tunnels them to the home agent. In the encapsulating delivery style, the mobile node encapsulates all its outgoing packets to the foreign agent. The foreign agent decapsulates and tunnels again, this time, directly to the home agent. 3. New Packet Formats 3.1. Agent Advertisements: Mobile Service Extension Montenegro Expires August 12, 1997 [Page 4] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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 reverse tunneling service. A foreign agent that sets the 'T' bit MUST support the two delivery styles currently supported (section 5). Using this information, a mobile node is able to choose a foreign agent that supports reverse tunnels. Notice that if a mobile node does not understand this bit, it simply ignores it. 3.2. Registration Request Reverse 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 reverse tunnels receives a request with the 'T' bit set, the Registration Request fails. This results in a registration denial (failure codes are specified in section 3.4). Most home agents would not object to providing reverse 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 reverse 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. Montenegro Expires August 12, 1997 [Page 5] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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|V|T|-| 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 accept a reverse tunnel from the care-of address. Lightweight mobile nodes ask the foreign agent to reverse-tunnel its packets. 3.3. Reverse Tunnel Extension The Reverse Tunnel Extension is used to further specify reverse tunneling behavior. Currently, it is only possible to request the encapsulating style of delivery, but future behavior may be defined. The Reverse Tunnel Extension MUST NOT be included if the 'T' bit is not set in the Registration Request. If this extension is absent, or if no style is explicitly requested, Lightweight Delivery is assumed. Besides the latter, currently only the Encapsulating style is defined (section 5). Montenegro Expires August 12, 1997 [Page 6] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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 |E| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 128 Length 2 E Encapsulating style of delivery. Encapsulation is done according to what was negotiated for the forward tunnel (i.e., IP in IP is assumed unless specified otherwise). reserved Ignored upon reception. Must be set to zero when transmitting. 3.4. New Registration Reply Codes Foreign and home agent replies MUST convey if the reverse tunnel request failed. Four new reply codes are defined. The use of codes 74 and 137 is preferred over code 70 for foreign agents and code 134 for home agents [1]: Service denied by the foreign agent: 74 requested reverse tunnel unavailable 75 reverse tunnel is mandatory and 'T' bit not set and Service denied by the home agent: 137 requested reverse tunnel unavailable 138 reverse tunnel is mandatory and 'T' bit not set Forward and reverse tunnels are symmetric, i.e. both are able to use the same tunneling options negotiated at registration. This implies that the home agent MUST deny registrations if an unsupported tunneling form is requested: 139 requested encapsulation unavailable Notice that Mobile IP [1] already defines the analogous failure code 72 for use by the foreign agent. Montenegro Expires August 12, 1997 [Page 7] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 4. Changes in Protocol Behavior Reverse tunnels must be handled appropriately by the different mobility entities. Differences in protocol behavior with respect to the Mobile IP specification are: 4.1. Mobile Node Considerations In addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel. It may optionally include a Reverse Tunnel Extension. Possible outcomes are: - Either the home agent or the foreign agent returns a registration denial: a. The mobile node follows the error checking guidelines in [1], and depending on the reply code, MAY try modifying the registration request (for example by eliminating the request for alternate forms of encapsulation), and issuing a new registration. b. Depending on the reply code, the mobile node MAY try zeroing the 'T' bit, eliminating the Reverse Tunnel Extension (if one was present), 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 reverse tunnel between its care-of address and its home agent. If the mobile node is operating with a co-located care-of address, it MUST 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 reverse tunnel. If the care-of address belongs to a separate foreign agent, the mobile node MUST employ whatever delivery style was requested (lightweight or encapsulated) and proceed as specified in section 5. A successful registration reply is an assurance that both the foreign agent and the home agent support whatever alternate forms of encapsulation (other than IP in IP) were requested. Accordingly, the Montenegro Expires August 12, 1997 [Page 8] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 mobile node MAY use them at its discretion. 4.2. Foreign Agent Considerations A foreign agent that receives a Registration Request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1], and determines if it can accomodate the forward tunnel request. If it cannot, it returns an appropriate code. In particular, if the foreign agent is unable to support the requested form of encapsulation, code 72 MUST be returned. As a last check, the foreign agent verifies that it can support a reverse tunnel with the same configuration. If it cannot, it MUST return a Registration Reply denying the request. Valid return codes are 74 (requested reverse tunnel unavailable) or 70 (poorly formed request). Code 74 is preferred. Otherwise, the foreign agent must relay the Registration Request 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 reverse tunnel and the delivery style expected (section 5). While this visitor list entry is in effect, the foreign agent MUST process incoming traffic according to the delivery style, encapsulate it and tunnel it from the care-of address to the home agent's address. 4.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]. and determines if it can accomodate the forward tunnel request. If it cannot, it returns an appropriate code. In particular, if the home agent is unable to support the requested form of encapsulation, code 139 MUST be returned. 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 reverse tunnel unavailable) or 134 (poorly formed Request). Code 137 is preferred. Montenegro Expires August 12, 1997 [Page 9] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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). 5. Mobile Node to Foreign Agent Delivery Styles This section specifies how the mobile node sends its data traffic via the foreign agent. In all cases, the mobile node learns the foreign agent's link-layer address from the link-layer header in the agent advertisement. 5.1. Lightweight Delivery Style This delivery mechanism is very simple to implement, and uses small (non-encapsulated) packets on the link between the mobile node and the foreign agent (potentially a very slow link). However, it only supports reverse-tunneling of unicast packets. 5.1.1. Packet Processing The mobile node MUST designate the foreign agent 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 reverse tunnel. The foreign agent MUST: - detect packets sent by the mobile node, and - modify its forwarding function to re-encapsulate them before forwarding. 5.1.2. Packet Header Format and Fields This section shows the format of the packet headers used by the Lightweight Delivery style. Montenegro Expires August 12, 1997 [Page 10] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 Packet format received by the foreign agent (lightweight delivery): Data Link fields: Source Address = mobile node's link-layer address Destination Address = foreign agent's link-layer address IP fields: Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol Packet format forwarded by the foreign agent (lightweight delivery): Data Link fields: Source Address = foreign agent's link-layer address Destination Address = next hop router's link-layer address IP fields (encapsulating header): Source Address = foreign agent's address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol These fields of the encapsulating header MUST be chosen in accordance with section 3.7.2.2 of Mobile IP [1]: IP Source Address The foreign agent's address on the interface from which the message will be sent. IP Destination Address Copied from the Home Agent field within the Registration Request. IP Protocol Field Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time. 5.2. Encapsulating Delivery Style This mechanism requires that the mobile node implement encapsulation, and explicitly directs packets at the foreign agent by designating it as the destination address in a new outermost Montenegro Expires August 12, 1997 [Page 11] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 header. Mobile nodes that wish to send either broadcast or multicast packets MUST use encapsulating delivery. 5.2.1 Packet Processing The foreign agent does not modify its forwarding function. Rather, it receives an encapsulated packet and after verifying that it was sent by the mobile node, it MUST: - recover the inner packet, - re-encapsulate it, and send it to the home agent. If the foreign agent expects encapsulating delivery, it MUST NOT reverse tunnel unencapsulated packets from the mobile node. 5.2.2. Packet Header Format and Fields This section shows the format of the packet headers used by the Encapsulating Delivery style. Packet format received by the foreign agent (encapsulated delivery): Data Link fields: Source Address = mobile node's link-layer address Destination Address = foreign agent's link-layer address IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = foreign agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol The fields of the encapsulating IP header MUST be chosen as follows: IP Source Address The mobile node's home address. Montenegro Expires August 12, 1997 [Page 12] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 IP Destination Address The address of the agent as learned from the IP source address of the agent's most recent registration reply. IP Protocol Field Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time. Packet format forwarded by the foreign agent (encapsulated delivery): Data Link fields: Source Address = foreign agent's link-layer address Destination Address = next hop router's link-layer address IP fields (encapsulating header): Source Address = foreign agent's address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol These fields of the encapsulating IP header MUST be chosen in accordance with section 3.7.2.2 of Mobile IP [1]: IP Source Address The foreign agent's address on the interface from which the message will be sent. IP Destination Address Copied from the Home Agent field within the Registration Request. IP Protocol Field Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time. 5.3. Support for Broadcast and Multicast Datagrams If a mobile node is operating with a co-located care-of address, broadcast and multicast datagrams are handled according to Sections 4.3 and 4.4 of the Mobile IP specification [1]. Light-weight mobile Montenegro Expires August 12, 1997 [Page 13] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 nodes MAY have their broadcast and multicast datagrams reverse-tunneled by the foreign agent. However, any mobile nodes doing so MUST use of the encapsulating delivery style. This delivers the datagram only to the foreign agent. The latter decapsulates it and then processes it as any other packet from the mobile node, namely, by reverse tunneling it to the home agent. 5.4. Selective Reverse Tunneling Packets destined to local resources (e.g. a nearby printer) may be unaffected by ingress filtering. A mobile node with a co-located care-of address MAY optimize delivery of these packets by not reverse tunneling them. On the other hand, a lightweight mobile node MAY use this selective reverse tunneling capability by requesting the encapsulating delivery style, and following these guidelines: Packets meant to be reversed tunneled: Sent using the Lightweight Delivery style. The foreign agent MUST process these packets as regular traffic: they MAY be forwarded but MUST NOT be reverse tunneled to the home agent. Packets NOT meant to be reverse tunneled: Sent using the Encapsulating Delivery style. The foreign agent MUST process these packets as specified in section 5.2: they MUST be reverse tunneled to the home agent. 6. 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 reverse tunnels for certain applications. There has been some concern regarding the long-term effectiveness of reverse-tunneling in the presence of ingress filtering. The Montenegro Expires August 12, 1997 [Page 14] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 conjecture is that network administrators will target reverse-tunneled packets (IP in IP encapsulated packets) for filtering. The ingress filtering recommendation spells out why this is not the case [8]: Tracking the source of an attack is simplified when the source is more likely to be "valid." 7. Acknowledgements The encapsulating style of delivery was proposed by Charlie Perkins. References [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 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, draft-ietf-mobileip-optim-05.txt, November 1996. [5] Manuel Rodriguez, private communication, August 1995. [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, August 1995. [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending Against IP Source Address Spoofing -- work in progress, draft-ferguson-ingress-filtering-01.txt, February 1996 Author's Address Montenegro Expires August 12, 1997 [Page 15] INTERNET DRAFT Reverse Tunneling for Mobile IP February 1997 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 gab@eng.sun.com Montenegro Expires August 12, 1997 [Page 16]