idnits 2.17.1 draft-keranen-hip-native-nat-traversal-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year == Line 412 has weird spacing: '...eserved reser...' == Line 414 has weird spacing: '...Address an I...' == Line 449 has weird spacing: '... Length len...' == Line 452 has weird spacing: '...eserved reser...' == Line 454 has weird spacing: '...Address an I...' == (1 more instance...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (April 9, 2010) is 5131 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-02 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft J. Melen 4 Intended status: Experimental Ericsson 5 Expires: October 11, 2010 April 9, 2010 7 Native NAT Traversal Mode for the Host Identity Protocol 8 draft-keranen-hip-native-nat-traversal-01 10 Abstract 12 This document specifies a new Network Address Translator (NAT) 13 traversal mode for the Host Identity Protocol (HIP). The new mode is 14 based on the Interactive Connectivity Establishment (ICE) methodology 15 and UDP encapsulation of data and signaling traffic. The main 16 difference from the previously specified modes is the use of HIP 17 messages for all NAT traversal procedures. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 11, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Registration Authentication . . . . . . . . . . . . . . . 4 64 3.3. Forwarding Rules and Permissions . . . . . . . . . . . . . 5 65 3.4. Relaying UDP Encapsulated Data and Control Packets . . . . 6 66 3.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 7 67 3.6. Base Exchange via HIP Relay Server . . . . . . . . . . . . 7 68 3.7. Native NAT Traversal Mode Negotiation . . . . . . . . . . 7 69 3.8. Connectivity Check Pacing Negotiation . . . . . . . . . . 7 70 3.9. Connectivity Checks . . . . . . . . . . . . . . . . . . . 8 71 3.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 8 72 3.11. Handling Conflicting SPI Values . . . . . . . . . . . . . 9 73 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 9 75 4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 10 76 4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . . 11 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The Host Identity Protocol (HIP) [RFC5201] is specified to run 88 directly on top of IPv4 or IPv6. However, many middleboxes found in 89 the Internet, such as NATs and firewalls, often allow only UDP or TCP 90 traffic to pass [RFC5207]. Also, especially NATs usually require the 91 host behind a NAT to create a forwarding state in the NAT before 92 other hosts outside of the NAT can contact the host behind the NAT. 93 To overcome this problem, different methods, commonly referred to as 94 NAT traversal techniques, have been developed. 96 Two NAT traversal techniques for HIP are specified in 97 [I-D.ietf-hip-nat-traversal]. One of them uses only UDP 98 encapsulation, while the other uses also the Interactive Connectivity 99 Establishment (ICE) [I-D.ietf-mmusic-ice] protocol, which in turn 100 uses Session Traversal Utilities for NAT (STUN) [RFC5389] and 101 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] 102 protocols to achieve a reliable NAT traversal solution. 104 The benefit of using ICE and STUN/TURN is that one can re-use the NAT 105 traversal infrastructure already available in the Internet, such as 106 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 107 could be able to do something "smart" when they see STUN being used 108 for NAT traversal. However, implementing a full ICE/STUN/TURN 109 protocol stack results in a considerable amount of effort and code 110 which could be avoided by re-using and extending HIP messages and 111 state machines for the same purpose. Thus, this document specifies a 112 new NAT traversal mode that uses HIP messages instead of STUN for the 113 connectivity checks, keepalives, and data relaying. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 This document uses the same terminology as 122 [I-D.ietf-hip-nat-traversal] and the following: 124 HIP data relay: 125 A host that forwards HIP data packets, such as Encapsulating 126 Security Payload (ESP) [RFC5202], between two hosts. 128 Registered host: 129 A host that has registered for a relaying service with a HIP data 130 relay. 132 3. Protocol Description 134 This section describes the normative behavior of the protocol 135 extension. Most of the procedures are similar to what is defined in 136 [I-D.ietf-hip-nat-traversal] but with different, or additional, 137 parameter types and values. In addition, a new type of relaying 138 server, HIP data relay, is specified. 140 3.1. Relay Registration 142 Relay registration procedure for HIP signaling is identical to the 143 one specified in Section 4.1 of [I-D.ietf-hip-nat-traversal]. 144 However, a host MAY also register for UDP encapsulated ESP relaying 145 using Registration Type value RELAY_UDP_ESP (value 3). 147 If the HIP relay server supports relaying of UDP encapsulated ESP, 148 the host is allowed to register for data relaying service (see 149 Section 3.2), and the relay has relaying resources (free port 150 numbers, bandwidth, etc.) available, the relay opens a UDP port on 151 one of its addresses and signals the address and port to the 152 registering host using the RELAYED_ADDRESS parameter (see Section 4.1 153 for details). If the relay would accept the data relaying request 154 but does not have enough resources to provide data relaying service, 155 it MUST reject the request with Failure Type 2 (Insufficient 156 resources). 158 The registered host MUST maintain an active HIP association with the 159 data relay as long as it requires the data relaying service. When 160 the HIP association is closed (or times out), or the registration 161 lifetime passes without the registered host refreshing the 162 registration, the data relay MUST stop relaying packets for that host 163 and close the corresponding UDP port. 165 The data relay MAY use the same relayed address and port for multiple 166 registered hosts, but since this can cause problems with stateful 167 firewalls (see Section 5) it is NOT RECOMMENDED. 169 3.2. Registration Authentication 171 If the HIP data relay knows the Host Identities (HIs) of all the 172 hosts that are allowed to use the relaying service, it SHOULD reject 173 registrations from unknown hosts. However, since it may be 174 unfeasible to pre-configure the relay with all the HIs, the relay 175 SHOULD also support HIP certificates [I-D.ietf-hip-cert] to allow for 176 certificate based authentication. 178 When a host wants to register with a HIP data relay, it SHOULD check 179 if it has a suitable certificate for authenticating with the relay. 180 How the suitability is determined and how the certificates are 181 obtained is out of scope for this document. If the host has one or 182 more suitable certificates, the host SHOULD include them (or just the 183 most suitable one) in a CERT parameter to the HIP packet along with 184 the REG_REQUEST parameter. If the host does not have any suitable 185 certificates, it SHOULD send the registration request without the 186 CERT parameter to test whether the relay accepts the request based on 187 the host's identity. 189 When a relay receives a HIP packet with a REG_REQUEST parameter, and 190 it requires authentication for at least one of the Registration Types 191 listed in the REG_REQUEST parameter, it MUST first check whether the 192 HI of the registering host is in the allowed list for all the 193 Registration Types in the REG_REQUEST parameter. If the host is in 194 the allowed list (or the relay does not require any authentication), 195 the relay MUST proceed with the registration. 197 If the host was not in the allowed list and the relay requires hosts 198 to authenticate, the relay MUST check whether the packet also 199 contains a CERT parameter. If the packet does not contain a CERT 200 parameter, the server MUST reject the registrations requiring 201 authentication with Failure Type 0 (Registration requires additional 202 credentials) [RFC5203]. If the certificate is valid and accepted 203 (issued for the registering host and signed by a trusted issuer), the 204 relay MUST proceed with the registration. If the certificate in the 205 parameter is not accepted, the relay MUST reject the corresponding 206 registrations with Failure Type 3 (Invalid certificate). 208 3.3. Forwarding Rules and Permissions 210 The HIP data relay uses a similar permission model as a TURN server: 211 before any ESP data packets sent by a peer are forwarded, a 212 permission must be set for the peer's address. The permissions also 213 install a forwarding rule, similar to TURN's channels, based on the 214 Security Parameter Index (SPI) values in the ESP packets. 216 Permissions are not required for the connectivity checks, but if a 217 relayed address is selected to be used for data, the registered host 218 MUST send an UPDATE message with a PEER_PERMISSION parameter with the 219 address of the peer and the outbound and inbound SPI values the host 220 is using with this peer. 222 When a data relay receives an UPDATE with a PEER_PERMISSION 223 parameter, it MUST check if the sender of the UPDATE is registered 224 for data relaying service, and drop the UPDATE if the host was not 225 registered. If the host was registered, the relay checks if there is 226 a permission with matching information (address, protocol, port and 227 SPI values). If there is no such permission, a new permission is 228 created and its lifetime is set to 5 minutes. If an identical 229 permission already existed, it is refreshed by setting the lifetime 230 to 5 minutes. A registered host SHOULD refresh permissions roughly 1 231 minute before the expiration if the permission is still needed. 233 3.4. Relaying UDP Encapsulated Data and Control Packets 235 When a HIP data relay accepts to relay UDP encapsulated data, it 236 opens a UDP port (relayed address) for this purpose as described in 237 Section 3.1. If the data relay receives a UDP encapsulated HIP 238 control packet on that port, it MUST forward the packet to the 239 registered host and add a RELAY_FROM parameter to the packet as if 240 the data relay was acting as a HIP relay server 241 [I-D.ietf-hip-nat-traversal]. 243 When a host wants to send a HIP control packet (such as a 244 connectivity check packet) to a peer via the data relay, it MUST add 245 a RELAY_TO parameter containing the peer's address to the packet and 246 send it to the data relay's address. The data relay MUST send the 247 packet to the peer's address from the relayed address. 249 If the data relay receives a UDP packet that is not a HIP control 250 packet to the relayed address, it MUST check whether there is a 251 permission set for the peer the packet is coming from (i.e., the 252 sender's address and SPI value matches to an installed permission), 253 and if there is, it MUST forward the packet to the registered host 254 that created the permission. Packets without a permission MUST be 255 dropped silently. 257 When a host wants to send a UDP encapsulated ESP packet to a peer via 258 the data relay, it MUST have an active permission at the data relay 259 for the peer with the outbound SPI value it is using. The host MUST 260 send the UDP encapsulated ESP packet to the data relay's address. 262 When the data relay receives a UDP encapsulated ESP packet from a 263 registered host, it MUST check whether there exists a permission for 264 that outbound SPI value. If such permission exists, the packet MUST 265 be forwarded to the address that was registered for the SPI value. 266 If no permission exists, the packet is dropped. 268 3.5. Candidate Gathering 270 A host needs to gather a set of address candidates before starting 271 the connectivity checks. One server reflexive candidate can be 272 discovered during the registration with the HIP relay server from the 273 REG_FROM parameter. 275 If a host has more than one network interface, additional server 276 reflexive candidates can be discovered by sending registration 277 requests with Registration Type CANDIDATE_DISCOVERY (value 4) from 278 each of the interfaces to a HIP relay server. When a HIP relay 279 server receives a registration request with CANDIDATE_DISCOVERY type, 280 it MUST add a REG_FROM parameter, containing the same information as 281 if this was a relay registration, to the response. This request type 282 SHOULD NOT create any state at the HIP relay server. 284 It is RECOMMENDED that the host also obtains a relayed candidate from 285 a HIP data relay as described in Section 3.1. 287 Gathering of candidates MAY also be performed like specified in 288 Section 4.2 of [I-D.ietf-hip-nat-traversal] if STUN and TURN servers 289 are available, or if the host has just a single interface and there 290 are no TURN or HIP data relay servers available. 292 3.6. Base Exchange via HIP Relay Server 294 The Base Exchange is performed as described in Section 4.5 of 295 [I-D.ietf-hip-nat-traversal], except that "ICE candidates" are 296 replaced by the candidates gathered using procedures described in 297 Section 3.5 299 3.7. Native NAT Traversal Mode Negotiation 301 A host implementing this specification can signal the support for the 302 native HIP NAT traversal mode by adding ICE-HIP-UDP NAT traversal 303 mode (value 3) in the NAT_TRAVERSAL_MODE [I-D.ietf-hip-nat-traversal] 304 parameter. If this mode is supported by both endpoints, and is the 305 most preferred mode out of the all supported modes, further NAT 306 traversal procedures are performed as specified in this document. 308 3.8. Connectivity Check Pacing Negotiation 310 Since the NAT traversal mode specified in this document utilizes 311 connectivity checks, the check pacing negotiation MUST be performed 312 as specified in Section 4.4 of [I-D.ietf-hip-nat-traversal]. New 313 connectivity check transactions MUST NOT be started faster than once 314 every Ta (the value negotiated with the TRANSACTION_PACING 315 parameter). 317 3.9. Connectivity Checks 319 The connectivity checks are performed as described in Section 4.6 of 320 [I-D.ietf-hip-nat-traversal] but instead of STUN packets, the 321 connectivity checks are HIP UPDATE packets. See Section 4.3 for 322 parameter details. 324 As defined in [I-D.ietf-hip-nat-traversal], both hosts MUST form a 325 priority ordered checklist and start check transactions every Ta 326 milliseconds as long as the checks are running and there are 327 candidate pairs whose tests have not started. The retransmission 328 timeout (RTO) for the connectivity check UPDATE packets MUST be 329 calculated as defined in Section 4.6 of [I-D.ietf-hip-nat-traversal]. 331 All connectivity check request packets MUST contain a 332 CANDIDATE_PRIORITY parameter with the priority value that would be 333 assigned to a peer reflexive candidate if one was learned from this 334 check. The UPDATE packets that acknowledge a connectivity check 335 requests MUST be sent from the same address that received the check 336 and to the same address where the check was received from. 338 The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS 339 parameter with the port, protocol, and IP address of the address 340 where the connectivity check request was received from. 342 After a working candidate pair, or pairs, have been discovered, the 343 controlling host MUST conclude the checks by nominating the highest 344 priority candidate pair for use. The pair MUST be nominated by 345 sending an ESP packet on the selected pair. If the controlling host 346 does not have any data to send, it SHOULD send an ICMP echo request 347 using the nominated pair to signal to the controlled host that it can 348 stop checks and start using the nominated pair. 350 If the connectivity checks failed the hosts SHOULD notify each other 351 about the failure with a CONNECTIVITY_CHECKS_FAILED NOTIFY packet. 353 3.10. NAT Keepalives 355 To keep the NAT bindings towards the HIP relay server and the HIP 356 data relay alive, if a registered host has not sent any data or 357 control messages to the relay for 15 seconds, it MUST send a HIP 358 NOTIFY packet to the relay. Likewise, if the host has not sent any 359 data to a host it has security association and has run connectivity 360 checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo 361 request using the same locators as the security association is using. 363 3.11. Handling Conflicting SPI Values 365 Since the HIP data relay determines from the SPI value to which peer 366 an ESP packet should be forwarded, the outbound SPI values need to be 367 unique for each relayed address registration. Thus, if a registered 368 host detects that a peer would use an SPI value that is already used 369 with another peer via the relay, it MUST NOT select the relayed 370 address for use. The host MAY restart the base exchange to avoid a 371 conflict or it MAY refrain from using the relayed candidate for the 372 connectivity checks. 374 Since the SPI space is 32 bits and the SPI values should be random, 375 the probability for a conflicting SPI value is fairly small. 376 However, a host with many peers MAY decrease the odds of a conflict 377 by registering more than one relayed address using different local 378 addresses. 380 4. Packet Formats 382 The following subsections define the parameter and packet encodings 383 for the new HIP parameters used for NAT traversal. UDP encapsulation 384 of the HIP and ESP packets and format of the other required 385 parameters is specified in Section 5 of [I-D.ietf-hip-nat-traversal]. 387 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 389 The format of the RELAYED_ADDRESS and MAPPED_ADDRESS parameters 390 (Figure 1) is identical to REG_FROM, RELAY_FROM and RELAY_TO 391 parameters. This document specifies only use of UDP relaying and 392 thus only protocol 17 is allowed. However, future documents may 393 specify support for other protocols. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Port | Protocol | Reserved | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | Address | 404 | | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Type [TBD by IANA; 952] 409 Length 20 410 Port the UDP port number 411 Protocol IANA assigned, Internet Protocol number (17 for UDP) 412 Reserved reserved for future use; zero when sent, ignored 413 when received 414 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 415 IPv6 address" format 417 Figure 1: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 419 4.2. PEER_PERMISSION Parameter 421 The format of the PEER_PERMISSION parameter is shown in Figure 2. 422 The parameter is used for setting up and refreshing forwarding rules 423 and permissions at the data relay for data packets. The parameter 424 contains one or more sets of Port, Protocol, Address, Outbound SPI, 425 and Inbound SPI values. One set defines a rule for one peer address. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Port | Protocol | Reserved | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 | Address | 436 | | 437 | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | OSPI | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | ISPI | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 | ... | 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Type [TBD by IANA; 1020] 449 Length length in octets, excluding Type and Length 450 Port the transport layer (UDP) port number 451 Protocol IANA assigned, Internet Protocol number (17 for UDP) 452 Reserved reserved for future use; zero when sent, ignored 453 when received 454 Address an IPv6 address, or an IPv4 address in "IPv4-Mapped 455 IPv6 address" format, of the peer 456 OSPI the outbound SPI value the registered host is using for 457 the peer with the Address and Port 458 ISPI the inbound SPI value the registered host is using for 459 the peer with the Address and Port 461 Figure 2: Format of the PEER_PERMISSION Parameter 463 4.3. HIP Connectivity Check Packets 465 The connectivity request messages are HIP UPDATE packets with 466 CANDIDATE_PRIORITY parameter (Figure 3). Response UPDATE packets 467 contain a MAPPED_ADDRESS parameter (Figure 1). 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Type | Length | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Priority | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Type [TBD by IANA; 954] 478 Length 4 479 Priority the priority of a peer reflexive candidate 481 Figure 3: Format of the CANDIDATE_PRIORITY Parameter 483 5. Security Considerations 485 If the data relay uses the same relayed address and port for multiple 486 registered hosts, it appears to all the peers, and their firewalls, 487 that all the registered hosts using the relay are at the same 488 address. Thus, a stateful firewall may allow packets pass from hosts 489 that would not normally be able to send packets to a peer behind the 490 firewall. Therefore, a HIP data relay SHOULD NOT re-use the port 491 numbers. If port numbers need to be re-used, the relay SHOULD have a 492 sufficiently large pool of port numbers and select ports from the 493 pool randomly to decrease the chances of a registered host obtaining 494 the same address that a certain other host is using. 496 6. Acknowledgements 498 This document re-uses many of the ideas proposed in various earlier 499 HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin 500 Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav 501 Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip 502 Matthews. 504 7. IANA Considerations 506 This section is to be interpreted according to [RFC5226]. 508 This document updates the IANA Registry for HIP Parameter Types 509 [RFC5201] by assigning new HIP Parameter Type value for the new HIP 510 Parameter: RELAYED_ADDRESS (defined in Section 4.1). 512 This document also updates the IANA Registry for HIP NAT traversal 513 modes [I-D.ietf-hip-nat-traversal] by assigning value for the NAT 514 traversal mode ICE-HIP-UDP (defined in Section 3.7). 516 This document defines additional registration types for the HIP 517 Registration Extension [RFC5203] that allow registering with a HIP 518 relay server for ESP relaying service: RELAY_UDP_ESP (defined in 519 Section 3.1); and performing server reflexive candidate discovery: 520 CANDIDATE_DISCOVERY (defined in Section 3.5). 522 The IANA Registry for HIP Registration Failure Types is updated with 523 new Failure Types "Insufficient resources" (defined in Section 3.1) 524 and "Invalid certificate" (defined in Section 3.2). 526 8. References 528 8.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 534 "Host Identity Protocol", RFC 5201, April 2008. 536 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 537 Encapsulating Security Payload (ESP) Transport Format with 538 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 540 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 541 Protocol (HIP) Registration Extension", RFC 5203, 542 April 2008. 544 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 545 Firewall Traversal Issues of Host Identity Protocol (HIP) 546 Communication", RFC 5207, April 2008. 548 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 549 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 550 May 2008. 552 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 553 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 554 October 2008. 556 [I-D.ietf-hip-nat-traversal] 557 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 558 Keranen, "Basic HIP Extensions for Traversal of Network 559 Address Translators", draft-ietf-hip-nat-traversal-09 560 (work in progress), October 2009. 562 [I-D.ietf-mmusic-ice] 563 Rosenberg, J., "Interactive Connectivity Establishment 564 (ICE): A Protocol for Network Address Translator (NAT) 565 Traversal for Offer/Answer Protocols", 566 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 568 [I-D.ietf-hip-cert] 569 Heer, T. and S. Varjonen, "HIP Certificates", 570 draft-ietf-hip-cert-02 (work in progress), October 2009. 572 8.2. Informative References 574 [I-D.ietf-behave-turn] 575 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 576 Relays around NAT (TURN): Relay Extensions to Session 577 Traversal Utilities for NAT (STUN)", 578 draft-ietf-behave-turn-16 (work in progress), July 2009. 580 Authors' Addresses 582 Ari Keranen 583 Ericsson 584 Hirsalantie 11 585 02420 Jorvas 586 Finland 588 Email: Ari.Keranen@ericsson.com 590 Jan Melen 591 Ericsson 592 Hirsalantie 11 593 02420 Jorvas 594 Finland 596 Email: Jan.Melen@ericsson.com