HIP P. Nikander Internet-Draft Ericsson Expires: August 18, 2005 H. Tschofenig Siemens T. Henderson The Boeing Company L. Eggert NEC J. Laganier SUN February 14, 2005 Preferred Alternatives for Tunnelling HIP (PATH) draft-nikander-hip-path-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 August 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Nikander, et al. Expires August 18, 2005 [Page 1] Internet-Draft PATH February 2005 With the extensions defined in this document Host Identity Protocol (HIP) can traverse legacy Network Address Translators (NATs) and certain Firewalls. The extension will be useful as part of the base exchange and with the HIP Registration Extension. By using a rendezvous server an additional entity inside the network is utilized, which not only allows but also supports more restrictive NATs to be traversed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . 6 3.1 UDP Encapsulation of HIP . . . . . . . . . . . . . . . . . 6 3.2 UDP-REA parameter . . . . . . . . . . . . . . . . . . . . 6 3.3 S-UDP-REA parameter . . . . . . . . . . . . . . . . . . . 8 4. Message Handling Rules . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 HIP Initiator behind a NAT . . . . . . . . . . . . . . . . 11 5.2 PATH Server Registration and Keep Alive . . . . . . . . . 11 5.3 Message flow for data receiver behind a NAT . . . . . . . 13 5.4 Mobility and multihoming message flow . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . 18 6.1 Third Party Bombing . . . . . . . . . . . . . . . . . . . 18 6.2 Black hole . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3 Man-in-the-middle attack . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 22 8.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22 8.3 Brittleness Introduced by PATH . . . . . . . . . . . . . . 23 8.4 Requirements for a Long Term Solution . . . . . . . . . . 24 8.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25 8.6 In Closing . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1 Normative References . . . . . . . . . . . . . . . . . . 29 11.2 Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . 32 Nikander, et al. Expires August 18, 2005 [Page 2] Internet-Draft PATH February 2005 1. Introduction This document defines extensions and allows the Host Identity Protocol (HIP) to be used in an environment where legacy NATs or Firewalls are presents. To support this functionality it is necessary to provide o UDP encapsulation for HIP signaling messages o UDP encapsulation for IPsec traffic The problems of IPsec protected traffic and also the problems for a signaling protocol (namely IKEv1) traversing a NA[P]T are well described in [5]. A proposal for UDP encapsulation of IPsec protected traffic is described in [6]. It is possible to design an optimized version of it for usage with HIP. This aspect is, however, outside the scope of this document. This document tries to accomplish the following goals: o Make HIP work through legacy NATs (and possibly through some firewalls) o Make HIP hosts reachable behind NATs By using a rendezvous server an additional entity inside the network is introduced which interacts with the HIP message exchange. The interaction of HIP with the rendezvous server is described in [1]. This allows a complete NAT/Firewall traversal to be accomplished. Two approaches are possible with respect to this rendezvous server concept. o First, it is possible to combine a HIP rendezvous server (i.e., PATH server) and a STUN server [7], TURN server [8] or NSIS NATFW [9] node. The client obviously needs to support the clide part of the protocol as well. The STUN, TURN or NSIS NATFW protocol is used to allow the PATH client to learn the public IP address (and port number) created at the NAT. o Second, the HIP registration protocol can integrate a NAT detection check. NAT-T support is provided by IKEv2 [10] and the corresponding extensions have been designed for IKEv1 (see [5] and [11]). This document uses the later approach to avoid the integration of another protocol and additional message exchanges but does not rule-out the former approach. An integration with STUN and TURN would not add more security to the protocol exchange. To support NAT detection a new parameter UDP-REA is introduced. To also allow the client to inform the server about its public IP address and port in a secure fashion (where this is possible and appropriate) another parameter has been defined S-UDP-REA, a secure version of the UDP-REA parameter. Using this parameter a secure Nikander, et al. Expires August 18, 2005 [Page 3] Internet-Draft PATH February 2005 traversal of legacy NATs is supported, for example by interworking with NSIS or MIDCOM. Both, MIDCOM and the NSIS NATFW NSLP provide better security properties. The interaction with these protocols is outside the scope of this document. Please note that this document tries to accomplish a different goal than [12] where middleboxes (such as NATs and firewalls) are assumed to be HIP-aware and participate in the HIP message exchange. As a consequence, the security properties of these protocols are different as well. Nikander, et al. Expires August 18, 2005 [Page 4] Internet-Draft PATH February 2005 2. Terminology 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 [2]. When interaction with a rendezvous server might be possible then we denote these entities as the PATH client and the PATH server traversing some type of legacy NAT. A PATH client is a HIP-aware device which supports the extensions defined in this document in addition to the HIP Registration Extension [13]. The PATH client might be located behind a legacy NAT and initiates the protocol exchange with the PATH server. The PATH server interacts with the client in the way specified in this document. Different types of NATs (e.g., full cone, restricted NAT) are deployed today and [7] assigns these NAT boxes to certain categories based on their data traffic forwarding or blocking behavior. The existence of different NAT types has an impact on the protocol. Nikander, et al. Expires August 18, 2005 [Page 5] Internet-Draft PATH February 2005 3. Protocol Extensions This section explains the necessary protocol extensions to support the above-mentioned functionality. 3.1 UDP Encapsulation of HIP In order to deal with NA[P]Ts, it is necessary that the HIP signaling messages are UDP encapsulated and moreover the source port and the destination port MUST NOT be expected at a fixed port number. This aspect of NAT traversal is known from IPsec/IKE and also reflected in the design of IKEv2. It is a policy issue whether to enable UDP encapsulation immediately when the first HIP base message is sent (i.e., the I1 message). For IPv4, the packet format is shown in Appendix E of [3]. The same specification states that UDP encapsulation is forbidden for IPv6 but might still be necessary particuarly particularly for IPv4-IPv6 transition. 3.2 UDP-REA parameter This section defines the UDP-REA parameter which will be used in the traversal of legacy NATs. Nikander, et al. Expires August 18, 2005 [Page 6] Internet-Draft PATH February 2005 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ HASH ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Padding ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (2 bytes): This parameter has the value of TBD. Length (2 bytes) Represents the length in octets, excluding Type and Length fields. Address Lifetime (4 bytes): This field represents the address lifetime, in seconds. HASH (variable): This field of variable length contains the hash of IP address and port information. Padding (variable): Padding information following the HASH value The HASH is calculated as follows: HASH = PRF(RANDOM | Source IP | Destination IP | Source Port | Destination Port) using the negotiated hash algorithm (denoted as PRF) as part of the HIP_TRANSFORM payload (see Section 6.2.8 of [3]). The hashed data is in the network byte-order. The IP address is 4 octets for an IPv4 address and 16 octets for an IPv6 address. The port number is encoded as a 2 octet number in network byte-order. The necessary padding length depends on the selected hash algorithm. It MUST be ensured that the total length (including padding) of the UDP-REA parameter is 11 + Length - (Length + 3) % 8. The RANDOM value is used to prevent precomputation attacks. The puzzle mechanism could be used for this purpose. Nikander, et al. Expires August 18, 2005 [Page 7] Internet-Draft PATH February 2005 3.3 S-UDP-REA parameter This section defines the S-UDP-REA parameter, a secure UDP-REA parameter version. An end host might be able to retrieve address information securely using some protocols, such as MIDCOM or the NSIS NATFW NSLP. These protocols enable the PATH client to create and retrieve a NAT binding in a secure fashion. This information is then communicated from the PATH client to the PATH server experiencing integrity protection. Furthermore, this extension might also be used when a stateful packet filtering firewall is known to be along the path which requires UDP encapsulation in order to perform properly. UDP-REA Section 3.2 would not be able to detect or act accordingly in such a situation. Nikander, et al. Expires August 18, 2005 [Page 8] Internet-Draft PATH February 2005 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Lifetime |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (2 bytes): This parameter has the value of TBD. Length (2 bytes) Represents the length in octets, excluding Type and Length fields. Address Lifetime (4 bytes): This field represents the address lifetime, in seconds. Type (T) Flag (1 bit): If this bit is set to 1 then the value in the Address field is an IPv6 address otherwise an IPv4 address. Source Port (2 bytes): This field contains the source port. Destination Port (2 bytes): This field contains the destination port. Source Address (4 or 16 bytes): This field contains either an IPv4 or an IPv6 address. Destination Address (4 or 16 bytes): This field contains either an IPv4 or an IPv6 address. Nikander, et al. Expires August 18, 2005 [Page 9] Internet-Draft PATH February 2005 4. Message Handling Rules The PATH client attaches the UDP-REA payload to indicate support for legacy NAT traversal. Thereby it creates a hash value over the source IP address, source port, destination IP and destination port from the IP header of the HIP packet. When the HIP message traverse a NAT along the path between the client and the server, the IP header will be modified. When the server receives the HIP message, it will compare the hash value carried in the HASH field of the UDP-REA parameter and the value computed on the IP address header information. If the two values do not match then the server is assured that someone along the path modified the IP header (and hopefully a NAT and not an adversary). The server will then use the information in the IP header to return a response to the client. If the two values are equal then it is assumed that no NAT is located along the path and UDP encapsulation might not be necessary. This section provides further information on the message handling. o Checksum and length field are provided in the UDP header and might not need to be repeated in the HIP header. o HIP version determined by the destination port used when sending the I1 packet o The digital signature and the keyed message digest is computed over the original payload. First, a "normal" HIP packet is constructed, then the the HMAC and the digital signatures are computed. Afterwards the the HIP packet is encapsulated into the UDP format. o Short timeout (e.g., 200ms) after first packet and therefore encourage NAT-less operation. o If preferred source address is in RFC 1918 address space then send I1 over IP and I1 over UDP a few milliseconds apart. Nikander, et al. Expires August 18, 2005 [Page 10] Internet-Draft PATH February 2005 5. Examples 5.1 HIP Initiator behind a NAT This figure shows the usage of the UDP-REA parameter by the Initiator and the Responder to detect the presence of a NAT along the path. In this case the HIP Initiator is behind a NAT. In this example, the HIP Initiator is behind a NAT and we assume the HIP Initiator immediately starts with UDP encapsulation. Private Public Addressing Addressing HIP Realm Network Address Realm HIP Initiator Translator Responder | | | | I1: Trigger exchange | I1: Trigger exchange | | over UDP | over UDP | | --------------------------> | --------------------------> | | | | | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | | HIP Transform}SIG | HIP Transform}SIG | | UDP-REA(R) | UDP-REA(R) | | <-------------------------- | <-------------------------- | | | | | I2: {Solution,DH(I), | I2: {Solution,DH(I), | | HIP Transform | HIP Transform | | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | | UDP-REA(I) | UDP-REA(I) | | --------------------------> | --------------------------> | | | | | R2: {HMAC}SIG | R2: {HMAC}SIG | | <-------------------------- | <-------------------------- | | | | Figure 3: HIP Initiation behind a NAT Message Flow 5.2 PATH Server Registration and Keep Alive This section illustrates the message exchange for a PATH client registering with a PATH server, as introduced with [13]. After the protocol exchange is finalized both peers will be mutually authenticated and authorized each other and a security association for HIP has been established. When the PATH client starts to interact with the PATH server the client might not be aware of the presence of the legacy NAT along the Nikander, et al. Expires August 18, 2005 [Page 11] Internet-Draft PATH February 2005 path. The I1 registration messages will most likely be dropped by the NA[P]T. After some retransmissions the PATH client will switch to an UDP encapsulated registration protocol exchange. Figure 4 shows such a message exchange. PATH Network Address PATH Client Translator Server | | | | I1: Trigger exchange | | | over IP | | | --------------------------> | ...I1 dropped | | | | | ..retransmissions.. | | | --------------------------> | ...I1 dropped | | | | | I1: Trigger exchange | I1: Trigger exchange | | over UDP | over UDP | | --------------------------> | --------------------------> | | | | | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | | HIP Transform}SIG | HIP Transform}SIG | | <-------------------------- | <-------------------------- | | | | | I2: {Solution,DH(I), | I2: {Solution,DH(I), | | HIP Transform | HIP Transform | | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | | --------------------------> | --------------------------> | | | | | R2: {HMAC}SIG | R2: {HMAC}SIG | | <-------------------------- | <-------------------------- | | | | | | | Figure 4: Registration Protocol Message Flow Additional payloads defined with the HIP Registration Extension are: REG_INFO (carried in the R1 message), REQ_REQ (carried in the I2 message) and REQ_RESP (carried in the R2 message). These payloads are not shown in the above message exchange. Note that this protocol exchange implicitly indicates that the PATH client will use the source IP address of the I1 and I2 messages as the preferred address. The PATH server will use the source IP address of the incoming packet as the preferred address even though it was not authenticated (i.e., integrity protected). The HIP middlebox registration protocol exchange already ensures that this address is authorized via a return routability test. Nikander, et al. Expires August 18, 2005 [Page 12] Internet-Draft PATH February 2005 5.3 Message flow for data receiver behind a NAT This section shows a message flow where one HIP node acting as the data receiver is behind a NAT. The registration with the PATH server is not shown in the figure. Figure 5 only shows the HIP base exchange between the HIP Initiator and the HIP Responder interacting with the PATH server. Figure 5 shows such a protocol exchange taken from [4]. Figure 5 shows that the HIP base exchange between the HIP Initiator and the PATH server does not use UDP encapsulation. UDP encapsulation for HIP signaling messages and for the IPsec data traffic is only enabled between the PATH server and the HIP Responder which is enabled with this extension to the HIP registration protocol. Note that IPsec data traffic will traverse the PATH server to experience UDP encapsulation. The main advantage of this approach is two-fold: (1) the HIP Initiator does not need to support the extension defined in this document and (2) traversal of more restrictive NATs can be supported when the PATH server also changes IP address information Nikander, et al. Expires August 18, 2005 [Page 13] Internet-Draft PATH February 2005 HIP PATH Network Address HIP Initiator Server Translator Responder | | | | | I1 over IP | | | | ----------------> | I1 over UDP | I1 over UDP | | | ----------------> | ----------------> | | | | | | | R1 over UDP | R1 over UDP | | R1 over IP | with UDP-REA | with UDP-REA | | without UDP-REA | <---------------- | <---------------- | | <---------------- | | | | | | | | I2 over IP | | | | without UDP-REA | I2 over UDP | I2 over UDP | | ----------------> | without UDP-REA | without UDP-REA | | | ----------------> | ----------------> | | | | | | | R2 over UDP | R2 over UDP | | R2 over IP | <---------------- | <---------------- | | <---------------- | | | | | | | | IPsec ESP | IPsec ESP | IPsec ESP | | <===============> | over UDP | over UDP | | | <================ | ================> | | | | | | | | | Legend: -->: HIP signaling messages ==>: Data traffic Figure 5: Establishing contact (1/3) Figure 6 modifies the message flow described in Figure 5 whereby R2 is already sent from the HIP Responder to the HIP Initiator directly. The responder thereby creates the necessary NAT binding at the NAT to potentially allow IPsec protected traffic from the initiator towards the responder to traverse the NAT. IPsec protected data traffic is sent only directly between the HIP Initiator and the HIP Responder. Nikander, et al. Expires August 18, 2005 [Page 14] Internet-Draft PATH February 2005 HIP PATH Network Address HIP Initiator Server Translator Responder | | | | | I1 over IP | | | | ----------------> | I1 over UDP | I1 over UDP | | | ----------------> | ----------------> | | | | | | | R1 over UDP | R1 over UDP | | R1 over IP | with UDP-REA | with UDP-REA | | with UDP-REA | <---------------- | <---------------- | | <---------------- | | | | | | | | I2 over IP | | | | without UDP-REA | I2 over UDP | I2 over UDP | | ----------------> | without UDP-REA | without UDP-REA | | | ----------------> | ----------------> | | | | | | R2 over UDP | R2 over UDP | R2 over UDP | | <------------------------------------ | <---------------- | | | | | | IPsec ESP | IPsec ESP | IPsec ESP | | over UDP | over UDP | over UDP | | <==================================== | ================> | | | | | | | | | Figure 6: Establishing contact (2/3) Figure 7 extends Figure 6 further by allowing I2 to be sent directly to the HIP Responder. This is only possible if the NAT forwards packets with a different source IP address and source port than the packets seen from the PATH server towards the HIP Responder. Nikander, et al. Expires August 18, 2005 [Page 15] Internet-Draft PATH February 2005 HIP PATH Network Address HIP Initiator Server Translator Responder | | | | | I1 over IP | | | | ----------------> | I1 over UDP | I1 over UDP | | | ----------------> | ----------------> | | | | | | | R1 over UDP | R1 over UDP | | R1 over IP | with UDP-REA | with UDP-REA | | with UDP-REA | <---------------- | <---------------- | | <---------------- | | | | | | | | I2 over UDP | I2 over UDP | I2 over UDP | | with UDP-REA | with UDP-REA | with UDP-REA | | ------------------------------------> | ----------------> | | | | | | R2 over UDP | R2 over UDP | R2 over UDP | | with UDP-REA | with UDP-REA | with UDP-REA | | <------------------------------------ | <---------------- | | | | | | IPsec ESP | IPsec ESP | IPsec ESP | | over UDP | over UDP | over UDP | | <==================================== | ================> | | | | | | | | | Figure 7: Establishing contact (3/3) FOR DISCUSSION: It needs to be decided which approach is the best one and if there are multiple preferred ways how we (a) can detect which approach is applicable and (b) what protocol extensions are required. The answer most likely depends on the types of NATs we are willing to support. For example, sending the IPsec protected data traffic via the PATH server is useful if a NAT is very restrictive but, as a default approach, probably not the best choice -- except if the PATH server is along the path anyway (see discussion about discovery exchange in the HIP registration protocol). Finally, the message flows need to add info about the information conveyed to the end hosts about the public IP address and port of it respective peer. 5.4 Mobility and multihoming message flow After the PATH client has registered itself to the PATH server, as described in Figure 4, the PATH client might roam within a network or roam outside a network. Whenever the PATH client obtains a new IP address (either due to mobility, IP address reconfiguration or switching of interfaces) a REA message will be sent towards the PATH Nikander, et al. Expires August 18, 2005 [Page 16] Internet-Draft PATH February 2005 server to update the stored IP address information. Note that the initial registration procedure might be executed without a NAT along the path. Hence, the messages are carried over IP and do not require UDP encapsulation. When the PATH client roams to a new network UDP encapsulation might be required due to the presence of a NAT. Hence, it is required to have the capability to enable UDP encapsulation for the HIP exchange (and for the IPsec protected data traffic) not only during the initial protocol exchange. Figure 8 shows such a protocol exchange which is taken from [4]. PATH Network Address PATH Client Translator Server | | | | UPDATE(REA, SEQ) | | | over IP | | | --------------------------> | ...UPDATE/REA dropped | | | | | ..retransmissions.. | | | --------------------------> | ...UPDATE/REA dropped | | | | | UPDATE(REA, SEQ) | UPDATE(REA, SEQ) | | over UDP | over UDP | | --------------------------> | --------------------------> | | | | | UPDATE(SPI, SEQ, | UPDATE(SPI, SEQ, | | ACK, ECHO_REQUEST) | ACK, ECHO_REQUEST) | | <-------------------------- | <-------------------------- | | | | | UPDATE(ACK, ECHO_RESPONSE) | UPDATE(ACK, ECHO_RESPONSE) | | --------------------------> | --------------------------> | | | | | | | Figure 8: Mobility Message Flow Nikander, et al. Expires August 18, 2005 [Page 17] Internet-Draft PATH February 2005 6. Security Considerations Currently this text in this section focuses on the attacks between the PATH client and the PATH server since they differ from the description of threats provided in the past about NAT traversal for mobility protocols. The latter one have been investigated in context of IKE, IKEv2 and various other protocols and will be summarized in a future version of the document. Attacks on the interaction between the PATH client and the PATH server can be classified as denial of service and might be launched against the PATH server itself, against third parties or against the PATH client. PATH servers create state through the HIP registration protocol. A number of counter-measures are built-in into HIP registration protocol. A PATH server might use the client-puzzle mechanism to prevent a certain degree of DoS attacks. Additionally, it might be reasonable to limit the number of registrations at a PATH server itself. Since the PATH server needs to be discovered somehow it needs to be ensured that some security mechanisms are provided for this procedure. For example, if the PATH server is discovered using DNS SRV records then an attacker can compromise the DNS, it can inject fake records which map a domain name to the IP address of a PATH server run by the attacker. This will allow it to inject fake responses to launch a number of the attacks. This discovery procedure might, however, be part of the HIP Registration protocol. A detailed discussion about the security properties of the HIP registration protocol is outside the scope of this document. Even though the base HIP registration protocol is outside the scope of this document some of its security properties are highly relevant and applicable for this discussion. This document extends the capabilities of the registration protocol that might raise security concerns. This section mostly focuses on the security properties of the UDP-REA parameter and it's semantic. 6.1 Third Party Bombing Threat: Third party bombing is also of concern when legacy NAT traversal mechanisms are in place. These attacks have been discovered in the context of Mobile IP and a threat description can be found in [14]. The main problem described in [14] is caused by the missing integrity protection of the IP address communicated from the PATH client to the PATH server. The PATH client cannot protect the IP address (without relying on additional protocol) since a NA[P]T is supposed to change the header's IP address (source, possibly Nikander, et al. Expires August 18, 2005 [Page 18] Internet-Draft PATH February 2005 destination IP address and transport protocol identifiers). Instead of using the protected IP address inside the signaling message the PATH server is supposed to use IP header information. An adversary might provide change the IP header address to point to the intended target. Data sent to the PATH server will be send to the target rather than to the true IP address of the client. Countermeasures: To prevent third party bombing, the address provided by the PATH client via the IP header needs to be verified using a return-routability check. This check might either be provided as part of the base exchange (which involves two roundtrips) or as part of the REA message exchange which also provides mechanisms to execute such a test. This return-routability test MUST be performed in order to ensure that this and other attacks can be thwarted. A third party entity cannot respond to any of these HIP messages due to the cryptographic properties of the HIP base protocol and the multi-homing and mobility extensions. 6.2 Black hole Threat: This attack again exploits the ability for an adversary to act as a NAT and to modify the IP address information in the header. This information will then be used by the PATH server to sent traffic towards the indicated address. If this address is not used by any entity (and particularly by the legitimate PATH client) then the traffic will be dropped. This attack is a denial of service attack. Countermeasures: This threat can be avoided using the same counter measures as third party bombing. 6.3 Man-in-the-middle attack Threat: This attack again requires the adversary to modify the IP header of the HIP registration protocol messages exchanged between the PATH server and the PATH client. Instead of pointing to a black hole or to a third party the adversary provides his address. This allows the adversary to eavesdrop the data traffic. However, in order to launch the attack, the adversary must have already been able to observe packets from the PATH client to the PATH server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe Nikander, et al. Expires August 18, 2005 [Page 19] Internet-Draft PATH February 2005 packets sent to the client. Countermeasures: It is possible that an adversary modifies the IP address information in such a way that it will receive the all traffic for a particular PATH client. Therefore, it is necessary for the adversary to be along the path to mount the initial attack. This will allow the adversary to eavesdrop both the HIP message exchange and the subsequent data traffic. However, the HIP exchange is a cryptographic protocol which is resistant against these types of attack. The data traffic is IPsec protected and therefore the adversary will gain very little profit from this attack. To make things worse for the adversary, if the PATH client roams and uses the HIP registration protocol or the REA message to update state at the PATH server the adversary needs to be located somewhere along the path where it can observe this exchange and to modify it. As a consequence, this attack is not particular useful for the adversary. The S-UDP-REA parameter does not suffer from the same threats as the UDP-REA parameter since it aims to provide a secure mechanism for the PATH server and the PATH client to communicate addressing information. Still, the PATH server might want to authorize the parameters provided by the PATH client by either executing a return-routability check or by using other techniques (e.g., authorization certificates) to ensure that the PATH client is indeed reachable at the indicated addresses. A malicious PATH client might add wrong addressing information to redirect traffic to a black hole or a third party. This threat has a different degree than the previously discussed threats in the sense that the PATH server will most likely know the identity of the PATH client, if we assume that only authenticated and authorized clients are allowed to use the PATH server. If the PATH server is able to detect the malicious behavior it can act accordingly. Finally, it is necessary to add a remark on the usage of NAT/Firewall signaling protocols in relationship with the S-UDP-REA parameter usage. If the PATH client uses these protocols in an insecure or inadequate way then the envisioned security of the S-UDP-REA parameter is seriously affected. A discussion of the security properties of various NAT/Firewall signaling protocols is outside the scope of the document (in the same way as these protocols are outside the scope of this document). Nikander, et al. Expires August 18, 2005 [Page 20] Internet-Draft PATH February 2005 7. IANA Considerations This document extends the HIP registration protocol by defining a new parameter (the UDP-REA and the S-UDP-REA parameter). These parameters need IANA registration: TBD: Changes to the PATH protocol are made through a standards track revision of this specification. This document does not create new IANA registries. Nikander, et al. Expires August 18, 2005 [Page 21] Internet-Draft PATH February 2005 8. IAB Considerations The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism (RFC 3424 [15]). PATH is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements. The text in this section heavily borrows from [7]. 8.1 Problem Definition From RFC 3424 [15], any UNSAF proposal must provide: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't". The specific problem being solved by PATH is to provide a means for a PATH client to detect the presence of one or more NATs between it and a PATH server. The purpose of such detection is to determine the need for UDP encapsulation by the PATH server (i.e., rendezvous server). PATH affect both UDP encapsulation of data traffic (which is IPsec protected) and HIP signaling messages. 8.2 Exit Strategy From [15], any UNSAF proposal must provide: Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed. PATH comes with its own built in exit strategy. This strategy is the detection operation that is performed as a precursor to the actual UNSAF address-fixing operation. The discovery operation, described in Section 3.2, attempts to discover the existence of, and type of, any NATS between the client and the PATH server. PATH does not aim to detect the type of NAT (due to known deficiencies) and the discovery of the existence of NAT is itself quite robust. As NATs are phased out through the deployment of IPv6, the discovery operation will return immediately with the result that there is no Nikander, et al. Expires August 18, 2005 [Page 22] Internet-Draft PATH February 2005 NAT, and no further operations are required. Indeed, the discovery operation itself can be used to help motivate deployment of IPv6; if a user detects a NAT between themselves and the public Internet, they can call up their access provider and complain about it. PATH can also help to facilitate the introduction of MICOM or NSIS. As MIDCOM or NSIS-capable NATs are deployed, HIP end hosts will, instead of using UDP-REA, first allocate an address binding using MIDCOM or NSIS and use S-UDP-REA. However, it is a well-known limitation of MIDCOM that it only works when the agent knows the middleboxes through which its traffic will flow. This issue is fixed with the path-coupled approach followed in NSIS. Once bindings have been allocated from those middleboxes, a PATH detection procedure can validate that there are no additional middleboxes on the path from the PATH server to the PATH client. If this is the case, the HIP end host can continue operation using the address bindings allocated from MIDCOM or NSIS. If it is not the case, PATH provides a mechanism for self-address fixing through the remaining MIDCOM or NSIS-unaware middleboxes. Thus, PATH provides a way to help transition to full MIDCOM or NSIS-aware networks. 8.3 Brittleness Introduced by PATH From [15], any UNSAF proposal must provide: Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition. PATH introduces brittleness into the system in several ways: [EDITOR's NOTE: Depending on the signaling flow and the involvement of the PATH server some behavior is assumed by NATs. There could be other types of NATs that are deployed that would not work well with some of the proposed signaling message flows. For some of the message flows the binding acquisition usage of PATH does not work for all NAT types. It will work for any application for full cone NATs only. For restricted cone and port restricted cone NAT, it may work for some cases. For symmetric NATs, the binding acquisition will not yield a usable address (in case that not all the signaling messages and the entire data traffic is routed through the PATH server). The tight dependency on the specific type of NAT makes the protocol brittle.] PATH assumes that the server exists on the public Internet. If the server is located in another private address realm, the HIP end host may or may not be able to use the established state at the PATH server. This heavily depends on the protocol interaction Nikander, et al. Expires August 18, 2005 [Page 23] Internet-Draft PATH February 2005 between the other HIP end host and possibly other PATH servers than are cascaded. The bindings allocated from the NAT need to be continuously refreshed. Since the timeouts for these bindings is implementation specific, the refresh interval cannot easily be determined. When the binding is not being actively used to receive traffic, but to wait for an incoming message, the binding refresh will needlessly consume network bandwidth. The use of the PATH server as an additional network element introduces another point of potential security attack. These attacks are largely prevented by the security measures provided the HIP registration protocol, but not entirely. The use of the PATH server as an additional network element introduces another point of failure. If the client cannot locate a PATH server, or if the server should be unavailable due to failure, no interaction can be performed. The use of PATH to enable UDP encapsulation for IPsec protected data traffic and for HIP messages introduces an additional bandwidth consumption which might be problematic in certain wireless networks. The modified packet forwarding through the PATH server, which might be necessary to ensure traversal of certain NAT types, might represent a non-optimal route and may increase latency for some applications (depending on the location of the PATH server). 8.4 Requirements for a Long Term Solution From [15], any UNSAF proposal must provide: Identify requirements for longer term, sound technical solutions - contribute to the process of finding the right longer term solution. Our experience with PATH has led to the following requirements for a long term solution to the NAT problem: Requests for bindings and control of other resources in a NAT need to be explicit. Much of the brittleness in PATH derives from its guessing at the parameters of the NAT, rather than telling the NAT what parameters to use. Control needs to be "in-band". There are far too many scenarios in which the client will not know about the location of middleboxes ahead of time. Instead, control of such boxes needs to occur in-band, traveling along the same path as the data will itself travel. This guarantees that the right set of middleboxes are controlled. NSIS exactly provides a solution for this purpose. Third-party controls are best handled using the MIDCOM framework. Nikander, et al. Expires August 18, 2005 [Page 24] Internet-Draft PATH February 2005 Control needs to be limited. Users will need to communicate through NATs which are outside of their administrative control. In order for providers to be willing to deploy NATs which can be controlled by users in different domains, the scope of such controls needs to be extremely limited - typically, allocating a binding to reach the address where the control packets are coming from. Simplicity is paramount. The control protocol will need to be implement in very simple clients. The servers will need to support extremely high loads. The protocol will need to be extremely robust, being the precursor to a host of application protocols. As such, simplicity is key. 8.5 Issues with Existing NAPT Boxes From [15], any UNSAF proposal must provide: Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports. Several of the practical issues with PATH involve future proofing - breaking the protocol when new NAT types get deployed. Fortunately, this is not an issue at the current time, since most of the deployed NATs are of the types assumed by PATH. The primary usage PATH has been found in the area of VoIP, to facilitate allocation of addresses for receiving RTP [12] traffic. In that application, the periodic keepalives are provided by the RTP traffic itself. However, several practical problems arise for RTP. First, RTP assumes that RTCP traffic is on a port one higher than the RTP traffic. This pairing property cannot be guaranteed through NATs that are not directly controllable. As a result, RTCP traffic may not be properly received. Protocol extensions to SDP have been proposed which mitigate this by allowing the client to signal a different port for RTCP [18]. However, there will be interoperability problems for some time. For VoIP, silence suppression can cause a gap in the transmission of RTP packets. This could result in the loss of a binding in the middle of a call, if that silence period exceeds the binding timeout. This can be mitigated by sending occasional silence packets to keep the binding alive. However, the result is additional brittleness; proper operation depends on the silence suppression algorithm in use, the usage of a comfort noise codec, the duration of the silence period, and the binding lifetime in the NAT. 8.6 In Closing Some of the limitations of PATH are not design flaws. Due to the Nikander, et al. Expires August 18, 2005 [Page 25] Internet-Draft PATH February 2005 properties of HIP, PATH is fairly secure and robust form of legacy NAT traversal compared to other approach such as STUN. Some limitations are, however, related to the lack of standardized behaviors and controls in NATs. The result of this lack of standardization has been a proliferation of devices whose behavior is highly unpredictable, extremely variable, and uncontrollable. PATH does the best it can in such a hostile environment. Ultimately, the solution is to make the environment less hostile, and to introduce controls and standardized behaviors into NAT. However, until such time as that happens, PATH provides a good short term solution given the terrible conditions under which it is forced to operate. PATH also offers a long-term solution if NATs are NSIS or MIDCOM aware. The main benefit is increased secure and a less brittle protocol operation since the NAT (or even firewalls) can be controlled and should then behave according to respective middlebox signaling protocol. Ultimately, NAT boxes might be HIP aware. Nikander, et al. Expires August 18, 2005 [Page 26] Internet-Draft PATH February 2005 9. Acknowledgements The authors would like to thank Julien Laganier, Aarthi Nagarajan and Murugaraj Shanmugam for their feedback on this document. Nikander, et al. Expires August 18, 2005 [Page 27] Internet-Draft PATH February 2005 10. Open Issues This document is a first attempt in defining HIP NAT/Firewall traversal extensions. The document raises some questions with regard to the usage of the PATH server and the later flow of data packets. The document still lacks a number of details which would benefit from hands-on experience. Nikander, et al. Expires August 18, 2005 [Page 28] Internet-Draft PATH February 2005 11. References 11.1 Normative References [1] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extensions", Internet-Draft draft-ietf-hip-rvs-00, October 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [3] Moskowitz, R., "Host Identity Protocol", Internet-Draft draft-ietf-hip-base-01, October 2004. [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", Internet-Draft draft-ietf-hip-mm-00, October 2004. 11.2 Informative References [5] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [6] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [8] Rosenberg, J., "Traversal Using Relay NAT (TURN)", Internet-Draft draft-rosenberg-midcom-turn-06, October 2004. [9] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October 2004. [10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. [11] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", Internet-Draft draft-ietf-ipsec-nat-t-ike-08, February 2004. [12] Tschofenig, H., Nagarajan, A., Torvinen, V. and J. Ylitalo, "NAT and Firewall Traversal for HIP", Internet-Draft draft-tschofenig-hiprg-natfw-traversal-01.txt, February 2005. Nikander, et al. Expires August 18, 2005 [Page 29] Internet-Draft PATH February 2005 [13] Laganier, J., Koponen, T. and L. Eggert, "A Middlebox Registration Protocol for HIP", Internet-Draft draft-koponen-hip-registration-00.txt, February 2005. [14] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", Internet-Draft draft-dupont-mipv6-3bombing-01, January 2005. [15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [16] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. Authors' Addresses Pekka Nikander Ericsson Research Nomadic Lab Hirsalantie 11 Turku FIN FIN-02420 JORVAS Finland Phone: +358 9 299 1 Email: pekka.nikander@nomadiclab.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Thomas R. Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA Email: thomas.r.henderson@boeing.com Nikander, et al. Expires August 18, 2005 [Page 30] Internet-Draft PATH February 2005 Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Email: lars.eggert@netlab.nec.de Julien Laganier Sun Labs (Sun Microsystems) and LIP (CNRS/INRIA/ENSL/UCBL) 180, Avenue de l'Europe Saint Ismier CEDEX 38334 France Phone: +33 476 188 815 Email: ju@sun.com URI: http://research.sun.com Nikander, et al. Expires August 18, 2005 [Page 31] Internet-Draft PATH February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Nikander, et al. Expires August 18, 2005 [Page 32]