Internet Engineering Task Force H. Levkowetz Internet-Draft ipUnplugged Expires: October 30, 2002 S. Vaarala Netseal May 2002 Mobile IP NAT/NAPT Traversal using UDP Tunnelling Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. Levkowetz & Vaarala Expires October 30, 2002 [Page 1] Internet-Draft NAT Traversal for MIP May 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Problem description . . . . . . . . . . . . . . . . . . . . 5 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 5 2. NAT Traversal Overview . . . . . . . . . . . . . . . . . . . 6 2.1 Basic Message Sequence . . . . . . . . . . . . . . . . . . . 6 3. New Message Formats . . . . . . . . . . . . . . . . . . . . 7 3.1 UDP Tunnel Request Extension . . . . . . . . . . . . . . . . 7 3.1.1 F (Force) Flag . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2 R (Registration through FA Required) flag . . . . . . . . . 9 3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.5 Mobile IP Registration Bits . . . . . . . . . . . . . . . . 9 3.2 UDP Tunnel Reply Extension . . . . . . . . . . . . . . . . . 10 3.2.1 Reply Code . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . . . 11 3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . . . 12 3.5 New Registration Reply Codes . . . . . . . . . . . . . . . . 13 4. Protocol Behaviour . . . . . . . . . . . . . . . . . . . . . 13 4.1 Relation to standard MIP tunnelling . . . . . . . . . . . . 13 4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . . . 14 4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Mobile Node Considerations . . . . . . . . . . . . . . . . . 15 4.5 Foreign Agent Considerations . . . . . . . . . . . . . . . . 17 4.6 Home Agent Considerations . . . . . . . . . . . . . . . . . 18 4.6.1 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 19 4.7 MIP signalling versus tunnelling . . . . . . . . . . . . . . 21 4.8 Packet fragmentation . . . . . . . . . . . . . . . . . . . . 21 4.9 Tunnel Keepalive . . . . . . . . . . . . . . . . . . . . . . 22 4.10 Co-located registration through FA . . . . . . . . . . . . . 23 5. Implementation Issues . . . . . . . . . . . . . . . . . . . 24 5.1 Movement Detection and Private Address Aliasing . . . . . . 24 5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . 25 6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . . . 26 6.1.1 Manipulation of the Registration Request Message . . . . . . 26 6.1.2 Sending a Bogus Keepalive Message . . . . . . . . . . . . . 26 6.2 Use of IPsec . . . . . . . . . . . . . . . . . . . . . . . . 27 6.3 Firewall Considerations . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 Levkowetz & Vaarala Expires October 30, 2002 [Page 2] Internet-Draft NAT Traversal for MIP May 2002 8. Intellectual property rights . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 Normative References . . . . . . . . . . . . . . . . . . . . 29 Informative References . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 Levkowetz & Vaarala Expires October 30, 2002 [Page 3] Internet-Draft NAT Traversal for MIP May 2002 1. Introduction 1.1 Terminology The Mobile IP related terminology described in RFC 3220 [10] is used in this document. In addition, the following terms are used: Forward Tunnel A tunnel that forwards 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. NAT Network Address Translation. "Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network." -- RFC 2663 [12]. Basic NAT and NAPT are two varieties of NAT. Basic NAT "With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated." -- RFC 2663 [12] NAPT Network Address Port Translation. "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation." -- RFC 2663 [12] In this document, the more general term NAT is used to cover both NATs and NAPTs. In most deployment cases today, we believe that the Levkowetz & Vaarala Expires October 30, 2002 [Page 4] Internet-Draft NAT Traversal for MIP May 2002 NATs used are of the NAPT variety. 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 [7]. 1.2 Problem description A basic assumption that Mobile IP [10] makes is that mobile nodes and foreign agents are uniquely identifiable by a routable IP address. This assumption breaks down when a mobile node attempts to communicate from behind a NAT. Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes which communicate from behind a NAT are reachable only through the NAT's public address(es). IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent which resides behind the NAT. For this reason, IP-in-IP tunnels cannot in general pass through a NAT, and Mobile IP will not work across a NAT. Mobile IP's Registration Request and Reply will on the other hand be able to pass through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP datagrams originated from the inside of the NAT or NAPT. When passing out, they make the NAT set up an address/port mapping through which the Registration Request will be able to pass in to the correct recipient. The current Mobile IP protocol does however not permit a registration where the mobile node's IP source address is not either the CoA, the Home Address, or 0.0.0.0. What is needed is an alternative data tunnelling mechanism for Mobile IP which will provide the means needed for NAT devices to do unique mappings so that address translation will work, and a registration mechanism which will permit such an alternative tunnelling mechanism to be set up when appropriate. 1.3 Assumptions The primary assumption in this document is that the network allows communication between an UDP port chosen by the mobile node and the home agent UDP port 434. If this assumption does not hold, neither Mobile IP registration nor data tunnelling will work. This document does NOT assume that mobility is constrained to a common IP address space. On the contrary, the routing fabric between Levkowetz & Vaarala Expires October 30, 2002 [Page 5] Internet-Draft NAT Traversal for MIP May 2002 the mobile node and the home agent may be partitioned into a "private" and a "public" network, and the assumption is that some mechanism is needed in addition to vanilla Mobile IP according to RFC 3220 [10] in order to achieve mobility within disparate IP address spaces. For a more extensive discussion of the problems with disparate address spaces, and how they may be solved, see RFC 3024 [9]. The reverse tunnels considered here are symmetric, that is, they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel. 2. NAT Traversal Overview This section gives a brief overview of the MIP UDP tunnelling mechanism which may be used to achieve NAT traversal for Mobile IP. In MIP UDP tunnelling, the mobile node may use an extension (described below) in its Registration Request to indicate that it is able to use Mobile IP UDP tunnelling instead of standard Mobile IP tunnelling if the home agent sees that the Registration Request seems to have passed through a NAT. The home agent may then send a registration reply with an extension indicating acceptance (or denial). After assent from the home agent, MIP UDP tunnelling will be available for use for both forward and reverse tunnelling. UDP tunnelled packets sent by the mobile node use the same ports as the registration request message. In particular, the source port may vary between new registrations, but remains the same for all tunnelled data and re-registrations. The destination port is always 434. UDP tunnelled packets sent by the home agent uses the same ports, but in reverse. 2.1 Basic Message Sequence The message sequence diagram below exemplifies setting up and using a Mobile IP UDP tunnel as described in this document. The tunnel is set up by the use of specific extensions in the initial Mobile IP Registration Request and Reply exchange. Thereafter, any traffic from the home agent to the mobile node is sent through the UDP tunnel. The mobile node may at its discretion use the UDP tunnel for reverse tunnelling or not, although in most cases where MIP UDP tunnelling is needed, reverse tunnelling will also be needed. Levkowetz & Vaarala Expires October 30, 2002 [Page 6] Internet-Draft NAT Traversal for MIP May 2002 mobile node NAT home agent | | | | | | | Registration | | | Request with | | |-----------------///--------------->>| |UDP Tunnel Request| | | | + | | || IP Source and | | || CCoA address | | || discrepancy | | || seen | | Registration + | | Reply with | |<<---------------///-----------------| | | UDP Tunnel Reply.| | | | | UDP tunnelled pkg| | |=================///===============>>| | | UDP tunnelled pkg| |<<===============///=================| | | ||absence of | | ||traffic for | | ||UDP keepalive | UDP keepalive | ||period |-----------------///--------------->>+ . . + . . . . . . 3. New Message Formats 3.1 UDP Tunnel Request Extension This extension is a skippable Extension. It signifies that the sender is capable of handling MIP UDP tunnelling, and optionally that a particular encapsulation format is requested in the MIP UDP tunnel. The format of this extension is as shown below. It adheres to the short extension format described in [10]. 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 | Sub-Type | Reserved 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| Reserved 2| Encapsulation | Reserved 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Levkowetz & Vaarala Expires October 30, 2002 [Page 7] Internet-Draft NAT Traversal for MIP May 2002 Type (to be assigned by IANA) (skippable). Length 6. Length in bytes of this extension, not including the Type and Length bytes. Sub-Type (to be assigned by IANA) Reserved 1 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. F F (Force) flag. Indicates that the mobile node wants to force MIP UDP tunnelling to be established. R R (Registration through FA Required) flag. Indicates that the R bit was set in the FA's Agent Advertisement. Registration is being made using a co-located care-of address, but through the FA. Reserved 2 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. Encapsulation Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field. Reserved 3 Reserved for future use. MUST be set to 0 on sending, any bit not understood MUST be 0 on receipt. 3.1.1 F (Force) Flag Indicates that the mobile node wants to use traversal regardless of the outcome of NAT detection performed by the home agent. This is useful if the route between the mobile node and the home agent works for Mobile IP signalling packets, but not for generic data packets (e.g. because of firewall filtering rules). If the home agent supports this protocol, it SHOULD either accept the traversal and reply with a UDP Tunnel Reply Extension or reject the Registration Request. In case of failed registrations the Home Agent SHOULD send a Registration Reply with Code field set to 129 ("administratively prohibited"). If the HA does not understand the UDP Tunnel Request Extension, it will silently discard it, and if everything else is fine, it will reply with a registration reply with reply code 0 (registration Levkowetz & Vaarala Expires October 30, 2002 [Page 8] Internet-Draft NAT Traversal for MIP May 2002 accepted), but without any UDP Tunnel Reply Extension. In this case, the mobile node MUST NOT use MIP UDP tunnelling. 3.1.2 R (Registration through FA Required) flag This flag MUST be set by the mobile node when it is using a co- located address, but registering through an FA because it has received an Agent Advertisement with the 'R' bit set. 3.1.3 Reserved Fields The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, while the 'Reserved 3' field must be 0 on receipt, otherwise this extension MUST be ignored and silently skipped. This permits future additions to this extension to be made which either can co-exist with old implementations, or will force a rejection of the extension from an old implementation. 3.1.4 Encapsulation The 'Encapsulation' field defines the mode of encapsulation requested if MIP UDP tunnelling is accepted by the home agent. This field uses the same values as the IP header Protocol field: 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8] 55 Minimal IP encapsulation header RFC 2004 [6] If the home agent finds that UDP tunnelling is not needed, the encapsulation will be determined by the 'M' and 'G' flags of the registration request; but if the home agent finds that MIP UDP tunnelling should be done, the encapsulation is determined from the value of the Encapsulation field. If the value of this field is zero, it defaults to the value of 'M' and 'G' fields in the Registration Request message, but if it is non-zero, it indicates that a particular encapsulation is desired. 3.1.5 Mobile IP Registration Bits The Mobile IP registration bits S, B, D, M, G and T retain their meaning as described in RFC 3220 [10] and RFC 3024 [9] (except that the significance of the M and G bits may be modified by the Encapsulation field when MIP UDP tunnelling is used, as described above). The use of the M and G bits together with MIP UDP tunnelling is also touched upon in Section 4.1. Levkowetz & Vaarala Expires October 30, 2002 [Page 9] Internet-Draft NAT Traversal for MIP May 2002 When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation by the mobile node) MUST be set, otherwise UDP tunnelling would not be meaningful. Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP tunnelling, even if not all traffic will be reverse tunnelled. This ensures that a HA which is not prepared to accept reverse tunnelling will not accept a registration which may later turn out to be unusable. Also see the discussion of use of the 'T' bit in Foreign Agent Considerations (Section 4.5). 3.2 UDP Tunnel Reply Extension This extension is a non-skippable extension. It is sent in reply to a UDP Tunnel Request extension, and indicates whether or not the HA will use MIP UDP tunnelling for the current mobility binding. The format of this extension is as shown below. 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 | Sub-Type | Reply Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|r|E| Reserved 2 | Keepalive Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (to be assigned by IANA) (non-skippable) Length 6. Length in bytes of this extension, not including the Type and Length bytes. Sub-Type (to be assigned by IANA) Reply Code Indicates whether the HA assents or declines to use UDP tunnelling for the current mobility binding. See Section 3.2.1 below. F F (Forced) flag. Indicates that tunnelling is being forced because the F flag was set in the tunnelling request, irrespective of the detection of a NAT or not. E E (Echo) flag. Indicates that icmp echo requests and replies should be used for keepalive messages, rather than registration requests/replies. Keepalive Interval Specifies the NAT keepalive interval that the Levkowetz & Vaarala Expires October 30, 2002 [Page 10] Internet-Draft NAT Traversal for MIP May 2002 mobile node SHOULD use. A keepalive packet SHOULD be sent if Keepalive Interval seconds have elapsed without any signalling or data traffic being sent. If this field is set to 0, the mobile node MUST use its default configured keepalive interval. r Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. Reserved 2 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. 3.2.1 Reply Code The Reply Code field of the UDP Tunnel Reply Extension indicates if UDP tunnelling have been accepted and will be used by the HA. Values in the range 0 .. 63 indicate assent, i.e. that tunnelling will be done, while values in the range 64 .. 255 indicate that tunnelling should not be done. More information may be given by the value of the response code. The following response codes are defined for use in the code field of the UDP Tunnel Reply Extension: 0 Will do tunnelling 64 Tunnelling declined, reason unspecified 3.3 MIP Tunnel Data Message This MIP message header serves to differentiate traffic tunnelled through the well-known port 434 from other Mobile IP messages, e.g. Registration Requests and Registration Replies. 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 | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (to be assigned by IANA) Next Header Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field. Levkowetz & Vaarala Expires October 30, 2002 [Page 11] Internet-Draft NAT Traversal for MIP May 2002 Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. The Next Header field uses the same values as the IP header Protocol field. Immediately relevant for use with Mobile IP are the following values: 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8] 55 Minimal IP encapsulation header RFC 2004 [6] The receiver of a tunnelled packet MUST check that the Next Header value matches the tunnelling mode established for the mobility binding with which the packet was sent. If a discrepancy is detected, the packet MUST be dropped. A log entry MAY be written, but in this case the receiver SHOULD ensure that the amount of log entries written is not excessive. In addition to the encapsulation forms listed above, the MIP UDP tunnelling can potentially support other encapsulations, by use of the Next Header field in the MIP Tunnel Data Header and the Encapsulation Header field of the UDP Tunnel Request Extension (Section 3.1). 3.4 UDP Tunnelling Flag in Agent Advertisements The only change to the Mobility Agent Advertisement Extension defined in RFC 3220 [10] is a flag indicating that the foreign agent generating the Agent Advertisement supports MIP UDP Tunnelling. The flag is inserted after the flags defined in [10]. 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|r|T|U| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | The flag is defined as follows: U UDP Tunnelling support. This Agent supports MIP UDP Tunnelling as specified in this document. This flag SHOULD be set in advertisements sent by a foreign agent which Levkowetz & Vaarala Expires October 30, 2002 [Page 12] Internet-Draft NAT Traversal for MIP May 2002 supports MIP UDP tunnelling and is situated behind a NAT. It MUST NOT be set in advertisements from foreign agents which are not situated behind a NAT, and thus has no need to advertise the capability. 3.5 New Registration Reply Codes One new registration reply code is defined: ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation unavailable This is used by the HA to distinguish the registration denial caused by an unavailable UDP tunnel encapsulation mode from a denial caused by unavailable standard tunnel encapsulation requested by use of the 'T' bit together with either 'M' or 'G' bit. 4. Protocol Behaviour 4.1 Relation to standard MIP tunnelling The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP encapsulation. The mobile node MAY request alternative forms of encapsulation to be used with UDP tunnelling by setting the 'M' bit and/or the 'G' bit of a Mobile IP registration request, or by explicitly requesting a particular encapsulation for the MIP UDP tunnel by using the Encapsulation field. The M and G bits retain the meaning as described in RFC 3220 [10] within the context of MIP UDP tunnelling. The UDP tunnelling version of the classic MIP encapsulation methods can be summarised as: IP in UDP. When Mobile IP UDP tunnelling is used, this is the default encapsulation type. Any home agent and mobile node that implements Mobile IP UDP tunnelling MUST implement this encapsulation type. GRE in UDP. If the 'G' bit is set in a registration request and the Encapsulation field is zero, the mobile node requests that its home agent use GRE encapsulation [3] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also requested and accepted, GRE-in-UDP encapsulation SHALL be used in the same cases as GRE in IP encapsulation would be used if the MIP UDP tunnelling had not been requested. Minimal encapsulation in UDP. If the 'M' bit is set and the Encapsulation field is zero, the mobile node requests that its home agent use minimal encapsulation [6] for datagrams Levkowetz & Vaarala Expires October 30, 2002 [Page 13] Internet-Draft NAT Traversal for MIP May 2002 tunnelled to the mobile node. If MIP UDP tunnelling is also used, minimal encapsulation in UDP SHALL be used in the same cases as minimal encapsulation according to RFC 2004 [6] would be used if the MIP UDP tunnelling had not been requested. When the Encapsulation field is non-zero, a particular encapsulation format is requested for the MIP UDP tunnel. If tunnelling is indicated, the request MUST either be accepted using the requested encapsulation, or rejected with the error code ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5. On receipt of this error, the mobile node MAY choose to send a new Registration Request with different requirements on MIP UDP tunnelling encapsulation. 4.2 Encapsulating IP Headers in UDP MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a manner analogous to that described for IP-in-IP tunnelling in RFC 2003 [5], with the exception of the addition of an UDP header [1] and IP Message header [10] between the outer and inner IP header. Mobile IP Registration Requests and Registration Replies are already in the form of UDP messages, and SHALL NOT be tunnelled even when MIP IP-in-UDP tunnelling is in force. To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an outer IP header [2], UDP header [1] and MIP Message header [10] is inserted before the datagram's existing IP header, as follows: +---------------------------+ | | | Outer IP Header | +---------------------------+ | | | UDP Header | +---------------------------+ | MIP Tunnel Data | | Message Header | +---------------------------+ +---------------------------+ | | | | | IP Header | | IP Header | +---------------------------+ ====> +---------------------------+ | | | | | IP Payload | | IP Payload | | | | | | | | | +---------------------------+ +---------------------------+ Levkowetz & Vaarala Expires October 30, 2002 [Page 14] Internet-Draft NAT Traversal for MIP May 2002 The outer IP header Source Address and Destination Address, together with the UDP header Source Port and Destination Port, identify the "endpoints" of the tunnel. The inner IP header Source Address and Destination Addresses identify the original sender and the recipient of the datagram, respectively. The inner IP header is not changed by the encapsulator, except to decrement the TTL by one if the tunnelling is being done as part of forwarding the datagram as noted in RFC 2003 [5], and remains unchanged during its delivery to the tunnel exit point. No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the tunnel. If need be, other protocol headers such as the IP Authentication Header [11] may be inserted between the outer IP header and the UDP header. Note that the security options of the inner IP header MAY affect the choice of security options for the encapsulating (outer) IP header. Minimal Encapsulation and GRE encapsulation is done in an analogous manner, following RFC 2004 [6] for Minimal Encapsulation and RFC 2784 [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in place of the outer IP header. All other provisions and requirements of RFC 2003 [5] and RFC 3024 [9] are in force, except in one respect, as covered in Packet Fragmentation (Section 4.8). 4.3 Decapsulation IP-in-UDP encapsulated traffic is processed by the receiver simply by stripping of the outer IP, UDP and MIP header, which leaves the original IP packet which is forwarded as is. Minimal IP encapsulation is processed by the receiver conceptually as follows. First, the UDP and the Mobile IP headers are removed from the packet, and the Protocol field of the IP header replaced with the Next Header field in the MIP Tunnel Data header. Second, the remaining IP header total length and checksum are adjusted to match the stripped packet. Third, ordinary minimal IP encapsulation processing is done. GRE encapsulated traffic is processed according to RFC 2784 [8] and RFC 1701 [3], with the delivery header consisting of the outer IP, UDP and MIP headers. 4.4 Mobile Node Considerations The UDP Tunnel Request Extension MAY be used in a Mobile IP Registration Request from the mobile node to the home agent when the mobile node uses a co-located care-of address. It SHALL NOT be used Levkowetz & Vaarala Expires October 30, 2002 [Page 15] Internet-Draft NAT Traversal for MIP May 2002 by the mobile node when it is registering with a foreign agent care- of address. The purpose of this extension is to indicate to the home agent that the mobile node is able to accept MIP UDP tunnelling if the home agent has an indication that the mobile node resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling. As per Section 3.2 and 3.6.1.3 of RFC 3220 [10], the mobile node MUST place this Extension before the Mobile-Home Authentication Extension in registration messages, so that it is covered by the Mobile-Home Authentication Extension. If the mobile node includes the UDP Tunnel Request extension in a registration request, but receives a registration reply without a UDP Tunnel Reply extension, it MUST assume that the HA does not understand this extension, and it MUST NOT use UDP tunnelling. If the mobile node is in fact behind a NAT, the registration may then succeed, but traffic will not be able to traverse the NAT. When the mobile node sends MIP UDP tunnelled data, it MUST use the same UDP source port as was used for the original registration request. When the mobile node re-registers without having moved, it MUST take care to use the same source port as was used for the original registration of the current mobility binding. (This does not mean that the home agent should refuse a registration request using MIP UDP tunnelling where a new port have been used, as this might be the result of the NAT dropping state, the mobile node re-booting, changing interface, etc.) If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent had the 'U' bit set, the mobile node MUST set the 'R' flag in its UDP Tunnel Request Extension, in order to make the HA use MIP UDP tunnelling. In this case, the mobile node MUST send a keepalive as soon as its registration has been accepted. The keepalives to be used in this case MUST contain one UDP encapsulated ICMP echo request with the home agent as destination address. If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent does not have the 'U' bit set, the mobile node MUST NOT include a UDP Tunnel Request Extension in the registration request. Levkowetz & Vaarala Expires October 30, 2002 [Page 16] Internet-Draft NAT Traversal for MIP May 2002 4.5 Foreign Agent Considerations The UDP Tunnel Request Extension MAY be used by a foreign agent when it is forwarding a Mobile IP Registration Request to a home agent, when the foreign agent is situated behind a NAT or has some other compelling reason to require MIP UDP tunnelling. The purpose of this extension is to indicate to the home agent that the foreign agent is able to accept MIP UDP tunnelling if the home agent has an indication that the foreign agent resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling. A foreign agent which requires the mobile node to register through a foreign agent by setting the 'R' bit in the agent advertisement, MUST NOT add the UDP Tunnel Request Extension when forwarding a registration request which uses a co-located care-of address, as this will lead to a UDP tunnel being set up from the home agent to the foreign agent instead of to the mobile node. As per Section 3.2 and 3.7.2.2 of RFC 3220 [10], the foreign agent when using this extension MUST place it after the Mobile-Home Authentication Extension in registration messages. If the foreign agent shares a mobility security association with the home agent and therefore appends a Foreign-Home Authentication Extension, the UDP Tunnel Request Extension MUST be placed before the Foreign-Home Authentication Extension. As the home agent detects the presence of a NAT in the path between the sender and itself by seeing a mismatch between the IP source address and the care-of address given in the registration request, it is REQUIRED that the foreign agent, when using this extension, sends the registration request with an IP source address matching the care- of address. Or in other words, the foreign agent should send the IP packet on the interface having the care-of address. A foreign agent using MIP UDP tunnelling to a home agent because it is situated behind a NAT may be configured to encourage reverse tunnelling, or be neutral about it, depending on the characteristics of the NAT. If the NAT translates all source addresses of outgoing packets to its own public address, it will not be possible to maintain sessions when moving away from this network if the mobile node has used triangular routing instead of reverse tunnelling. On the other hand, if it is known that the NAT is smart enough to not translate publicly routable source addresses, AND does not do ingress filtering, triangular routing may succeed. The leg from the home agent to the foreign agent will still use MIP UDP tunnelling to pass through the NAT. Levkowetz & Vaarala Expires October 30, 2002 [Page 17] Internet-Draft NAT Traversal for MIP May 2002 Therefore, if it is known when configuring a foreign agent behind a NAT that the NAT will translate public as well as private addresses, or it is known that ingress filtering is being done between the private and public networks, the foreign agent SHOULD reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set". Conversely, if it is known that the NAT is smart about not translating public addresses, and no ingress filtering is done, so it is reasonable to believe that a mobile node with a publicly routable address may be able to keep up sessions when moving to or from this network, the foreign agent MAY be configured to forward registration requests even if they don't have the 'T' bit set. If the behaviour of the NAT is unknown in this respect, it SHOULD be assumed that it may translate all addresses, thus the foreign agent SHOULD be configured to reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set". 4.6 Home Agent Considerations The purpose of the MIP UDP Tunnel Reply Extension is to indicate whether or not the home agent accepts the use of MIP UDP tunnelling for this mobility binding, and to inform the mobile node or foreign agent of the suggested tunnel keepalive interval to be used. The UDP Tunnel Reply Extension MUST be used in a Mobile IP Registration Reply from the home agent to the mobile node when it has received and accepted a UDP Tunnel Request (Section 3.1) from a mobile node. The home agent MUST use a mismatch between source IP address and care-of address in the Mobile IP Registration Request message as the indication that a mobile node may reside behind a NAT. If the Registration Request also contains the UDP Tunnel Request extension without the 'R' flag set, and the home agent is capable of, and permits MIP UDP tunnelling, the home agent SHALL respond with a registration reply containing an assenting UDP Tunnel Reply Extension as described in Section 3.2. If the 'R' flag is set, special considerations apply, as described below. If the home agent receives a Registration Request with matching source IP address and co-located care-of address which contains a MIP UDP Tunnel Request Extension, the home agent SHOULD respond with a Registration Reply containing an declining UDP Tunnel Reply - unless tunnelling has been explicitly requested by the mobile node using the 'F' flag as described in Section 3.1. Levkowetz & Vaarala Expires October 30, 2002 [Page 18] Internet-Draft NAT Traversal for MIP May 2002 If the home agent assents to UDP tunnelling, it MUST use the source address of the registration request as the effective care-of address, rather than the care-of address given in the registration request, except in the case where the 'R' flag is set in the UDP Tunnel Request Extension. If the home agent receives a Registration Request with the 'R' flag set in the UDP Tunnel Request Extension, it SHOULD reply with an assenting UDP Tunnel Reply Extension if it is capable of, and permits MIP UDP tunnelling. In this case, however, the source address and port of the registration request may be a NAT'ed version of the foreign agent source address and port. In order to direct tunnelled traffic correctly to the mobile node, the home agent MUST wait for the first keepalive packet from the mobile node to arrive, before it can send traffic back to the correct NAT port (the one which is mapped to the MN). In this case, the home agent MUST check that the outer source address (but not the port) of this keepalive packet is identical with the source address of the corresponding registration request. The inner source address (that of the encapsulated ICMP echo request) MUST be the home address of the mobile node, and the inner destination address MUST be that of the home agent. If all this holds, the outer source address and port of this keepalive packet SHALL be used by the HA as the outer destination address and port of the MIP UDP tunnel when forwarding traffic to the mobile node. The home agent MUST be consistent in acknowledging support for UDP tunnelling or not. A home agent which understands the UDP Tunnel Request Extension and is prepared to respond positively to such a request MUST also respond with a UDP Tunnel Reply Extension containing a declining reply code if use of MIP UDP tunnelling is not indicated for a session. The mobile node MUST NOT assume such behaviour from the home agent, since the home agent may undergo a software change and reboot, and consequently change behaviour. 4.6.1 Error Handling The following actions take place when things go wrong. The HA does not support the UDP Tunnel Request extension: The home agent ignores the extension and proceeds normally, which would be to refuse the registration if the IP source address does not match the care-of address, the home address or 0.0.0.0. Even if the HA mistakenly does accept the registration, the mobile node will not be able to receive forward tunnelled data if it is behind a NAT. Levkowetz & Vaarala Expires October 30, 2002 [Page 19] Internet-Draft NAT Traversal for MIP May 2002 (It would be beneficial to have the mobile node de-register in this case. The mobile node, however, normally has no way of telling that it is behind a NAT if it does not receive a UDP Tunnelling Reply.) NAT detected by home agent, but traversal not allowed: In some cases the home agent may disable NAT traversal even though it supports the UDP Tunnel Request extension and a NAT is detected. In this case, the home agent SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited". NAT not detected, 'F' flag set, but home agent does not allow forced use of MIP UDP tunnelling: The home agent SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited". UDP Tunnel Request extension sent by the mobile node, but 'D' bit in registration request header not set: The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". UDP Tunnel Request extension sent by the foreign agent, but 'D' bit is set: The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". Reserved 3 field of UDP Tunnel Request extension is nonzero and the home agent does not recognize the value: The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". Encapsulation type requested in UDP Tunnel Request extension is unsupported. The home agent SHOULD send a Registration Reply with the Code field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5. Levkowetz & Vaarala Expires October 30, 2002 [Page 20] Internet-Draft NAT Traversal for MIP May 2002 4.7 MIP signalling versus tunnelling UDP tunnelling SHALL be used only for data packets, and only when the mobility binding used for sending was established using the UDP Tunnel Request, and accepted by an UDP Tunnel Reply from the home agent. After MIP UDP tunnelling has been established for a mobility binding, data packets that are forward or reverse tunnelled using this mobility binding MUST be tunnelled using MIP UDP tunnelling, not IP-in-IP tunnelling or some other tunnelling method. As a consequence: - Mobile IP signalling is never tunnelled. - When using simultaneous bindings, each binding may have a different type (i.e. UDP tunnelling bindings may be mixed with non-UDP tunnelling bindings). - Tunnelling is only allowed for the duration of the binding lifetime. 4.8 Packet fragmentation From RFC 3022 [13]: "Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT set-up are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted." Because of this, if the mobile node or foreign agent for any reason needs to send fragmented packets, the fragmentation MUST be done prior to the encapsulation. This differs from the case for IP-in-IP tunnelling, where fragmentation may be done before or after encapsulation, although RFC 2003 [5] recommends doing it before encapsulation. A similar issue exists with some firewalls, which may have rules that Levkowetz & Vaarala Expires October 30, 2002 [Page 21] Internet-Draft NAT Traversal for MIP May 2002 only permit traffic on certain TCP and UDP ports, and not arbitrary outbound (or inbound) IP traffic. If this is the case and the firewall is not set to do packet reassembly, a home agent behind a firewall will also have to do packet fragmentation before MIP UDP encapsulation. Otherwise, only the first fragment (which contains the UDP header) will be allowed to pass from the home agent out through the firewall. For this reason, the home agent SHOULD do packet fragmentation before it does MIP UDP encapsulation. 4.9 Tunnel Keepalive As the existence of the bi-directional UDP tunnel through the NAT is dependent on the NAT keeping state information associated with a session, as described in RFC 2663 [12], and as the NAT may decide that the session has terminated after a certain time, keepalive messages may be needed to keep the tunnel open. The keepalives should be sent more often than the timeout value used by the NAT. This timeout may be assumed to be a couple of minutes, according to RFC 2663 [12], but it is conceivable that shorter timeouts may exist in some NATs. For this reason the extension used to set up the UDP tunnel has the option of setting the keepalive message interval to another value than the default value, see Section 3.2. Sending a keepalive message SHOULD consist of doing a regular Mobile IP Registration Request, exactly as would otherwise have been done before the expiration of the current registration, except in the case where the mobile node has set the 'R' flag in the UDP Tunnel Request Extension. When the keepalive does not consist of a registration request, it MUST instead consist of a properly encapsulated ICMP echo request directed to the home agent. If the home agent because of processing load or other reasons would prefer the mobile node to use ICMP echo requests rather than Registration Requests, it may do so by setting the 'E' flag in the UDP Tunnel Reply Extension. For each mobility binding which has UDP tunnelling established, the node which sent the UDP Tunnel Request Extension MUST send a keepalive packet if no other packet to the HA has been sent in K seconds, where K is a parameter with a default value of 20 seconds. K may be set to another value by the HA as described in the UDP tunnelling reply extension (Section 3.2). Except for the case where the mobile node registers with co-located address through an FA (see Section 4.10) MIP UDP tunnelling is done using the same ports that have already been used for the registration Levkowetz & Vaarala Expires October 30, 2002 [Page 22] Internet-Draft NAT Traversal for MIP May 2002 request / reply exchange, the MN will send its first keepalive message at the earliest K seconds after the registration request was sent. The mobile node MUST use the same UDP source port for the keepalive messages as was used for the original Registration Messages and for data messages. The home agent MUST be prepared to receive re-registration requests at the rate indicated by the Keepalive Interval in the UDP Tunnel Reply Extension. 4.10 Co-located registration through FA This section summarizes the protocol details which have been necessary in order to handle and support the case when a mobile node registers with a co-located address through a foreign agent, due to the FA advertisements having the 'R' bit set. It gives background information, but lists no new requirements. When a mobile registers a co-located care-of address through an FA, the registration request which reaches the HA will have a different care-of address in the registration request compared to the source address in the registration request IP-header. If the registration request also contains a UDP Tunnel Request Extension, the HA will erroneously set up a UDP tunnel, which will go to the FA instead of the MN. For this reason, as mentioned in Section 4.4, the mobile node must not include a UDP Tunnel Request Extension in the registration if it is registering a co-located address through an FA which does not have the 'U' bit set in its advertisements. In order to still be able to use MIP UDP tunnelling in this case, foreign agents which are situated behind a NAT are encouraged to send advertisements which have the 'U' bit set, as described in Section 3.4. If the FA advertisement has the 'U' bit set, indicating that it is behind a NAT, and also the 'R' bit set, and the mobile node wishes to use a co-located care-of address, it MUST set the 'R' flag in the UDP Tunnel Request Extension, in order to inform the HA of the situation so that it may act appropriately, as described in Section 4.4. The use of MIP UDP tunnelling with a co-located care-of address when registering through a foreign agent brings another problem too. The use of re-registration requests as tunnel keepalives does not work in this case, as registration is done through the foreign agent, not directly on the same path as the tunnel. For this reason, alternative keepalives has to be used. As described in Section 4.4, ICMP echo requests are to be used in this case. Compared to sending an empty packet, these have the benefit of soliciting a return packet, which will let the mobile node know that it has connectivity with the HA through the tunnel. Levkowetz & Vaarala Expires October 30, 2002 [Page 23] Internet-Draft NAT Traversal for MIP May 2002 Because the UDP tunnel is now taking another path than the registration requests, the home agent, when handling registrations of this type, must wait till the arrival of the first keepalive packet before it can set up the tunnel to the correct address and port. To reduce the possibility of tunnel hijacking by sending a keepalive with a phony source address, it is required that only the port of the keepalive packet may be different from that of the registration request; the source address must be the same. This means that if the FA and MN are communicating with the HA through different NATs, the connection will fail. 5. Implementation Issues 5.1 Movement Detection and Private Address Aliasing In providing a mobile node with a mechanism for NAT traversal of Mobile IP traffic, we expand the address space where a mobile node may function and acquire care-of addresses. With this comes a new problem of movement detection and address aliasing. We here have a case which may not occur frequently, but is mentioned for completeness: Since private networks use overlapping address spaces, they may be mistaken for one another in some situations; this is referred to as private address aliasing in this document. For this reason, it may be necessary for mobile nodes implementing this specification to monitor the link layer address(es) of the gateway(s) used for sending packets. A change in the link layer address indicates probable movement to a new network, even if the IP address remains reachable using a new link layer address. For instance, a mobile node may obtain the co-located care-of address 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP from network #1. It then moves to network #2, which uses an identical addressing scheme. The only difference for the mobile node is the gateway's link layer address. The mobile node should store the link layer address it initially obtains for the gateway (using ARP, for instance). The mobile node may then detect changes in the link layer address in successive ARP exchanges as part of its ordinary movement detection mechanism. In rare cases the mobile nodes may not be able to monitor the link layer address of the gateway(s) it is using, and may thus confuse one point of attachment with another. This specification does not explicitly address this issue. The potential traffic blackout caused by this situation may be limited by ensuring that the mobility binding lifetime is short enough; the re-registration caused by expiration of the mobility binding fixes the problem (see Section Levkowetz & Vaarala Expires October 30, 2002 [Page 24] Internet-Draft NAT Traversal for MIP May 2002 5.2). 5.2 Mobility Binding Lifetime When responding to a registration request with a registration reply, the home agent is allowed to decrease the lifetime indicated in the registration request, as covered in RFC 3220 [10]. When using UDP tunnelling, there are some cases where a short lifetime is beneficial. First, if the NAT mapping maintained by the NAT device is dropped, a connection blackout will arise. New packets sent by the mobile node (or the foreign agent) will establish a new NAT mapping, which the home agent will not recognize until a new mobility binding is established by a new registration request. A second case where a short lifetime is useful is related to the aliasing of private network addresses. In case the mobile node is not able to detect mobility and ends up behind a new NAT device (as described in Section 5.1), a short lifetime will ensure that the traffic blackout will not be exceedingly long, and is terminated by a re-registration. The definition of "short lifetime" in this context is dependent on the requirements of the usage scenario. Suggested maximum lifetime returned by the home agent is 60 seconds, but in case the abovementioned scenarios are not considered a problem, longer lifetimes may of course be used. 6. Security Considerations The ordinary Mobile IP security mechanisms are also used with the NAT traversal mechanism described in this document. However, there is one noticeable change: the NAT traversal mechanism requires that the HA trust unauthenticated address (and port) fields possibly modified by NATs. Relying on unauthenticated address information when forming or updating a mobility binding leads to several redirection attack vulnerabilities. In essence, an attacker may do what NATs do, i.e. modify addresses and ports and thus cause traffic to be redirected to a chosen address. The same vulnerabilities apply to both MN-HA and FA-HA NAT traversal. In more detail: without a NAT, the care-of address in the registration request will be directly used by the HA to send traffic back to the MN (or the FA), and the care-of address is protected by Levkowetz & Vaarala Expires October 30, 2002 [Page 25] Internet-Draft NAT Traversal for MIP May 2002 the MN-HA (or FA-HA) authentication extension. When communicating across a NAT, the effective care-of address from the HA point of view is that of the NAT, which is not protected by any authentication extension, but inferred from the apparent IP source address of received packets. This means that by using the mobile IP registration extensions described in this document to enable traversal of NATs, one is opening oneself up to having the care-of address of a MN (or a FA) maliciously changed by an attacker. Some, but not all, of the attacks could be alleviated to some extent by using a simple routability check. However, this document does not specify such a mechanism for simplicity reasons and because the mechanism would not protect against all redirection attacks. To limit the duration of such redirection attacks, it is RECOMMENDED to use a conservative (that is, short) mobility binding lifetime when using the NAT traversal mechanism specified in this document, and also use registration request keepalives rather than ICMP echo request keepalives. The known security issues are described in the sections that follow. 6.1 Traffic Redirection Vulnerabilities 6.1.1 Manipulation of the Registration Request Message An attacker on the route between the mobile node (or foreign agent) and the home agent may redirect mobility bindings to a desired address simply by modifying the IP and UDP headers of the Registration Request message. Having modified the binding, the attacker no longer needs to listen to (or manipulate) the traffic. The redirection is in force until the mobility binding expires or the mobile node re-registers. This vulnerability may be used by an attacker to read traffic destined to a mobile node, and to send traffic impersonating the mobile node. The vulnerability may also be used to redirect traffic to a victim host in order to cause denial-of-service on the victim. The only defence against this vulnerability is to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped modifying registration messages. 6.1.2 Sending a Bogus Keepalive Message When registering through a FA using a co-located care-of address, another redirection vulnerability opens up. Having exchanged RRQ/RRP messages with the HA through the FA, the MN is expected to send the Levkowetz & Vaarala Expires October 30, 2002 [Page 26] Internet-Draft NAT Traversal for MIP May 2002 first keepalive message to the HA, thus finalizing the mobility binding (the binding will remain in a "half open" state until the keepalive is received). Having observed a RRQ/RRP exchange, an attacker may send a bogus keepalive message assuming that the mobility binding is in the "half open" state. This opens up a similar redirection attack as discussed in Section 6.1.1. Note, however, that the attacker does not need to be able to modify packets in flight; simply being able to observe the RRQ/RRP message exchange is sufficient to mount the attack. With this in mind, the home agent MUST NOT accept a keepalive message from a different source IP address than where the RRQ came from, as specified in Section 4.6. This requirement limits the extent of the attack to redirecting the traffic to a bogus UDP port, while the IP address must remain the same as in the initial RRQ. The only defences against this vulnerability are: (1) to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped sending bogus keepalive messages, and (2) to minimize the time the binding is in a "half open" state by having the mobile node send the first keepalive message immediately after receiving an affirmative registration reply. 6.2 Use of IPsec If the intermediate network is considered insecure, it is recommended that IPsec be used to protect user data traffic. However, IPsec does not protect against the redirection attacks described previously, other than to protect confidentiality of hijacked user data traffic. The NAT traversal mechanism described in this document allows all IPsec-related traffic to go through NATs without any modifications to IPsec. In addition, the IPsec security associations do not need to be re-established when the mobile node moves. 6.3 Firewall Considerations This document does not specify a general firewall traversal mechanism. However, the mechanism makes it possible to use only a single address and a port for all MN-HA (or FA-HA) communication. Furthermore, using the same port for the MIP UDP tunnelled traffic as for control messages makes it quite probable that if a MIP registration can reach the home agent, MIP tunnelling and reverse tunnelling using the described mechanism will also work. Levkowetz & Vaarala Expires October 30, 2002 [Page 27] Internet-Draft NAT Traversal for MIP May 2002 7. IANA Considerations The numbers for the extensions defined in this I-D should be taken from the numbering space defined for Mobile IP messages, registration extensions and error codes defined in RFC 3220 [10]. This draft proposes one new message, three new extensions and a new error code that require type numbers and error code value to be assigned by IANA. Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request Extension. The type number for this extension should be of type skippable. Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply Extension . The type value for this extension should be of type non- skippable. Section 3.3 defines a new Mobile IP message, the Tunnel Data message. The type value for this message should be taken from the numbering space defined for Mobile IP messages. Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: "Requested UDP tunnel encapsulation unavailable", from the numbering space for values defined for use with the Code field of Mobile IP Registration Reply Messages. This code should be taken from the subset "Error Codes from the Home Agent". The values for the Next Header field in the MIP Tunnel Data Message (Section 3.3) shall be the same as those used for the Protocol field of the IP header[2], and requires no new number assignment. 8. Intellectual property rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. ipUnplugged has notified the working group of one or more patents or patent applications that may be relevant to this internet-draft. ipUnplugged has given a licence for those patents to the IETF. For more information consult the online list of claimed rights. 9. Acknowledgements Much of the text in Section 4.2 has been taken almost verbatim from RFC 2003, IP Encapsulation within IP [5]. Levkowetz & Vaarala Expires October 30, 2002 [Page 28] Internet-Draft NAT Traversal for MIP May 2002 Adding support for the FA case was suggested by George Tsirtsis and Frode B. Nilsen. Roy Jose pointed out a problem with binding updates, and Frode, Roy and George pointed out that there are cases where triangular routes may work, and suggested that reverse tunnelling need not be mandatory. Roy and Qiang Zhang drew attention to a number of sections which needed to be corrected or stated more clearly. Phil Roberts helped remove a number of rough edges, and suggested the 'E' bit to permit an HA to indicate preference for icmp echo request keepalives. Farid Adrangi pointed out the DoS issue now covered in Security Considerations (Section 6). Francis Dupont's helpful comments made us extend the Security Considerations section to make it more comprehensive and clear. Milind Kulkarni and Madhavi Chandra pointed out the required match between the FA source and care-of addresses when the mechanism is used by an FA, and also contributed a number of clarifications to the text. Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik Liden at ipUnplugged. They have read and re-read the text, and contributed many valuable corrections and insights. Normative References [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [4] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1768, March 1995. [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [6] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. Levkowetz & Vaarala Expires October 30, 2002 [Page 29] Internet-Draft NAT Traversal for MIP May 2002 [9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [10] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 2002. Informative References [11] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. [12] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [13] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. Authors' Addresses O. Henrik Levkowetz ipUnplugged AB Arenavagen 33 Stockholm S-121 28 SWEDEN Phone: +46 8 725 9513 EMail: henrik@levkowetz.com Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND Phone: +358 9 435 310 EMail: sami.vaarala@iki.fi Levkowetz & Vaarala Expires October 30, 2002 [Page 30] Internet-Draft NAT Traversal for MIP May 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Levkowetz & Vaarala Expires October 30, 2002 [Page 31]