idnits 2.17.1 draft-ietf-hip-nat-traversal-03.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 26. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1106. 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 (February 25, 2008) is 5903 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-15 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-06 == Outdated reference: A later version (-01) exists of draft-rosenberg-mmusic-ice-nonsip-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group M. Komu 3 Internet-Draft HIIT 4 Intended status: Experimental T. Henderson 5 Expires: August 28, 2008 The Boeing Company 6 P. Matthews 7 Avaya 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Keraenen 11 J. Melen 12 Ericsson Research Nomadiclab 13 M. Bagnulo 14 Huawei Lab at UC3M 15 February 25, 2008 17 Basic HIP Extensions for Traversal of Network Address Translators and 18 Firewalls 19 draft-ietf-hip-nat-traversal-03.txt 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on August 28, 2008. 46 Copyright Notice 48 Copyright (C) The IETF Trust (2008). 50 Abstract 52 The Host Identity Protocol (HIP) provides a new namespace that can be 53 used for uniquely identifying hosts. Existing HIP experimental 54 specifications do not specify protocol operations across Network 55 Address Translators (NATs). 57 This document specifies NAT traversal extensions for HIP. The HIP 58 shim layer is located between the network and transport layer, the 59 extensions can also provide a more general-purpose NAT traversal 60 support for higher-layer networking applications. The extensions are 61 based on the use of the The Interactive Connectivity Establishment 62 (ICE) methodology to discover a working path between two end-hosts. 63 Using the specified extensions, two HIP-capable hosts are able to 64 communicate with each other even when both nodes are behind NATs or 65 firewalls. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Relay Registration and NAT Detection . . . . . . . . . . . 7 73 3.2. Base Exchange via HIP Relay . . . . . . . . . . . . . . . 9 74 4. Connectivity Tests . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1. NAT Transformation Negotiation . . . . . . . . . . . . . . 11 76 4.2. ICE Procedure . . . . . . . . . . . . . . . . . . . . . . 12 77 4.3. NAT Keep-alives . . . . . . . . . . . . . . . . . . . . . 12 78 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 13 80 5.2. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.3. Relay and Registration Parameters . . . . . . . . . . . . 14 82 5.4. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 14 83 5.5. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.6. Registration Types . . . . . . . . . . . . . . . . . . . . 16 85 5.7. HIP ESP Data Packet Formats . . . . . . . . . . . . . . . 17 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 17 88 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 18 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 18 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 95 Appendix A. Firewall Traversal . . . . . . . . . . . . . . . . . 21 96 Appendix B. Base Exchange without ICE Connectivity Checks . . . . 22 97 Appendix C. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 22 98 Appendix D. Base Exchange through a Rendezvous Server . . . . . . 22 99 Appendix E. Document Revision History . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 101 Intellectual Property and Copyright Statements . . . . . . . . . . 26 103 1. Introduction 105 HIP [I-D.ietf-hip-base] is defined as a protocol that runs directly 106 over IPv4 or IPv6. This approach is known to have problems 107 traversing NATs. Several different types of NATs exist, see 108 [RFC2663]. This document describes HIP extensions for the traversal 109 of both Network Address Translator (NAT) and Network Address and Port 110 Translator (NAPT) middleboxes. Additionally, it covers firewalls to 111 a certain extend (see Appendix A for a more detailed discussion). 112 The document generally uses the term NAT to refer to these types of 113 middleboxes. A detailed description of HIP problems with traversing 114 legacy middleboxes is documented in [I-D.irtf-hiprg-nat]. 116 NAT devices do not operate consistently even though a recommended 117 behavior is described in [RFC4787]. The HIP protocol extensions in 118 this document make as few assumptions as possible about the behavior 119 of the NAT devices so that NAT traversal will work even with legacy 120 NAT devices. The purpose of these extensions is to allow two HIP- 121 enabled hosts to communicate with each other even if one or both 122 communicating hosts are in private address realms. With some legacy 123 NAT devices, utilizing the shortest path between two end hosts 124 located behind NATs is not possible without relaying the traffic 125 through a relay, such as a TURN server [I-D.ietf-behave-p2p-state]. 126 As a consequence, the TURN server increases the roundtrip delay and 127 may become a point of network congestion. With the extensions 128 described in this document, hosts try to avoid the use of such a 129 relay when possible. 131 A distinction must be made between a HIP rendezvous server (defined 132 in [I-D.ietf-hip-rvs]) and a HIP Relay, defined herein. HIP 133 rendezvous servers solve initial contact and mobility related 134 problems in networks without NATs. HIP Relay solve the same 135 problems, in addition to NAT traversal problems. HIP Relay servers 136 can be used both in NATted and non-NATted networks. 138 Both rendezvous and relay services forward HIP control packets, but 139 the main difference is that the rendezvous service forwards only the 140 initial I1 packet of the base exchange while all other HIP control 141 packets are sent directly between the communicating hosts. In 142 contrast, the relay service relays all HIP control packets because 143 p2p-unfriendly NAT devices drop the packets otherwise 144 [I-D.ietf-behave-p2p-state]. The peers use the control channel to 145 communicate their current locators to each other to find a direct 146 path for carrying ESP encapsulated data traffic. A direct path 147 between the hosts enables efficient delivery of data traffic without 148 relaying of ESP packets through an intermediary TURN server. The 149 direct path is searched using connectivity tests. 151 The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice]. 153 [I-D.ietf-mmusic-ice] describes ICE as follows: 155 "The Interactive Connectivity Establishment (ICE) methodology is a 156 technique for NAT traversal for UDP-based media streams (though 157 ICE can be extended to handle other transport protocols, such as 158 TCP) established by the offer/answer model. ICE is an extension 159 to the offer/answer model, and works by including a multiplicity 160 of IP addresses and ports in SDP offers and answers, which are 161 then tested for connectivity by peer-to-peer connectivity checks. 162 The IP addresses and ports included in the SDP and the 163 connectivity checks are performed using the revised STUN 164 specification [I-D.ietf-behave-rfc3489bis], now renamed to Session 165 Traversal Utilities for NAT." 167 ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP 168 protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip]. 170 Two hosts communicate their peer address set (typically consisting of 171 IP address and port number pairs) to each other in the HIP base 172 exchange. They are then paired with the locally operational address 173 of the other end point and prioritized according to some policy. 174 These address sets are then tested sequentially based on the 175 procedure specified in ICE. Both sides participate in the 176 connectivity tests. The tests also determine whether operational 177 address pairs and select the preferred address pair to be used for 178 subsequent communication. 180 As a summary, the extensions in this document 182 o illustrate how to encapsulate HIP packets in UDP 184 o refer to the UDP encapsulation of IPsec ESP packets defined in 185 Section 2.1 of RFC 3948 [RFC3948] 187 o define how a node interacts with a HIP rendezvous server (defined 188 in [I-D.ietf-hip-rvs]) when middleboxes are present 190 o describe a methodology to determine operational address pairs 191 between two end hosts based on ICE. 193 2. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 This document borrows terminology from [I-D.ietf-hip-base], 200 [I-D.ietf-hip-mm], [RFC4423], [I-D.ietf-mmusic-ice], and 201 [I-D.ietf-behave-rfc3489bis]. Additionally, the following terms are 202 used: 204 Rendezvous server: 206 A host that forwards I1 packets to the Responder 208 HIP Relay: 210 A host that forwards all HIP control packets between an Initiator 211 and Responder 213 TURN server: 215 A server that forwards data traffic between two end-hosts 217 Locator: 219 A name that controls how the packet is routed through the network 220 and demultiplexed by the end host. It may include a concatenation 221 of traditional network addresses such as an IPv6 address and end- 222 to-end identifiers such as an ESP SPI. It may also include 223 transport port numbers or IPv6 Flow Labels as demultiplexing 224 context, or it may simply be a network address. [I-D.ietf-hip-mm] 225 "Address" is used in this document as a synonym for locator. 227 Transport address: 229 Transport layer port and the corresponding IPv4/v6 address 231 Candidate: 233 A transport address that has not been verified yet for 234 reachability using ICE 236 Host candidate: 238 An IPv4 or IPv6 address of a network interface of a host 240 Server reflexive transport candidate: 242 A translated transport address of a host as observed by a HIP 243 Relay or a STUN server 245 Peer reflexive transport candidate: 247 A translated transport address of a host as observed by its peer 249 Relayed transport candidate: 251 A transport address that exists on a TURN server. If a permission 252 exists, packets that arrive at this address are relayed towards 253 the TURN client. 255 3. Protocol Description 257 This section describes the normative behavior of the protocol 258 extension. Examples of packet exchanges are provided for 259 illustration purposes. 261 3.1. Relay Registration and NAT Detection 263 HIP rendezvous servers are used in non-NATted environments and their 264 use is described in [I-D.ietf-hip-rvs]. This section specifies a new 265 role for these rendezvous servers to act as HIP Relays. HIP Relays 266 forward HIP control packets between the Initiator and the Responder. 267 TURN servers [I-D.ietf-behave-turn] are used for relaying ESP 268 traffic. A host SHOULD register to a TURN server before registering 269 to a HIP Relay to guarantee that the host can accept ESP traffic 270 immediately after HIP Relay registration. 272 A HIP relay forwards UDP-encapsulated HIP traffic, and in future 273 extensions, a relay may also forward TCP-encapsulated traffic. The 274 HIP Relay forwards HIP control packets. NAT traversal for HIP 275 between two end-hosts may require the use of relays in certain 276 scenarios. A successful NAT traversal therefore requires at least 277 the Responder located behind a NAT to register with a HIP Relay. 279 A HIP Relay MUST silently drop packets to a HIP Relay Client that has 280 not previously registered with the HIP Relay. The registration 281 process follows the generic registration extensions defined in 282 [I-D.ietf-hip-registration] and is illustrated in Figure 1. 284 HIP HIP 285 Relay Relay 286 Client Server 287 | 1. UDP(I1) | 288 +------------------------------------------------------->| 289 | | 290 | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | 291 |<-------------------------------------------------------+ 292 | | 293 | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | 294 +------------------------------------------------------->| 295 | | 296 | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | 297 |<-------------------------------------------------------+ 299 Figure 1: Example Registration to a HIP Relay 301 In step 1, the Initiator starts the registration procedure by sending 302 an I1 packet over UDP. It is RECOMMENDED that the Initiator selects 303 a random port number from the ephemeral port range 49152-65535 for 304 initiating a base exchange. However, the allocated port MUST be 305 maintained until all of the corresponding HIP Associations are 306 closed. Alternatively, a host MAY also use a single fixed port for 307 initiating all outgoing connections. 309 In step 2, the Responder lists the services that it supports in the 310 R1 packet. The support for HIP-over-UDP relaying is denoted by the 311 RELAY_UDP_HIP value. The R1 does not contain any NAT transform 312 parameter (see Section 4.1) as discussed in Appendix B. 314 In step 3, the Initiator selects the services it registers for and 315 lists them in the REG_REQ parameter. In this example, the Initiator 316 registers for HIP Relay service. 318 In step 4, the Responder concludes the registration procedure with an 319 R2 packet and acknowledges the registered services in the REG_RES 320 parameter. The Responder may also denote unsuccessful registrations 321 in the REG_FAILED parameter in R2. The Responder also includes a 322 REG_FROM parameter that contains the transport address of the client 323 as observed by the Relay (Server Reflexive candidate). After the 324 registration, the Initiator needs to send periodically NAT keep- 325 alives. 327 There are different ways for an Initiator to learn it's publically 328 visible IP address and port that are referred to as the "server 329 reflexive transport candidate" in this document. This document makes 330 use of two ways: 332 o The Relay client may use STUN servers to detect the server 333 reflexive locator, as described in [I-D.ietf-behave-p2p-state]. 335 o Alternatively, the Relay Client can learn it from the REG_FROM 336 parameter when registering to a Relay. 338 3.2. Base Exchange via HIP Relay 340 It is RECOMMENDED that the Initiator sends an I1 packet encapsulated 341 in UDP when it is destined to an IPv4 address of the Responder. 342 Respectively, the Responder MUST respond to a such I1 packet with an 343 R1 packet over the transport layer and using the same transport 344 protocol. The rest of the base exchange, I2 and R2, MUST also use 345 the same transport layer. 347 I HIP Relay R 348 | 1. UDP(I1) | | 349 +----------------------------->| 2. UDP(I1(RELAY_FROM)) | 350 | +------------------------------->| 351 | | | 352 | | 3. UDP(R1(RELAY_TO)) | 353 | 4. UDP(R1(RELAY_TO)) |<-------------------------------+ 354 |<-----------------------------+ | 355 | | | 356 | 5. UDP(I2(LOCATOR)) | | 357 +----------------------------->| | 358 | | 6. UDP(I2(LOCATOR,RELAY_FROM)) | 359 | +------------------------------->| 360 | | | 361 | | 7. UDP(R2(LOCATOR,RELAY_TO)) | 362 | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ 363 |<-----------------------------+ | 364 | | | 366 Figure 2: Base Exchange via a HIP Relay 368 In step 1 of Figure 2, the Initiator sends an I1 packet over the 369 transport layer to the HIT of the Responder. The source address is 370 one of the locators of the host. The locators of the end-hosts are 371 referred as "host candidates" in this document. 373 In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If 374 the destination HIT belongs to a registered Responder, the Relay 375 processes the packet. Otherwise, the Relay MUST drop the packet 376 silently. The Relay appends a RELAY_FROM parameter to the I1 packet 377 which constains the transport source address and port of the I1 as 378 observed by the Relay. The Relay protects the I1 packet with 379 RELAY_HMAC as described in [I-D.ietf-hip-rvs], except that the 380 parameter type is different. The Relay changes the source and 381 destination ports and IP addresses of the packet to match the values 382 the Responder used when registering to the Relay, i.e., the reverse 383 of the R2 used in the registration. The Relay MUST recalculate the 384 transport checksum and forward the packet to the Responder. 386 In step 3, the Responder receives the I1 packet. The Responder 387 processes it according to the rules in [I-D.ietf-hip-base]. In 388 addition, the Responder validates the RELAY_HMAC according to 389 [I-D.ietf-hip-rvs] and silenty drops the packet if the validation 390 fails. The Responder replies with an R1 packet to which it includes 391 a RELAY_TO parameter. The RELAY_TO parameter contains same 392 information as the RELAY_FROM parameter, i.e., Initiator transport 393 address, but the type of the parameter is different. The RELAY_TO 394 parameter is not integrity protected by the signature of the R1 to 395 allow pre-created R1 packets at the Responder. 397 In step 4, the Relay receives the R1 packet. The Relay drops the 398 packet silently if the source HIT belongs to an unregistered host. 399 The Relay MAY verify the signature of the R1 packet and drop it if 400 the signature is invalid. Otherwise, the Relay rewrites to source 401 address and port, changes the destination address and port to match 402 RELAY_TO information, recalculates transport checksum and forwards 403 the packet. 405 In step 5, the Initiator receives the R1 packet and processes it 406 according to [I-D.ietf-hip-base]. It replies with an I2 packet that 407 uses the destination transport address of R1 as the source address 408 and port. The I2 contains a LOCATOR parameter that lists all the ICE 409 candidates (offer) of the Initiator. The candidates are encoded 410 using the format defined in Section 5.4. 412 In step 6, the Relay receives the I2 packet. The relay appends a 413 RELAY_FROM and a RELAY_HMAC to the I2 packet as in the second step. 415 In step 7, the Responder receives the I2 packet and processes it 416 according to [I-D.ietf-hip-base]. It replies with a R2 packet and 417 includes a RELAY_TO parameter as in step three. The R2 packet 418 includes a LOCATOR parameter that lists all the ICE candidates 419 (answer) of the Responder. The RELAY_TO parameter is protected by 420 the HMAC. 422 In step 8, the Relay processes the R2 as described in step four. The 423 Relay forwards the packet to the Responder. 425 4. Connectivity Tests 427 4.1. NAT Transformation Negotiation 429 This section describes usage of a new optional transform parameter 430 type. The presence of the parameter in HIP base exchange means that 431 the host supports all of the extensions defined in this document. If 432 the transform parameter is used, hosts MUST use a password for STUN 433 HMACs that is drawn from the DH keying material. 435 The transform parameter applies both to the registration to the HIP 436 Relay as well as to a base exchange between end-hosts. The transform 437 negotiation in base exchange is illustrated in Figure 3. 439 Initiator Responder 440 | 1. UDP(I1) | 441 +------------------------------------------------------------->| 442 | | 443 | 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..)) | 444 |<-------------------------------------------------------------+ 445 | | 446 | 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) | 447 +------------------------------------------------------------->| 448 | | 449 | 4. UDP(R2(.., LOCATOR, ..)) | 450 |<-------------------------------------------------------------+ 451 | .... | 453 Figure 3: Negotiation of NAT Transforms 455 In step 1, the Initiator sends an I1 to the Responder. In step 2, 456 the Responder responds with an R1. The R1 contains a list of 457 transforms the Responder supports in NAT_TRANSFORM parameter as shown 458 in Table 1. 460 +--------------+----------------------------------------------------+ 461 | Transform | Purpose | 462 | Type | | 463 +--------------+----------------------------------------------------+ 464 | RESERVED | Reserved for future use | 465 | ICE-STUN-UDP | UDP encapsulated control and data traffic with | 466 | | ICE-based connectivity tests using STUN messages | 467 +--------------+----------------------------------------------------+ 469 Table 1: Locator Transformations 471 In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORM 472 parameter. It contains the transform type selected by the Initiator 473 from the list of transforms offered by the Responder. The I2 also 474 includes the locators of the Initiator in a LOCATOR parameter. 476 In step 4, the Responder concludes the base exchange with an R2 477 packet. The Responder includes a LOCATOR parameter in the R2 packet. 479 4.2. ICE Procedure 481 Hosts exchange HIP control packets through the HIP Relay. 482 Connectivity tests are, however, directly exchanged between the 483 address pairs to determine operational address pairs. If a working 484 direct path between the hosts is found, also the HIP control traffic 485 MAY start using it. 487 The base exchange is completed with an R2 packet. Then, the state of 488 the HIP associations at both peers is ESTABLISHED, but the peers MUST 489 NOT allow any ESP traffic until the connectivity tests are performed 490 successfully. All of the locators, except the HIP Relay address, are 491 in UNVERIFIED state. In the connectivity tests, the hosts test 492 connectivity between different locator pairs in order to find a 493 working one. The connectivity tests are illustrated in Figure 4. In 494 this example, both hosts are behind NATs. 496 I HIP Relay R 497 | 2. UDP(R2(LOCATOR,RELAY_TO)) | 1. UDP(R2(LOCATOR,RELAY_TO)) | 498 |<------------------------------+-------------------------------| 499 | | 500 | 3. Connectivity tests for address pairs | 501 |<------------------------------------------------------------->| 502 | | 503 | 4. HIP UPDATE for preferred address pair | 504 |<------------------------------------------------------------->| 505 | | 507 Figure 4: Connectivity tests 509 In steps 1 and 2, the R2 packet is relayed from the Responder through 510 the Relay to the Initiator. 512 Afterwards, connectivity tests are started based on the procedure 513 described in [I-D.rosenberg-mmusic-ice-nonsip] by using the candiates 514 previously exchanged in the HIP base exchange. 516 4.3. NAT Keep-alives 518 Data channel keepalives are STUN Binding Indications. Keepalives 519 MUST be sent every 20 seconds at the minimum when the channel is 520 idle. To implement failure tolerance, a host SHOULD have smaller 521 keepalive period. When data traffic is exchanged between the end 522 points then no further STUN keepalives need to be exchanged. 524 5. Packet Formats 526 The following subsections define the parameter and packet encodings. 527 All values MUST be in network byte order. 529 5.1. HIP Control Packets 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Source Port | Destination Port | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Length | Checksum | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | 32 bits of zeroes | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 ~ HIP Header and Parameters ~ 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 5: Format for UDP-encapsulated HIP Control Packets 547 HIP control packets are encapsulated in UDP packets like in Section 548 2.2 of [RFC3948], "rules for encapsulating IKE messages", except that 549 a different port number is used. Figure 5 shows the encapsulation: 550 UDP header is followed by 32 zero bits that can be used to 551 differentiate HIP control packets from ESP packets. The HIP header 552 and parameters follow the conventions of [I-D.ietf-hip-base] with the 553 exception that the HIP header checksum MUST be zero. The HIP header 554 checksum is zero for two reasons. First, the UDP header contains 555 already a checksum. Second, the checksum definition in 556 [I-D.ietf-hip-base] includes the IP addresses in the checksum 557 calculation. The NATs unaware of HIP cannot recompute the HIP 558 checksum after changing IP addresses. 560 A HIP Relay or a Responder without a relay MUST listen at transport 561 port HIPPORT for incoming UDP-encapsulated HIP control packets. 563 5.2. Keep-Alives 565 Control and data channel keep-alives are STUN Binding Indications, as 566 defined in [I-D.ietf-behave-rfc3489bis]. They use the same UDP 567 header as the HIP control packets but there is no non-ESP-marker 568 between the UDP header and the STUN header. STUN messages are 569 demultiplexed from ESP and HIP control messages using the STUN 570 markers, such as the magic cookie value. 572 5.3. Relay and Registration Parameters 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Type | Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 | Address | 581 | | 582 | | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Port | Transport | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Type [ TBD by IANA: 588 RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2) 589 RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2) 590 REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ] 592 Length 20 593 Address An IPv6 address or an IPv4 address in "IPv4-compatible 594 IPv6 address" format 595 Port Transport port number; zero when plain IP is used 596 Transport Transport protocol type; zero for UDP 598 Figure 6: Format for the RELAY_FROM, RELAY_TO and REG_FROM 599 parameters 601 Format of the RELAY_FROM, RELAY_TO and REG_FROM parameters is shown 602 in Figure 6. Parameters are identical except for the type field. 604 5.4. LOCATOR Parameter 606 The generic LOCATOR parameter format is the same as in 607 [I-D.ietf-hip-mm]. However, presenting ICE candidates requires a new 608 locator type. The generic and NAT traversal specific locator 609 parameters are illustrated in Figure 7. 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type | Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Traffic Type | Locator Type | Locator Length| Reserved |P| 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Locator Lifetime | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Locator | 621 | | 622 | | 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 . . 626 . . 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Locator Lifetime | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Transport Port | Transp. Proto| Kind | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Priority | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | SPI | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Locator | 639 | | 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 7: LOCATOR parameter 645 The individual fields in the LOCATOR parameter are described in 646 Table 2. 648 +-----------+----------+--------------------------------------------+ 649 | Field | Value(s) | Purpose | 650 +-----------+----------+--------------------------------------------+ 651 | Type | 193 | Parameter type | 652 | Length | Variable | Length in octets, excluding Type and | 653 | | | Length fields and padding | 654 | Traffic | 0-2 | Is the locator for HIP signaling (1), for | 655 | Type | | ESP (2), or for both (0) | 656 | Locator | 2 | "Transport address" locator type | 657 | Type | | | 658 | Locator | 7 | Length of the Locator field in 4-octet | 659 | Length | | units | 660 | Reserved | 0 | Reserved for future extensions | 661 | Preferred | 0 | Not used for transport address locators; | 662 | (P) bit | | MUST be ignored by the receiver. | 663 | Locator | Variable | Locator lifetime in seconds | 664 | Lifetime | | | 665 | Transport | Variable | Transport layer port number | 666 | Port | | | 667 | Transport | 0 | 0 for UDP | 668 | Protocol | | | 669 | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | 670 | | | peer reflexive or 3 for relayed address | 671 | Priority | Variable | Locator's priority as described in | 672 | | | [I-D.ietf-mmusic-ice] | 673 | SPI | Variable | SPI value which the host expects to see in | 674 | | | incoming ESP packets that use this locator | 675 | Locator | Variable | IPv6 address or an "IPv4-compatible IPv6 | 676 | | | address" format IPv4 address [RFC3513], | 677 | | | obfuscated by XORring it with the owner's | 678 | | | HIT | 679 +-----------+----------+--------------------------------------------+ 681 Table 2: Fields of the LOCATOR parameter 683 5.5. RELAY_HMAC 685 The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 686 2^4). It has the same semantics as RVS_HMAC [I-D.ietf-hip-rvs]. 688 5.6. Registration Types 690 The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contain 691 values for HIP Relay registration. The value for RELAY_UDP_HIP is 2. 692 The value for RELAY_UDP_ESP is 3. 694 5.7. HIP ESP Data Packet Formats 696 [RFC3948] describes UDP encapsulation of the IPsec ESP transport and 697 tunnel mode. On the wire the HIP ESP packets do not differ from the 698 transport mode ESP and thus the encapsulation of the HIP ESP packets 699 is same as the UDP encapsulation transport mode ESP. 701 During the HIP base exchange, the two peers exchange parameters that 702 enable them to define a pair of IPsec ESP security associations 703 (SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a 704 UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs 705 that produces UDP-encapsulated ESP data traffic. 707 The management of encryption/authentication protocols and security 708 parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. The UDP 709 encapsulation format and processing of HIP ESP traffic is described 710 in Section 6.1 of [I-D.ietf-hip-esp]. 712 Section 5.1 of [RFC3948] describes a security issue for the UDP 713 encapsulation in the standard IP tunnel mode when two hosts behind 714 different NATs have the same private IP address and initiate 715 communication to the same Responder in the public Internet. The 716 Responder cannot distinguish between two hosts, because security 717 associations are based on the same inner IP addresses. 719 This issue does not exist with the UDP encapsulation of HIP ESP 720 transport format because the Responder use HITs to distinguish 721 between different communication instances. 723 6. Security Considerations 725 6.1. Privacy Considerations 727 The LOCATORs are sent XORed format in plain text in favour of 728 inspection at HIP-aware middleboxes in the future. The current draft 729 does not specify encrypted versions of LOCATORs even though it could 730 be beneficial for privacy reasons. 732 It is possible that an Initiator or Responder may not want to reveal 733 all of its locators to its peer. For example, a host may not want to 734 reveal the internal topology of the private address realm and it 735 discards host addresses. Such behavior creates non-optimal paths 736 when the hosts are located behind the same NAT. Especially, this 737 could be a problem with a legacy NAT that does not support routing 738 from the private address realm back to itself through the outer 739 address of the NAT. This scenario is referred to as the hairpin 740 problem [I-D.ietf-behave-p2p-state]. With such a legacy NAT, the 741 only option left would be to use a relayed transport address from a 742 TURN server. As a consequence, a host may support locator-based 743 privacy by leaving out the reflexive candidates. Using only host 744 candidates can produce suboptimal paths possibly causing congestion. 746 The use of HIP Relays or TURN Relays can be useful for protection 747 against Denial-of-Service attacks. If a Responder reveals only its 748 HIP and ESP relay candidates to malign Initiators, the Initiators can 749 only attack the relays that does not prevent the Responder from 750 initiating new outgoing connections if a path around the relay 751 exists. 753 6.2. Opportunistic Mode 755 A HIP Relay should have one address per Relay Client when a HIP Relay 756 is serving more than one Relay Clients and is willing to support 757 opportunistic mode. Otherwise, it cannot be guaranteed that the 758 Relay can deliver the I1 packet to the intended recipient. 760 7. IANA Considerations 762 This section is to be interpreted according to [RFC2434]. 764 This draft currently uses a UDP port in the "Dynamic and/or Private 765 Port" and HIPPORT. Upon publication of this document, IANA is 766 requested to register a UDP port and the RFC editor is requested to 767 change all occurrences of port HIPPORT to the port IANA has 768 registered. The HIPPORT number 50500 should be used for initial 769 experimentation. 771 This document updates the IANA Registry for HIP Parameter Types by 772 assigning new HIP Parameter Type values for the new HIP Parameters: 773 RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 5.3) and 774 RELAY_HMAC (defined in Section 5.5). 776 8. Contributors 778 Marcelo Bagnulo, Jan Melen, Simon Schuetz, Martin Stiemerling, Lars 779 Eggert, Vivien Schmitt, Abhinav Pathak and Andrei Gurtov have 780 contributed to the initial versions of this draft. 782 9. Acknowlegements 784 Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for 785 the excellent work on ICE. In addition, the authors would like to 786 thank Andrei Gurtov, Tobias Heer, Teemu Koponen, Juhana Mattila, 787 Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, Janne 788 Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha 789 Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Hannes Tschofenig, 790 Jan Melen, Jani Hautakorpi and Ari Keraenen For their comments on 791 this document. 793 Miika Komu is working in the Networking Research group at Helsinki 794 Institute for Information Technology (HIIT). The InfraHIP project 795 was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence 796 Forces, and Ericsson and Birdstep. 798 10. References 800 10.1. Normative References 802 [I-D.ietf-behave-rfc3489bis] 803 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 804 "Session Traversal Utilities for (NAT) (STUN)", 805 draft-ietf-behave-rfc3489bis-15 (work in progress), 806 February 2008. 808 [I-D.ietf-behave-turn] 809 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 810 Relays around NAT (TURN): Relay Extensions to Session 811 Traversal Utilities for NAT (STUN)", 812 draft-ietf-behave-turn-06 (work in progress), 813 January 2008. 815 [I-D.ietf-hip-base] 816 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 817 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 818 progress), October 2007. 820 [I-D.ietf-hip-esp] 821 Jokela, P., "Using ESP transport format with HIP", 822 draft-ietf-hip-esp-06 (work in progress), June 2007. 824 [I-D.ietf-hip-mm] 825 Henderson, T., "End-Host Mobility and Multihoming with the 826 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 827 progress), March 2007. 829 [I-D.ietf-hip-registration] 830 Laganier, J., "Host Identity Protocol (HIP) Registration 831 Extension", draft-ietf-hip-registration-02 (work in 832 progress), June 2006. 834 [I-D.ietf-hip-rvs] 835 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 836 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 837 progress), June 2006. 839 [I-D.ietf-mmusic-ice] 840 Rosenberg, J., "Interactive Connectivity Establishment 841 (ICE): A Protocol for Network Address Translator (NAT) 842 Traversal for Offer/Answer Protocols", 843 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 845 [I-D.rosenberg-mmusic-ice-nonsip] 846 Rosenberg, J., "NICE: Non Session Initiation Protocol 847 (SIP) usage of Interactive Connectivity Establishment 848 (ICE)", draft-rosenberg-mmusic-ice-nonsip-00 (work in 849 progress), February 2008. 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, March 1997. 854 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 855 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 856 October 1998. 858 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 859 (IPv6) Addressing Architecture", RFC 3513, April 2003. 861 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 862 (HIP) Architecture", RFC 4423, May 2006. 864 10.2. Informative References 866 [I-D.ietf-behave-p2p-state] 867 Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 868 Peer(P2P) Communication Across Network Address 869 Translators(NATs)", draft-ietf-behave-p2p-state-06 (work 870 in progress), November 2007. 872 [I-D.irtf-hiprg-nat] 873 Stiemerling, M., "NAT and Firewall Traversal Issues of 874 Host Identity Protocol (HIP) Communication", 875 draft-irtf-hiprg-nat-04 (work in progress), March 2007. 877 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 878 Translator (NAT) Terminology and Considerations", 879 RFC 2663, August 1999. 881 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 883 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 884 RFC 3948, January 2005. 886 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 887 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 888 RFC 4787, January 2007. 890 Appendix A. Firewall Traversal 892 This section describes firewall traversal issues separately from NAT 893 issues. When the Initiator or the Responder of a HIP association is 894 behind a firewall, additional issues arise. The firewall discussion 895 applies both to IPv4 and IPv6 addressing. 897 The NAT traversal mechanisms described in this document require that 898 the firewall - stateful or not - allows UDP traffic. At the minimum, 899 successful firewall control packet traversal requires that the host 900 behind the firewall is allowed to communicate packets with a HIP 901 Relay (or a Responder without HIP Relay) that is listening on UDP 902 port HIPPORT. Successful ESP data packet traversal requires the same 903 for the TURN server. For unrelayed traffic, the destination port 904 HIPPORT should be open at the firewall to all hosts behind the 905 firewall. 907 Most firewall implementations support "UDP connection tracking", 908 i.e., after a host behind a firewall has initiated UDP communication 909 to the public Internet, the firewall accepts UDP response traffic in 910 the return direction. If no such return traffic arrives for a 911 specific period of time, the firewall stops accepting the given IP 912 address and port pair. The mechanisms described in this document 913 already enable traversal of such firewalls, if the keep-alive 914 interval used is less than the refresh interval of the firewall. 916 When the Initiator is behind a firewall, the NAT traversal mechanisms 917 described in this document depend on the ability to initiate 918 communication via UDP to the destination port HIPPORT from arbitrary 919 source ports and to receive UDP response traffic from that port to 920 the chosen source port. If the Initiator is behind a firewall that 921 does not support "UDP connection tracking", the NAT traversal 922 mechanisms described in this document can still be supported, if the 923 firewall allows permanently inbound UDP traffic from the port HIPPORT 924 and destined to arbitrary source IP addresses and UDP ports. 926 When the Responder is behind a firewall, the NAT traversal mechanisms 927 described in this document depend on the ability to send and receive 928 UDP traffic originating from HIPPORT of the HIP Relays and TURN 929 servers. When end-to-end traffic is preferred, arbitrary source IP 930 addresses and ports are required. 932 Appendix B. Base Exchange without ICE Connectivity Checks 934 In certain network environments, the ICE connectivity tests can be 935 omitted to reduce initial connection set up latency because base 936 exchange acts an implicit connectivity test itself. There are three 937 assumptions about such as environments. First, the Responder should 938 have a long-term, fixed locator in the network. Second, the 939 Responder should not have a HIP Relay configured for itself. Third, 940 the Initiator can reach the Responder by simply UDP encapsulating HIP 941 and ESP packets to the host. Detecting and configuring this 942 particular scenario is prone administrative failure unless carefully 943 planned. 945 In such a scenario, the Initiator sends an I1 packet over UDP to the 946 Responder. The Responder replies with a R1 packet that does not 947 contain the transform parameter as explained in Section 4.1. The 948 Initiator receives the R1 packet and determines from the absence of 949 the transform and RELAY_TO parameters that ICE connectivity tests can 950 be omitted with the Responder. Finally, the hosts set up IPsec 951 security associations using the locators observed from the concluding 952 I2 and R2 packets of the base exchange without ICE connectivity 953 tests. 955 Appendix C. IPv4-IPv6 Interoperability 957 Currently Relay Client and Server do not have to run any ICE 958 connectivity tests as described in Appendix B. However, it could be 959 useful for IPv4-IPv6 interoperability when the Relay Server actually 960 includes both the NAT transform parameter and multiple locators in 961 R2. The interoperability benefit is that the Relay could support 962 IPv4-based Initiators and IPv6-based Responders by converting the 963 network headers and recalculating UDP checksums. 965 Such an approach is underspecified in this document currently. It is 966 not yet recommended because it may consume resources at the Relay and 967 requires also similar conversion support at the TURN relay for data 968 packets. 970 Appendix D. Base Exchange through a Rendezvous Server 972 This section describes handling for a scenario where Initiator looks 973 up the information of the Responder from DNS and discovers a RVS 974 record [I-D.ietf-hip-rvs]. In such a case, the Initiator uses its 975 own HIP Relay to forward HIP traffic to the Rendezvous server. The 976 Initiator will send the I1 message using the its HIP Relay server 977 which will then forward it to the RVS server of the responder. The 978 responder will send the R1 packet directly to the Initiator's HIP 979 Relay server and the following I2 and R2 packets are also sent 980 directly using the Relay. 982 In case the Initiator is not able to distinguish which records are 983 RVS address records and which are Responders address records, then 984 the Initiator SHOULD first try to contact the Responder directly and 985 if none of the addresses is reachable it MAY try out them using its 986 own HIP Relay as described in the above. 988 Appendix E. Document Revision History 990 To be removed upon publication 992 +-----------------------------+-------------------------------------+ 993 | Revision | Comments | 994 +-----------------------------+-------------------------------------+ 995 | draft-ietf-nat-traversal-00 | Initial version. | 996 | draft-ietf-nat-traversal-01 | Draft based on RVS. | 997 | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | 998 | | ICE concepts. | 999 | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | 1000 +-----------------------------+-------------------------------------+ 1002 Authors' Addresses 1004 Miika Komu 1005 Helsinki Institute for Information Technology 1006 Metsanneidonkuja 4 1007 Espoo 1008 Finland 1010 Phone: +358503841531 1011 Fax: +35896949768 1012 Email: miika@iki.fi 1013 URI: http://www.hiit.fi/ 1014 Thomas Henderson 1015 The Boeing Company 1016 P.O. Box 3707 1017 Seattle, WA 1018 USA 1020 Email: thomas.r.henderson@boeing.com 1022 Philip Matthews 1023 Avaya 1024 100 Innovation Drive 1025 Ottawa, Ontario K2K 3G7 1026 Canada 1028 Phone: +1 613 592 4343 224 1029 Email: philip_matthews@magma.ca 1031 Hannes Tschofenig 1032 Nokia Siemens Networks 1033 Linnoitustie 6 1034 Espoo 02600 1035 Finland 1037 Phone: +358 (50) 4871445 1038 Email: Hannes.Tschofenig@gmx.net 1039 URI: http://www.tschofenig.com 1041 Ari Keraenen 1042 Ericsson Research Nomadiclab 1043 Hirsalantie 11 1044 02420 Jorvas 1045 Finland 1047 Phone: +358 9 2991 1048 Email: ari.keranen@ericsson.com 1049 Jan Melen 1050 Ericsson Research Nomadiclab 1051 Hirsalantie 11 1052 02420 Jorvas 1053 Finland 1055 Phone: +358 9 2991 1056 Email: jan.melen@ericsson.com 1058 Marcelo Bagnulo 1059 Huawei Lab at UC3M 1060 Av. Universidad 30 1061 Leganes, Madrid 28911 1062 Spain 1064 Phone: 34 91 6249500 1065 Email: marcelo@it.uc3m.es 1066 URI: http://www.it.uc3m.es/ 1068 Full Copyright Statement 1070 Copyright (C) The IETF Trust (2008). 1072 This document is subject to the rights, licenses and restrictions 1073 contained in BCP 78, and except as set forth therein, the authors 1074 retain all their rights. 1076 This document and the information contained herein are provided on an 1077 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1078 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1079 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1080 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1081 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1082 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1084 Intellectual Property 1086 The IETF takes no position regarding the validity or scope of any 1087 Intellectual Property Rights or other rights that might be claimed to 1088 pertain to the implementation or use of the technology described in 1089 this document or the extent to which any license under such rights 1090 might or might not be available; nor does it represent that it has 1091 made any independent effort to identify any such rights. Information 1092 on the procedures with respect to rights in RFC documents can be 1093 found in BCP 78 and BCP 79. 1095 Copies of IPR disclosures made to the IETF Secretariat and any 1096 assurances of licenses to be made available, or the result of an 1097 attempt made to obtain a general license or permission for the use of 1098 such proprietary rights by implementers or users of this 1099 specification can be obtained from the IETF on-line IPR repository at 1100 http://www.ietf.org/ipr. 1102 The IETF invites any interested party to bring to its attention any 1103 copyrights, patents or patent applications, or other proprietary 1104 rights that may cover technology that may be required to implement 1105 this standard. Please address the information to the IETF at 1106 ietf-ipr@ietf.org. 1108 Acknowledgment 1110 Funding for the RFC Editor function is provided by the IETF 1111 Administrative Support Activity (IASA).