Internet Draft M. Stiemerling Document: draft-stiemerling-hip-nat-00.txt J. Quittek Expires: August 2004 NEC Europe Ltd. February 2004 Problem Statement: HIP operation over Network Address Translators Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo investigates issues for Host Identity Protocol (HIP) nodes that communicate over a network path that inlcudes Network Address Translators (NATs). There are two groups of issues: Operating HIP itself across NATs and operating the IPsec-based data transmission initiated by HIP across NATs. For both groups problems are summarized. Stiemerling, Quittek [Page 1] Internet-Draft HIP and NAT February 2004 Table of Contents 1 Introduction ................................................. 3 2 Terminology .................................................. 3 3 HIP Network Environment ...................................... 4 4 Problems with operating HIP across NATs ...................... 5 4.1 HIP Base Exchange .......................................... 5 4.1.1 HIP over IPv6 ............................................ 6 4.1.2 HIP over IPv4 ............................................ 6 4.2 IPSec Data Exchange ........................................ 7 5 Extensions to HIP ............................................ 7 6 Extension to NATs ............................................ 8 7 Security Considerations ...................................... 8 8 Acknowledgements ............................................. 8 9 References ................................................... 8 10 Authors' Addresses .......................................... 10 11 IPR Notices ................................................. 10 12 Full Copyright Statement .................................... 11 Stiemerling, Quittek [Page 2] Internet-Draft HIP and NAT February 2004 1. Introduction The Host Identity Protocol (HIP) architecture [HIP-ARCH] introduces a new kind of identifier for each host. Instead of using the IP address as host identity, a new Host Identifier is introduced. This additional namespace, separates the host identity from the routing information contained in the IP address. The current version of the HIP Architecture is based on the assumption of full reachability between the IP addresses assigned to the participating hosts. This is usually given if both hosts have IP addresses belonging to the same address realm, for example if both have public addresses. But if the host's addresses belong to different realms, for example one has a private IP address and the other one a public one, then network address translation must be provided between the realms. So far, network address translation is not integrated into the HIP architecture and HIP [HIP-PROTO] does not have particular means to support it. Problems arising in conjunction with Network Address Translators (NATs) are two-fold. First the HIP base exchange needs to traverse NATs and then the IPSec encoded transport initiated by HIP needs to traverse it (see [RFC2401] for an introduction to IPSec). In general, both protocols may be blocked by NATs. This document discusses the problems encountered when using HIP in the presence of NATs in Section 4. Impacts on HIP itself and the used IPsec mechanism are elaborated. Section 5 discusses extensions to HIP that potentially can solve some of the problems. Section 6 suggests extensions to the functions provided by today's NATs complementing the HIP extensions. 2. Terminology Terms used throughout this document are consistent with IPSec terminology [RFC2401], HIP terminology [HIP-ARCH][HIP-PROTO][HIP-MM], and NAT terminology [RFC2663]. For an introduction to NATs readers are recommended to read [RFC2663]. In this memo the term NAT refers to NAT and NAPT. So-called twice-NATs are not considered, yet. Stiemerling, Quittek [Page 3] Internet-Draft HIP and NAT February 2004 3. HIP Network Environment The HIP Architecture described in [HIP-ARCH] assumes full reachability between the IP addresses assigned to the participating hosts. +---------+ -------- +---------+ | HIP | / \ | HIP | | peer |----| Internet |---| peer | | A | \ realm / | B | +---------+ -------- +---------+ Figure 1: Assumed network environment for HIP This is usually given if both hosts have IP addresses belonging to the to the same address realm, for example if both have public addresses or if both have addresses belonging to the same private address realm as shown by Figure 1. Within one realm, IP addresses provide end-to-end routing information between hosts A and B. If A wants to send a packet to B, it is sufficient for A to know the IP address assigned to B. The scenario sketched by Figure 1 is an ideal one. It does not (anymore) match today's current scenarios where an increasing number of hosts use private IP addresses, mainly, because of lack of IP addresses in IPv4. Furthermore, a separation of an organization's network from the public Internet realm hides the organization's network structure and enables more flexible internal renumbering of IP addresses. If the host's addresses belong to different realms, then communication between these hosts requires network address translation between the realms. Network Address Translators (NATs, [RFC2663]) provide this service. Figure 2 shows an example of a host A with a private IP address and a host B with a public IP address +--+ +---------+ -------- | | -------- +---------+ | HIP | / public \ |N | / private \ | HIP | | peer |--| Internet |--|A |--| Internet |--| peer | | A | \ realm / |T | \ realm / | B | +---------+ -------- | | -------- +---------+ +--+ Figure 2: Network environment with NAT The translation performed by NATs affects the IP header and (in most Stiemerling, Quittek [Page 4] Internet-Draft HIP and NAT February 2004 existing cases) also the transport header. IP addresses and transport port numbers are translated between the address realms. In the scenario illustrated by Figure 2, host A would address all HIP messages that it intends to send to host B to a public IP address that is provided by the NAT. The NAT receives the message for this address (typically in combination with a dynamically chosen port number) and replaces the destination IP address (and typically also the TCP or UPD port number) before it forwards the packet into the private realm. The public IP address (and port number) that the NAT uses for this translation service is in general not known to host B. Therefore, applications that carry address information in their payload or applications that rely on static protocol header fields experience severe problems. Often, the application-level signaling can traverse NATs, but subsequent data exchange fails (see [NATP2P]). NATs are heavily used in IPv4 networks when there is a significant lack of address space. Initially, they were expected not to be present in IPv6 networks, but the authors believe that NATs will also be used in IPv6 networks, despite the availability of a much larger address space. Today, even organizations owning a sufficiently large IPv4 address space tend to use private Internet realms, because this hides their internal network structure and allows to renumber the internal network addresses without communicating this to the public network. 4. Problems with operating HIP across NATs HIP operation can be divided into two phases. The first one is the HIP base exchange using HIP only. The second one is the actual application data exchange via IPSec. This section separately describes the problems that occur in each of the phases when network address translation is integrated into the HIP architecture. 4.1. HIP Base Exchange The HIP base exchange uses different transport mechanisms for IPv6 and IPv4. o IPv6 When IPv6 is used, a HIP-specific IPv6 extension header carries all information necessary (see Section 6 of [HIP-PROTO]). o IPv4 When IPv4 is used, HIP messages are transmitted as UDP payload. (see Appendix E of [HIP-PROTO]). Stiemerling, Quittek [Page 5] Internet-Draft HIP and NAT February 2004 4.1.1. HIP over IPv6 Current implementations use plain IPv6 packets without any payload other than the HIP extension header. This causes problems in combination with NATs that multiplex many private IP addresses into a few public addresses. Usually, this kind of multiplexing is performed on a combination of IP address and TCP or UDP port number. In the absence of a TCP or UDP transport header, typical network address and port translation will fail. Currently there is no specific scheme defined for translating IPv6 HIP extension headers in the absence of TCP or UDP headers. Another problem (that also applies to IPv4) is that HIP provides no explicit means for transmitting the IP address used by a host other than using the source IP address of the packet carrying HIP messages. Even if a host B in Figure 2 would know the public IP address used by the NAT for translation, it has no means of providing this information to host A. 4.1.2. HIP over IPv4 The use of UDP encapsulation for IPv4 transmission enables the HIP base exchange to traverse NATs and to reach their final destination. This encapsulation scheme replaces the IPv6 extension header with a UDP header followed by a HIP header. All HITs and HIP parameters are appended to this new HIP UDP header. UDP transport suffers from many well known problems when traversing NATs (compare Section 2.2 of [IPSEC-NAT-REQ] also for some issues on UDP traversal). One problem is that often NATs are not able or do not allow to traverse UDP packets, they are blocked and discarded. If NATs do allow UDP packets to traverse, it is not determinable which UDP port number and IP address is used for outgoing UDP packets. HIP over UDP is mandating a fixed port number of 272 for source and destination ports. NATs may change the source port number to any possible port number, for instance a source port of 272 may be changed by the NAT to 34657. The above paragraph implies that outgoing packets (packets origin in a private address realm and traversing towards the public address realm) are allowed to traverse, but the opposite way, incoming packets, is not necessary given. Only incoming packets that are replies to outgoing packets are able to traverse the NAT. For incoming packets, from flows originating in the public address realm, there is no way of traversing. The destination address in the private address realm (more precise the IP address NAT binding) is not given, thus no address mapping is possible. So transmissions originating in the public Internet are unable to traverse (or even reach the NAT), unless the NAT has some pre-configured configurations. Stiemerling, Quittek [Page 6] Internet-Draft HIP and NAT February 2004 4.2. IPSec Data Exchange IPSec secures data transmission between two HIP nodes after their base exchange is completed. Well-known issues with IPSec and NAT are listed in [IPSEC-NAT-REQ] and apply to the IPSec use of HIP as well. Those issues are separated into NAT intrinsic issues, NAT implementation issues and helper incompatibilities. The NAT intrinsic issues related to IPSec (IKE issues are omitted) are: 1. By using ESP all upper layer headers are invisible to the NAT. So changes of the IP header during NAT traversal invalidate any upper layer checksums that are protected within ESP after ESP decryption. 2. It is possible to use ESP encrypted packets through a NAT, but as [IPSEC-NAT-REQ] remarks, the used SPI values have only one- way significance. Furthermore, SPI values may collide at the NAT, meaning that two different peers behind the NAT are using the same SPI value. 3 SPI could be use for multiplexing different IPSec flows at the NAT. But since SPI have only this one-way significance, NATs can only learn the SPI value of outgoing ESP flows, but not the SPI value of the response ESP flow. A possible way of carrying IPSec traffic through NATs has been proposed in [IPSEC-UDP]. IPSec traffic is encapsulated in UDP packets. 5. Extensions to HIP [HIP-MM][HIP-PA] propose new extensions to HIP to make it usable for end host mobility and multi-homing. Out of those proposals one extension to HIP can be used for HIP and NAT traversal: HIP peers are able to notify other HIP peers about new addresses they have obtained with the REA packet exchange (see Section 4 of [HIP-MM]). With REA a HIP node can notify other HIP nodes about new addresses, for instance about its new address at a NAT. This functionality has been already described and can be used for NAT traversal. The issue is how to determine the publicly reachable IP address, so that it can be announced within the REA packet to the HIP peer. A possible extension of HIP for mobility and multi- homing is the usage of an IPSec IKE mechanism proposed in [IPSEC-NAT-T]. Since the checksums of upper layer protocols are invalidated (see Section Stiemerling, Quittek [Page 7] Internet-Draft HIP and NAT February 2004 4.2.), the receiving HIP peer needs to know the complete pseudo header of the sending HIP peer (see [RFC793] and [RFC768] for TCP and UDP pseudo header). With the knowledge of the pseudo header, a receiving HIP peer can first decrypt the ESP payload and insert the pseudo header before passing this content to checksum computation (see also Section 5.2 of [IPSEC-NAT-T]). This extension would require a new HIP payload for carrying pseudo header information to be included in the REA exchange. 6. Extension to NATs As described in Section 4.2, IPSec SPIs have only one-way significance, meaning that NATs can learn SPI values of outgoing packets, but they cannot learn the corresponding SPI values of incoming packets. Therefore, a matching between SPI values used for outgoing flows to SPI values used for incoming flows is not possible. NATs must learn the corresponding SPI values for outgoing and incoming IPSec flows. There are two ways in doing so. First, NATs can monitor the HIP base exchange and learn the SPI values agreed by both HIP peers. Afterwards, NATs can remember these values and map outgoing and incoming IPSec flows accordingly. Second, HIP peers can use a NAT signaling protcol and signal the appropriate SPI values with IP addresses. NATs can so learn the SPI values out of the signaling protocol. Both approaches require changes to NATs. The first approach would require changes that are only benificial to HIP, the second one would be benificial for other protocols as well. Possible solutions for signaling NATs SPI values are NSIS NAT/FW traversal and MIDCOM. 7. Security Considerations To be done. 8. Acknowledgements The authors like to thank Lars Eggert for a lot of valuable comments. 9. References Stiemerling, Quittek [Page 8] Internet-Draft HIP and NAT February 2004 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [IPSEC-UDP] Huttunen, A., et al, "UDP Encapsulation of IPsec Packets ", draft-ietf-ipsec-udp-encaps-07.txt, Internet Draft ( work in progress), October 2003. [IPSEC-NAT-T] Kivinen, T., et al, "Negotiation of NAT-Traversal in the IKE", draft-ipsec-nat-t-ike-07.txt, Internet Draft (work in progress), September 2003. [IPSEC-NAT-REQ] Aboba, B., and W. Dixon, "IPsec-NAT Compatibility Requirements ", draft-ietf-ipsec-nat-reqts-06.txt, Internet Draft (work in progress), October 2003. [HIP-ARCH] Moskowitz, R., and P. Nikander, "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-05.txt, Internet Draft (work in progress), September 2003. [HIP-PROTO] Moskowitz, R., Nikander, P., and T. Henderson, "Host Identity Protocol", draft-moskowitz-hip-08.txt, Internet Draft (work in progress), October 2003. [HIP-MM] Nikander, P., and P. Jokela, "End-Host Mobility and Multi- Homing with Host Identity Protocol", draft-nikander-hip- mm00.txt, Internet Draft (work in progress), June 2003. [HIP-PA] Nikander, P., Ylitalo, J., and J. Wall, "Integrating Security, Mobility, and Multi-Homing in a HIP way", NDSS 2003, 2003. [NATP2P] Ford, B., Srisuresh, P., and D. Kegel, *(lqPeer-to-Peer (P2P) communication across middleboxes*(rq, draft-ford- midcom-p2p-01.txt, Internet Draft (work in progress), October 2003 [RFC2663] Srisuresh, P., and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981 Stiemerling, Quittek [Page 9] Internet-Draft HIP and NAT February 2004 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1980 10. Authors' Addresses Martin Stiemerling NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-13 Email: stiemerling@netlab.nec.de Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de 11. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Stiemerling, Quittek [Page 10] Internet-Draft HIP and NAT February 2004 12. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 implmentation 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. Stiemerling, Quittek [Page 11] Internet-Draft HIP and NAT February 2004