idnits 2.17.1 draft-ietf-hip-native-nat-traversal-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 417 has weird spacing: '...eserved reser...' == Line 419 has weird spacing: '...Address an I...' == Line 455 has weird spacing: '... Length len...' == Line 458 has weird spacing: '...eserved reser...' == Line 460 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 (January 28, 2011) is 4808 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: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-04 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-00 == Outdated reference: A later version (-11) exists of draft-ietf-hip-rfc5203-bis-00 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Downref: Normative reference to an Experimental RFC: RFC 5770 == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-cert (ref. 'I-D.ietf-hip-cert') -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). 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: Standards Track Ericsson 5 Expires: August 1, 2011 January 28, 2011 7 Native NAT Traversal Mode for the Host Identity Protocol 8 draft-ietf-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 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). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 1, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Registration Authentication . . . . . . . . . . . . . . . 5 58 3.3. Forwarding Rules and Permissions . . . . . . . . . . . . . 5 59 3.4. Relaying UDP Encapsulated Data and Control Packets . . . . 6 60 3.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 7 61 3.6. Base Exchange via HIP Relay Server . . . . . . . . . . . . 7 62 3.7. Native NAT Traversal Mode Negotiation . . . . . . . . . . 7 63 3.8. Connectivity Check Pacing Negotiation . . . . . . . . . . 8 64 3.9. Connectivity Checks . . . . . . . . . . . . . . . . . . . 8 65 3.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 9 66 3.11. Handling Conflicting SPI Values . . . . . . . . . . . . . 9 67 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 9 69 4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 10 70 4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is 82 specified to run directly on top of IPv4 or IPv6. However, many 83 middleboxes found in the Internet, such as NATs and firewalls, often 84 allow only UDP or TCP traffic to pass [RFC5207]. Also, especially 85 NATs usually require the host behind a NAT to create a forwarding 86 state in the NAT before other hosts outside of the NAT can contact 87 the host behind the NAT. To overcome this problem, different 88 methods, commonly referred to as NAT traversal techniques, have been 89 developed. 91 Two NAT traversal techniques for HIP are specified in [RFC5770]. One 92 of them uses only UDP encapsulation, while the other uses also the 93 Interactive Connectivity Establishment (ICE) [RFC5245] protocol, 94 which in turn uses Session Traversal Utilities for NAT (STUN) 95 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] 96 protocols to achieve a reliable NAT traversal solution. 98 The benefit of using ICE and STUN/TURN is that one can re-use the NAT 99 traversal infrastructure already available in the Internet, such as 100 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 101 could be able to do something "smart" when they see STUN being used 102 for NAT traversal. However, implementing a full ICE/STUN/TURN 103 protocol stack results in a considerable amount of effort and code 104 which could be avoided by re-using and extending HIP messages and 105 state machines for the same purpose. Thus, this document specifies a 106 new NAT traversal mode that uses HIP messages instead of STUN for the 107 connectivity checks, keepalives, and data relaying. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 This document uses the same terminology as [RFC5770] and the 116 following: 118 HIP data relay: 119 A host that forwards HIP data packets, such as Encapsulating 120 Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis], between two 121 hosts. 123 Registered host: 124 A host that has registered for a relaying service with a HIP data 125 relay. 127 3. Protocol Description 129 This section describes the normative behavior of the protocol 130 extension. Most of the procedures are similar to what is defined in 131 [RFC5770] but with different, or additional, parameter types and 132 values. In addition, a new type of relaying server, HIP data relay, 133 is specified. Also, it should be noted that HIP version 2 134 [I-D.ietf-hip-rfc5201-bis] (instead of [RFC5201] used in [RFC5770]) 135 is expected to be used with this NAT traversal mode. 137 3.1. Relay Registration 139 Relay registration procedure for HIP signaling is identical to the 140 one specified in Section 4.1 of [RFC5770]. However, a host MAY also 141 register for UDP encapsulated ESP relaying using Registration Type 142 RELAY_UDP_ESP (value [TBD by IANA: 3]). 144 If the HIP relay server supports relaying of UDP encapsulated ESP, 145 the host is allowed to register for data relaying service (see 146 Section 3.2), and the relay has relaying resources (free port 147 numbers, bandwidth, etc.) available, the relay opens a UDP port on 148 one of its addresses and signals the address and port to the 149 registering host using the RELAYED_ADDRESS parameter (see Section 4.1 150 for details). If the relay would accept the data relaying request 151 but does not have enough resources to provide data relaying service, 152 it MUST reject the request with Failure Type [TBD by IANA: 2] 153 (Insufficient resources). 155 The registered host MUST maintain an active HIP association with the 156 data relay as long as it requires the data relaying service. When 157 the HIP association is closed (or times out), or the registration 158 lifetime passes without the registered host refreshing the 159 registration, the data relay MUST stop relaying packets for that host 160 and close the corresponding UDP port (unless other registered hosts 161 are still using it). 163 The data relay MAY use the same relayed address and port for multiple 164 registered hosts, but since this can cause problems with stateful 165 firewalls (see Section 5) it is NOT RECOMMENDED. 167 3.2. Registration Authentication 169 If the HIP data relay knows the Host Identities (HIs) of all the 170 hosts that are allowed to use the relaying service, it SHOULD reject 171 registrations from unknown hosts. However, since it may be 172 unfeasible to pre-configure the relay with all the HIs, the relay 173 SHOULD also support HIP certificates [I-D.ietf-hip-cert] to allow for 174 certificate based authentication. 176 When a host wants to register with a HIP data relay, it SHOULD check 177 if it has a suitable certificate for authenticating with the relay. 178 How the suitability is determined and how the certificates are 179 obtained is out of scope for this document. If the host has one or 180 more suitable certificates, the host SHOULD include them (or just the 181 most suitable one) in a CERT parameter to the HIP packet along with 182 the REG_REQUEST parameter. If the host does not have any suitable 183 certificates, it SHOULD send the registration request without the 184 CERT parameter to test whether the relay accepts the request based on 185 the host's identity. 187 When a relay receives a HIP packet with a REG_REQUEST parameter, and 188 it requires authentication for at least one of the Registration Types 189 listed in the REG_REQUEST parameter, it MUST first check whether the 190 HI of the registering host is in the allowed list for all the 191 Registration Types in the REG_REQUEST parameter. If the host is in 192 the allowed list (or the relay does not require any authentication), 193 the relay MUST proceed with the registration. 195 If the host was not in the allowed list and the relay requires the 196 host to authenticate, the relay MUST check whether the packet also 197 contains a CERT parameter. If the packet does not contain a CERT 198 parameter, the server MUST reject the registrations requiring 199 authentication with Failure Type 0 (Registration requires additional 200 credentials) [I-D.ietf-hip-rfc5203-bis]. If the certificate is valid 201 and accepted (issued for the registering host and signed by a trusted 202 issuer), the relay MUST proceed with the registration. If the 203 certificate in the parameter is not accepted, the relay MUST reject 204 the corresponding registrations with Failure Type [TBD by IANA: 3] 205 (Invalid certificate). 207 3.3. Forwarding Rules and Permissions 209 The HIP data relay uses a similar permission model as a TURN server: 210 before any ESP data packets sent by a peer are forwarded, a 211 permission MUST be set for the peer's address. The permissions also 212 install a forwarding rule, similar to TURN's channels, based on the 213 Security Parameter Index (SPI) values in the ESP packets. 215 Permissions are not required for the connectivity checks, but if a 216 relayed address is selected to be used for data, the registered host 217 MUST send an UPDATE message [I-D.ietf-hip-rfc5201-bis] with a 218 PEER_PERMISSION parameter (see Section 4.2) with the address of the 219 peer and the outbound and inbound SPI values the host is using with 220 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 MUST 228 be created and its lifetime MUST be set to 5 minutes. If an 229 identical permission already existed, it MUST be refreshed by setting 230 the lifetime to 5 minutes. A registered host SHOULD refresh 231 permissions roughly 1 minute before the expiration if the permission 232 is still needed. 234 3.4. Relaying UDP Encapsulated Data and Control Packets 236 When a HIP data relay accepts to relay UDP encapsulated data, it 237 opens a UDP port (relayed address) for this purpose as described in 238 Section 3.1. If the data relay receives a UDP encapsulated HIP 239 control packet on that port, it MUST forward the packet to the 240 registered host and add a RELAY_FROM parameter to the packet as if 241 the data relay was acting as a HIP relay server [RFC5770]. 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 [TBD by 278 IANA: 4]) from each of the interfaces to a HIP relay server. When a 279 HIP relay server receives a registration request with 280 CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, 281 containing the same information as if this was a relay registration, 282 to the response. This request type SHOULD NOT create any state at 283 the HIP relay server. 285 It is RECOMMENDED that the host also obtains a relayed candidate from 286 a HIP data relay as described in Section 3.1. 288 Gathering of candidates MAY also be performed like specified in 289 Section 4.2 of [RFC5770] if STUN and TURN servers are available, or 290 if the host has just a single interface and there are no TURN or HIP 291 data relay servers available. 293 3.6. Base Exchange via HIP Relay Server 295 The Base Exchange is performed as described in Section 4.5 of 296 [RFC5770], except that "ICE candidates" are replaced by the 297 candidates gathered using procedures described in Section 3.5 299 3.7. Native NAT Traversal Mode Negotiation 301 A host implementing this specification SHOULD signal the support for 302 the native HIP NAT traversal mode by adding ICE-HIP-UDP NAT traversal 303 mode (value [TBD by IANA: 3]) in the NAT_TRAVERSAL_MODE [RFC5770] 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. 307 Note that the results of the previously described methods, candidate 308 gathering and HIP data relay registration with HIP messages, can be 309 used also with the ICE-STUN-UDP NAT traversal mode. 311 3.8. Connectivity Check Pacing Negotiation 313 Since the NAT traversal mode specified in this document utilizes 314 connectivity checks, the check pacing negotiation MUST be performed 315 as specified in Section 4.4 of [RFC5770]. New connectivity check 316 transactions MUST NOT be started faster than once every Ta (the value 317 negotiated with the TRANSACTION_PACING parameter). 319 3.9. Connectivity Checks 321 The connectivity checks are performed as described in Section 4.6 of 322 [RFC5770] but instead of STUN packets, the connectivity checks are 323 HIP UPDATE packets. See Section 4.3 for parameter details. 325 As defined in [RFC5770], both hosts MUST form a priority ordered 326 checklist and start check transactions every Ta milliseconds as long 327 as the checks are running and there are candidate pairs whose tests 328 have not started. The retransmission timeout (RTO) for the 329 connectivity check UPDATE packets MUST be calculated as defined in 330 Section 4.6 of [RFC5770]. 332 All connectivity check request packets MUST contain a 333 CANDIDATE_PRIORITY parameter (see Section 4.3) with the priority 334 value that would be assigned to a peer reflexive candidate if one was 335 learned from this check. The UPDATE packets that acknowledge a 336 connectivity check requests MUST be sent from the same address that 337 received the check and to the same address where the check was 338 received from. 340 The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS 341 parameter with the port, protocol, and IP address of the address 342 where the connectivity check request was received from. 344 After a working candidate pair, or pairs, have been discovered, the 345 controlling host MUST conclude the checks by nominating the highest 346 priority candidate pair for use. The pair MUST be nominated by 347 sending an ESP packet on the selected pair. If the controlling host 348 does not have any data to send, it SHOULD send an ICMP echo request 349 using the nominated pair to signal to the controlled host that it can 350 stop checks and start using the nominated pair. 352 If the connectivity checks failed the hosts SHOULD notify each other 353 about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message 354 Type [RFC5770]. 356 3.10. NAT Keepalives 358 To keep the NAT bindings towards the HIP relay server and the HIP 359 data relay alive, if a registered host has not sent any data or 360 control messages to the relay for 15 seconds, it MUST send a HIP 361 NOTIFY packet to the relay. Likewise, if the host has not sent any 362 data to a host it has security association and has run connectivity 363 checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo 364 request using the same locators as the security association is using. 366 3.11. Handling Conflicting SPI Values 368 Since the HIP data relay determines from the SPI value to which peer 369 an ESP packet should be forwarded, the outbound SPI values need to be 370 unique for each relayed address registration. Thus, if a registered 371 host detects that a peer would use an SPI value that is already used 372 with another peer via the relay, it MUST NOT select the relayed 373 address for use. The host MAY restart the base exchange to avoid a 374 conflict or it MAY refrain from using the relayed candidate for the 375 connectivity checks. 377 Since the SPI space is 32 bits and the SPI values should be random, 378 the probability for a conflicting SPI value is fairly small. 379 However, a host with many peers MAY decrease the odds of a conflict 380 by registering more than one relayed address using different local 381 addresses. 383 4. Packet Formats 385 The following subsections define the parameter and packet encodings 386 for the new HIP parameters used for NAT traversal. UDP encapsulation 387 of the HIP and ESP packets and format of the other required 388 parameters is specified in Section 5 of [RFC5770]. 390 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 392 The format of the RELAYED_ADDRESS and MAPPED_ADDRESS parameters 393 (Figure 1) is identical to REG_FROM, RELAY_FROM and RELAY_TO 394 parameters. This document specifies only use of UDP relaying and 395 thus only protocol 17 is allowed. However, future documents may 396 specify support for other protocols. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Port | Protocol | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 | Address | 407 | | 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Type [TBD by IANA; 412 RELAYED_ADDRESS: 4650 413 MAPPED_ADDRESS: 4660] 414 Length 20 415 Port the UDP port number 416 Protocol IANA assigned, Internet Protocol number (17 for UDP) 417 Reserved reserved for future use; zero when sent, ignored 418 when received 419 Address an IPv6 address or an IPv4 address in "IPv4-Mapped 420 IPv6 address" format 422 Figure 1: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 424 4.2. PEER_PERMISSION Parameter 426 The format of the PEER_PERMISSION parameter is shown in Figure 2. 427 The parameter is used for setting up and refreshing forwarding rules 428 and permissions at the data relay for data packets. The parameter 429 contains one or more sets of Port, Protocol, Address, Outbound SPI 430 (OSPI), and Inbound SPI (ISPI) values. One set defines a rule for 431 one peer address. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Port | Protocol | Reserved | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 | Address | 442 | | 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | OSPI | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | ISPI | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 | ... | 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Type [TBD by IANA; 4680] 455 Length length in octets, excluding Type and Length 456 Port the transport layer (UDP) port number 457 Protocol IANA assigned, Internet Protocol number (17 for UDP) 458 Reserved reserved for future use; zero when sent, ignored 459 when received 460 Address an IPv6 address, or an IPv4 address in "IPv4-Mapped 461 IPv6 address" format, of the peer 462 OSPI the outbound SPI value the registered host is using for 463 the peer with the Address and Port 464 ISPI the inbound SPI value the registered host is using for 465 the peer with the Address and Port 467 Figure 2: Format of the PEER_PERMISSION Parameter 469 4.3. HIP Connectivity Check Packets 471 The connectivity request messages are HIP UPDATE packets with a 472 CANDIDATE_PRIORITY parameter (Figure 3). Response UPDATE packets 473 contain a MAPPED_ADDRESS parameter (Figure 1). 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Priority | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Type [TBD by IANA; 4700] 484 Length 4 485 Priority the priority of a (potential) peer reflexive candidate 487 Figure 3: Format of the CANDIDATE_PRIORITY Parameter 489 5. Security Considerations 491 Same security considerations as with [RFC5770] apply also to this NAT 492 traversal mode. 494 If the data relay uses the same relayed address and port for multiple 495 registered hosts, it appears to all the peers, and their firewalls, 496 that all the registered hosts using the relay are at the same 497 address. Thus, a stateful firewall may allow packets pass from hosts 498 that would not normally be able to send packets to a peer behind the 499 firewall. Therefore, a HIP data relay SHOULD NOT re-use the port 500 numbers. If port numbers need to be re-used, the relay SHOULD have a 501 sufficiently large pool of port numbers and select ports from the 502 pool randomly to decrease the chances of a registered host obtaining 503 the same address that a certain other host is using. 505 6. Acknowledgements 507 This document re-uses many of the ideas proposed in various earlier 508 HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin 509 Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav 510 Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip 511 Matthews. 513 7. IANA Considerations 515 This section is to be interpreted according to [RFC5226]. 517 This document updates the IANA Registry for HIP Parameter Types 518 [I-D.ietf-hip-rfc5201-bis] by assigning new HIP Parameter Type values 519 for the new HIP Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined 520 in Section 4.1), and PEER_PERMISSION (defined in Section 4.2). 522 This document also updates the IANA Registry for HIP NAT traversal 523 modes [RFC5770] by assigning value for the NAT traversal mode ICE- 524 HIP-UDP (defined in Section 3.7). 526 This document defines additional registration types for the HIP 527 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow 528 registering with a HIP relay server for ESP relaying service: 529 RELAY_UDP_ESP (defined in Section 3.1); and performing server 530 reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in 531 Section 3.5). 533 The IANA Registry for HIP Registration Failure Types is updated with 534 new Failure Types "Insufficient resources" (defined in Section 3.1) 535 and "Invalid certificate" (defined in Section 3.2). 537 8. References 539 8.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [I-D.ietf-hip-rfc5201-bis] 545 Moskowitz, R., Jokela, P., Henderson, T., and T. Heer, 546 "Host Identity Protocol", draft-ietf-hip-rfc5201-bis-04 547 (work in progress), January 2011. 549 [I-D.ietf-hip-rfc5202-bis] 550 Jokela, P., Moskowitz, R., Nikander, P., and J. Melen, 551 "Using the Encapsulating Security Payload (ESP) Transport 552 Format with the Host Identity Protocol (HIP)", 553 draft-ietf-hip-rfc5202-bis-00 (work in progress), 554 September 2010. 556 [I-D.ietf-hip-rfc5203-bis] 557 Laganier, J., Koponen, T., and L. Eggert, "Host Identity 558 Protocol (HIP) Registration Extension", 559 draft-ietf-hip-rfc5203-bis-00 (work in progress), 560 August 2010. 562 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 563 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 564 May 2008. 566 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 567 (ICE): A Protocol for Network Address Translator (NAT) 568 Traversal for Offer/Answer Protocols", RFC 5245, 569 April 2010. 571 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 572 Keranen, "Basic Host Identity Protocol (HIP) Extensions 573 for Traversal of Network Address Translators", RFC 5770, 574 April 2010. 576 [I-D.ietf-hip-cert] 577 Heer, T. and S. Varjonen, "Host Identity Protocol 578 Certificates", draft-ietf-hip-cert-09 (work in progress), 579 January 2011. 581 8.2. Informative References 583 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 584 "Host Identity Protocol", RFC 5201, April 2008. 586 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 587 Firewall Traversal Issues of Host Identity Protocol (HIP) 588 Communication", RFC 5207, April 2008. 590 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 591 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 592 October 2008. 594 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 595 Relays around NAT (TURN): Relay Extensions to Session 596 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 598 Authors' Addresses 600 Ari Keranen 601 Ericsson 602 Hirsalantie 11 603 02420 Jorvas 604 Finland 606 Email: Ari.Keranen@ericsson.com 607 Jan Melen 608 Ericsson 609 Hirsalantie 11 610 02420 Jorvas 611 Finland 613 Email: Jan.Melen@ericsson.com