diff options
Diffstat (limited to 'doc/rfc/rfc2344.txt')
| -rw-r--r-- | doc/rfc/rfc2344.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc2344.txt b/doc/rfc/rfc2344.txt new file mode 100644 index 0000000..158d9ff --- /dev/null +++ b/doc/rfc/rfc2344.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group G. Montenegro, Editor +Request for Comments: 2344 Sun Microsystems, Inc. +Category: Standards Track May 1998 + + + Reverse Tunneling for Mobile IP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +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 + network, 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. + +Table of Contents + + 1. Introduction ................................................ 2 + 1.1. Terminology ............................................... 3 + 1.2. Assumptions ............................................... 4 + 1.3. Justification ............................................. 4 + 2. Overview .................................................... 4 + 3. New Packet Formats .......................................... 5 + 3.1. Mobility Agent Advertisement Extension .................... 5 + 3.2. Registration Request ...................................... 5 + 3.3. Encapsulating Delivery Style Extension .................... 6 + 3.4. New Registration Reply Codes .............................. 7 + 4. Changes in Protocol Behavior ................................ 8 + 4.1. Mobile Node Considerations ................................ 8 + + + +Montenegro Standards Track [Page 1] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + 4.1.1. Sending Registration Requests to the Foreign Agent ...... 8 + 4.1.2. Receiving Registration Replies from the Foreign Agent ... 9 + 4.2. Foreign Agent Considerations .............................. 9 + 4.2.1. Receiving Registration Requests from the Mobile Node ... 10 + 4.2.2. Relaying Registration Requests to the Home Agent ....... 10 + 4.3. Home Agent Considerations ................................ 10 + 4.3.1. Receiving Registration Requests from the Foreign Agent . 11 + 4.3.2. Sending Registration Replies to the Foreign Agent ...... 11 + 5. Mobile Node to Foreign Agent Delivery Styles ............... 12 + 5.1. Direct Delivery Style .................................... 12 + 5.1.1. Packet Processing ...................................... 12 + 5.1.2. Packet Header Format and Fields ........................ 12 + 5.2. Encapsulating Delivery Style ............................. 13 + 5.2.1 Packet Processing ....................................... 13 + 5.2.2. Packet Header Format and Fields ........................ 14 + 5.3. Support for Broadcast and Multicast Datagrams ............ 15 + 5.4. Selective Reverse Tunneling .............................. 15 + 6. Security Considerations .................................... 16 + 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ... 16 + 6.2. Ingress Filtering ........................................ 17 + 7. Acknowledgements ........................................... 17 + References .................................................... 17 + Editor and Chair Addresses .................................... 18 + Full Copyright Statement ...................................... 19 + +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 (for example, IP spoofing attacks), and + in accordance with RFC 2267 [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 network + prefix from where it emanates. + + This document discusses topologically correct reverse tunnels. + + + +Montenegro Standards Track [Page 2] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + 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 (for example, when + sending packets to other hosts in its home network) may be so + low that they might expire before reaching their destination. A + reverse tunnel solves the problem as it represents a TTL + decrement of one [5]. + +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. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [9]. + + + + + + + + + + +Montenegro Standards Track [Page 3] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +1.2. Assumptions + + Mobility is constrained to a common IP address space (that is, 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 may not know if the + correspondent host can decapsulate packets, reverse 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 correct co-located care-of address. + + However, one of the primary objectives of the Mobile IP specification + is not to 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 mobile nodes, + even in the presence of filtering routers. + +2. Overview + + A mobile node arrives at a foreign network, listens for agent + 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 + + + + + +Montenegro Standards Track [Page 4] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + mobile node wishes to deliver packets to the foreign agent, it also + requests either the Direct or the Encapsulating Delivery Style + (section 5). + + In the Direct Delivery Style, the mobile node designates the foreign + agent as its default router and proceeds to send packets directly to + the foreign agent, that is, without encapsulation. 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 re-tunnels them to the home agent, using the foreign + agent's care-of address as the entry-point of this new tunnel. + +3. New Packet Formats + +3.1. Mobility Agent Advertisement 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 Mobility Agent Advertisement 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: Direct and Encapsulating Delivery Style + (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 as per [1]. + +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). + + + +Montenegro Standards Track [Page 5] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + 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. + + In Registration Requests sent by a mobile node, the Time to Live + field in the IP header MUST be set to 255. This limits a denial of + service attack in which malicious hosts send false Registration + Requests (see Section 6). + + 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. Mobile nodes using a foreign agent care-of + address ask the foreign agent to reverse-tunnel its + packets. + +3.3. Encapsulating Delivery Style Extension + + The Encapsulating Delivery Style Extension MAY be included by the + mobile node in registration requests to further specify reverse + tunneling behavior. It is expected to be used only by the foreign + agent. Accordingly, the foreign agent MUST consume this extension + (that is, it must not relay it to the home agent or include it in + + + +Montenegro Standards Track [Page 6] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + replies to the mobile node). As per Section 3.6.1.3 of [1], the + mobile node MUST include the Encapsulating Delivery Style Extension + after the Mobile-Home Authentication Extension, and before the + Mobile-Foreign Authentication Extension, if present. + + The Encapsulating Delivery Style Extension MUST NOT be included if + the 'T' bit is not set in the Registration Request. + + If this extension is absent, Direct Delivery is assumed. + Encapsulation is done according to what was negotiated for the + forward tunnel (that is, IP in IP is assumed unless specified + otherwise). For more details on the delivery styles, please refer to + section 5. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 130 + + Length + + 0 + +3.4. New Registration Reply Codes + + Foreign and home agent registration replies MUST convey if the + reverse tunnel request failed. These new reply codes are defined: + + Service denied by the foreign agent: + + 74 requested reverse tunnel unavailable + 75 reverse tunnel is mandatory and 'T' bit not set + 76 mobile node too distant + + and + + Service denied by the home agent: + + 137 requested reverse tunnel unavailable + 138 reverse tunnel is mandatory and 'T' bit not set + 139 requested encapsulation unavailable + + + + + +Montenegro Standards Track [Page 7] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + In response to a Registration Request with the 'T' bit set, mobile + nodes may receive (and MUST accept) code 70 (poorly formed request) + from foreign agents and code 134 (poorly formed request) from home + agents. However, foreign and home agents that support reverse + tunneling MUST use codes 74 and 137, respectively. + + Absence of the 'T' bit in a Registration Request MAY elicit denials + with codes 75 and 138 at the foreign agent and the home agent, + respectively. + + Forward and reverse tunnels are symmetric, that is, both are able to + use the same tunneling options negotiated at registration. This + implies that the home agent MUST deny registrations if an unsupported + form of tunneling is requested (code 139). Notice that Mobile IP [1] + already defines the analogous failure code 72 for use by the foreign + agent. + +4. Changes in Protocol Behavior + + Unless otherwise specified, behavior specified by Mobile IP [1] is + assumed. In particular, if any two entities share a mobility security + association, they MUST use the appropriate Authentication Extension + (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication + Extension) when exchanging registration protocol datagrams. The + Mobile-Home Authentication Extension MUST always be present. + + Reverse tunneling imposes additional protocol processing requirements + on mobile entities. Differences in protocol behavior with respect to + Mobile IP [1] are specified in the subsequent sections. + +4.1. Mobile Node Considerations + + This section describes how the mobile node handles registrations that + request a reverse tunnel. + +4.1.1. Sending Registration Requests to the Foreign Agent + + In addition to the considerations in [1], a mobile node sets the 'T' + bit in its Registration Request to petition a reverse tunnel. + + The mobile node MUST set the TTL field of the IP header to 255. This + is meant to limit the reverse tunnel hijacking attack (Section 6). + + The mobile node MAY optionally include an Encapsulating Delivery + Style Extension. + + + + + + +Montenegro Standards Track [Page 8] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +4.1.2. Receiving Registration Replies from the Foreign Agent + + Possible valid responses are: + + - A registration denial issued by either the home agent or the + foreign agent: + + 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 Encapsulating Delivery + Style Extension (if one was present), and issuing a new + registration. Notice that after doing so the registration + may succeed, but due to the lack of a reverse tunnel data + transfer may not be possible. + + - 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 + MAY encapsulate outgoing data such that the destination address of + the outer header is the home agent. This ability to selectively + reverse-tunnel packets is discussed further in section 5.4. + + If the care-of address belongs to a separate foreign agent, the + mobile node MUST employ whatever delivery style was requested (Direct + or Encapsulating) 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 + mobile node MAY use them at its discretion. + +4.2. Foreign Agent Considerations + + This section describes how the foreign agent handles registrations + that request a reverse tunnel. + + + + + + + + +Montenegro Standards Track [Page 9] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +4.2.1. Receiving Registration Requests from the Mobile Node + + 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 whether 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 it MUST return code 72. + + The foreign agent MAY reject Registration Requests without the 'T' + bit set by denying them with code 75 (reverse tunnel is mandatory and + 'T' bit not set). + + The foreign agent MUST verify that the TTL field of the IP header is + set to 255. Otherwise, it MUST reject the registration with code 76 + (mobile node too distant). The foreign agent MUST limit the rate at + which it sends these registration replies to a maximum of one per + second. + + 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 with code 74 + (requested reverse tunnel unavailable). + +4.2.2. Relaying Registration Requests to the Home Agent + + Otherwise, the foreign agent MUST relay the Registration Request to + the home agent. + + Upon receipt of a Registration Reply that satisfies validity checks, + the foreign agent 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 + + This section describes how the home agent handles registrations that + request a reverse tunnel. + + + + + + + + +Montenegro Standards Track [Page 10] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +4.3.1. Receiving Registration Requests from the Foreign Agent + + 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 whether 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 it MUST return code 139 (requested encapsulation + unavailable). + + The home agent MAY reject registration requests without the 'T' bit + set by denying them with code 138 (reverse tunnel is mandatory and ' + T' bit not set). + + As a last check, the home agent determines whether it can support a + reverse tunnel with the same configuration as the forward tunnel. If + it cannot, it MUST send back a registration denial with code 137 + (requested reverse tunnel unavailable). + + Upon receipt of a Registration Reply that satisfies validity checks, + the home agent MUST update its mobility bindings list to indicate + that this mobile node has been granted a reverse tunnel and the type + of encapsulation expected. + +4.3.2. Sending Registration Replies to the Foreign Agent + + In response to a valid Registration Request, a home agent MUST issue + a Registration Reply to the mobile node. + + After a successful registration, the home agent may receive + encapsulated packets addressed to itself. Decapsulating such packets + and blindly injecting them into the network is a potential security + weakness (section 6.1). Accordingly, the home agent MUST implement, + and, by default, SHOULD enable the following check for encapsulated + packets addressed to itself: + + The home agent searches 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. + + If no such binding is found, or if the packet uses an encapsulation + mechanism that was not negotiated at registration the home agent MUST + silently discard the packet and SHOULD log the event as a security + exception. + + Home agents that terminate tunnels unrelated to Mobile IP (for + example, multicast tunnels) MAY turn off the above check, but this + practice is discouraged for the aforementioned reasons. + + + +Montenegro Standards Track [Page 11] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + While the registration is in effect, a home agent MUST process each + valid reverse tunneled packet (as determined by checks like the + above) by decapsulating it, recovering the original packet, and then + forwarding 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. Direct Delivery Style + + This delivery mechanism is very simple to implement at the mobile + node, 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, and + does not allow selective reverse tunneling (section 5.4). + +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 encapsulate them before + forwarding. + +5.1.2. Packet Header Format and Fields + + This section shows the format of the packet headers used by the + Direct Delivery style. The formats shown assume IP in IP + encapsulation [2]. + + Packet format received by the foreign agent (Direct Delivery Style): + + 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 (Direct Delivery Style): + + + + +Montenegro Standards Track [Page 12] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + IP fields (encapsulating header): + Source Address = foreign agent's care-of 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 as follows: + + IP Source Address + + Copied from the Care-of Address field within the Registration + Request. + + 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 header. Mobile nodes + that wish to send either broadcast or multicast packets MUST use the + Encapsulating Delivery Style. + +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: + + - decapsulates to recover the inner packet, + + - re-encapsulates, and sends it to the home agent. + + If a foreign agent receives an un-encapsulated packet from a mobile + node which had explicitly requested the Encapsulated Delivery Style, + then the foreign agent MUST NOT reverse tunnel such a packet and + rather MUST forward it using standard, IP routing mechanisms. + + + +Montenegro Standards Track [Page 13] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +5.2.2. Packet Header Format and Fields + + This section shows the format of the packet headers used by the + Encapsulating Delivery style. The formats shown assume IP in IP + encapsulation [2]. + + Packet format received by the foreign agent (Encapsulating Delivery + Style): + + 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. + + 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 (Encapsulating Delivery + Style): + + IP fields (encapsulating header): + Source Address = foreign agent's care-of 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 as + follows: + + + +Montenegro Standards Track [Page 14] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + IP Source Address + + Copied from the Care-of Address field within the Registration + Request. + + 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]. Mobile nodes using a + foreign agent care-of address MAY have their broadcast and multicast + datagrams reverse-tunneled by the foreign agent. However, any mobile + nodes doing so MUST use 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 (for example, a nearby printer) + might 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 mobile node using a + foreign agent care-of address MAY use this selective reverse + tunneling capability by requesting the Encapsulating Delivery Style, + and following these guidelines: + + Packets NOT meant to be reversed tunneled: + + Sent using the Direct 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. + + + + + + + + +Montenegro Standards Track [Page 15] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + + Packets 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]. + Essentially, creation of both forward and reverse tunnels involves an + authentication procedure, which reduces the risk for attack. + +6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks + + Once the tunnel is set up, a malicious node 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. + + Unauthenticated exchanges involving the foreign agent allow a + malicious node to pose as a valid mobile node and re-direct an + existing reverse tunnel to another home agent, perhaps another + malicious node. The best way to protect against these attacks is by + employing the Mobile-Foreign and Foreign-Home Authentication + Extensions defined in [1]. + + If the necessary mobility security associations are not available, + this document introduces a mechanism to reduce the range and + effectiveness of the attacks. The mobile node MUST set to 255 the TTL + value in the IP headers of Registration Requests sent to the foreign + agent. This prevents malicious nodes more than one hop away from + posing as valid mobile nodes. Additional codes for use in + registration denials make those attacks that do occur easier to + track. + + With the goal of further reducing the attacks the Mobile IP Working + Group considered other mechanisms involving the use of + unauthenticated state. However, these introduce the possibilities of + denial-of-service attacks. The consensus was that this was too much + of a trade-off for mechanisms that guarantee no more than weak (non- + cryptographic) protection against attacks. + + + + + + + +Montenegro Standards Track [Page 16] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +6.2. Ingress Filtering + + There has been some concern regarding the long-term effectiveness of + reverse-tunneling in the presence of ingress filtering. The + 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. + Jim Solomon has been instrumental in shaping this document into its + present form. + +References + + [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. + + [2] Perkins, C., "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] Johnson, D., and C. Perkins, "Route Optimization in Mobile IP", + Work in Progress. + + [5] Manuel Rodriguez, private communication, August 1995. + + [6] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. + + [7] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, + August 1995. + + [8] Ferguson, P., and D. Senie, "Network Ingress Filtering: Defeating + Denial of Service Attacks which employ IP Source Address + Spoofing", RFC 2267, January 1998. + + [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + +Montenegro Standards Track [Page 17] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +Editor and Chair Addresses + + Questions about this document may be directed at: + + Gabriel E. Montenegro + Sun Microsystems, Inc. + 901 San Antonio Road + Mailstop UMPK 15-214 + Mountain View, California 94303 + + Voice: +1-415-786-6288 + Fax: +1-415-786-6445 + EMail: gabriel.montenegro@eng.sun.com + + The working group can be contacted via the current chairs: + + Jim Solomon + Motorola, Inc. + 1301 E. Algonquin Rd. - Rm 2240 + Schaumburg, IL 60196 + + Voice: +1-847-576-2753 + Fax: +1-847-576-3240 + EMail: solomon@comm.mot.com + + + Erik Nordmark + Sun Microsystems, Inc. + 901 San Antonio Road + Mailstop UMPK17-202 + Mountain View, California 94303 + + Voice: +1-415-786-5166 + EMail: erik.nordmark@eng.sun.com + + + + + + + + + + + + + + + + + +Montenegro Standards Track [Page 18] + +RFC 2344 Reverse Tunneling for Mobile IP May 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Montenegro Standards Track [Page 19] + |