One document matched: draft-stiemerling-hip-nat-00.txt
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
<draft-stiemerling-hip-nat-00.txt>
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
| PAFTECH AB 2003-2026 | 2026-04-22 06:24:47 |