idnits 2.17.00 (12 Aug 2021) /tmp/idnits15917/draft-ietf-hip-nat-traversal-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1565. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2007) is 5555 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. 'I-D.ietf-hip-esp') == Outdated reference: draft-ietf-hip-mm has been published as RFC 5206 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. 'I-D.ietf-hip-mm') == Outdated reference: draft-ietf-hip-rvs has been published as RFC 5204 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. 'I-D.ietf-hip-rvs') == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-06 -- Possible downref: Normative reference to a draft: ref. 'I-D.nikander-esp-beet-mode' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: draft-ietf-behave-nat-behavior-discovery has been published as RFC 5780 == Outdated reference: draft-ietf-behave-nat-udp has been published as RFC 4787 == Outdated reference: draft-irtf-hiprg-nat has been published as RFC 5207 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group M. Komu, Ed. 3 Internet-Draft HIIT 4 Intended status: Standards Track S. Schuetz 5 Expires: September 6, 2007 M. Stiemerling 6 NEC 7 L. Eggert 8 Nokia 9 A. Pathak 10 IIT Kanpur 11 March 5, 2007 13 HIP Extensions for the Traversal of Network Address Translators 14 draft-ietf-hip-nat-traversal-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 6, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document specifies extensions to Host Identity Protocol (HIP) to 48 support traversal of Network Address Translator (NAT) middleboxes. 50 The traversal mechanism tunnels HIP control and data traffic over UDP 51 and enables HIP initiators which MAY be behind NATs to contact HIP 52 responders which MAY be behind another NAT. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 6 62 3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6 63 3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 7 64 3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 8 65 3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 8 66 3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 8 67 3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 10 68 3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 10 69 3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 11 70 3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 13 71 3.3.3. Use of the Rendezvous Service when only the 72 Initiator is Behind NAT . . . . . . . . . . . . . . . 15 73 3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 17 74 3.4.1. Rendezvous Client Registration From Behind NAT . . . . 17 75 3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 18 76 3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 20 77 3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 22 78 3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 22 79 3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 25 80 3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 26 81 3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 27 82 3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 29 83 3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 29 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 30 85 4.1. A Difference to RFC3948 . . . . . . . . . . . . . . . . . 30 86 4.2. Rendezvous and Responder Privacy . . . . . . . . . . . . . 30 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 92 Appendix A. Document Revision History . . . . . . . . . . . . . . 33 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 94 Intellectual Property and Copyright Statements . . . . . . . . . . 35 96 1. Introduction 98 The Host Identity Protocol (HIP) describes a new communication 99 mechanism for Internet hosts [RFC4423]. It introduces a new 100 namespace and protocol layer between the network and transport layers 101 that decouples the identifier and locator roles to support e.g. 102 mobility and multihoming in the Internet architecture. 104 The HIP protocol [I-D.ietf-hip-base] cannot operate across Network 105 Address Translator (NAT) middleboxes, as described in 106 [I-D.irtf-hiprg-nat]. This document specifies how HIP can traverse 107 through legacy NAT middleboxes that are not aware of HIP or ESP. The 108 mechanisms defined in this document do not assume that the NAT 109 middleboxes are reconfigured, as long as they allow UDP traffic. 111 The use of HIP in NAT traversal has also some additional benefits 112 provided by the new namespace. First, it is possible to address 113 hosts behind a single NAT middlebox in a relatively simple way. The 114 NAT middlebox translates the locators, but the Host Identifiers and 115 ESP SPIs remain the same. Second, multiple services can share the 116 same transport layer port number behind a single NAT. There is no 117 multiplexing issue as long as these services have different Host 118 Identifiers. 120 Several different flavors of NATs exist [RFC2663]. This document 121 describes HIP extensions for the traversal of both Network Address 122 Translator (NAT) and Network Address and Port Translator (NAPT) 123 middleboxes. It generally uses the term NAT to refer to both types 124 of middleboxes, unless it needs to distinguish between the two types. 126 Three basic cases exist for NAT traversal. In the first case, only 127 the initiator of a HIP base exchange is located behind a NAT. In the 128 second case, only the responder of a HIP base exchange is located 129 behind a NAT. The respective peer host is assumed to be located at a 130 publicly reachable address in both cases. In the third case, both 131 parties are located behind (different) NATs. This document describes 132 extensions for the first case in Section 3.3, for the second case in 133 Section 3.4 and in Section 3.5 for the third case. 135 The mechanisms described here also cover use of rendezvous server 136 from NATted environments. The rendezvous server MUST be used when 137 the responder is behind a NAT because otherwise successful NAT 138 traversal cannot be guaranteed. The rendezvous server MUST be 139 located in a publicly addressable location. Cascading of multiple 140 NAT enabled rendezvous servers is not possible, although there may be 141 other kind of rendezvous servers on the path. The NAT middleboxes 142 MUST support address independent mapping in the case where both hosts 143 are behind NAT devices. Otherwise, some other external relaying 144 mechanism MUST be used. Endpoint independent filtering is not 145 required in any of the cases. The NAT categories are defined in 146 [I-D.srisuresh-behave-p2p-state]. 148 The mechanisms described in this document are based on encapsulating 149 both the control and data traffic in UDP in order to traverse NAT(s). 150 The data traffic is assumed to be ESP. Other types of data traffic 151 are out of scope for this document. The responder listens at a fixed 152 UDP port number for incoming HIP control packets. The port number 153 can be manually configured to the NAT to allow passing incoming 154 traffic directly to the host behind the NAT (port forwarding). The 155 benefit of such a configuration is that it does not require any 156 rendezvous server for the host behind the NAT. Although this 157 document does not prevent such configurations, it is out of scope 158 because of two drawbacks. First, it allows only a single responder 159 behind the NAT box. Second, manual configuration through several NAT 160 devices may be difficult or administratively prohibited. 162 The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm], 163 allow HIP hosts to change network location during the lifetime of a 164 HIP association. Consequently, hosts need to start using the 165 proposed NAT traversal mechanisms after a mobility event relocates 166 one or both peers behind a NAT. They may also stop using the 167 proposed mechanisms if they both move to publicly addressable 168 locations. 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 2. Detecting NATs 176 In order to know whether to use the NAT traversal mechanisms, HIP 177 hosts need to detect the presence and type of NAT middleboxes along 178 the path to their peer hosts. This document does not describe any 179 new NAT detection mechanism but rather assumes that the NAT is 180 detected using some external mechanism. Hence, no special HIP 181 parameters are required in HIP control messages to detect NATs. The 182 NAT detection MUST occur prior to a base exchange, after node 183 movement and prior to sending UPDATE messages. 185 For example, STUN [RFC3489] offers a generic mechanism for detecting 186 both the presence and type of a NAT. In STUN, the host contacts a 187 STUN server that is always located at a publicly reachable address. 188 The STUN server replies back and provides information on the NAT 189 presence and type. 191 A limitation of STUN is that it cannot detect whether the responder 192 is behind the same NAT as the initiator. This can lead to an 193 unoptimal route through the public address of the NAT, especially in 194 combination the rendezvous extensions that are described later in 195 this document. In the worst case, the NAT may not be able to forward 196 the traffic unless it supports "hairpin translation" as described in 197 [I-D.srisuresh-behave-p2p-state]. 199 To guarantee connectivity behind the same NAT, the initiator MUST 200 detect the hairpin support of the NAT as described in 201 [I-D.ietf-behave-nat-behavior-discovery]. If the NAT supports 202 hairpinning, the initiator uses the UDP encapsulation procedures 203 described in the following sections. If the NAT does not support 204 hairpinning, the initiator SHOULD broadcast a single I1 packet 205 without UDP encapsulation to the local network. The responder MUST 206 process the I1 according to [I-D.ietf-hip-base]. However, the 207 initiator MUST continue with the UDP encapsulation mechanisms 208 described in the following sections because the responder may 209 actually be located in a different network. 211 HIP-aware NATs are not in the scope of this document. In the future, 212 it may be possible to use some other protocol that is launched in 213 parallel with e.g. STUN to detect the presence of HIP aware NATs. 214 When the path between the initiator and responder consists of HIP 215 aware NATs, the extensions defined in this document SHOULD NOT be 216 used. 218 3. HIP Across NATs 220 The HIP base exchange as defined in [I-D.ietf-hip-base] works well in 221 public networks. However, this does not work with some legacy NATs 222 that are not able to multiplex HIP or ESP traffic. As a result, such 223 NATs just drop HIP control traffic and/or ESP data traffic. As a 224 solution for this, we propose UDP encapsulation of control and data 225 traffic using a specific scheme described in this document. The 226 scheme also allows hosts behind NATs to act as servers. 228 [RFC3948] describes UDP encapsulation of transport and tunnel mode 229 ESP packets. This document describes a similar mechanism for BEET 230 mode ESP packets [I-D.nikander-esp-beet-mode]. 232 3.1. Packet Formats 234 This section defines the UDP-encapsulation packet format for HIP base 235 exchange and control traffic, IPsec ESP BEET-mode traffic and NAT 236 keep-alive. 238 3.1.1. Control Traffic 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Source Port | Destination Port | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Length | Checksum | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 ~ HIP Header and Parameters ~ 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 1: Format for UDP-encapsulated HIP control traffic. 254 Figure 1 shows how HIP control packets are encapsulated within UDP. 255 A minimal UDP packet carries a complete HIP packet in its payload. 256 Contents of the UDP source and destination ports are described below. 257 The UDP length and checksum field MUST be computed as described in 258 [RFC0768]. The HIP header and parameter follow the conventions 259 [I-D.ietf-hip-base] with the exception that the HIP header checksum 260 MUST be zero. The HIP headers checksum is zero for two reasons. 261 First, the UDP header contains already a checksum. Second, the 262 checksum definition in [I-D.ietf-hip-base] includes the IP addresses 263 in the checksum calculation which is not applicable on HIP unaware 264 NAT devices. 266 3.1.2. Control Channel Keep-Alives 268 The keep-alive for control channel are basically UDP encapsulated 269 NOTIFY packets [I-D.ietf-hip-base]. The NOTIFY packets MAY contain 270 HIP parameters. The NAT traversal mechanisms encapsulate these 271 NOTIFY packets within the payload of UDP packets. 273 3.1.3. Data Traffic 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Source Port | Destination Port | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Length | Checksum | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 ~ ESP Header ~ 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic. 288 Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated 289 within UDP. Again, a minimal UDP packet carries the ESP packet in 290 its payload. The contents of the UDP source and destination ports 291 are described in later sections. The UDP length and checksum field 292 MUST be computed as described in [RFC0768]. 294 3.1.4. FROM_NAT Parameter 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 | Address | 303 | | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | UDP Port | Padding | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ] 310 Length 18 311 Address An IPv6 address or an IPv4 address in IPv4-in-IPv6 312 format. 313 UDP Port A UDP port number 315 Figure 3: Format for the FROM_NAT Parameter 317 Figure 3 shows FROM_NAT parameter. The use of this parameter is 318 described in the following sections. 320 3.1.5. VIA_RVS_NAT Parameter 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 | Address | 329 | | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | UDP Port | Padding | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ] 336 Length 16 337 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 338 UDP Port A UDP port 340 Figure 4: Format for the VIA_RVS_NAT Parameter 342 Figure 4 shows VIA_RVS_NAT parameter. The parameter is used for 343 diagnostic purposes, similarly as VIA_RVS parameter in 344 [I-D.ietf-hip-rvs]. The exact use of this parameter is described in 345 later sections. 347 3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP 349 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 350 tunnel mode. This section describes the UDP encapsulation of the 351 BEET mode. 353 3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP 355 During the HIP base exchange, the two peers exchange parameters that 356 enable them to define a pair of IPsec ESP security associations 357 (SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a 358 UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs 359 that result in UDP-encapsulated BEET-mode ESP data traffic. 361 The management of encryption and authentication protocols and 362 security parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. 363 Additional SA parameters, such as IP addresses and UDP ports, MUST be 364 defined according to this section. Two SAs MUST be defined on each 365 host for one HIP association; one for outgoing data and another one 366 for incoming data. 368 The BEET mode provides limited tunnel mode semantics without the 369 regular tunnel mode overhead. [I-D.nikander-esp-beet-mode] In the 370 BEET mode, transport-layer checksums in the payload data are based on 371 the HITs. The packet MUST then undergo BEET-mode ESP cryptographic 372 processing as defined in Section 5.3 of [I-D.nikander-esp-beet-mode]. 374 Next, the resulting BEET-mode packet is UDP encapsulated. For this 375 purpose, a UDP header MUST be inserted between the IP and ESP header. 376 The source and destination ports are filled in. The UDP checksum 377 MUST be calculated based on the outer addresses (locators) of the 378 IPsec security association. The other fields of the UDP header are 379 computed as described in [RFC0768]. 381 The resulting UDP packet MUST then undergo BEET IP header processing 382 as defined in Section 5.4 of [I-D.nikander-esp-beet-mode]. 384 Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a 385 TCP packet. 387 ORIGINAL TCP PACKET: 388 +------------------------------------------+ 389 | inner IPv6 hdr | ext hdrs | | | 390 | with HITs | if present | TCP | Data | 391 +------------------------------------------+ 393 PACKET AFTER BEET-MODE ESP PROCESSING: 394 +----------------------------------------------------------+ 395 | inner IPv6 hdr | ESP | dest | | | ESP | ESP | 396 | with HITs | hdr | opts.| TCP | Data | Trailer | ICV | 397 +----------------------------------------------------------+ 398 |<------- encryption -------->| 399 |<----------- integrity ----------->| 401 FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING: 402 +------------------------------------------------------------+ 403 | outer IPv4 | UDP | ESP | dest | | | ESP | ESP | 404 | hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV | 405 +------------------------------------------------------------+ 406 |<------- encryption -------->| 407 |<----------- integrity ----------->| 409 Figure 5: UDP Encapsulation of an IPsec BEET-mode ESP packet 410 containing a TCP segment. 412 3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP 414 An incoming UDP-encapsulated IPsec BEET-mode ESP packet is 415 decapsulated as follows. First, if the UDP checksum is invalid, then 416 the packet MUST be dropped. Then, the packet MUST be verified as 417 defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data 418 contained in the payload of the UDP packet MUST be decrypted as 419 described in [I-D.nikander-esp-beet-mode]. 421 The NAT traversal methods described in this section are based on 422 connection reversal and UDP hole punching similar to 423 [I-D.ietf-behave-nat-udp]. However, the methods in this section are 424 adapted for HIP purposes, especially with the rendezvous server in 425 mind. 427 3.3. Initiator Behind NAT 429 This section discusses mechanisms to reach a HIP responder located in 430 publicly addressable network by a HIP initiator that is located 431 behind a NAT. The section describes also the case where the 432 responder is using a rendezvous service. 434 Table 1 lists some short-hand notations used in this section. For 435 simplicity, the ports mangled by NAT are presented as example port 436 numbers (11111, 22222, etc) instead of symbolic ones. In the 437 examples, we assume that the NAT(s) timeout after the I1-R1 exchange 438 over UDP because of e.g large RTT or high puzzle difficulty. In such 439 a case, the NAT drops the related UDP port state and port numbers 440 change for the I2-R2 exchange. 442 +------------------+------------------------------------------------+ 443 | Notation | Explanation | 444 +------------------+------------------------------------------------+ 445 | HIT-I | Initiator's HIT | 446 | HIT-R | Responder's HIT | 447 | IP-I | Initiator's IP address | 448 | IP-R | Responder's IP address | 449 | IP-RVS | IP address of the responder's rendezvous | 450 | | server | 451 | IP-NAT-I | Public IP of the NAT of the initiator | 452 | IP-NAT-R | Public IP of the NAT of the responder | 453 | UDP(50500,11111) | UDP packet with source port 50500 and | 454 | | destination port 11111 | 455 | UDP(11111,22222) | Example port numbers mangled by a NAT | 456 | UDP(44444,22222) | Port 44444 is used throughout the examples to | 457 | | denote the NAT mangled source port of I2 as | 458 | | received by the rendezvous server during the | 459 | | registration | 460 +------------------+------------------------------------------------+ 462 Table 1: Notations Used in This Section 464 3.3.1. NAT Traversal of HIP Control Traffic 466 This section describes the details of enabling NAT traversal for HIP 467 control traffic for the base exchange [I-D.ietf-hip-base] through UDP 468 encapsulation for the case when the initiator of the association is 469 located behind a NAT and the responder is located in a publicly 470 addressable network. UDP-encapsulated HIP control traffic MUST use 471 the packet formats described in Section 3.1. When sending UDP- 472 encapsulated HIP control traffic, a HIP implementation MUST zero the 473 HIP header checksum before calculating the UDP checksum. The 474 receiver MUST only verify the correctness of the UDP checksum and 475 MUST NOT verify the checksum of the HIP header. 477 The initiator of a UDP-encapsulated HIP base exchange MUST use the 478 UDP destination port 50500 for all control packets it sends. It is 479 RECOMMENDED to use 50500 as the source port as well, but an 480 implementation MAY use a (randomly selected) unoccupied source port. 481 If it uses a random source port, it MUST listen for and accept 482 arriving HIP control/ESP Data packets on this port until the 483 corresponding HIP association is torn down. The random source port 484 is RECOMMENDED to be in the range of the dynamic and private ports 485 (49152-65535). Using a random source port, instead of a fixed one, 486 enables to have multiple clients behind a NAT middlebox that supports 487 only address translation but no port translation. This is referred 488 to as port overloading in [I-D.ietf-behave-nat-udp]. 490 The responder of a UDP-encapsulated HIP base exchange MUST use 50500 491 as the source port for all UDP-encapsulated control packets it sends. 492 The source address for all the packets that the responder sends MUST 493 be the same as the IP address on which responder receives packets 494 from initiator. The responder MUST respond to any arriving UDP- 495 encapsulated control message using UDP encapsulation as well. Hosts 496 MUST process UDP-encapsulated base exchange messages equivalently to 497 non-encapsulated messages, i.e., according to [I-D.ietf-hip-base]. 499 The remainder of this section clarifies this process through an 500 example which is illustrated in Figure 6. It shows an initiator with 501 the private address IP-I behind a NAT. The NAT has the public IP 502 address as NAT. The responder is in a publicly addressable location 503 IP-R. 505 +---+ +---+ +---+ 506 | |----(1)--->| |---------------(2)-------------->| | 507 | | | N | | | 508 | |<---(4)----| A |<--------------(3)---------------| | 509 | I | | T | | R | 510 | |----(5)--->| - |---------------(6)-------------->| | 511 | | | I | | | 512 | |<---(8)----| |<--------------(7)---------------| | 513 +---+ +---+ +---+ 515 1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 516 2. IP(IP-NAT-I, IP-R) UDP(11111, 50500) I1(HIT-I, HIT-R) 517 3. IP(IP-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I) 518 4. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I) 519 5. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 520 6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I2(HIT-I, HIT-R) 521 7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R2(HIT-R, HIT-I) 522 8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 524 Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator 525 behind a NAT, responder in a publicly addressable location). 527 Before beginning the base exchange, the initiator detects that it is 528 behind a NAT through some external mechanism, e.g. STUN. The 529 initiator starts the base exchange by sending a UDP-encapsulated I1 530 packet to the responder. According to the rules specified above, the 531 source IP address of this I1 packet is IP-I and its source UDP port 532 is 50500. It is addressed to IP-R on port 50500. The NAT in 533 Figure 6 forwards the I1 but substitutes the source address IP-I with 534 its own public address IP-NAT-I and the source UDP port 50500 with 535 11111. 537 When the responder in Figure 6 receives the UDP-encapsulated I1 538 packet on UDP port 50500, it decapsulates the packet and processes 539 the decapsulated packet according to [I-D.ietf-hip-base]. The 540 responder replies back with a UDP-encapsulated R1 using the addresses 541 and port information of I1. Thus, the R1 packet is destined to the 542 source IP address and UDP port of the I1, i.e., IP address IP-NAT-I 543 and port 11111. The NAT receives the I1 and substitutes the 544 destination of this packet with the initiator address (IP-I) and port 545 information (50500). 547 The initiator receives a UDP-encapsulated R1 packet from the 548 responder, decapsulates and processes it according to 549 [I-D.ietf-hip-base]. When it responds with a UDP-encapsulated I2 550 packet, it uses the same IP source and destination addresses and UDP 551 source and destination ports that it used for sending the 552 corresponding I1 packet, i.e., the packet is addressed from IP-I port 553 50500 to IP-R port 50500. The NAT again substitutes the source 554 information. For illustration purposes, the NAT state times out and 555 it chooses a different source port (22222) for the I2 than for the I1 556 (11111). 558 When a responder receives a UDP-encapsulated I2 packet destined to 559 UDP port 50500, it MUST use the UDP source port contained in this 560 packet for further HIP communications with the initiator. It then 561 processes the I2 packet according to [I-D.ietf-hip-base]. When it 562 responds with an R2 message, it UDP-encapsulates the message, using 563 the UDP source port of the I2 packet as the destination UDP port, and 564 sends it to the source IP address of the I2 packet, i.e., it sends 565 the R2 packet from IP-R port 50500 to IP-NAT-I port 22222. The NAT 566 again replaces the destination information in the R2 with IP-I port 567 50500 569 Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT 570 state to persist. This means that the NAT uses the same port for the 571 I1-R1 exchange to translate as the I2-R2 exchange. However, the host 572 MUST handle even the case where the NAT state times out between the 573 two exchanges and the I1 and I2 arrive from different UDP source 574 ports and/or IP addresses, as illustrated in Figure 6. 576 3.3.2. NAT Traversal of HIP Data Traffic 578 This section describes the details of enabling NAT traversal of HIP 579 data traffic. As described in Section 3, HIP data traffic is carried 580 in UDP-encapsulated IPsec BEET-mode ESP packets. 582 3.3.2.1. IPsec BEET-Mode Security Associations 584 The initiator MUST use UDP destination port 50500 for all UDP- 585 encapsulated ESP packets it sends. It MAY also use port 50500 as 586 source port or it MAY use a random source port. If it uses a random 587 source port, it MUST listen for and accept arriving UDP-encapsulated 588 ESP packets on this port until the corresponding HIP association is 589 torn down. 591 The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST 592 use 50500 as the source port for all UDP-encapsulated ESP packets it 593 sends. The destination port is the port from which the responder is 594 receiving UDP encapsulated ESP data from the initiator. 596 Both the initiator and the responder of a HIP association MUST define 597 BEET mode with UDP encapsulation as the IPsec mode for the SA after a 598 successful base exchange. The inner source address MUST be the local 599 HIT used during base exchange and the inner destination address MUST 600 be the HIT of the peer. The other parts of the SA are described in 601 individual sections. 603 3.3.2.1.1. Security Associations at the Initiator 605 The initiator of a UDP-encapsulated base exchange defines its 606 outbound SA as shown in Table 2 608 +--------------+----------------------------------------------------+ 609 | Field | Value | 610 +--------------+----------------------------------------------------+ 611 | Outer src | The local IP address from which the base exchange | 612 | address | packets were transmitted | 613 | Outer dst | The peer IP address to which base exchange packets | 614 | address | were transmitted | 615 | UDP src port | The port number as chosen for I2 packet in base | 616 | | exchange | 617 | UDP dst port | Port 50500 | 618 +--------------+----------------------------------------------------+ 620 Table 2: Outbound SA at initiator 622 The initiator of a UDP-encapsulated base exchange defines its inbound 623 SA as shown in Table 3 625 +--------------+----------------------------------------------------+ 626 | Field | Value | 627 +--------------+----------------------------------------------------+ 628 | Outer src | The peer IP address to which base exchange packets | 629 | address | were transmitted | 630 | Outer dst | The local IP address from which the base exchange | 631 | address | packets were transmitted | 632 | UDP src port | Port 50500 | 633 | UDP dst port | Initiator MUST use the UDP source port it uses in | 634 | | the outbound SA here | 635 +--------------+----------------------------------------------------+ 637 Table 3: Inbound SA at initiator 639 3.3.2.1.2. Security Associations at the Responder 641 The responder of a UDP-encapsulated base exchange defines its 642 outbound SA shown in Table 4. 644 +-------------+-----------------------------------------------------+ 645 | Field | Value | 646 +-------------+-----------------------------------------------------+ 647 | Outer src | The local IP address from which the base exchange | 648 | address | packets were transmitted | 649 | Outer dst | Peer IP address of the I2 packet received during | 650 | address | the base exchange | 651 | UDP src | Port 50500 | 652 | port | | 653 | UDP dst | Source UDP port of the I2 packet received from the | 654 | port | initiator during base exchange | 655 +-------------+-----------------------------------------------------+ 657 Table 4: Outbound SA at Responder 659 Similarly, the responder of a UDP-encapsulated base exchange defines 660 its inbound SA as shown in Table 5 662 +-------------+-----------------------------------------------------+ 663 | Field | Value | 664 +-------------+-----------------------------------------------------+ 665 | Outer src | Source IP address of the I2 packet received from | 666 | address | the initiator during base exchange | 667 | Outer dst | The local IP address from which the base exchange | 668 | address | packets were transmitted | 669 | UDP src | Source UDP port of the I2 packet received from the | 670 | port | initiator during base exchange | 671 | UDP dst | Port 50500 | 672 | port | | 673 +-------------+-----------------------------------------------------+ 675 Table 5: Inbound SA at responder 677 3.3.3. Use of the Rendezvous Service when only the Initiator is Behind 678 NAT 680 The rendezvous extensions for HIP without NAT traversal have been 681 defined in [I-D.ietf-hip-rvs]. This section addresses only the 682 scenario where a NATted HIP node uses the rendezvous service to 683 contact another HIP node in a publicly addressable network. Figure 7 684 illustrates the mechanism described in this section. 686 A rendezvous server MUST listen on UDP port 50500 for incoming UDP 687 encapsulated I1 packets. However, in this specific case with only 688 the initiator behind NAT, the rendezvous server MUST NOT relay the I1 689 packets. Instead, the rendezvous server replies to the initiator 690 with a NOTIFY message that includes the responder's locator in a 691 VIA_RVS parameter. The rendezvous server can differentiate this 692 scenario from the others because the I1 arrives UDP encapsulated, but 693 the responder has registered without UDP encapsulation. 695 Upon receiving the NOTIFY with the locators of the responder through 696 the NAT, the initiator MUST send an I1 to the responder. However, it 697 MUST continue retransmissions using the RVS location. This is 698 mandatory because NOTIFY messages are not protected with signatures 699 and can be forged by a rogue host. 701 When the initiator receives an R1 through the NAT, the responder 702 verifies the integrity of the packet and replies with an I2. The 703 responder should be aware that the I2 may arrive from a different 704 port than the I1. In such a case, the responder should send the R2 705 to the source port of I2. 707 +---+ +---+ +-------+ +---+ 708 | |----(1)--->| |---------------(2)-->| | | | 709 | | | | | RVS R | | | 710 | |<---(4)----| |<--------------(3)---| | | | 711 | | | | +-------+ | | 712 | | | N | | | 713 | |----(5)--->| A |---------------(6)-------------->| | 714 | I | | T | | R | 715 | |<---(8)----| - |<--------------(7)---------------| | 716 | | | T | | | 717 | |----(9)--->| |---------------(10)------------->| | 718 | | | | | | 719 | |<---(11)---| |<--------------(12)--------------| | 720 +---+ +---+ +---+ 722 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 723 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 724 3. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) 725 NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R)) 726 4. IP(IP-RVS, IP-I) UDP(50500, 50500) 727 NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R)) 728 5. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 729 6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I1(HIT-I, HIT-R) 730 7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R1(HIT-R, HIT-I) 731 8. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I) 732 9. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 733 10. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I2(HIT-I, HIT-R) 734 11. IP(IP-R, IP-NAT-I) UDP(50500, 33333) R2(HIT-R, HIT-I) 735 12. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 737 Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS 738 (initiator behind a NAT, responder and RVS on the public Internet). 740 3.4. Responder Behind NAT 742 This section discusses mechanisms to reach a HIP responder that is 743 located behind a NAT. This section assumes that the initiator is 744 located on publicly addressable network. The initiator contacts the 745 responder through an RVS server. 747 3.4.1. Rendezvous Client Registration From Behind NAT 749 The rendezvous client registration [I-D.ietf-hip-rvs] describes the 750 case when rendezvous client is present in publicly addressable 751 network. This section defines an extension to the rendezvous client 752 registration for the case when the rendezvous client has detected 753 that it is behind a NAT. The process in the NAT case is identical to 754 the case without NAT, except that UDP encapsulation is used. The 755 registration is illustrated in Figure 8. 757 A node behind a NAT MUST first register to the RVS when it is going 758 to act as a responder for some other nodes. The node (i.e. 759 rendezvous client) performs a base exchange with the RVS over UDP as 760 described in Section 3.3 by sending I1 UDP encapsulated and 50500 as 761 destination port number. RVS sends REG_INFO parameter in R1 to which 762 rendezvous client replies with REG_REQ paramter in I2. Both I1 and 763 R1 are sent using UDP-encapsulation. If RVS grants service to the 764 rendezvous client, it MUST store the source IP address and source 765 port number of the I2 UDP packet that it had received from the 766 rendezvous client during base exchange. The source IP address 767 belongs to the NAT and the source port number is the NAT mangled 768 port. RVS then replies with REG_RESP in R2 over UDP. If the 769 registration process results in a successful REG_RESP, the rendezvous 770 client MUST send NAT keepalives (Section 3.1.2) to keep the mapping 771 in the NAT with the RVS open. The NAT keepalives sent from 772 rendezvous client to the RVS MUST have the same source port as the I2 773 packet. 775 When the RVS receives an I1 packet from a HIP node to be relayed to 776 the successfully registered rendezvous client behind NAT, RVS MUST 777 relay the I1 over UDP with the destination port as the one stored 778 during registration. The RVS also zeroes the HIP header checksum of 779 the I1. This process is explained in Section 3.4.2. 781 +---+ +---+ +---+ 782 | |----(1)--->| |---------------(2)-------------->| | 783 | | | N | | | 784 | |<---(4)----| A |<--------------(3)---------------| | 785 | I | | T | | R | 786 | |----(5)--->| - |---------------(6)-------------->| | 787 | | | I | | | 788 | |<---(8)----| |<--------------(7)---------------| | 789 +---+ +---+ +---+ 791 Initiator = Rendezvous client, Responder = Rendezvous server 793 1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 794 2. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I1(HIT-I, HIT-R) 795 3. IP(IP-R, IP-NAT-I) UDP(50500, 33333) 796 R1(HIT-R, HIT-I, REG_INFO) 797 4. IP(IP-R, IP-I) UDP(50500, 50500) 798 R1(HIT-R, HIT-I, REG_INFO) 799 5. IP(IP-I, IP-R) UDP(50500, 50500) 800 I2(HIT-I, HIT-R, REG_REQ) 801 6. IP(IP-NAT-I, IP-R) UDP(44444, 50500) 802 I2(HIT-I, HIT-R, REG_REQ) 803 7. IP(IP-R, IP-NAT-I) UDP(50500, 44444) 804 R2(HIT-R, HIT-I, REG_RES) 805 8. IP(IP-R, IP-I) UDP(50500, 50500) 806 R2(HIT-R, HIT-I, REG_RES) 808 Figure 8: Rendezvous NAT Client Registration 810 3.4.2. NAT Traversal of HIP Control Traffic 812 This section describes the details of enabling NAT traversal for base 813 exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for 814 the case when the HIP initiator is on publicly addressable network 815 and the HIP responder is behind NAT. The process is illustrated in 816 Figure 9. 818 Before the HIP base exchange starts, the responder of the HIP base 819 exchange MUST have completed a successful rendezvous client 820 registration using the scheme defined in Section 3.4.1. 822 The initiator of the HIP base exchange sends a plain I1 packet 823 (without UDP encapsulation) to the RVS as described in 824 [I-D.ietf-hip-rvs]. In this case, the rendezvous server detects that 825 the I1 is not UDP encapsulated, but the rendezvous client has 826 registered using UDP encapsulation. 828 To relay the I1 packet, RVS MUST zero the HIP header checksum from 829 the I1 packet. RVS MUST add a FROM parameter, as described in 830 [I-D.ietf-hip-rvs], which contains the IP address of HIP initiator. 831 The FROM parameter is integrity protected by a RVS_HMAC parameter as 832 described in [I-D.ietf-hip-rvs]. RVS replaces the destination IP 833 address in the IP header of the packet with IP that it had stored 834 during the rendezvous client registration (which is the IP address of 835 the outermost NAT behind which rendezvous client is located). It 836 MUST then encapsulate the I1 packet within UDP. The source port in 837 the UDP header MUST be 50500 and the destination port MUST be the 838 same as the source port number (44444) of the I2 packet which it had 839 stored during the registration process. RVS then recomputes the IP 840 header checksum and sends the packet. 842 +-------+ 843 | | 844 +----->| RVS +-----+ +----+ 845 +---+ | | | | | | +---+ 846 | |---(1)---+ +-------+ +----(2)--->| |---(3)--->| | 847 | | | N | | | 848 | |<------------------(5)--------------------| A |<--(4)----| | 849 | I | | T | | R | 850 | |-------------------(6)------------------->| - |---(7)--->| | 851 | | | R | | | 852 | |<------------------(9)--------------------| |<--(8)----| | 853 +---+ +----+ +---+ 855 1. IP(IP-I, IP-RVS) I1(HIT-I, HIT-R) 856 2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) 857 I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC) 858 3. IP(IP-RVS, IP-R) UDP(50500, 50500) 859 I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC) 860 4. IP(IP-R, IP-I) 861 UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)) 862 5. IP(IP-NAT-R, IP-I) 863 UDP(44444, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500) 864 6. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R) 865 7. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 866 8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 867 9. IP(IP-NAT-R, IP-I) UDP(44444, 50500) R2(HIT-R, HIT-I) 869 Figure 9: UDP-encapsulated HIP base exchange (initiator on public 870 Internet, responder behind a NAT). 872 The relayed I1 packet travels from RVS to the NAT. The NAT changes 873 the destination IP address of the UDP encapsulated I1 packet, and the 874 destination port number in the UDP header. The responder accepts the 875 packet from the RVS and processes it according to [I-D.ietf-hip-rvs]. 876 The resulting R1 must be encapsulated within UDP. The responder MAY 877 append a VIA_RVS_NAT parameter to the message, which contains the IP 878 address of the rendezvous and the port the rendezvous server used for 879 relaying the I1. The RECOMMENDED source port is 50500 and the 880 destination port number MUST be 50500. The destination address in 881 the IP header MUST be the same as the one specified in the FROM 882 parameter of the relayed I1 packet. 884 The initiator MUST listen on port 50500 and it receives the UDP 885 encapsulated R1. After verifying the HIP packet, it concludes that 886 the responder is behind a NAT because the packet was UDP 887 encapsulated. The initiator processes the R1 control packet 888 according to [I-D.ietf-hip-base] and replies using I2 that is UDP 889 encapsulated. The addresses and ports are derived from the received 890 R1. 892 The NAT translates and forwards the UDP encapsulated I2 packet to the 893 responder. The resulting R2 packet is also UDP encapsulated using 894 the address and port information from the received I2 packet. 896 3.4.3. NAT Traversal of HIP Data Traffic 898 After a successful base exchange, both of the HIP nodes have 899 communicated all the necessary information to establish UDP- 900 encapsulated BEET mode Security Associations. The following section 901 describes inbound and outbound security associations at initiator and 902 responder. 904 3.4.3.1. Security Associations at the Initiator 906 The initiator of a base exchange defines its outbound SA as shown in 907 Table 6 909 +--------------+----------------------------------------------------+ 910 | Field | Value | 911 +--------------+----------------------------------------------------+ 912 | Outer src | The local IP address from which the base exchange | 913 | address | packets were transmitted | 914 | Outer dst | The peer IP address from which R2 packet was | 915 | address | received during base exchange | 916 | UDP src port | Port 50500 | 917 | UDP dst port | Source port of incoming R2 packet during base | 918 | | exchange | 919 +--------------+----------------------------------------------------+ 921 Table 6: Outbound SA at initiator 923 The initiator of a base exchange defines its inbound SA as shown in 924 Table 7 925 +--------------+----------------------------------------------------+ 926 | Field | Value | 927 +--------------+----------------------------------------------------+ 928 | Outer src | The peer IP address from which R2 packet was | 929 | address | received during base exchange | 930 | Outer dst | The local IP address from which the base exchange | 931 | address | packets were transmitted | 932 | UDP src port | Source port of incoming R2 packet during base | 933 | | exchange | 934 | UDP dst port | Port 50500 | 935 +--------------+----------------------------------------------------+ 937 Table 7: Inbound SA at initiator 939 3.4.3.2. Security Associations at the Responder 941 The responder of a UDP-encapsulated base exchange defines its 942 outbound SA shown in Table 8. 944 +--------------+----------------------------------------------------+ 945 | Field | Value | 946 +--------------+----------------------------------------------------+ 947 | Outer src | The local IP address from which the base exchange | 948 | address | packets were transmitted | 949 | Outer dst | The peer IP as that used during base exchange | 950 | address | | 951 | UDP src port | The as source port chosen during base exchange | 952 | UDP dst port | Port 50500 | 953 +--------------+----------------------------------------------------+ 955 Table 8: Outbound SA at Responder 957 Similarly, the responder of a UDP-encapsulated base exchange defines 958 its inbound SA as shown in Table 9 960 +--------------+----------------------------------------------------+ 961 | Field | Value | 962 +--------------+----------------------------------------------------+ 963 | Outer src | Source peer IP address as used in base exchange | 964 | address | | 965 | Outer dst | The local IP address from which the base exchange | 966 | address | packets were transmitted | 967 | UDP src port | Port 50500 | 968 | UDP dst port | The as source port chosen during base exchange | 969 +--------------+----------------------------------------------------+ 971 Table 9: Inbound SA at responder 973 3.5. Both Hosts Behind NAT 975 This section describes the details of enabling NAT traversal for HIP 976 control and ESP data traffic, such as the base exchange 977 [I-D.ietf-hip-base], through UDP encapsulation, for the case when the 978 HIP initiator and the HIP responder are both behind two separate 979 NATs. The limitation of this approach is that the NAT middlebox MUST 980 support endpoint independent mapping 981 [I-D.srisuresh-behave-p2p-state]. 983 The registration and rendezvous relay are handled similarly as 984 described in Section 3.3.3 and Section 3.4.1. Now that both hosts 985 are behind NATs, both the initiator (Section 3.3) and responder 986 (Section 3.4) mechanisms are combined here. There is one exception 987 though; the initiator does not retransmit an I1 but rather a NOTIFY 988 message. 990 3.5.1. NAT Traversal of HIP Control Traffic 992 Before an initiator can start the base exchange, the responder MUST 993 have completed a successful rendezvous client registration with its 994 RVS using the mechanism described in Section 3.4.1. The initiator of 995 the HIP base exchange starts the base exchange by sending a UDP 996 encapsulated I1 packet to RVS. The UDP packet MUST have destination 997 port number 50500 and the initiator is RECOMMENDED to use 50500 as 998 source port number. RVS MUST listen on UDP port 50500. RVS MUST 999 accept the packet as described in Section 3.3.3. As there has been a 1000 successful rendezvous client registration between the responder and 1001 the RVS as described in Section 3.4.1, the RVS knows the port number 1002 to be used to communicate with the responder through the NAT. RVS 1003 MUST add a FROM_NAT parameter to the I1 packet. The FROM_NAT 1004 parameter contains the source address of the I1 packet, which is 1005 effectively the address of the outermost NAT of the initiator. The 1006 RVS copies the source port of the UDP encapsulated I1 packet into the 1007 port number field of the FROM_NAT parameter. The FROM_NAT parameter 1008 is integrity protected by an RVS_HMAC as described in 1009 [I-D.ietf-hip-rvs]. It MUST replace the destination IP address of 1010 the I1 packet by the one it had stored earlier during rendezvous 1011 client registration. It MUST replace source IP address of I1 packet 1012 with its own address. UDP source port of the relayed I1 packet MUST 1013 be 50500 and destination port MUST be the same as one it had stored 1014 during the client rendezvous registration. It MUST recompute the IP 1015 header checksum. 1017 Upon receiving the VIA_RVS_NAT parameter, the initiator sends NOTIFY 1018 message without any contents to the responder, which responder MUST 1019 ignore. This punches a hole to the NAT of the initiator. 1021 The responder receives the I1 relayed by the RVS. The responder acts 1022 as described in Section 3.4.2 by replying with an R1. The R1 punches 1023 a hole to the responder's NAT for the initiator. The R1 makes it to 1024 the initiator because the initiator already punched a hole in its own 1025 NAT with the empty NOTIFY message for the responder. 1027 The initiator and responder complete the rest of the base exchange 1028 with I2 and R2. The NAT state may timeout in case the R1 cookie was 1029 relatively large or in case the RTT is large. For this reason, the 1030 initiator MUST refresh the state of the NATs by resending empty 1031 NOTIFY messages until it receives an R2. 1033 +---+ +----+ +-------+ +----+ +---+ 1034 | +--(1)-->| +---(2)-->+ | | | | | 1035 | | | | | RVS-R | | | | | 1036 | | | |<--(3a)--+ +---(3b)---->| | | | 1037 | | | | +-------+ | | | | 1038 | |<-(4a)--+ N | | N +--(4b)->| | 1039 | | | A | | A | | | 1040 | I +--(5a)->| T | | T |<-(5b)--+ R | 1041 | | | - |<-(6b)------------------(6a)->| - | | | 1042 | |<-(7b)--+ I | | R +--(7a)->| | 1043 | | | | | | | | 1044 | +--(8)-->| +--------------(9)------------>| +--(10)->| | 1045 | | | | | | | | 1046 | |<-(13)--+ |<-------------(12)------------+ |<-(11)--+ | 1047 +---+ +----+ +----+ +---+ 1049 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 1050 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 1052 3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) 1053 NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) 1054 3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) 1055 I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC) 1057 4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500) 1058 NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) 1059 4b. IP(IP-RVS, IP-R) UDP(50500, 50500) 1060 I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC) 1062 5a. IP(IP-I, IP-NAT-R) UDP(50500, 44444) NOTIFY(HIT-I, HIT-R) 1063 5b. IP(IP-R, IP-NAT-I) UDP(50500, 11111) 1064 R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)) 1066 6a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) NOTIFY(HIT-I, HIT-R) 1067 6b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111) 1068 R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)) 1069 7a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 50500) NOTIFY(HIT-I, HIT-R) 1070 7b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 50500) 1071 R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)) 1072 8-10. I2(HIT-I, HIT-R), details similarly as in the cases before 1073 11-13 R2(HIT-R, HIT-I), details similarly as in the cases before 1075 Figure 10: UDP-encapsulated HIP base exchange (initiator and 1076 responder behind a NAT, RVS on public IP). 1078 The UDP hole punching is applicable only in the case when the NAT 1079 devices on the path support address independent mapping 1080 [I-D.srisuresh-behave-p2p-state]. After the initiator has received a 1081 VIA_RVS_NAT parameter and has been in I1_SENT state for a policy 1082 specific period, the initiator MAY transition to E-FAILED state. 1083 Alternatively, it is RECOMMENED to switch to an external relay based 1084 protocol mechanism. 1086 3.5.2. NAT Traversal of HIP Data Traffic 1088 After a successful base exchange, both the HIP nodes have all the 1089 parameters with them to establish UDP BEET mode Security Association. 1090 The following section describes inbound and outbound security 1091 associations at initiator and responder. 1093 3.5.2.1. Security Associations at the Initiator 1095 The initiator of a base exchange defines its outbound SA as shown in 1096 Table 10 1098 +--------------+----------------------------------------------------+ 1099 | Field | Value | 1100 +--------------+----------------------------------------------------+ 1101 | Outer src | The local IP address from which the base exchange | 1102 | address | packets were transmitted | 1103 | Outer dst | The peer IP address from which R2 packet was | 1104 | address | received during base exchange | 1105 | UDP src port | The as the port number chosen to send I2 during | 1106 | | base exchange | 1107 | UDP dst port | Source port of incoming R2 packet during base | 1108 | | exchange | 1109 +--------------+----------------------------------------------------+ 1111 Table 10: Outbound SA at initiator 1113 The initiator of a base exchange defines its inbound SA as shown in 1114 Table 11 1116 +--------------+----------------------------------------------------+ 1117 | Field | Value | 1118 +--------------+----------------------------------------------------+ 1119 | Outer src | The peer IP address from which R2 packet was | 1120 | address | received during base exchange | 1121 | Outer dst | The local IP address from which the base exchange | 1122 | address | packets were transmitted | 1123 | UDP src port | Source port of incoming R2 packet during base | 1124 | | exchange | 1125 | UDP dst port | The as the port number chosen to send I2 during | 1126 | | base exchange | 1127 +--------------+----------------------------------------------------+ 1128 Table 11: Inbound SA at initiator 1130 3.5.2.2. Security Associations at the Responder 1132 The responder of a UDP-encapsulated base exchange defines its 1133 outbound SA shown in Table 12. 1135 +--------------+----------------------------------------------------+ 1136 | Field | Value | 1137 +--------------+----------------------------------------------------+ 1138 | Outer src | The local IP address from which the base exchange | 1139 | address | packets were transmitted | 1140 | Outer dst | The peer IP as that used during base exchange | 1141 | address | | 1142 | UDP src port | The as source port chosen send R2 during base | 1143 | | exchange | 1144 | UDP dst port | The as source port number of I2 packet during base | 1145 | | exchange | 1146 +--------------+----------------------------------------------------+ 1148 Table 12: Outbound SA at Responder 1150 Similarly, the responder of a UDP-encapsulated base exchange defines 1151 its inbound SA as shown in Table 13 1153 +--------------+----------------------------------------------------+ 1154 | Field | Value | 1155 +--------------+----------------------------------------------------+ 1156 | Outer src | Source peer IP address as used in base exchange | 1157 | address | | 1158 | Outer dst | The local IP address from which the base exchange | 1159 | address | packets were transmitted | 1160 | UDP src port | The as source Port received from I2 during base | 1161 | | exchange | 1162 | UDP dst port | The as source port used to send R2 during base | 1163 | | exchange | 1164 +--------------+----------------------------------------------------+ 1166 Table 13: Inbound SA at responder 1168 3.6. NAT Keep-Alives 1170 Typically, NATs cache an established binding and time it out if they 1171 have not used it to relay traffic for a given period of time. This 1172 timeout is different for different NAT implementations. The BEHAVE 1173 working group is discussing recommendations for standardized timeout 1174 values. To prevent NAT bindings that support the traversal of UDP- 1175 encapsulated HIP traffic from timing out during times when there is 1176 no control or data traffic, HIP hosts SHOULD send periodic keep-alive 1177 messages. 1179 Typically, only outgoing traffic refreshes the NAT port state for 1180 security reasons. Consequently, both hosts SHOULD send periodic 1181 keep-alives for the UDP channel of all their established HIP 1182 associations if the channel has been idle for a specific period of 1183 time. 1185 For the UDP channel, keep-alives MUST be UDP-encapsulated HIP NOTIFY 1186 packets as defined in Section 3.1.2. The packets MUST use the same 1187 source and destination ports and IP addresses as the corresponding 1188 UDP tunnel. The default keep-alive interval for control channels 1189 SHOULD be 20 seconds. The peer host of the HIP association MUST 1190 discard the keep-alives. 1192 3.7. HIP Mobility 1194 After a successful base exchange, a mobile node can change its 1195 network location using the mechanisms defined in [I-D.ietf-hip-mm]. 1196 This section describes such mobility mechanisms in the presence of 1197 NATs. However, the double jump scenario, where both peers move 1198 simultaneously, is excluded. 1200 The mobile node can change its location as described in Table 14. 1202 +----+---------------------------+----------------------------------+ 1203 | No | From network | To network | 1204 +----+---------------------------+----------------------------------+ 1205 | 1 | Behind NAT | Publicly Addressable Network | 1206 | 2 | Publicly Addressable | Behind NAT | 1207 | | Network | | 1208 | 3 | Behind NAT-A | Stays behind NAT-A, but | 1209 | | | different IP | 1210 | 4 | Behind NAT-A | Behind NAT-B | 1211 | 5 | Publicly Addressable | Publicly Addressable Network | 1212 | | Network | | 1213 +----+---------------------------+----------------------------------+ 1215 Table 14: End host mobility scenarios 1217 The corresponding peer node can be located as follows Table 15 1218 +----+------------------------------------------+ 1219 | No | Peer Node network | 1220 +----+------------------------------------------+ 1221 | A | Publicly Addressable Network With RVS | 1222 | B | Publicly Addressable Network Without RVS | 1223 | C | Behind NAT With RVS | 1224 | D | Behind NAT Without RVS | 1225 +----+------------------------------------------+ 1227 Table 15: Peer host Network Scenarios 1229 The NAT traversal mechanisms may not work when the corresponding node 1230 is behind a NAT without RVS (case D), except when the mobile node 1231 stays behind the same cone NAT (case 3D). 1233 When a mobile node changes its location, it SHOULD detect the 1234 presence of NATs along the new paths to its corresponding nodes using 1235 some external mechanism before sending any UPDATE messages. If no 1236 NAT was detected in such a case, it SHOULD send an UPDATE to its 1237 corresponding nodes without UDP encapsulation. 1239 The mobile node MUST send the UPDATE packet through the corresponding 1240 node's RVS if it uses one, in addition to sending it to the 1241 corresponding node directly. The mobile node encapsulates the UPDATE 1242 packet within UDP only when it is behind a NAT. The corresponding 1243 node MUST reply using UDP when the packet was encapsulated within 1244 UDP, or without UDP when the UDP header was not present in the UPDATE 1245 packet. 1247 The rendezvous server relays the UPDATE similarly to I1. The 1248 rendezvous server MUST add FROM parameter when it gets an UPDATE 1249 packet without UDP encapsulation, or a FROM_NAT parameter when the 1250 UPDATE packet it receives is UDP encapsulated and MUST in both cases 1251 protect the packet with a HMAC parameter. Upon replying to the 1252 UPDATE, the corresponding node MUST add a VIA_RVS (or VIA_RVS_NAT) 1253 parameter to the reply. 1255 The mobile node MUST leave out the NATted locators from the LOCATOR 1256 parameter. This MUST be done before applying HMAC and SIGNATURE to 1257 an R1, I2 or UPDATE packet. Thus, the LOCATOR parameter consists 1258 only of the type and length fields when the mobile node has only 1259 NATted addresses. When the mobile node has e.g. a single IPv6 1260 address and one NATted address, the LOCATOR parameter consists of 1261 single locator. The UDP header along with its port number conveys 1262 the NATted locator to the peer. 1264 3.8. HIP Multihoming 1266 Multiple security associations can exists between the same hosts. 1267 They may be connected through several paths, some of which may 1268 include a NAT and others may not. Implementations that support 1269 multihoming MUST support concurrent HIP associations between the same 1270 host pair in a way that allows some of them to use UDP encapsulation 1271 while others are not UDP encapsulated. 1273 3.9. Firewall Traversal 1275 When the initiator or the responder of a HIP association is behind a 1276 firewall, additional issues arise. 1278 When the initiator is behind a firewall, the NAT traversal mechanisms 1279 described in Section 3 depend on the ability to initiate 1280 communication via UDP to destination port 50500 from arbitrary source 1281 ports and to receive UDP response traffic from that port to the 1282 chosen source port. 1284 Most firewall implementations support "UDP connection tracking", 1285 i.e., after a host behind a firewall has initiated a UDP 1286 communication to the public Internet, the firewall relays UDP 1287 response traffic in the return direction. If no such return traffic 1288 arrives for a specific period of time, the firewall stops relaying 1289 the given IP address and port pair. The mechanisms described in 1290 Section 3 already enable traversal of such firewalls, if the keep- 1291 alive interval used is less than the refresh interval of the 1292 firewall. 1294 If the initiator is behind a firewall that does not support "UDP 1295 connection tracking", the NAT traversal mechanisms described in 1296 Section 3 can still be supported, if the firewall allows permanently 1297 inbound UDP traffic from port 50500 and destined to arbitrary source 1298 IP addresses and UDP ports. 1300 When the responder is behind a firewall, the NAT traversal mechanisms 1301 described in Section 3 depend on the ability to receive UDP traffic 1302 on port 50500 from arbitrary source IP addresses and ports. 1304 The NAT traversal mechanisms described in Section 3 require that the 1305 firewall - stateful or not - allow inbound UDP traffic to port 50500 1306 and allow outbound UDP traffic to arbitrary UDP ports. If necessary 1307 for firewall traversal, ports reserved for IKE MAY be used for 1308 initiating new connections, but the implementation MUST be able to 1309 listen for UDP packets from port 50500. 1311 4. Security Considerations 1313 4.1. A Difference to RFC3948 1315 Section 5.1 of [RFC3948] describes a security issue for the UDP 1316 encapsulation of standard IP tunnel mode when two hosts behind 1317 different NATs have the same private IP address and initiate 1318 communication to the same responder in the public Internet. The 1319 responder cannot distinguish between the two hosts, because security 1320 associations are based on the same inner IP addresses. 1322 This issue does not exist with the UDP encapsulation of IPsec BEET 1323 mode as described in Section 3, because the responder use the HITs to 1324 distinguish between different communication instances. 1326 4.2. Rendezvous and Responder Privacy 1328 The rendezvous usage in this draft has been designed to follow the 1329 RVS specification [I-D.ietf-hip-rvs] when the NAT supports end-point 1330 independent filtering. However, as NAT networking presents some 1331 additional challenges, it is not possible to follow the RVS design 1332 exactly. Particularly, the mechanisms described in Figure 7 and 1333 Section 3.5.1 require that the rendezvous server replies back to the 1334 initiator with a message which includes the address and port of the 1335 responder NAT. Another design choice would have been to relay also 1336 the R1 (and I2 in case of both hosts behind NAT) through the 1337 rendezvous server to delay the exposure of the responder NAT address 1338 and port related information for additional DoS protection. However, 1339 this choice was not selected to reduce round trip time. As a 1340 consequence, the rendezvous client must accept the risk of lowered 1341 privacy protection when it registers to the RVS over UDP as defined 1342 in Figure 8. 1344 5. IANA Considerations 1346 This section is to be interpreted according to [RFC2434]. 1348 This draft currently uses a UDP port in the "Dynamic and/or Private 1349 Port" range, i.e., 50500. Upon publication of this document, IANA is 1350 requested to register a UDP port and the RFC editor is requested to 1351 change all occurrences of port 50500 to the port IANA has registered. 1353 6. Acknowledgements 1355 The authors would like to thank Vivien Schmitt for his contributions 1356 to previous versions of this draft. In addition, the authors would 1357 like to thank Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. 1358 Ahrenholz, Thomas Henderson, Kristian Slavov, Janne Lindqvist, Pekka 1359 Nikander, Lauri Silvennoinen, Jukka Ylitalo, Andrei Gurtov and Juha 1360 Heinanen for their comments on this document. 1362 [I-D.nikander-hip-path] presented some initial ideas for NAT 1363 traversal of HIP communication. This document describes 1364 significantly different mechanisms that, among other differences, use 1365 external NAT discovery and do not require encapsulation servers. 1367 Simon Schuetz and Martin Stiemerling are partly funded by Ambient 1368 Networks, a research project supported by the European Commission 1369 under its Sixth Framework Program. The views and conclusions 1370 contained herein are those of the authors and should not be 1371 interpreted as necessarily representing the official policies or 1372 endorsements, either expressed or implied, of the Ambient Networks 1373 project or the European Commission. 1375 Miika Komu is working for InfraHIP research group at Helsinki 1376 Institute for Information Technology (HIIT). The InfraHIP project is 1377 funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and 1378 Ericsson. 1380 7. References 1382 7.1. Normative References 1384 [I-D.ietf-hip-base] 1385 Moskowitz, R., "Host Identity Protocol", 1386 draft-ietf-hip-base-06 (work in progress), June 2006. 1388 [I-D.ietf-hip-esp] 1389 Jokela, P., "Using ESP transport format with HIP", 1390 draft-ietf-hip-esp-04 (work in progress), October 2006. 1392 [I-D.ietf-hip-mm] 1393 Nikander, P., "End-Host Mobility and Multihoming with the 1394 Host Identity Protocol", draft-ietf-hip-mm-04 (work in 1395 progress), June 2006. 1397 [I-D.ietf-hip-rvs] 1398 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1399 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 1400 progress), June 2006. 1402 [I-D.nikander-esp-beet-mode] 1403 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 1404 (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 1405 (work in progress), August 2006. 1407 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1408 August 1980. 1410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1411 Requirement Levels", BCP 14, RFC 2119, March 1997. 1413 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1414 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1415 October 1998. 1417 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1418 (HIP) Architecture", RFC 4423, May 2006. 1420 7.2. Informative References 1422 [I-D.ietf-behave-nat-behavior-discovery] 1423 MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 1424 Using STUN", draft-ietf-behave-nat-behavior-discovery-00 1425 (work in progress), February 2007. 1427 [I-D.ietf-behave-nat-udp] 1428 Audet, F. and C. Jennings, "NAT Behavioral Requirements 1429 for Unicast UDP", draft-ietf-behave-nat-udp-08 (work in 1430 progress), October 2006. 1432 [I-D.irtf-hiprg-nat] 1433 Stiemerling, M., "NAT and Firewall Traversal Issues of 1434 Host Identity Protocol (HIP) Communication", 1435 draft-irtf-hiprg-nat-03 (work in progress), June 2006. 1437 [I-D.nikander-hip-path] 1438 Nikander, P., "Preferred Alternatives for Tunnelling HIP 1439 (PATH)", draft-nikander-hip-path-01 (work in progress), 1440 March 2006. 1442 [I-D.srisuresh-behave-p2p-state] 1443 Srisuresh, P., "State of Peer-to-Peer(P2P) Communication 1444 Across Network Address Translators(NATs)", 1445 draft-srisuresh-behave-p2p-state-04 (work in progress), 1446 September 2006. 1448 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1449 Translator (NAT) Terminology and Considerations", 1450 RFC 2663, August 1999. 1452 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1453 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1454 Through Network Address Translators (NATs)", RFC 3489, 1455 March 2003. 1457 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1458 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1459 RFC 3948, January 2005. 1461 Appendix A. Document Revision History 1463 To be removed upon publication 1465 +------------+------------------------------------------------------+ 1466 | Revision | Comments | 1467 +------------+------------------------------------------------------+ 1468 | schmitt-00 | Initial version. | 1469 | ietf-00 | Officially adopted as WG item. Solved issues | 1470 | | 1-9,11,12 | 1471 +------------+------------------------------------------------------+ 1473 Authors' Addresses 1475 Miika Komu (editor) 1476 Helsinki Institute for Information Technology 1477 Tammasaarenkatu 3 1478 Helsinki 1479 Finland 1481 Phone: +358503841531 1482 Fax: +35896949768 1483 Email: miika@iki.fi 1484 URI: http://www.hiit.fi/ 1486 Simon Schuetz 1487 NEC Network Laboratories 1488 Kurfuerstenanlage 36 1489 Heidelberg 69115 1490 Germany 1492 Phone: +49 6221 4342 165 1493 Fax: +49 6221 4342 155 1494 Email: simon.schuetz@netlab.nec.de 1495 URI: http://www.netlab.nec.de/ 1496 Martin Stiemerling 1497 NEC Network Laboratories 1498 Kurfuerstenanlage 36 1499 Heidelberg 69115 1500 Germany 1502 Phone: +49 6221 4342 113 1503 Fax: +49 6221 4342 155 1504 Email: stiemerling@netlab.nec.de 1505 URI: http://www.netlab.nec.de/ 1507 Lars Eggert 1508 Nokia Research Center 1509 P.O. Box 407 1510 Nokia Group 00045 1511 Finland 1513 Phone: +358 50 48 24461 1514 Email: lars.eggert@nokia.com 1515 URI: http://research.nokia.com/people/lars_eggert/ 1517 Abhinav Pathak 1518 IIT Kanpur 1519 B204, Hall - 1, IIT Kanpur 1520 Kanpur 208016 1521 India 1523 Phone: +91 9336 20 1002 1524 Email: abhinav.pathak@hiit.fi 1525 URI: http://www.iitk.ac.in/ 1527 Full Copyright Statement 1529 Copyright (C) The IETF Trust (2007). 1531 This document is subject to the rights, licenses and restrictions 1532 contained in BCP 78, and except as set forth therein, the authors 1533 retain all their rights. 1535 This document and the information contained herein are provided on an 1536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1538 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1539 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1540 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1543 Intellectual Property 1545 The IETF takes no position regarding the validity or scope of any 1546 Intellectual Property Rights or other rights that might be claimed to 1547 pertain to the implementation or use of the technology described in 1548 this document or the extent to which any license under such rights 1549 might or might not be available; nor does it represent that it has 1550 made any independent effort to identify any such rights. Information 1551 on the procedures with respect to rights in RFC documents can be 1552 found in BCP 78 and BCP 79. 1554 Copies of IPR disclosures made to the IETF Secretariat and any 1555 assurances of licenses to be made available, or the result of an 1556 attempt made to obtain a general license or permission for the use of 1557 such proprietary rights by implementers or users of this 1558 specification can be obtained from the IETF on-line IPR repository at 1559 http://www.ietf.org/ipr. 1561 The IETF invites any interested party to bring to its attention any 1562 copyrights, patents or patent applications, or other proprietary 1563 rights that may cover technology that may be required to implement 1564 this standard. Please address the information to the IETF at 1565 ietf-ipr@ietf.org. 1567 Acknowledgment 1569 Funding for the RFC Editor function is provided by the IETF 1570 Administrative Support Activity (IASA).