idnits 2.17.1 draft-ietf-hip-native-nat-traversal-05.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 (June 14, 2013) is 3967 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-11 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-02 == Outdated reference: A later version (-11) exists of draft-ietf-hip-rfc5203-bis-02 ** 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 ** Obsolete normative reference: RFC 6253 (Obsoleted by RFC 8002) -- 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 (~~), 11 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: December 16, 2013 June 14, 2013 7 Native NAT Traversal Mode for the Host Identity Protocol 8 draft-ietf-hip-native-nat-traversal-05 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 December 16, 2013. 36 Copyright Notice 38 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . 4 57 3.2. Registration Authentication . . . . . . . . . . . . . . . 4 58 3.3. Forwarding Rules and Permissions . . . . . . . . . . . . 5 59 3.4. Relaying UDP Encapsulated Data and Control Packets . . . 6 60 3.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . 7 64 3.9. Connectivity Checks . . . . . . . . . . . . . . . . . . . 8 65 3.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 11 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 8.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 80 The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is 81 specified to run directly on top of IPv4 or IPv6. However, many 82 middleboxes found in the Internet, such as NATs and firewalls, often 83 allow only UDP or TCP traffic to pass [RFC5207]. Also, especially 84 NATs usually require the host behind a NAT to create a forwarding 85 state in the NAT before other hosts outside of the NAT can contact 86 the host behind the NAT. To overcome this problem, different 87 methods, commonly referred to as NAT traversal techniques, have been 88 developed. 90 Two NAT traversal techniques for HIP are specified in [RFC5770]. One 91 of them uses only UDP encapsulation, while the other uses also the 92 Interactive Connectivity Establishment (ICE) [RFC5245] protocol, 93 which in turn uses Session Traversal Utilities for NAT (STUN) 94 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] 95 protocols to achieve a reliable NAT traversal solution. 97 The benefit of using ICE and STUN/TURN is that one can re-use the NAT 98 traversal infrastructure already available in the Internet, such as 99 STUN and TURN servers. Also, some middleboxes may be STUN-aware and 100 could be able to do something "smart" when they see STUN being used 101 for NAT traversal. However, implementing a full ICE/STUN/TURN 102 protocol stack results in a considerable amount of effort and code 103 which could be avoided by re-using and extending HIP messages and 104 state machines for the same purpose. Thus, this document specifies a 105 new NAT traversal mode that uses HIP messages instead of STUN for the 106 connectivity checks, keepalives, and data relaying. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 This document uses the same terminology as [RFC5770] and the 115 following: 117 HIP data relay: 118 A host that forwards HIP data packets, such as Encapsulating 119 Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis], between two 120 hosts. 122 Registered host: 123 A host that has registered for a relaying service with a HIP data 124 relay. 126 3. Protocol Description 128 This section describes the normative behavior of the protocol 129 extension. Most of the procedures are similar to what is defined in 130 [RFC5770] but with different, or additional, parameter types and 131 values. In addition, a new type of relaying server, HIP data relay, 132 is specified. Also, it should be noted that HIP version 2 133 [I-D.ietf-hip-rfc5201-bis] (instead of [RFC5201] used in [RFC5770]) 134 is expected to be used with this NAT traversal mode. 136 3.1. Relay Registration 138 Relay registration procedure for HIP signaling is identical to the 139 one specified in Section 4.1 of [RFC5770]. However, a host MAY also 140 register for UDP encapsulated ESP relaying using Registration Type 141 RELAY_UDP_ESP (value [TBD by IANA: 3]). 143 If the HIP relay server supports relaying of UDP encapsulated ESP, 144 the host is allowed to register for data relaying service (see 145 Section 3.2), and the relay has relaying resources (free port 146 numbers, bandwidth, etc.) available, the relay opens a UDP port on 147 one of its addresses and signals the address and port to the 148 registering host using the RELAYED_ADDRESS parameter (see Section 4.1 149 for details). If the relay would accept the data relaying request 150 but does not have enough resources to provide data relaying service, 151 it MUST reject the request with Failure Type [TBD by IANA: 2] 152 (Insufficient resources). 154 The registered host MUST maintain an active HIP association with the 155 data relay as long as it requires the data relaying service. When 156 the HIP association is closed (or times out), or the registration 157 lifetime passes without the registered host refreshing the 158 registration, the data relay MUST stop relaying packets for that host 159 and close the corresponding UDP port (unless other registered hosts 160 are still using it). 162 The data relay MAY use the same relayed address and port for multiple 163 registered hosts, but since this can cause problems with stateful 164 firewalls (see Section 5) it is NOT RECOMMENDED. 166 3.2. Registration Authentication 168 If the HIP data relay knows the Host Identities (HIs) of all the 169 hosts that are allowed to use the relaying service, it SHOULD reject 170 registrations from unknown hosts. However, since it may be 171 unfeasible to pre-configure the relay with all the HIs, the relay 172 SHOULD also support HIP certificates [RFC6253] to allow for 173 certificate based authentication. 175 When a host wants to register with a HIP data relay, it SHOULD check 176 if it has a suitable certificate for authenticating with the relay. 177 How the suitability is determined and how the certificates are 178 obtained is out of scope for this document. If the host has one or 179 more suitable certificates, the host SHOULD include them (or just the 180 most suitable one) in a CERT parameter to the HIP packet along with 181 the REG_REQUEST parameter. If the host does not have any suitable 182 certificates, it SHOULD send the registration request without the 183 CERT parameter to test whether the relay accepts the request based on 184 the host's identity. 186 When a relay receives a HIP packet with a REG_REQUEST parameter, and 187 it requires authentication for at least one of the Registration Types 188 listed in the REG_REQUEST parameter, it MUST first check whether the 189 HI of the registering host is in the allowed list for all the 190 Registration Types in the REG_REQUEST parameter. If the host is in 191 the allowed list (or the relay does not require any authentication), 192 the relay MUST proceed with the registration. 194 If the host was not in the allowed list and the relay requires the 195 host to authenticate, the relay MUST check whether the packet also 196 contains a CERT parameter. If the packet does not contain a CERT 197 parameter, the server MUST reject the registrations requiring 198 authentication with Failure Type 0 (Registration requires additional 199 credentials) [I-D.ietf-hip-rfc5203-bis]. If the certificate is valid 200 and accepted (issued for the registering host and signed by a trusted 201 issuer), the relay MUST proceed with the registration. If the 202 certificate in the parameter is not accepted, the relay MUST reject 203 the corresponding registrations with Failure Type [TBD by IANA: 3] 204 (Invalid certificate). 206 3.3. Forwarding Rules and Permissions 208 The HIP data relay uses a similar permission model as a TURN server: 209 before any ESP data packets sent by a peer are forwarded, a 210 permission MUST be set for the peer's address. The permissions also 211 install a forwarding rule, similar to TURN's channels, based on the 212 Security Parameter Index (SPI) values in the ESP packets. 214 Permissions are not required for the connectivity checks, but if a 215 relayed address is selected to be used for data, the registered host 216 MUST send an UPDATE message [I-D.ietf-hip-rfc5201-bis] with a 217 PEER_PERMISSION parameter (see Section 4.2) with the address of the 218 peer and the outbound and inbound SPI values the host is using with 219 this peer. 221 When a data relay receives an UPDATE with a PEER_PERMISSION 222 parameter, it MUST check if the sender of the UPDATE is registered 223 for data relaying service, and drop the UPDATE if the host was not 224 registered. If the host was registered, the relay checks if there is 225 a permission with matching information (address, protocol, port and 226 SPI values). If there is no such permission, a new permission MUST 227 be created and its lifetime MUST be set to 5 minutes. If an 228 identical permission already existed, it MUST be refreshed by setting 229 the lifetime to 5 minutes. A registered host SHOULD refresh 230 permissions roughly 1 minute before the expiration if the permission 231 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 [RFC5770]. 242 When a host wants to send a HIP control packet (such as a 243 connectivity check packet) to a peer via the data relay, it MUST add 244 a RELAY_TO parameter containing the peer's address to the packet and 245 send it to the data relay's address. The data relay MUST send the 246 packet to the peer's address from the relayed address. 248 If the data relay receives a UDP packet that is not a HIP control 249 packet to the relayed address, it MUST check whether there is a 250 permission set for the peer the packet is coming from (i.e., the 251 sender's address and SPI value matches to an installed permission), 252 and if there is, it MUST forward the packet to the registered host 253 that created the permission. Packets without a permission MUST be 254 dropped silently. 256 When a host wants to send a UDP encapsulated ESP packet to a peer via 257 the data relay, it MUST have an active permission at the data relay 258 for the peer with the outbound SPI value it is using. The host MUST 259 send the UDP encapsulated ESP packet to the data relay's address. 261 When the data relay receives a UDP encapsulated ESP packet from a 262 registered host, it MUST check whether there exists a permission for 263 that outbound SPI value. If such permission exists, the packet MUST 264 be forwarded to the address that was registered for the SPI value. 265 If no permission exists, the packet is dropped. 267 3.5. Candidate Gathering 269 A host needs to gather a set of address candidates before starting 270 the connectivity checks. One server reflexive candidate can be 271 discovered during the registration with the HIP relay server from the 272 REG_FROM parameter. 274 If a host has more than one network interface, additional server 275 reflexive candidates can be discovered by sending registration 276 requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by 277 IANA: 4]) from each of the interfaces to a HIP relay server. When a 278 HIP relay server receives a registration request with 279 CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, 280 containing the same information as if this was a relay registration, 281 to the response. This request type SHOULD NOT create any state at 282 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 [RFC5770] if STUN and TURN servers are available, or 289 if the host has just a single interface and there are no TURN or HIP 290 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 [RFC5770], except that "ICE candidates" are replaced by the 296 candidates gathered using procedures described in Section 3.5 298 3.7. Native NAT Traversal Mode Negotiation 300 A host implementing this specification SHOULD signal the support for 301 the native HIP NAT traversal mode by adding ICE-HIP-UDP NAT traversal 302 mode (value [TBD by IANA: 3]) in the NAT_TRAVERSAL_MODE [RFC5770] 303 parameter. If this mode is supported by both endpoints, and is the 304 most preferred mode out of the all supported modes, further NAT 305 traversal procedures are performed as specified in this document. 306 Note that the results of the previously described methods, candidate 307 gathering and HIP data relay registration with HIP messages, can be 308 used also with the ICE-STUN-UDP NAT traversal mode. 310 3.8. Connectivity Check Pacing Negotiation 312 Since the NAT traversal mode specified in this document utilizes 313 connectivity checks, the check pacing negotiation MUST be performed 314 as specified in Section 4.4 of [RFC5770]. New connectivity check 315 transactions MUST NOT be started faster than once every Ta (the value 316 negotiated with the TRANSACTION_PACING parameter). 318 3.9. Connectivity Checks 320 The connectivity checks are performed as described in Section 4.6 of 321 [RFC5770] but instead of STUN packets, the connectivity checks are 322 HIP UPDATE packets. See Section 4.3 for parameter details. 324 As defined in [RFC5770], both hosts MUST form a priority ordered 325 checklist and start check transactions every Ta milliseconds as long 326 as the checks are running and there are candidate pairs whose tests 327 have not started. The retransmission timeout (RTO) for the 328 connectivity check UPDATE packets MUST be calculated as defined in 329 Section 4.6 of [RFC5770]. 331 All connectivity check request packets MUST contain a 332 CANDIDATE_PRIORITY parameter (see Section 4.3) with the priority 333 value that would be assigned to a peer reflexive candidate if one was 334 learned from this check. The UPDATE packets that acknowledge a 335 connectivity check requests MUST be sent from the same address that 336 received the check and to the same address where the check was 337 received from. 339 The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS 340 parameter with the port, protocol, and IP address of the address 341 where the connectivity check request was received from. 343 After a working candidate pair, or pairs, have been discovered, the 344 controlling host MUST conclude the checks by nominating the highest 345 priority candidate pair for use. The pair MUST be nominated by 346 sending an ESP packet on the selected pair. If the controlling host 347 does not have any data to send, it SHOULD send an ICMP echo request 348 using the nominated pair to signal to the controlled host that it can 349 stop checks and start using the nominated pair. 351 If the connectivity checks failed the hosts SHOULD notify each other 352 about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message 353 Type [RFC5770]. 355 3.10. NAT Keepalives 357 To keep the NAT bindings towards the HIP relay server and the HIP 358 data relay alive, if a registered host has not sent any data or 359 control messages to the relay for 15 seconds, it MUST send a HIP 360 NOTIFY packet to the relay. Likewise, if the host has not sent any 361 data to a host it has security association and has run connectivity 362 checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo 363 request using the same locators as the security association is using. 365 3.11. Handling Conflicting SPI Values 367 Since the HIP data relay determines from the SPI value to which peer 368 an ESP packet should be forwarded, the outbound SPI values need to be 369 unique for each relayed address registration. Thus, if a registered 370 host detects that a peer would use an SPI value that is already used 371 with another peer via the relay, it MUST NOT select the relayed 372 address for use. The host MAY restart the base exchange to avoid a 373 conflict or it MAY refrain from using the relayed candidate for the 374 connectivity checks. 376 Since the SPI space is 32 bits and the SPI values should be random, 377 the probability for a conflicting SPI value is fairly small. 378 However, a host with many peers MAY decrease the odds of a conflict 379 by registering more than one relayed address using different local 380 addresses. 382 4. Packet Formats 384 The following subsections define the parameter and packet encodings 385 for the new HIP parameters used for NAT traversal. UDP encapsulation 386 of the HIP and ESP packets and format of the other required 387 parameters is specified in Section 5 of [RFC5770]. 389 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 391 The format of the RELAYED_ADDRESS and MAPPED_ADDRESS parameters 392 (Figure 1) is identical to REG_FROM, RELAY_FROM and RELAY_TO 393 parameters. This document specifies only use of UDP relaying and 394 thus only protocol 17 is allowed. However, future documents may 395 specify support for other protocols. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Port | Protocol | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | 405 | Address | 406 | | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Type [TBD by IANA; 411 RELAYED_ADDRESS: 4650 412 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 463 OSPI the outbound SPI value the registered host is using for 464 the peer with the Address and Port 465 ISPI the inbound SPI value the registered host is using for 466 the peer with the Address and Port 468 Figure 2: Format of the PEER_PERMISSION Parameter 470 4.3. HIP Connectivity Check Packets 472 The connectivity request messages are HIP UPDATE packets with a 473 CANDIDATE_PRIORITY parameter (Figure 3). Response UPDATE packets 474 contain a MAPPED_ADDRESS parameter (Figure 1). 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type | Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Priority | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Type [TBD by IANA; 4700] 485 Length 4 486 Priority the priority of a (potential) peer reflexive candidate 488 Figure 3: Format of the CANDIDATE_PRIORITY Parameter 490 5. Security Considerations 492 Same security considerations as with [RFC5770] apply also to this NAT 493 traversal mode. 495 If the data relay uses the same relayed address and port for multiple 496 registered hosts, it appears to all the peers, and their firewalls, 497 that all the registered hosts using the relay are at the same 498 address. Thus, a stateful firewall may allow packets pass from hosts 499 that would not normally be able to send packets to a peer behind the 500 firewall. Therefore, a HIP data relay SHOULD NOT re-use the port 501 numbers. If port numbers need to be re-used, the relay SHOULD have a 502 sufficiently large pool of port numbers and select ports from the 503 pool randomly to decrease the chances of a registered host obtaining 504 the same address that a certain other host is using. 506 6. Acknowledgements 508 This document re-uses many of the ideas proposed in various earlier 509 HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin 510 Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav 511 Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip 512 Matthews. 514 7. IANA Considerations 516 This section is to be interpreted according to [RFC5226]. 518 This document updates the IANA Registry for HIP Parameter Types 519 [I-D.ietf-hip-rfc5201-bis] by assigning new HIP Parameter Type values 520 for the new HIP Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined 521 in Section 4.1), and PEER_PERMISSION (defined in Section 4.2). 523 This document also updates the IANA Registry for HIP NAT traversal 524 modes [RFC5770] by assigning value for the NAT traversal mode ICE- 525 HIP-UDP (defined in Section 3.7). 527 This document defines additional registration types for the HIP 528 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow 529 registering with a HIP relay server for ESP relaying service: 530 RELAY_UDP_ESP (defined in Section 3.1); and performing server 531 reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in 532 Section 3.5). 534 The IANA Registry for HIP Registration Failure Types is updated with 535 new Failure Types "Insufficient resources" (defined in Section 3.1) 536 and "Invalid certificate" (defined in Section 3.2). 538 8. References 540 8.1. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [I-D.ietf-hip-rfc5201-bis] 546 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 547 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 548 hip-rfc5201-bis-11 (work in progress), February 2013. 550 [I-D.ietf-hip-rfc5202-bis] 551 Jokela, P., Moskowitz, R., and J. Melen, "Using the 552 Encapsulating Security Payload (ESP) Transport Format with 553 the Host Identity Protocol (HIP)", draft-ietf-hip- 554 rfc5202-bis-02 (work in progress), June 2013. 556 [I-D.ietf-hip-rfc5203-bis] 557 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 558 Registration Extension", draft-ietf-hip-rfc5203-bis-02 559 (work in progress), September 2012. 561 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 562 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 563 May 2008. 565 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 566 (ICE): A Protocol for Network Address Translator (NAT) 567 Traversal for Offer/Answer Protocols", RFC 5245, April 568 2010. 570 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 571 Keranen, "Basic Host Identity Protocol (HIP) Extensions 572 for Traversal of Network Address Translators", RFC 5770, 573 April 2010. 575 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 576 Certificates", RFC 6253, May 2011. 578 8.2. Informative References 580 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 581 "Host Identity Protocol", RFC 5201, April 2008. 583 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 584 Firewall Traversal Issues of Host Identity Protocol (HIP) 585 Communication", RFC 5207, April 2008. 587 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 588 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 589 October 2008. 591 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 592 Relays around NAT (TURN): Relay Extensions to Session 593 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 595 Authors' Addresses 596 Ari Keranen 597 Ericsson 598 Hirsalantie 11 599 02420 Jorvas 600 Finland 602 Email: Ari.Keranen@ericsson.com 604 Jan Melen 605 Ericsson 606 Hirsalantie 11 607 02420 Jorvas 608 Finland 610 Email: Jan.Melen@ericsson.com