idnits 2.17.1 draft-brunner-ikev2-mediation-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1597. 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 (April 16, 2008) is 5854 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == 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-07 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Brunner 3 Internet-Draft University of Applied Sciences, 4 Intended status: Experimental Rapperswil 5 Expires: October 18, 2008 April 16, 2008 7 IKEv2 Mediation Extension 8 draft-brunner-ikev2-mediation-00 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 18, 2008. 35 Abstract 37 This document describes the IKEv2 Mediation Extension (IKE-ME), a 38 connectivity extension to the Internet Key Exchange IKEv2. IKE-ME 39 allows two peers, each behind one or more Network Address Translators 40 (NATs) or firewalls to establish a direct and secure connection 41 without the need to configure any of the intermediate network 42 devices. To establish this direct connection, a process similar to 43 Interactive Connectivity Establishment (ICE) is used. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.1. Terminology and Notation . . . . . . . . . . . . . . . . . 4 50 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 51 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 52 2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 7 53 3. Mediation Connection . . . . . . . . . . . . . . . . . . . . . 11 54 3.1. Initial IKE Exchanges . . . . . . . . . . . . . . . . . . 11 55 3.2. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . 12 56 3.3. Obtaining Endpoints . . . . . . . . . . . . . . . . . . . 12 57 3.3.1. Host Endpoints . . . . . . . . . . . . . . . . . . . . 12 58 3.3.2. Server Reflexive and Relayed Endpoints . . . . . . . . 12 59 3.3.2.1. Considerations Concerning TURN . . . . . . . . . . 13 60 3.3.2.2. Obtaining Server Reflexive Endpoints from 61 Mediation Servers . . . . . . . . . . . . . . . . 13 62 3.3.3. Peer Reflexive Endpoints . . . . . . . . . . . . . . . 14 63 3.3.4. The Base of Local Endpoints . . . . . . . . . . . . . 14 64 3.3.5. Prioritizing Endpoints . . . . . . . . . . . . . . . . 14 65 3.3.5.1. Recommended Formula . . . . . . . . . . . . . . . 15 66 3.3.6. Guidelines for Choosing Type and IP Address 67 Preferences . . . . . . . . . . . . . . . . . . . . . 15 68 3.3.7. Eliminating Redundant Endpoints . . . . . . . . . . . 16 69 3.4. Initiating a Connection . . . . . . . . . . . . . . . . . 16 70 3.4.1. ME_CONNECT Exchange . . . . . . . . . . . . . . . . . 16 71 3.4.2. Receiving a ME_CONNECT Request . . . . . . . . . . . . 18 72 3.4.3. Receiving a ME_CONNECT Response . . . . . . . . . . . 19 73 3.4.4. Timeout for the Overall Transaction . . . . . . . . . 19 74 4. Building Endpoint Pairs . . . . . . . . . . . . . . . . . . . 19 75 5. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 20 76 5.1. Forming Connectivity Checks . . . . . . . . . . . . . . . 22 77 5.1.1. ME_CONNECTAUTH . . . . . . . . . . . . . . . . . . . . 22 78 5.2. Responding to Connectivity Checks . . . . . . . . . . . . 23 79 5.3. Processing Connectivity Checks . . . . . . . . . . . . . . 26 80 5.3.1. Failure Cases . . . . . . . . . . . . . . . . . . . . 26 81 5.3.2. Success Cases . . . . . . . . . . . . . . . . . . . . 26 82 5.3.3. Stopping the Checks and Selecting the Endpoints . . . 27 83 6. Mediated Connection . . . . . . . . . . . . . . . . . . . . . 27 84 6.1. Initiating the Mediated Connection . . . . . . . . . . . . 27 85 7. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 28 86 7.1. Identification Payload - Peer Identity . . . . . . . . . . 28 87 7.2. Notify Messages - Error Types . . . . . . . . . . . . . . 28 88 7.2.1. ME_CONNECT_FAILED Notify Payload . . . . . . . . . . . 28 89 7.3. Notify Messages - Status Types . . . . . . . . . . . . . . 28 90 7.3.1. ME_MEDIATION Notify Payload . . . . . . . . . . . . . 28 91 7.3.2. ME_ENDPOINT Notify Payloads . . . . . . . . . . . . . 28 92 7.3.3. ME_CALLBACK Notify Payload . . . . . . . . . . . . . . 29 93 7.3.4. ME_CONNECTID Notify Payload . . . . . . . . . . . . . 30 94 7.3.5. ME_CONNECTKEY Notify Payload . . . . . . . . . . . . . 30 95 7.3.6. ME_CONNECTAUTH Notify Payload . . . . . . . . . . . . 30 96 7.3.7. ME_RESPONSE Notify Payload . . . . . . . . . . . . . . 30 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 98 8.1. Trusting the Mediation Servers . . . . . . . . . . . . . . 31 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 100 10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 32 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 104 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 105 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 106 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 33 107 A.1. Is the second ME_CONNECTKEY required? . . . . . . . . . . 33 108 A.2. Different NAT, Same Subnet . . . . . . . . . . . . . . . . 34 109 A.3. Relaying Provided by the Mediation Server . . . . . . . . 34 110 A.4. Compatibility/Synergy with MOBIKE . . . . . . . . . . . . 34 111 Appendix B. Design Decisions . . . . . . . . . . . . . . . . . . 34 112 B.1. Two exchanges between mediation server and second peer . . 34 113 B.2. Why the ME_RESPONSE Notify payload is needed . . . . . . . 34 114 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . . 35 115 C.1. Changes from -.3 to -00 . . . . . . . . . . . . . . . . . 35 116 C.2. Changes from -.2 to -.3 . . . . . . . . . . . . . . . . . 35 117 C.3. Changes from -.1 to -.2 . . . . . . . . . . . . . . . . . 35 118 C.4. Changes from -.0 to -.1 . . . . . . . . . . . . . . . . . 35 120 1. Introduction 122 IKEv2 [RFC4306] inherently supports the traversal of Network Address 123 Translators (NATs) by doing automatic NAT discovery during the IPsec 124 connection setup. If a NAT situation is detected, IKE floats to UDP 125 source and destination ports 4500 and after a CHILD_SA has been 126 successfully established, ESP packets encapsulated in UDP datagrams 127 [RFC3948] will share the same floated ports. While both IPsec and 128 IKEv2 are peer-to-peer protocols by their nature, NATs and firewalls 129 often restrict these protocols to a unidirectional mode where only 130 the peer on the inside is able to actively set up a connection. If 131 both peers are hidden by NATs or firewalls, the IKEv2 protocol 132 usually fails to establish IPsec connectivity. 134 In the area of multimedia communications the Interactive Connectivity 135 Establishment protocol [I-D.ietf-mmusic-ice] has been developed to 136 solve the NAT and firewall problems mentioned above. Unfortunately 137 the proposed solution is rather closely bound to the Session 138 Initiation Protocol (SIP) and Session Description Protocol (SDP), and 139 generally tends to solve problems specific to voice and/or video 140 media streams. 142 The IKEv2 Mediation Extension (IKE-ME) adapts the connectivity 143 establishment methods known from ICE to the IPsec domain, allowing 144 secure IP connections to be established in environments with multiple 145 NATs or firewalls. 147 The IKEv2 Mediation Extension protocol uses a mediation server to 148 locate other peers and allows them to exchange their communication 149 endpoints. It implements an ICE-like mechanism with a minimum impact 150 on the standard IKEv2 protocol. IKEv2 exchanges are used for 151 communication between peers and the mediation server to simplify 152 implementation in existing IKEv2 products. 154 1.1. Terminology and Notation 156 The following terms are used throughout this document: 158 Peer 160 A peer is an IKEv2 host that supports the protocol defined in 161 this document and wants to establish a direct connection with 162 another peer. 164 Mediation Server 166 A server is an IKEv2 host that helps peers to establish a 167 direct connection between them. The server has to be reachable 168 by all peers involved in the mediation scheme. 170 Transport Address 172 A transport address is the combination of an IP address, a 173 transport protocol (limited to UDP in this specification), and 174 a port number. 176 Endpoint 178 An endpoint is a transport address that is obtained in order to 179 be used in a direct connection. In addition to a plain 180 transport address it has a type, a priority, and a base. The 181 term endpoint may also be used to simply indicate the end of a 182 connection. The actual meaning should be clear from the 183 context. 185 Host Endpoint 187 An endpoint directly obtained from a local interface. 189 Server Reflexive Endpoint 191 Server reflexive endpoints are endpoints allocated on a NAT and 192 are learned by a method such as Session Traversal Utilities for 193 NAT (STUN). 195 Relayed Endpoint 197 Relayed endpoints are like remote host endpoints. Traversal 198 Using Relays around NAT (TURN) is a possible source for relayed 199 endpoints. 201 Peer Reflexive Endpoint 203 Peer reflexive endpoints are learned during connectivity 204 checks. See Section 5 for how this is done. 206 Base 208 The base of an endpoint is the transport address from which 209 messages are actually sent. For instance, a peer cannot send 210 messages directly from a server reflexive endpoint which it got 211 allocated on a NAT, but only from the host endpoint from which 212 it obtained the server reflexive endpoint. See Section 3.3 for 213 details. 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 2. Protocol Overview 221 2.1. Basic Operation 223 In order to establish a direct connection between them, two peers 224 need to connect to a mediation server first. The mediation server is 225 required to forward the endpoints on which a peer is potentially 226 reachable by another peer. Figure 1 provides a general overview of 227 the most common situation. Peer 1 and Peer 2 want to establish a 228 secure direct connection between them. Since both are behind a NAT 229 they cannot reach one another directly - they most likely don't even 230 know where to try. This is where the mediation server comes into 231 play. It helps to locate other peers and to exchange endpoints over 232 which a peer may be reachable. 234 +-------------+ 235 | Mediation | 236 | Server | 237 +--+-------+--+ 238 | | 239 Mediation Connection | | Mediation Connection 240 +---------------+ +---------------+ 241 | | 242 + +-----------------------------------+ + 243 |/ Mediated Connection \| 244 +-----+-----+ +-----+-----+ 245 | NAT 1 | | NAT 2 | 246 +-----+-----+ +-----+-----+ 247 | | 248 +-----+-----+ Secure Connection +-----------+ 249 | Peer 1 |===========================| Peer 2 | 250 +-----------+ +-----------+ 252 Figure 1: Overview 254 Each peer registers itself with the mediation server in order to 255 announce its online presence. It does so by setting up an IKE_SA 256 including special mediation payloads. No CHILD_SA is established 257 between a peer and the mediation server because there is no need to 258 exchange any encrypted IP payloads. 260 Before a peer can connect to other peers it has to collect a number 261 of endpoints on which it is potentially reachable by other hosts. To 262 obtain endpoints an arbitrary method can be used. For instance, STUN 263 might be used to learn server reflexive endpoints and TURN could be 264 used to obtain a relayed endpoint. A client may also request a 265 server reflexive endpoint from the mediation server. By connecting 266 to the mediation server, the peer automatically gets transport 267 addresses allocated on the intermediate NATs. The transport address 268 on the NAT nearest to the mediation server is the source from which 269 the mediation server receives the messages from the peer. This 270 transport address can be requested from the mediation server and 271 provides a server reflexive endpoint. 273 If a peer requests a connection to another peer that is already 274 registered, the mediation server acts as a relay to allow the peers 275 to exchange their endpoints. 277 Each peer then performs connectivity checks on all available endpoint 278 pairs constructed by combining its own with the received endpoints. 280 After all path combinations have been probed and the best suited 281 endpoint pair has been elected, the initiating peer then goes on to 282 set up an IKE_SA using the standard IKEv2 protocol and including at 283 least one request for a CHILD_SA. 285 The protocol is designed to establish connectivity between peers in 286 any network topology. As local endpoints are included in the checks, 287 peers in the same (private) network can establish a connection 288 directly. Depending on the NAT implementation, the used hole 289 punching mechanism may not work. If both NAT are too restrictive, a 290 relayed endpoint may be used to establish an IKE_SA between the 291 peers. 293 2.2. Example Protocol Exchanges 295 This section illustrates some example protocol exchanges. The 296 notation is based on [RFC4306], Section 1.2. In addition, the 297 source/destination IP addresses and ports are shown for each packet: 298 here IP_P1, IP_P2, and IP_MS represent IP addresses used by the two 299 peers and the mediation server, respectively. Referring to Figure 1, 300 the two peers are each located behind a NAT. Thus, the modifications 301 on outgoing packets, as performed by the NATs, are also shown. At 302 this, IP_N1 and IP_N2 denote the public addresses of the NATs. 304 In a first step, Peer 1 connects to the mediation server starting 305 with an IKE_SA_INIT exchange. 307 Initiator Responder 308 ----------- ----------- 310 1) IP_P1:500 -> IP_MS:500 311 \--> IP_N1:1201 -> IP_MS:500 312 HDR, SAi1, KEi, Ni, 313 N(ME_MEDIATION), 314 N(NAT_DETECTION_SOURCE_IP), 315 N(NAT_DETECTION_DESTINATION_IP) --> 317 IP_MS:500 -> IP_N1:1201 318 <-- HDR, SAr1, KEr, Nr, 319 N(ME_MEDIATION), 320 N(NAT_DETECTION_SOURCE_IP), 321 N(NAT_DETECTION_DESTINATION_IP) 322 [,CERTREQ] 324 The IKEv2 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 325 Notify payloads are used to detect if there is any NAT between the 326 peer and the mediation server. The new ME_MEDIATION Notify payload 327 announces the request for a mediation connection. As mentioned 328 above, we assume that both peers are behind a NAT. Therefore Peer 1 329 floats to UDP port 4500 before continuing with a modified IKE_AUTH 330 exchange that does not contain a CHILD_SA proposal. 332 2) IP_P1:4500 -> IP_MS:4500 333 \--> IP_N1:1202 -> IP_MS:4500 334 HDR, SK { IDi, [CERT,] [CERTREQ,] 335 [IDr,] AUTH, N(ME_ENDPOINT) } --> 337 IP_MS:4500 -> IP_N1:1202 338 <-- HDR, SK { IDr, [CERT,] AUTH, 339 N(ME_ENDPOINT) } 341 The peer uses the new ME_ENDPOINT Notify payload to request a server 342 reflexive endpoint from the mediation server. After this exchange 343 Peer 1 is connected to the mediation server and thus available for 344 mediation with any other peer, as well as eligible to request a 345 mediated connection itself. Peer 2 connects to the mediation server 346 using the same procedure. 348 3) IP_P2:500 -> IP_MS:500 349 \--> IP_N2:1024 -> IP_MS:500 350 HDR, SAi1, KEi, Ni, 351 N(ME_MEDIATION), 352 N(NAT_DETECTION_SOURCE_IP), 353 N(NAT_DETECTION_DESTINATION_IP) --> 355 IP_MS:500 -> IP_N2:1024 356 <-- HDR, SAr1, KEr, Nr, 357 N(ME_MEDIATION), 358 N(NAT_DETECTION_SOURCE_IP), 359 N(NAT_DETECTION_DESTINATION_IP) 360 [,CERTREQ] 362 4) IP_P2:4500 -> IP_MS:4500 363 \--> IP_N2:1025 -> IP_MS:4500 364 HDR, SK { IDi, [CERT,] [CERTREQ,] 365 [IDr,] AUTH, N(ME_ENDPOINT) } --> 367 IP_MS:4500 -> IP_N2:1025 368 <-- HDR, SK { IDr, [CERT,] AUTH, 369 N(ME_ENDPOINT) } 371 A direct connection is initiated by Peer 1 with the transmission of a 372 ME_CONNECT request to the mediation server. Peers are identified by 373 the ID with which they authenticate against the mediation server. 374 So, this request includes the ID of the other peer, denoted IDp2, and 375 several endpoints on which Peer 1 is potentially reachable by the 376 other peer. Also included are a randomly generated ID and a randomly 377 generated key that are mainly used for the ensuing connectivity 378 checks. 380 5) IP_P1:4500 -> IP_MS:4500 381 \--> IP_N1:1202 -> IP_MS:4500 382 HDR, SK { IDp2, N(ME_CONNECTID), N(ME_CONNECTKEY), 383 N(ME_ENDPOINT), N(ME_ENDPOINT) } --> 385 IP_MS:4500 -> IP_N1:1202 386 <-- HDR, SK {} 388 The mediation server relays this ME_CONNECT request to the other 389 peer, but replaces the IDp payload with the ID of Peer 1. 391 IP_MS:4500 -> IP_N2:1025 392 HDR, SK { IDp1, N(ME_CONNECTID), N(ME_CONNECTKEY), 393 N(ME_ENDPOINT), N(ME_ENDPOINT) } --> 395 IP_P2:4500 -> IP_MS:4500 396 \--> IP_N2:1025 -> IP_MS:4500 397 <-- HDR, SK {} 399 Peer 2 answers with a ME_CONNECT exchange of its own, including the 400 initiating peer's ID, the connect ID, as well as its own randomly 401 generated key and obtained endpoints. To mark the exchange as a 402 response a ME_RESPONSE Notify payload is included. The mediation 403 server extracts this information and forwards it back to Peer 1, 404 again, exchanging the IDp accordingly. 406 6) IP_P2:4500 -> IP_MS:4500 407 \--> IP_N2:1025 -> IP_MS:4500 408 HDR, SK { IDp1, N(ME_RESPONSE), N(ME_CONNECTID), 409 N(ME_CONNECTKEY), N(ME_ENDPOINT), 410 N(ME_ENDPOINT) } --> 412 IP_MS:4500 -> IP_N2:1025 413 <-- HDR, SK {} 415 IP_MS:4500 -> IP_N1:1202 416 HDR, SK { IDp2, N(ME_RESPONSE), N(ME_CONNECTID), 417 N(ME_CONNECTKEY), N(ME_ENDPOINT), 418 N(ME_ENDPOINT) } --> 420 IP_P1:4500 -> IP_MS:4500 421 \--> IP_N1:1202 -> IP_MS:4500 422 <-- HDR, SK {} 424 Both peers now pair their own endpoints with those received from the 425 other end and proceed with connectivity checks. Connectivity checks 426 are done using unprotected INFORMATIONAL exchanges that include the 427 connect ID, an ME_ENDPOINT payload, and a ME_CONNECTAUTH Notify 428 payload, which contains a MAC to authenticate the sender of the 429 check. In this example we assume that both NATs perform endpoint 430 independent mapping and filtering. 432 7) IP_P1:4500 -> IP_P2:4500 433 HDR, N(ME_CONNECTID), N(ME_ENDPOINT), 434 N(ME_CONNECTAUTH) --> !! NOT REACHABLE 436 IP_P1:4500 -> IP_N2:1025 437 \--> IP_N1:1202 -> IP_N2:1025 438 HDR, N(ME_CONNECTID), N(ME_ENDPOINT), 439 N(ME_CONNECTAUTH) --> 441 IP_P2:4500 -> IP_N1:1202 442 \--> IP_N2:1025 -> IP_N1:1202 443 <-- HDR 445 Peer 2 does the same in the opposite direction. If at least one 446 connectivity check is successful, the initiating peer proceeds with a 447 normal IKE_SA_INIT request using the endpoints from the successful 448 check. 450 3. Mediation Connection 452 This section describes the protocol between peers and the mediation 453 server. 455 3.1. Initial IKE Exchanges 457 To establish a mediation connection with a mediation server an 458 implementation MUST include a ME_MEDIATION notification in the 459 IKE_SA_INIT exchange. The initiator MUST stop the initiation if the 460 responder does not include a ME_MEDIATION notification in its 461 response. 463 The format of the ME_MEDIATION notification is described in 464 Section 7. 466 If the transport address used to communicate with the mediation 467 server is also to be used as Host endpoint (see Section 3.3.2.2), the 468 peer MUST now float to port 4500 even if no NAT is detected between 469 the peer and the mediation server. Because connectivity checks are 470 sent with non-ESP marker in front of the IKE header it would be 471 confusing for implementations to receive such packets on port 500. 473 As no CHILD_SAs are established on mediation connections, the 474 IKE_AUTH exchange differs from [RFC4306]. The payloads SAi2 and TSi, 475 and SAr2 and TSr MUST be omitted from request and response, 476 respectively. If any of these payloads are found included in the 477 request, an implementation MUST respond with a NO_ADDITIONAL_SAS 478 notification without any other payloads, and then delete the IKE_SA. 480 All other payloads of the IKE_AUTH exchange remain as defined in 481 [RFC4306]. 483 A peer MUST NOT have more than one connection to a specific mediation 484 server at the same time. Thus, a mediation server MUST delete an 485 existing IKE_SA with a peer upon receipt of a valid IKE_AUTH request 486 of the same peer. 488 An implementation that supports MOBIKE [RFC4555] SHALL include the 489 MOBIKE_SUPPORTED notification in the IKE_AUTH exchange. 491 Optionally, a peer MAY obtain a server reflexive endpoint from the 492 mediation server, as described in Section 3.3.2.2. 494 3.2. CREATE_CHILD_SA Exchange 496 The absence of CHILD_SAs on mediation connections also affects the 497 allowed usages of the CREATE_CHILD_SA exchange. Exchanges of this 498 type SHALL only be used to rekey the IKE_SA. An implementation MUST 499 respond to CREATE_CHILD_SA requests that demand the creation of a 500 CHILD_SA with a NO_ADDITIONAL_SAS notification, without any other 501 payloads. 503 3.3. Obtaining Endpoints 505 A peer obtains endpoints before requesting a mediated connection or 506 before responding to such a request. There are four types of 507 endpoints defined in this document - host, peer reflexive, server 508 reflexive, and relayed endpoints. Since every peer decides on its 509 own which endpoints it wants to share with other peers, the methods 510 to obtain these endpoints can vary widely. 512 3.3.1. Host Endpoints 514 Host endpoints are obtained by binding ports to an IP address on a 515 peer's host. A peer could use the same endpoint it uses to 516 communicate with the mediation server, but it could also use a 517 different port. If a peer is multihomed, it SHOULD obtain endpoints 518 for every available IP address. 520 3.3.2. Server Reflexive and Relayed Endpoints 522 Server reflexive and relayed endpoints can be obtained from various 523 sources. One possibility is to use STUN 524 ([I-D.ietf-behave-rfc3489bis]) and its Binding Discovery and Relay 525 Usages ([I-D.ietf-behave-turn]). This specification does not 526 restrict implementations on the methods used to obtain such 527 endpoints. But a peer SHOULD obtain server reflexive and MAY obtain 528 relayed endpoints for each host endpoint, to increase the probability 529 of a successful connection. 531 Use of relays is expensive, and when using this protocol, relays will 532 only be utilized when both peers are behind NATs that perform address 533 and port dependent mapping. Consequently, some deployments might 534 consider this use case marginal and decide not to use relays. 536 3.3.2.1. Considerations Concerning TURN 538 An implementation that opts for STUN's Relay Usage 539 ([I-D.ietf-behave-turn]) as source for relayed endpoints has to 540 consider several implications that result from that decision. For 541 instance, as long as no active destination is set for such an 542 endpoint, any IKE or ESP traffic that will be transferred through 543 that endpoint will be encapsulated in Data Indication messages. 544 Aside from the overhead of this additional layer of encapsulation, 545 this also means that the implementation has to be able to process 546 such traffic. This may be significantly easier for IKE traffic, 547 since IKE traffic is often processed in user space, whereas ESP 548 traffic is usually handled in kernel space, where the introduction of 549 an additional layer of encapsulation might be more difficult to 550 implement. Therefore, it is RECOMMENDED that an owner of such a 551 relayed endpoint sets an active destination as soon as it becomes 552 apparent that the endpoint is being used to establish the mediated 553 connection. Thus, it depends on the selected pair and the associated 554 endpoints. If the initiator owns the relayed endpoint of the 555 selected endpoint pair, it sets the active destination to the remote 556 endpoint of that pair, just before sending the IKE_SA_INIT request to 557 initiate the mediated connection. Because the responder does not 558 know which pair finally gets selected by the initiator, it waits 559 until it gets the IKE_SA_INIT request and just before sending the 560 IKE_SA_INIT response sets the active destination to the endpoint 561 provided in the REMOTE-ADDRESS attribute of the Data Indication 562 message. In the extremely rare case of the selected pair consisting 563 of two relayed endpoints, the procedure is the same, with both peers 564 taking appropriate measures. This could happen, for instance, if 565 both peers are behind a NAT and neither did provide server reflexive 566 endpoints. 568 3.3.2.2. Obtaining Server Reflexive Endpoints from Mediation Servers 570 A peer MAY obtain a server reflexive endpoint from the mediation 571 server. To do so, it includes a ME_ENDPOINT Notify payload either in 572 the IKE_AUTH request or at a later stage in a separate INFORMATIONAL 573 exchange. 575 The priority, family, and port fields of this payload are set to 576 zero, the address field is zero length, and the type field is set to 577 SERVER_REFLEXIVE. Upon receiving such a payload, the mediation 578 server includes in its answer a ME_ENDPOINT notification of the same 579 type filling in the family, address and port of the endpoint it 580 received the request from. 582 The mediation server MUST ignore the ME_ENDPOINT Notify payload if 583 the type is not SERVER_REFLEXIVE [anchor11]. 585 If MOBIKE [RFC4555] is in use on the mediation connection, detection 586 of changes in NAT mappings SHOULD be activated (as specified in 587 [RFC4555], Section 3.8). A peer that previously obtained a server 588 reflexive endpoint from the mediation server SHOULD refresh that 589 endpoint, whenever MOBIKE indicates that the NAT mapping has changed. 591 3.3.3. Peer Reflexive Endpoints 593 Peer reflexive endpoints are different from the previous endpoint 594 types. Endpoints of this type are never obtained before a connection 595 attempt, but dynamically learned during the connectivity checks. The 596 process of how and when these endpoints MAY be learned is explained 597 in Section 5. 599 3.3.4. The Base of Local Endpoints 601 All local endpoints have a Base. This is the transport address used 602 to send the actual messages for an endpoint. Since it is not 603 possible to send messages directly from a server reflexive endpoint, 604 the base of such an endpoint is the host endpoint from which the 605 server reflexive endpoint was obtained. If the peer is not behind a 606 NAT, the base of a server reflexive endpoint will equal that 607 endpoint, which is then redundant and will be eliminated. The base 608 of host endpoints is the endpoint itself. The same is true for 609 relayed endpoints, since these are like remote host endpoints. Peer 610 reflexive endpoints also have a base; it is the base of the local 611 endpoint of the pair from whose connectivity check the peer reflexive 612 endpoint was learned. 614 3.3.5. Prioritizing Endpoints 616 Each obtained endpoint is assigned a unique priority that MUST be a 617 positive integer between 0 and 2**32 - 1. A peer SHOULD compute this 618 priority using the formula in Section 3.3.5.1 and choose its 619 parameters using the guidelines in Section 3.3.6. Using a different 620 formula will most likely break the coordination in the connectivity 621 checks, causing the protocol to take longer to converge. 623 3.3.5.1. Recommended Formula 625 The priority is based on a preference for each type of endpoint 626 (host, peer reflexive, server reflexive and relayed) and a preference 627 for each of a peer's local IP addresses, in case it is multihomed. 628 These two preferences are combined to compute the priority for an 629 endpoint using the following formula (which is derived from the 630 formula defined in [I-D.ietf-mmusic-ice], Section 4.1.2): 632 priority = (2**16)*(type preference) + 633 IP address preference 635 The type preference MUST be an integer from 0 to 255 inclusive and 636 represents the preference for the type of the endpoint. 255 is the 637 highest preference, and 0 is the lowest. Setting the value to 0 638 means that endpoints of this type will only be used as a last resort. 639 The type preference MUST be identical for all endpoints of the same 640 type and MUST be different for endpoints of different types. The 641 type preference for peer reflexive endpoints MUST be higher than that 642 of server reflexive endpoints. This is because it is easier for an 643 attacker to foist a bad server reflexive endpoint on a peer, than it 644 is to do the same with peer reflexive endpoints. 646 The IP address preference MUST be an integer from 0 to 65535 647 inclusive. It represents a preference for the particular IP address 648 from which the endpoint was obtained in case a peer is multihomed. 649 65535 represents the highest preference and 0 the lowest. When there 650 is only a single IP address, this value SHOULD be set to 65535. If a 651 peer is dual-stacked the IP address preference SHOULD be equal to the 652 precedence value for IP addresses as described in [RFC3484]. 654 3.3.6. Guidelines for Choosing Type and IP Address Preferences 656 The RECOMMENDED values for the type preference are 255 for host 657 endpoints, 128 for peer reflexive endpoints, 64 for server reflexive 658 endpoints, and 0 for relayed endpoints. 660 One criteria for the selection of the IP address preference values is 661 IP address family. This protocol works with both IPv4 and IPv6. It 662 also allows dual-stack hosts to prefer connections over IPv6, but to 663 fall back to IPv4. Other criteria MAY be established as a matter of 664 local optimization. 666 3.3.7. Eliminating Redundant Endpoints 668 After obtaining the endpoints, the peer eliminates redundant ones. 669 An endpoint is redundant if its transport address equals that of 670 another endpoint and its base equals the base of that other endpoint. 671 Two endpoints that share the same transport address but have 672 different bases are not considered redundant. The peer SHOULD 673 eliminate the redundant candidate with the lower priority. 675 3.4. Initiating a Connection 677 To initiate a direct connection with another peer and to exchange 678 endpoints, a new exchange type (ME_CONNECT) is defined. The 679 communication between initiating peer and responding peer passes 680 through the mediation server and therefore consists of multiple 681 exchanges. Request and response between the peers are each composed 682 of two distinct exchanges between the mediation server and the peers. 683 This results in the following message flow: 685 Peer 1 Mediation Server Peer 2 686 -------- ------------------ -------- 687 / ME_CONNECT request -> 688 Re- <- ME_CONNECT response 689 quest ME_CONNECT request -> 690 \ <- ME_CONNECT response 692 / <- ME_CONNECT request 693 Re- ME_CONNECT response -> 694 sponse <- ME_CONNECT request 695 \ ME_CONNECT response -> 697 Figure 2: ME_CONNECT Exchanges 699 3.4.1. ME_CONNECT Exchange 701 The first payload included in a ME_CONNECT request is an IDp payload 702 containing the ID of the other peer. All other payloads are 703 notifications. 705 The first two notifications are ME_CONNECTID and ME_CONNECTKEY. 706 ME_CONNECTID contains a randomly chosen value that is used to 707 identify the current connection setup. This identifier is provided 708 by the initiator and is sent back by the other peer in the reply in 709 order to be able to distinguish concurrent ME_CONNECT exchanges 710 initiated by both sides. Each peer also provides a randomly chosen 711 key contained in a ME_CONNECTKEY Notify payload that is used to 712 authenticate the connectivity checks. 714 If the requested peer is currently not online, that is, not connected 715 to the mediation server, the mediation server MUST include a 716 ME_CONNECT_FAILED error notification in its response. To prevent an 717 initiator from constantly having to poll the other peer's online 718 status, it MAY include a ME_CALLBACK notification in its request. 719 This instructs the mediation server to notify the initiator as soon 720 as the requested peer gets online. 722 To transmit the previously obtained endpoints, notification payloads 723 of type ME_ENDPOINT are used. A ME_CONNECT request MUST include at 724 least one such payload. Mediation servers MUST reply with a 725 ME_CONNECT_FAILED if a request contains no endpoints. 727 Figure 3 shows a schematic overview of the ME_CONNECT exchange that 728 is used to initiate a connection. Figure 4 shows the exchange used 729 to indicate a failure. 731 Initiator Responder 732 ----------- ----------- 734 HDR, SK { IDp, [N(ME_RESPONSE)], N(ME_CONNECTID), 735 N(ME_CONNECTKEY), [N(ME_CALLBACK)], 736 N(ME_ENDPOINT)+ } --> 738 <-- HDR, SK { [N(ME_CONNECT_FAILED)] } 740 Figure 3: ME_CONNECT Exchange: Initiation 742 Initiator Responder 743 ----------- ----------- 745 HDR, SK { IDp, N(ME_CONNECT_FAILED) } --> 747 <-- HDR, SK {} 749 Figure 4: ME_CONNECT Exchange: Failure 751 On every ME_CONNECT request the mediation server checks whether the 752 requested peer is connected to it. If this is the case, the 753 mediation server forwards the data included in the request to the 754 requested peer by initiating another ME_CONNECT exchange, thereby 755 replacing the IDp payload with the ID of the initiator. If the 756 requested peer is not available the mediation server responds 757 immediately with a ME_CONNECT_FAILED notification. If the initiator 758 included a ME_CALLBACK notification in its request, the mediation 759 server registers the requested ID. Once the requested peer connects, 760 the mediation server notifies all waiting peers by initiating a 761 ME_CONNECT exchange containing the peer ID of the requested peer and 762 a ME_CALLBACK Notify payload, as shown in Figure 5. Afterwards, the 763 mediation server removes the ID from the list of requested peers. 765 Initiator Responder 766 ----------- ----------- 768 HDR, SK { IDp, N(ME_CALLBACK) } --> 770 <-- HDR, SK {} 772 Figure 5: ME_CONNECT Exchange: Callback 774 3.4.2. Receiving a ME_CONNECT Request 776 Upon receipt of a ME_CONNECT request from the mediation server, a 777 peer has to obtain endpoints itself. Actually the peer could have 778 done that earlier, even before connecting to the mediation server, 779 keeping the endpoints alive while waiting for incoming requests. The 780 peer then assembles a ME_CONNECT request which contains its own 781 endpoints, the ID of the other peer, and a randomly generated value 782 for the ME_CONNECTKEY payload. It also includes the ME_CONNECTID 783 payload from the request and a ME_RESPONSE Notify payload to mark 784 this exchange as a response. This message is then sent to the 785 mediation server which should confirm it with an empty response. If 786 the response contains a ME_CONNECT_FAILED notification, the other 787 peer is not connected to the mediation server anymore. In this case 788 the peer stops handling the request, otherwise, it proceeds with 789 connectivity checks, as described beginning with Section 4. 791 In case a peer is unable to handle the request for a mediated 792 connection - this could be due to missing configuration, local policy 793 or other failures - it immediately responds with a ME_CONNECT_FAILED 794 in the response to the ME_CONNECT request it received from the 795 mediation server. If it later faces a condition that prevents it 796 from responding to the request, it SHOULD initiate a ME_CONNECT 797 exchange containing only an IDp and a ME_CONNECT_FAILED Notify 798 payload. This notification is then forwarded to the initiating peer 799 to inform it of this situation. 801 3.4.3. Receiving a ME_CONNECT Response 803 The initiator eventually gets a ME_CONNECT request from the mediation 804 server containing the response from the other peer. It correlates 805 the response with the previously sent request using the ID contained 806 in the ME_CONNECTID payload. It extracts the endpoints and key 807 provided by the responder and proceeds with connectivity checks, as 808 described beginning with Section 4. 810 3.4.4. Timeout for the Overall Transaction 812 Since the whole transaction is split in four separate exchanges (see 813 Figure 2) a timeout for the overall transaction is required. This 814 timeout allows the initiator to act appropriately in case any of the 815 three exchanges, in which it is not actively involved, fails. The 816 nature of appropriate means is not defined by this specification, a 817 peer might just restart the process, cancel it and log a message, or 818 might take more sophisticated measures (like contacting an 819 alternative mediation server). The timer controlling this timeout 820 SHOULD be started right after the initial ME_CONNECT exchange 821 finished successfully. 823 Since [RFC4306] does not exactly specify how retransmissions for 824 IKEv2 messages have to be effected and does not define the time frame 825 within which dead peers have to be detected, it becomes impossible to 826 specify an exact timeout value. Therefore this document only 827 specifies that an overall timeout value MUST be configurable to allow 828 it to be adapted to specific conditions. As a recommendation the 829 timeout value SHOULD approximately amount to at least three times the 830 maximum time it takes the initiating peer to conclude that the 831 retransmission of an IKEv2 message has finally failed. 833 4. Building Endpoint Pairs 835 After receiving endpoints with a ME_CONNECT exchange, a peer builds a 836 list of endpoint pairs. This is done by pairing each local endpoint 837 with each remote endpoint (endpoints get only paired if they share 838 the same IP address family). Then for each pair a priority is 839 computed. The resulting list is then sorted in decreasing order of 840 priorities. The formula used to compute this priority is as follows 841 (it is basically the same formula as defined in 842 [I-D.ietf-mmusic-ice], Section 5.7.2): 844 priority = (2**32) * MIN(pI, pR) + 845 2 * MAX(pI, pR) + (pI > pR ? 1 : 0) 847 where pI and pR denote the priorities of the initiator and the 848 responder, respectively. MIN and MAX are functions that result in 849 either the minimum or the maximum value of their parameters, 850 respectively. The last term of the formula evaluates to 1 if pI is 851 greater than pR or to 0 otherwise. 853 A peer cannot send messages directly from a reflexive endpoint, but 854 only from its base. Since a peer generated pairs with both host 855 endpoints and server reflexive endpoints as local endpoints, it's 856 likely that there are duplicate entries in the list of pairs. 857 Therefore, the peer MUST prune the list. This is done by removing a 858 pair if the base of its local endpoint and the remote endpoint are 859 identical to those of a pair higher up on the list. 861 After sorting and pruning the list, the pairs are numbered serially. 862 This number serves as a message ID in connectivity checks. The 863 result is a sequentially numbered, ordered list of endpoint pairs, 864 called the checklist. 866 Each pair in the checklist has a specific state assigned to it that 867 changes during the connectivity checks. Initially all pairs are in 868 state Waiting. The possible states are as follows: 870 Waiting: No check has been performed yet for this pair. As soon 871 as it becomes the highest priority Waiting pair on the checklist, 872 a check can be performed. 874 In-Progress: A check has been sent for this pair, but the 875 transaction is still in progress. 877 Succeeded: A check for this pair produced a successful result. 879 Failed: A check for this pair was done and it failed. 881 An implementation SHOULD limit the number of endpoints it accepts in 882 a ME_CONNECT exchange as well as the number of pairs in a single 883 checklist. This specification does not define what the limits are 884 but the limits MUST be configurable, so that users can adjust the 885 limits if a specific situation demands it. If more endpoints are 886 received than the configured upper limit, the implementation SHOULD 887 discard them according to their priority. The same procedure is 888 RECOMMENDED for supernumerary pairs. 890 5. Connectivity Checks 892 Connectivity checks are done using unprotected INFORMATIONAL 893 exchanges. The peers process the checklist sequentially and send a 894 request from the local endpoint to the remote endpoint of each pair. 896 In addition to the checklist each peer maintains a FIFO queue, called 897 the triggered check queue, which contains pairs for which checks are 898 to be sent at the next available opportunity. A periodically firing 899 timer T controls the generation of the checks. Whenever timer T 900 fires, a peer first checks whether there are any elements in the 901 triggered check queue. If so, it removes the first pair from it and 902 initiates a connectivity check for that pair. Otherwise the peer 903 sends a check for the topmost pair in the checklist which is in state 904 Waiting. If no such pair exists the peer does nothing in this time 905 slot. This process is illustrated in Figure 6. Once a check has 906 been sent the state of the pair is set to In-Progress. 908 +---------------------+ /---------------\ 909 /----->| idle |<-----| send check | 910 | +---------------------+ \---------------/ 911 | | timer fires ^ 912 | v | 913 | +----------------------+ | 914 | |triggered check queue:| ok | 915 | | get first item |--------------+ 916 | +----------------------+ | 917 | | none | 918 | v | 919 | +---------------------+ | 920 | none |checklist: get first | ok | 921 \------|pair in state Waiting|--------------/ 922 +---------------------+ 924 Figure 6: Sending Connectivity Checks 926 There is no RECOMMENDED setting for timer T specified in this 927 document. But timer T MUST be configurable so that a user may change 928 the setting to adjust to specific environments. There is a second 929 timer called retransmission timer R which is started for each 930 connectivity check request after it has been initially sent. 931 Whenever timer R fires the request is retransmitted. This not done 932 indefinitely, though. After a set number of retransmissions the 933 connectivity check times out and the state of the pair is set to 934 Failed. As with timer T, this specification does not restrict 935 implementors on how to design these retransmissions. However, it is 936 RECOMMENDED that a user may be able to configure how often and how 937 long retransmissions are sent in order to improve the connectivity in 938 specific situations. 940 5.1. Forming Connectivity Checks 942 Specially crafted unprotected INFORMATIONAL exchanges act as 943 connectivity checks. The INFORMATIONAL request is formed as follows. 944 The SPI fields in the IKE header are set to zero. The message ID is 945 set to the ID of the corresponding entry in the checklist. Three 946 payloads follow the header. The first one is a ME_CONNECTID 947 notification containing the value provided by the initiator that 948 allows the recipient to locate the correct checklist. The next 949 payload is a ME_ENDPOINT Notify payload that has all fields but the 950 priority and the type set to zero. The priority field is set equal 951 to the priority that would be assigned based on the formula in 952 Section 3.3.5.1 to a peer reflexive endpoint. Hence, the type field 953 is set to PEER_REFLEXIVE. To authenticate the message a 954 ME_CONNECTAUTH notification is built and added, containing an SHA-1 955 hash of several parts of the message and the value of the appropriate 956 ME_CONNECTKEY (see Section 5.1.1 for details). Request and response 957 of a connectivity check are always authenticated with the same key, 958 that of the responder. Thus a connectivity check from peer L to peer 959 R (and its response) is authenticated with the key provided by R. 960 Likewise, a connectivity check from R to L (and its response) is 961 authenticated with the key provided by L. 963 To simplify things, the IKE messages used to do connectivity checks 964 are always sent with a non-ESP marker in front of the IKE header, as 965 defined in [RFC3948], even if the port numbers used are not 4500. 967 Figure 7 provides a schematic diagram of a connectivity check. 969 Initiator Responder 970 ----------- ----------- 972 HDR, N(ME_CONNECTID), N(ME_ENDPOINT), 973 N(ME_CONNECTAUTH) --> 975 <-- HDR, N(ME_CONNECTID), N(ME_ENDPOINT) 976 N(ME_CONNECTAUTH) 978 Figure 7: Connectivity Checks 980 5.1.1. ME_CONNECTAUTH 982 The formula used to compute the value of the ME_CONNECTAUTH Notify 983 payload is: 985 auth = Hash(MID | ME_CONNECTID | ME_ENDPOINT | ME_CONNECTKEY) 987 where MID denotes the message ID in the IKE Header in network byte 988 order and | indicates concatenation. Of each included Notify payload 989 only the notification data is considered. The hash function used is 990 SHA-1. 992 5.2. Responding to Connectivity Checks 994 After receiving a connectivity check request, a peer uses the value 995 of the ME_CONNECTID payload to locate the correct checklist and the 996 appropriate key. It verifies that the message is genuine, by 997 computing the hash as the sender did and comparing the result with 998 the content of the ME_CONNECTAUTH Notify payload. If either the 999 checklist is not found or the verification fails, the peer MUST 1000 ignore the connectivity check request. Otherwise, it proceeds as 1001 follows. Refer to Figure 8 for an illustration of this process. 1003 1. It checks whether the source address and port of the message are 1004 already included in the list of remote endpoints. If this is not 1005 the case, this represents a new peer reflexive endpoint. The 1006 priority of this endpoint is set to the priority noted in the 1007 ME_ENDPOINT payload of the request and it is then added to the 1008 list of remote endpoints. 1010 2. A new pair is constructed setting the local endpoint to the one 1011 on which the request was received, and the remote endpoint to the 1012 one where the request came from (this may be the peer reflexive 1013 endpoint just learned). The priority of this pair is computed as 1014 usual. 1016 3. If this pair is already in the checklist, further processing 1017 depends on the state of that pair. 1019 * If the pair is in waiting state, a check for it is enqueued 1020 into the triggered check queue. 1022 * If the state is In-Progress, retransmissions for the pending 1023 request will be cancelled, but the peer will wait the duration 1024 of the retransmission timeout for a response. If there is no 1025 answer the peer MUST schedule a new connectivity check for 1026 that pair, by enqueuing a check in the triggered check queue. 1027 The state of the pair is then changed to Waiting. 1029 * If the state of the pair is Failed, it is changed to Waiting 1030 and the peer MUST enqueue a new connectivity check for that 1031 pair in the triggered check queue. 1033 * If the state is already Succeeded, nothing is done. 1035 If the pair had not yet been included in the checklist, it is now 1036 inserted based on its priority. The ID is set to the number of 1037 pairs in the checklist plus one. The state is set to Waiting and 1038 a connectivity check is enqueued in the triggered check queue. 1040 4. A response is then sent back. It includes the same ME_CONNECTID 1041 as the request, the ME_ENDPOINT is filled with the source 1042 endpoint from which the request was received - for relayed 1043 endpoints that are obtained using STUN, the source address is 1044 included in the REMOTE-ADDRESS attribute, if it was encapsulated 1045 in a Data Indication message, or it is the current active 1046 destination for the STUN relay session, otherwise - and the 1047 ME_CONNECTAUTH is built as in the request, using the appropriate 1048 key. 1050 +-------------------+ 1051 | request received | 1052 | and verified | 1053 +-------------------+ 1054 | 1055 v 1056 +---------------+ +-------------------+ 1057 | add to | no | source in list of | 1058 |remote endoints|<----| remote endpoints? | 1059 +---------------+ +-------------------+ 1060 | | yes 1061 | v 1062 | +------------------+ 1063 \------------->| create pair and | 1064 | compute priority | 1065 +------------------+ 1066 | 1067 v 1068 +---------------+ +------------------+ 1069 | add pair to | no | pair is already | 1070 | checklist |<-----| in checklist? | 1071 +---------------+ +------------------+ 1072 | | yes 1073 | v 1074 | Waiting /------------------\ Succeeded 1075 +--------------| pair state |--------------\ 1076 | \------------------/ | 1077 | / \ | 1078 | Failed | | In-Progress | 1079 | v v | 1080 | +------------+ +------------+ | 1081 | |change state| failed | wait for | ok | 1082 +-----| to Waiting |<---------| response |-----+ 1083 | +------------+ +------------+ | 1084 v | 1085 +---------------+ | 1086 |queue triggered| | 1087 | check | | 1088 +---------------+ | 1089 | +------------------+ | 1090 \------------->| send response |<-------------/ 1091 +------------------+ 1093 Figure 8: Responding to Connectivity Checks 1095 5.3. Processing Connectivity Checks 1097 This section describes how responses to connectivity checks are 1098 processed. On receipt of a connectivity check response a peer 1099 correlates it to the corresponding pair using, first, the 1100 ME_CONNECTID to find the correct checklist and then the message ID to 1101 identify the pair. It MUST verify the authenticity of the check 1102 using the key provided by the other peer. 1104 5.3.1. Failure Cases 1106 If the peer either cannot find the checklist or cannot find the 1107 corresponding pair or if the verification of the check fails, it MUST 1108 ignore the check response. 1110 Implementations MAY support receipt of ICMP errors for connectivity 1111 checks. If a connectivity check generates an ICMP error, a peer sets 1112 the state of the corresponding pair to Failed. 1114 If a connectivity check times out, the peer also sets the state of 1115 the corresponding pair to Failed. 1117 The peer MUST check that the source address and port of the response 1118 equals the remote endpoint of the pair, and the destination address 1119 and port of the response equals the base of the local endpoint of the 1120 pair. If either of these comparisons fails the state of the pair is 1121 set to Failed. 1123 5.3.2. Success Cases 1125 A connectivity check is considered a success, if the following are 1126 true: 1128 o The source address and port of the response equal the remote 1129 endpoint of the pair. 1131 o The destination address and port of the response match the base of 1132 the local endpoint of the pair. 1134 After verifying that the check is successful, the peer checks the 1135 mapped endpoint that is returned in the ME_ENDPOINT Notify payload. 1136 If the endpoint does not match any of the local endpoints that the 1137 peer knows about, the mapped endpoint represents a new peer reflexive 1138 endpoint. The base of this endpoint is set equal to the base of the 1139 local endpoint of the pair the check was sent for. The priority is 1140 set equal to the value noted in the payload. This endpoint is then 1141 added to the list of local endpoints and a new pair is built as 1142 follows. 1144 A new pair is constructed whose local endpoint equals the endpoint 1145 from the ME_ENDPOINT Notify payload as described in the preceding 1146 paragraph, and whose remote endpoint equals the destination address 1147 to which the request was sent. This pair is inserted into a second 1148 list called valid list, since it has been validated by a connectivity 1149 check. The valid pair may equal the pair that generated the check, 1150 may equal a different pair in the checklist, or may be a pair not 1151 currently in the checklist. 1153 If the pair is not on the checklist, the priority is computed as 1154 usual. If the local endpoint is peer reflexive, its priority is 1155 equal to the priority field of the ME_ENDPOINT payload. The priority 1156 of the remote endpoint is looked up in the list of remote endpoints. 1158 The state of the pair that generated the check is then set to 1159 Succeeded. 1161 5.3.3. Stopping the Checks and Selecting the Endpoints 1163 Once one or more connectivity checks have completed successfully, 1164 valid pairs are generated and added to the valid list. The 1165 initiating peer lets the checks continue until some stopping criteria 1166 is met and then selects one pair from the valid list based on an 1167 evaluation criteria. The criteria for stopping the checks and for 1168 evaluating the valid pairs is entirely a matter of local 1169 optimization. 1171 The responding peer does not stop the checks for a checklist until it 1172 receives an IKE_SA_INIT request that includes a ME_CONNECTID Notify 1173 payload containing the respective connect ID. 1175 6. Mediated Connection 1177 6.1. Initiating the Mediated Connection 1179 After the initiating peer has selected a valid pair, it uses these 1180 endpoints to initiate an IKE_SA_INIT exchange with the other peer. 1181 Like the connectivity checks, the IKE traffic on mediated connections 1182 is sent with the non-ESP Marker prepended to the IKE header, as 1183 defined in [RFC3948]. Whether UDP encapsulation of ESP traffic is 1184 enabled on the mediated connection, is decided as usual, using NAT 1185 detection as defined in [RFC4306], Section 2.23. 1187 In addition to all the default payloads in the IKE_SA_INIT exchange 1188 the initiating peer also includes a ME_CONNECTID Notify payload 1189 containing the appropriate connect ID. 1191 7. Payload Formats 1193 7.1. Identification Payload - Peer Identity 1195 This payload, denoted IDp in this document, is used to exchange the 1196 identities of mediated peers. It is identical to the Identification 1197 Payloads defined in [RFC4306], Section 3.5. 1199 The payload type for this Identification Payload (IDp) is 1200 TBD_BY_IANA. 1202 7.2. Notify Messages - Error Types 1204 7.2.1. ME_CONNECT_FAILED Notify Payload 1206 This notification is used to signal that the attempt to mediate a 1207 connection with a peer has failed. It is used in the ME_CONNECT 1208 exchange request or response. 1210 The Notify Message Type for ME_CONNECT_FAILED is TBD-BY-IANA. The 1211 Protocol ID and SPI Size fields are set to zero. There is no data 1212 associated with this Notify type. 1214 7.3. Notify Messages - Status Types 1216 7.3.1. ME_MEDIATION Notify Payload 1218 This notification is included in the IKE_SA_INIT exchange of a 1219 mediation connection to indicate that both parties support this 1220 specification and want to establish a mediation connection. 1222 The Notify Message Type for ME_MEDIATION is TBD-BY-IANA. The 1223 Protocol ID and SPI Size fields are set to zero. The notification 1224 data field MUST be left empty (zero-length) when sending, and its 1225 contents (if any) MUST be ignored when this notification is received. 1226 This allows the field to be used by future versions of this protocol. 1228 7.3.2. ME_ENDPOINT Notify Payloads 1230 This notification is used to exchange endpoints. 1232 The Notify Message Type for ME_ENDPOINT is TBD-BY-IANA. The Protocol 1233 ID and SPI Size fields are set to zero. The data associated with 1234 these Notify types starts with a four-octet long number denoting the 1235 endpoint's priority, followed by the eight bit long address family, 1236 and an eight bit long number indicating the type of the endpoint. 1237 The data further consists of a two-octet port number, which is 1238 finally followed by either a four-octet IPv4 address or a 16-octet 1239 IPv6 address. 1241 The following figure illustrates the format of the notification data 1242 of the ME_ENDPOINT payload: 1244 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 ! priority ! 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 ! family ! type ! port ! 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 ! IP address (variable) 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 The address family can take on the following values: 1256 Name Value 1257 ------------------------------ ----- 1258 RESERVED 0 1259 IPv4 1 1260 IPv6 2 1262 The following endpoint types are defined: 1264 Name Value 1265 ------------------------------ ----- 1266 RESERVED 0 1267 HOST 1 1268 PEER_REFLEXIVE 2 1269 SERVER_REFLEXIVE 3 1270 RELAYED 4 1272 This payload is also used to request endpoints from a mediation 1273 server and in connectivity checks. Refer to Section 3.3 and 1274 Section 5 for details. 1276 7.3.3. ME_CALLBACK Notify Payload 1278 This notification allows a peer to instruct the mediation server to 1279 send out a notification once a specific peer connects to it, if it 1280 was not available when the peer initially sent the ME_CONNECT. The 1281 mediation server also includes a Notify payload of this type in the 1282 requested callback. 1284 The Notify Message Type for ME_CONNECTID is TBD-BY-IANA. The 1285 Protocol ID and SPI Size fields are set to zero. There is no data 1286 associated with this Notify type. 1288 7.3.4. ME_CONNECTID Notify Payload 1290 This notification is used to exchange an identification number that 1291 uniquely identifies a direct connection attempt. The initiator 1292 provides this identifier in the ME_CONNECT exchange. It is then 1293 later used in the connectivity checks as well as in the IKE_SA_INIT 1294 request of the mediated connection. The randomly generated 1295 identifier MUST have a length of 4 to 16 octets. 1297 The Notify Message Type for ME_CONNECTID is TBD-BY-IANA. The 1298 Protocol ID and SPI Size fields are set to zero. The data associated 1299 with this Notify type consists of random data of variable length. 1301 7.3.5. ME_CONNECTKEY Notify Payload 1303 This notification contains a symmetric key used in the MAC that 1304 authenticates the connectivity checks. The randomly generated key 1305 MUST be at least 16 octets long, but MAY have a length of up to 32 1306 octets. 1308 The Notify Message Type for ME_CONNECTKEY is TBD-BY-IANA. The 1309 Protocol ID and SPI Size fields are set to zero. The data associated 1310 with this Notify type consists of random data of variable length. 1312 7.3.6. ME_CONNECTAUTH Notify Payload 1314 This notification contains the message authentication code (MAC) in a 1315 connectivity check. 1317 The Notify Message Type for ME_CONNECTAUTH is TBD-BY-IANA. The 1318 Protocol ID and SPI Size fields are set to zero. The data associated 1319 with this Notify type consists of a 20-octet SHA-1 digest. 1321 7.3.7. ME_RESPONSE Notify Payload 1323 This notification is used in ME_CONNECT exchanges to mark an exchange 1324 as a response. Since ME_CONNECT exchanges usually contain the same 1325 payloads, this Notify payload is required to distinguish between 1326 exchanges that serve as requests and exchanges that serve as 1327 responses. This is particularly important in the case of two peers 1328 trying to initiate a connection to each other at the same time. 1330 The Notify Message Type for ME_RESPONSE is TBD-BY-IANA. The Protocol 1331 ID and SPI Size fields are set to zero. There is no data associated 1332 with this Notify type. 1334 8. Security Considerations 1336 8.1. Trusting the Mediation Servers 1338 The peers must at least partially trust the mediation servers they 1339 use. Because the information that is passed to other peers is not 1340 encrypted in an end-to-end fashion the mediation server can observe 1341 all the exchanged endpoints. This could lead to the unwanted 1342 disclosure of private IP addresses and address ranges. Of course 1343 each peer can decide which endpoints it wants to share with other 1344 peers and hence with the mediation server. 1346 9. IANA Considerations 1348 This document does not create any new namespaces to be maintained by 1349 IANA, but it requires new values in namespaces that have been defined 1350 in the IKEv2 base specification [RFC4306]. 1352 This document defines a new IKEv2 exchange whose value is to be 1353 allocated from the "IKEv2 Exchange Types" namespace: 1355 Exchange Type Value 1356 ------------------------------ ----- 1357 ME_CONNECT TBD-BY-IANA (38..239) 1359 These exchange is described in Section 3.4.1. 1361 This document defines one new IKEv2 payload whose value is to be 1362 allocated from the "IKEv2 Payload Types" namespace: 1364 Payload Type Notation Value 1365 ------------------------------ -------- ----- 1366 Identification - Peer IDp TBD-BY-IANA (49..127) 1368 This payload is described in Section 7. 1370 This document defines several new IKEv2 notifications whose values 1371 are to be allocated from the "IKEv2 Notify Message Types" namespace: 1373 Notify Messages - Error Types Value 1374 ------------------------------ ----- 1375 ME_CONNECT_FAILED TBD-BY-IANA (42..8191) 1377 Notify Messages - Status Types Value 1378 ------------------------------ ----- 1379 ME_MEDIATION TBD-BY-IANA (16406..40959) 1380 ME_ENDPOINT TBD-BY-IANA (16406..40959) 1381 ME_CALLBACK TBD-BY-IANA (16406..40959) 1382 ME_CONNECTID TBD-BY-IANA (16406..40959) 1383 ME_CONNECTKEY TBD-BY-IANA (16406..40959) 1384 ME_CONNECTAUTH TBD-BY-IANA (16406..40959) 1385 ME_RESPONSE TBD-BY-IANA (16406..40959) 1387 These notification payloads are described in Section 7. 1389 10. IAB Considerations 1391 TODO? 1393 11. Acknowledgements 1395 The author would like to thank Martin Willi for his work on the 1396 introductory sections, and both him and Andreas Steffen for their 1397 comments and suggestions. A special thanks goes to Daniel 1398 Roethlisberger who worked with the author on an early revision of 1399 this specification. 1401 12. References 1403 12.1. Normative References 1405 [RFC2119] Bradner, S., "Key words for use in RFCs 1406 to Indicate Requirement Levels", 1407 BCP 14, RFC 2119, March 1997. 1409 [RFC3948] Huttunen, A., Swander, B., Volpe, V., 1410 DiBurro, L., and M. Stenberg, "UDP 1411 Encapsulation of IPsec ESP Packets", 1412 RFC 3948, January 2005. 1414 [RFC4306] Kaufman, C., "Internet Key Exchange 1415 (IKEv2) Protocol", RFC 4306, 1416 December 2005. 1418 12.2. Informative References 1420 [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P., 1421 and D. Wing, "Session Traversal 1422 Utilities for (NAT) (STUN)", 1423 draft-ietf-behave-rfc3489bis-15 (work 1424 in progress), February 2008. 1426 [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. 1427 Matthews, "Traversal Using Relays 1428 around NAT (TURN): Relay Extensions to 1429 Session Traversal Utilities for NAT 1430 (STUN)", draft-ietf-behave-turn-07 1431 (work in progress), February 2008. 1433 [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive 1434 Connectivity Establishment (ICE): A 1435 Protocol for Network Address 1436 Translator (NAT) Traversal for Offer/ 1437 Answer Protocols", 1438 draft-ietf-mmusic-ice-19 (work in 1439 progress), October 2007. 1441 [RFC3484] Draves, R., "Default Address Selection 1442 for Internet Protocol version 6 1443 (IPv6)", RFC 3484, February 2003. 1445 [RFC4555] Eronen, P., "IKEv2 Mobility and 1446 Multihoming Protocol (MOBIKE)", 1447 RFC 4555, June 2006. 1449 Editorial Comments 1451 [anchor11] this allows later revisions of this specification to 1452 define a relay usage 1454 Appendix A. Open Issues 1456 A.1. Is the second ME_CONNECTKEY required? 1458 The key provided by the responding peer is not really required. It's 1459 just that the MACs of the connectivity check requests from both peers 1460 would look the same, if only one key was used. On the other hand 1461 using just one key, would allow us to drop the ME_RESPONSE Notify 1462 payload from the ME_CONNECT response. Because the response from the 1463 other peer would not contain a ME_CONNECTKEY Notify it were clearly 1464 distinguishable from a ME_CONNECT request (see Appendix B.2). 1466 A.2. Different NAT, Same Subnet 1468 One problem arises when two hosts behind different NATs are attached 1469 to the same subnet. Is this just a configuration problem that we 1470 need or need not to document, or is it a main issue that we should 1471 provide a solution for (Virtual IP?). 1473 A.3. Relaying Provided by the Mediation Server 1475 As we provide the possibility to request a server reflexive endpoint 1476 from the mediation server, should we also provide relayed endpoints? 1478 A.4. Compatibility/Synergy with MOBIKE 1480 What happens in the following situations: Moving behind a NAT. 1481 Moving out of a NAT. External IP changes (NAT/no NAT). Multihomed 1482 host (active link goes down). If both peers still are connected to 1483 the mediation server, is there a possibility to update the endpoints? 1484 If a peer notices an address change with MOBIKE, should it update the 1485 endpoints? Should it send updated endpoints to the other peer? If 1486 the mediation server notices that our endpoint changed, does it send 1487 us a notice (other than through MOBIKE)? 1489 Appendix B. Design Decisions 1491 B.1. Two exchanges between mediation server and second peer 1493 This document proposes the initiation of a connection to be composed 1494 of four exchanges: from one peer to the mediation server, from the 1495 mediation server to the other peer, and vice-versa. The two 1496 exchanges between the other peer and the mediation server could 1497 theoretically be combined in one exchange. This would be problematic 1498 in situations where the second peer first has to obtain endpoints 1499 before being able to answer the request. As this will take some 1500 time, the mediation server would most likely have retransmitted the 1501 request due to a timeout. And, if the peer wants to acquire a server 1502 reflexive endpoint from the mediation server a window size higher 1503 than one is required. 1505 B.2. Why the ME_RESPONSE Notify payload is needed 1507 It might seem that the ME_RESPONSE is rather superfluous. The 1508 ME_CONNECTID alone seems to be enough to distinguish requests from 1509 responses. A peer just has to maintain a list of issued ids and then 1510 simply compares the ME_CONNECTID of received ME_CONNECT messages with 1511 the items in this list. If an item matches, the received message is 1512 a response, otherwise, it is a request. Since the ME_CONNECTID is 1513 randomly chosen by the initiator, the ids contained in requests from 1514 two different peers should never match. So, this should even work if 1515 two peers concurrently initiate a mediation with each other. 1517 But there is a problem: What happens if a peer looses its state (e.g. 1518 due to a crash/restart) right after initiating a mediation, but 1519 immediately reconnects to the mediation server? Now, the 1520 ME_CONNECTID included in the answer from the other peer to the 1521 previously sent request is not included in the list of issued ids 1522 anymore. The answer thus looks exactly like a request for a new 1523 mediation. To avoid such a misunderstanding, peers have to be able 1524 to clearly distinguish requests from responses. Therefore, a 1525 ME_RESPONSE Notify payload is included in mediation responses. 1527 Appendix C. Changelog 1529 C.1. Changes from -.3 to -00 1531 o Lots of clarifications and refinements. Major work on the 1532 introductory sections. 1534 C.2. Changes from -.2 to -.3 1536 o Refined some details after implementing the protocol. 1538 C.3. Changes from -.1 to -.2 1540 o Complete redesign to an ICE-like solution. 1542 C.4. Changes from -.0 to -.1 1544 o P2P_CONNECT for both sides 1546 o "Endpoint..." terms expanded. 1548 Author's Address 1550 Tobias Brunner 1551 University of Applied Sciences, Rapperswil 1552 Oberseestrasse 10 1553 Rapperswil, SG 8640 1554 Switzerland 1556 EMail: tobias.brunner@hsr.ch 1557 URI: http://ita.hsr.ch 1559 Full Copyright Statement 1561 Copyright (C) The IETF Trust (2008). 1563 This document is subject to the rights, licenses and restrictions 1564 contained in BCP 78, and except as set forth therein, the authors 1565 retain all their rights. 1567 This document and the information contained herein are provided on an 1568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1570 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1571 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1572 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1575 Intellectual Property 1577 The IETF takes no position regarding the validity or scope of any 1578 Intellectual Property Rights or other rights that might be claimed to 1579 pertain to the implementation or use of the technology described in 1580 this document or the extent to which any license under such rights 1581 might or might not be available; nor does it represent that it has 1582 made any independent effort to identify any such rights. Information 1583 on the procedures with respect to rights in RFC documents can be 1584 found in BCP 78 and BCP 79. 1586 Copies of IPR disclosures made to the IETF Secretariat and any 1587 assurances of licenses to be made available, or the result of an 1588 attempt made to obtain a general license or permission for the use of 1589 such proprietary rights by implementers or users of this 1590 specification can be obtained from the IETF on-line IPR repository at 1591 http://www.ietf.org/ipr. 1593 The IETF invites any interested party to bring to its attention any 1594 copyrights, patents or patent applications, or other proprietary 1595 rights that may cover technology that may be required to implement 1596 this standard. Please address the information to the IETF at 1597 ietf-ipr@ietf.org.