idnits 2.17.1 draft-wang-dispatch-oars-00.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 107 has weird spacing: '...fferent add...' == Line 108 has weird spacing: '...warding capa...' == Line 122 has weird spacing: '...success of c...' == Line 123 has weird spacing: '...locates diffe...' == Line 127 has weird spacing: '...ansport relay...' == (32 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 18, 2018) is 2229 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) == Missing Reference: 'REFLX-Relay' is mentioned on line 350, but not defined == Unused Reference: 'RFC2629' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 505, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DISPATCH Working Group A.Wang 2 Internet Draft China Telecom 3 B.Liu 4 Huawei Technologies 5 J.Uberti 6 Google 7 Peng.Ding 8 China Telecom 9 Intended status: Standard Track March 18, 2018 10 Expires: September 17, 2018 12 Operator-Assisted Relay Service Architecture (OARS) 13 draft-wang-dispatch-oars-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 17, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. 44 Abstract 46 This document proposes a new relay-based NAT traversal architecture 47 called OARS which could simplify the data communication process 49 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 50 between two hosts that locates behind some non-BEHAVE compliant 51 [RFC4787] [RFC5382] NAT devices. The key mechanism in OARS is the 52 newly defined "Couple" message which allows the Relay servers to be 53 easily incorporated into existing CGN/CDN nodes which are already 54 deployed within the network in a distributed manner. 55 Table of Contents 57 1. Introduction ................................................ 2 58 1.1. Motivations ............................................ 2 59 1.2. Relationship with TURN.................................. 5 60 2. Conventions used in this document............................ 5 61 3. Solution Overview ........................................... 5 62 3.1. Reference Architecture of OARS.......................... 5 63 3.2. Solution Rationale...................................... 6 64 3.2.1. Get_RS_Token()..................................... 7 65 3.2.2. Get_Optimal_Relay()................................ 7 66 3.2.3. Get_Relay_Reflex()................................. 7 67 3.2.4. Couple() .......................................... 7 68 3.2.5. Data() ............................................ 7 69 4. Detailed Example ............................................ 8 70 4.1. Procedures of Communication between two IPv4 hosts...... 8 71 4.2. Procedures of IPv4 and IPv6 Host Communication...........9 72 5. OARS Benefits ............................................... 9 73 6. OARS Deployment Considerations............................... 10 74 7. Security Considerations...................................... 10 75 8. IANA Considerations ......................................... 11 76 9. Conclusions ................................................. 11 77 10. Acknowledgements ........................................... 11 78 11. References ................................................. 11 79 11.1. Normative References................................... 11 80 11.2. Informative References................................. 12 82 1. Introduction 84 1.1. Motivations 86 This document proposes a new relay-based NAT traversal architecture 87 called OARS based on the following motivations. 89 1) Leverage ISPs' infrastructures 91 Currently, the deployment of TURN [RFC5766] is very limited and most 92 of the application providers use their own platform to transfer the 93 data between two hosts that behind NATs and to translate the 94 communication packets between two hosts in different address families. 96 The relay devices deployed centrally by various application providers 97 often lead to inefficient data transmit between two hosts and it must 99 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 100 deal with complex network layer problems which the application 101 providers are not familiar with. 103 On the other hand, service providers have deployed many CGN/CDN nodes 104 in a distributed manner within their networks. If the service 105 providers can use these CGN devices/CDN nodes as the relay devices 106 for communication between two hosts behind NATs or that from 107 different address family, and provide their data 108 translation/forwarding capability to the application providers, the 109 host to host communication will be more efficient. Given most of the 110 CGNs are capable of translating packets between IPv4 and IPv6, the 111 adoption of IPv6 technology will also be accelerated. 113 2) Simplify the communication procedures 115 OARS needs less communication procedures than TURN of which the 116 procedures are considered very complex to be integrated into the 117 ISPs' infrastructure, for example: 119 o TURN solution has to closely interact with ICE 120 Within current TURN solution, there are scenarios where the ICE 121 or other NAT-hole punching procedures must be included for the 122 success of communication via TURN servers. The key point is 123 that TURN allocates different relay transport address-port 124 pairs for different hosts. 126 Each client must first use TURN allocation request to get their 127 transport relay address-port pairs, and then must use ICE 128 procedure (connectivity check) or other similar signaling to 129 punch holes for these transport relay addresses on the 130 alongside NAT devices. Or else the relayed UDP/TCP packet will 131 be blocked. 133 Even with the above procedures, there still exist some risks 134 that the packets be rejected by TURN server due to the 135 permission list that created by client via "CreatePermission 136 Request" before it sending data to the peer. In order to 137 mitigate such issues, current TURN solution requires the TURN 138 servers only check the IP address part of the relay transport 139 address, and ignore the port portion. But this will again 140 introduce some attack risks because different host may share one 141 public IP address when the CGN device is deployed within network. 143 o IPv4/IPv6 Relay Address/Port Reservation and Allocation 145 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 146 Another drawback of different relay transport addresses for 147 different host is that the TURN server must reserve some IPv4/ 148 IPv6 address block for the allocation and plan the TCP/UDP port 149 usage for each host. When TURN servers are deployed in a 150 distribute manner (For example when they are incorporated into 151 the CGN devices), there will be much coordination work to do 152 for the address/port reservation and allocation on the TURN 153 servers. 155 o Simultaneous TCP/UDP connections burden on TURN server 157 Current TURN solution requires the TURN servers to open and 158 listen on many TCP/UDP ports at the same time, Under TURN solution 159 for TCP[RFC6062], each host requires two connections to the TURN 160 server. This will increase the burden on TURN server and the 161 complexity to incorporate them into the CGN/CDN devices. 163 o Different procedures for TCP/UDP communication 165 Current TURN solution adopts different procedures for the TCP 166 and UDP communication channel. So for one TURN server to 167 provide the TCP/UDP relay function, it must implement two 168 different procedures. This again increases the complexity of 169 the TURN server implementation, especially in CGN devices. 171 o Communication complexity between two different TURN servers 173 Current TURN solution cannot assure two hosts select the same 174 TURN server, and then it must deal with the communication 175 situation between two different TURN servers. This scenario 176 has not been covered by the current TURN related drafts. The client 177 must reuse the XOR-PEER-ADDRESS attribute to include the relay 178 address of the peer to reach the second TURN server. 180 On the other hand, because the hosts select their own TURN 181 server, there is no mechanism to assure the relayed path is 182 most optimal for them. The application latency will be 183 increased when this occurs. 185 OARS solution will simplify the above mentioned complexity and make 186 the TCP/UDP data relay function be easily incorporated into the 187 existing distributed CGN devices or other kinds distributed devices 188 i.e. the CDN nodes etc. 190 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 191 1.2. Relationship with TURN 193 This document doesn't intent to replace TURN with OARS, but 194 consider OARS as a complementary solution along with TURN for some 195 specific scenarios. 197 If one SP wants to open its infrastructure to accelerate their 198 customers' (mainly regarding to application providers) client-to- 199 client communications within the SP's domain, OARS could be a good 200 candidate. 202 2. Conventions used in this document 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in RFC 2119 [RFC2119]. 208 O Relay Selector: which is in charge of selecting a proper relay 209 device (CGN or CDN nodes) for the communicating hosts behind NATs. 210 Normally, the RS is a function located in the network's management 211 plane and possibly a part of the NMS server 213 O OARS: Operator-Assisted Relay Service. Compared with the relay 214 services that implemented independently by each TURN client, OARS can 215 simplify the relay procedures in central control mode via the 216 assistance of network operator. 218 o OARS Client: The client that initiated the Couple() message to bind 219 two TCP/UDP sessions on one relay device or two different relay 220 devices. 221 . 222 o OARS Server: The server that implemented the Couple() message to 223 bind two TCP/UDP sessions on one relay device or two different relay 224 devices. 226 3. Solution Overview 228 3.1. Reference Architecture of OARS 230 +-----------+----------+ 231 | RS | 232 | (Relay Selector) | 233 +-----------+----------+ 235 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 236 / | \ 237 / | \ 238 / | \ 239 / | \ 240 +------------------+ +---------+--------+ +------------------+ 241 | CGN-1 | | CGN-X | | CGN-2 | 242 | (OARS Server) | | (OARS Server) |...| (OARS Server) | 243 +-------------+----+ +------------------+ +----+-------------+ 244 | | 245 | | 246 | | 247 +----+----+ +----+----+ 248 | | | | 249 | NAT | | NAT | 250 | | | | 251 +----+----+ +----+----+ 252 | | 253 +----+---+ +---+----+ 254 | Host A | | Host B | 255 |(v4/v6) | |(v4/v6) | 256 +--------+ +--------+ 257 (OARS Client) (OARS Client) 259 Fig. 3-1: OARS Architecture 261 As depicted in above figure, the application clients that located on 262 hosts act as the OARS clients while the CGNs act as OARS Servers. 263 There is a Relay Selector (RS) for choosing a proper CGN to relay 264 traffic between the two hosts. In practice, the RS could be a 265 dedicated server or a function located in the management plane 266 servers such as NMS server or SDN Controller. 268 RS has the intelligent route selection capability to choose a proper 269 CGN for a given host pair. It generate the communication token upon 270 the request of Application server, transfer these tokens to the relay 271 devices to authenticate and authorize the communication between OARS 272 clients(host) and OARS server(Relay/CGN devices). 274 BEHAVE compliant and non-BEHAVE compliant NAT traverse [RFC4787] 275 [RFC5382] is supported in OARS. IPv6 and IPv4 host communication is 276 also supported. 278 3.2. Solution Rationale 280 The solution could be briefly described in the following sections. 282 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 284 3.2.1. Get_RS_Token() 286 When clients register to their server, they will get the ip address 287 of appropriate Relay Selector from the service provider, together 288 with the token for the further usage of relay(CGN device)service. The 289 token is generated dynamically via the communication between 290 application server and RS, which is out the scope of this draft. 292 3.2.2. Get_Optimal_Relay() 294 Upon receiving the RS information, the clients will send 295 Get_Optimal_Relay(RS,AP_Reflex_Pair,Token) message to the RS, with 296 the AP_Reflex_Pair(client's reflective address to the App server) and 297 allocated token as the parameters, to let the RS select on optimal 298 relay device for the clients. 300 3.2.3. Get_Relay_Reflex() 302 Client will send the Get_Relay_Reflex(Optimal_Relay, Token) message 303 to the optimal relay, get its reflective address to this relay, and 304 exchange such information with the peer via the Application server. 306 3.2.4. Couple() 308 Client then send the 309 Couple(Relay_A,Reflex_Relay_A,Relay_B,Reflex_Relay_B,Token) message 310 to the optimal relay, build the mapping table on such relay, with the 311 relay address, the reflective address to them and token as the 312 parameter. 314 3.2.5. Data() 316 Client can now send data directly to relay via Data(Relay,Token) 317 message. Upon receiving the user data, the relay will change the 318 source and destination address of the data packet respectively 319 according to the mapping table built by previous Couple message. The 320 return data will follow the same procedure. 322 The procedure is same regardless of the communication peer are 323 located in the same SP or different SPs. 325 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 326 4. Detailed Example 328 4.1. Procedures of Communication between two IPv4 hosts 330 When one of the communication hosts located behind the symmetric NAT 331 device, the host-to-host communication must via one relay device. 332 Below are the key procedures of OARS solution, we use the Fig3-1 to 333 describe the example. 335 1) If Host A and Host B want to communicate with each other, they 336 will send Get_RS_Token() message to the application server, to get 337 the IPv4 address/port of RS and the token for further 338 communication with the relay device. 340 2) Host A and Host B will request the RS to select one optimal relay 341 device for their communication, based on the host's reflective 342 address to the Application server. In this example, we assume the 343 CGN-1 is selected for Host A and CGN-2 is selected for Host B. 345 3) Host A and Host B will send Get_Relay_Reflex message to CGN-1 and 346 CGN-2 respectively, get their relay address to CGN[REFLX-Relay] 347 and exchange them via the Application server. 349 4) Host will send the Couple message to the optimal relay, which 350 includes mainly the [REFLX-Relay] addresses of Host A and Host B 351 and their communication protocol, here we assume they use TCP to 352 communicate. 354 5) Upon receiving the Couple message, the CGN device will form 355 one forwarding table that look like below: 357 +--------------------------------------------------------------+ 359 |Reflex_A|Relay_1|T_Relay_1|Reflex_B|Relay_2|T_Relay_2|Protocol| 361 +--------------------------------------------------------------+ 363 Table 5-1: Couple Table Example (symmetric case) 365 6) Host A will send the application data to the relay transport 366 address in CGN-1(Relay_1). 368 7) CGN-1 device will look up the Couple table, use the source address 369 of received packet(Reflex_A in this example) to get the 370 reflex IPv4 address of Host B. 372 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 373 8) It then will change the source address of the packet to the relay 374 transport address in CGN-2 device (Relay_2), the destination 375 address of this packet to the IPv4 reflex address of Host 376 B(Reflex_B), then encapsulated in the tunnel, with T_Relay_1 as 377 the tunnel source address and T_Relay_2 as tunnel destination 378 address. The translated and tunneled packet will be forwarded to 379 CGN-2(Relay 2). 381 9) CGN-2 device will decapsulate the packet, send the decapsulate 382 packet to Reflex_B. This packet will pass the NAT device, be 383 translated by the NAT and then be forwarded to the Host2. 385 10) The return traffic will be sent to CGN-2(Relay_2). Upon receiving 386 the return packet, CGN-2(Relay_2) will change the source address 387 to Relay_1, the destination address to Reflex_A, according to the 388 mapping table, and then encapsulate it into one tunnel packet, 389 with the T_Relay_2 as tunnel source address and T_Relay_1 as 390 tunnel destination address. 392 11) Relay_1 will decapsulate the packet, send the decapsulate packet 393 to Reflex_A. This packet will pass the NAT device, be translated 394 by the NAT and then forward to the Host1. 396 4.2. Procedures of IPv4 and IPv6 Host Communication 398 If Host A is one IPv4 node and Host B is one IPv6 node. The 399 communication process is similar, except that the relay address of 400 Host A is the IPv4 address of the CGN-1 and the relay address of the 401 Host B is the IPv6 address of the CGN-2. Host A and Host B will not 402 notice that they are talking to one node that in different address 403 family. 405 The mapping table is same except that the Reflex_A/Relay_1 is belong 406 to IPv4 address family and the Reflex_B/Relay_2 is belong to IPv6 407 address family. The T_Relay_1 and T_Relay_2 should be in the same 408 address family, and are determined by the operator themselves. 410 5. OARS Benefits 412 Comparing to TURN, OARS could provide following benefits: 414 o Decoupled from ICE 416 TURN is tightly coupled with ICE. Operations like NAT punching, 417 create permission .etc all require ICE connectivity check packets. 418 Benefited from the couple operation, OARS doesn't necessarily need 419 ICE interaction. 421 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 422 o Less Relay Address/Port Consumption and Management 424 OARS doesn't need to allocate different address-port pair for each 425 session initiated from the hosts. Thus, it could obviously reduce 426 the resource consumption and the human burden for planning the 427 resource allocation. 429 o Unified solution for TCP/UDP and IPv4(6)-IPv6(4) data relay 430 OARS supports the data relay for the communication between two hosts, 431 uses same mechanism for TCP and UDP transport protocol, even for the 432 communication between different address families. 434 o Support for optimal relay selection 436 Because of the central deployed RS could have the whole 437 network's routing/path knowledge, OARS is more likely to 438 achieve an optimal relay (OARS server) selection based on 439 various information such as the reflective transport addresses 440 of the two communicating peers, the link usage information 441 between two peers and the load status of the candidate TURN- 442 Lite servers etc. 444 With the RS's knowledge, OARS is also more likely to achieve better 445 relay selection for some specific requirements. For example, if one 446 peer wants to hide its ip address to protect its privacy, the RS in 447 OARS architecture could possibly select one OARS server that located 448 far away from the host. 450 6. OARS Deployment Considerations 452 The OARS Server can be deployed in distributed manner. The most 453 appropriate devices for incorporating this function are the CGN 454 devices that have been deployed distributed by the service provider. 455 Each distributed OARS Server has one unique public IPv4/IPv6 456 transport address. 458 The RS can select the appropriate OARS Server based on the 459 proximity of the OARS server with the communication hosts and can 460 also use other criteria to influence the selection procedure, as 461 described in Section 3. 463 7. Security Considerations 465 The additional requirement of OARS is authenticating the messages 466 between the OARS Client, RS and Relay device. Currently, we use the 468 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 469 RS allocated token to accomplish this task. Because such token is 470 allocated dynamically, such security risks can be mitigated 471 accordingly. 473 8. IANA Considerations 475 TBD. 477 9. Conclusions 479 Currently, the communication between two hosts that located behind 480 NAT devices, especially that behind the symmetric NAT devices is 481 emerging. With the development of IPv6 technology, the communication 482 between two hosts that in different address families needs also be 483 considered. Under the OARS architecture, the communication requests 484 for IPv4/IPv4, IPv4/IPv6 scenario can be met in one general solution. 485 Such solution can alleviate the burden of various CP/SP to deploy the 486 TURN server by themselves, exploit and open the capabilities of CGN 487 device that deployed by service provider to the third party(CP/SP), 488 make the host-to-host communication more efficient. 490 10. Acknowledgements 492 Many valuable comments were received from Brandon Williams, Oleg 493 Moskalenko, Jonathan Rosenberg, and Dan Wing etc. 495 11. References 497 11.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, July 1997. 502 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 503 June 1999. 505 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 506 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 507 October 2008. 509 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 510 Relays around NAT (TURN): Relay Extensions to Session 511 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 513 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 514 11.2. Informative References 516 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 517 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 518 RFC 4787, January 2007. 520 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 521 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 522 RFC 5382, October 2008. 524 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 525 around NAT (TURN) Extensions for TCP Allocations", RFC 526 6062, November 2010. 528 Authors' Addresses 530 Aijun Wang 531 China Telecom 532 Beiqijia Town, Changping District 533 Beijing, 102209 534 Email: wangaj.bri@chinatelecom.cn 536 Bing Liu 537 Huawei Technologies 538 Q14, Huawei Campus, No.156 Beiqing Road, Hai-Dian District 539 Beijing, 100095 540 P.R. China 541 Email: leo.liubing@huawei.com 543 Justin Uberti 544 Google 545 747 6th Ave S 546 Kirkland, WA 98033 547 USA 548 Email: justin@uberti.name 550 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 551 Peng Ding 552 China Telecom 553 Beiqijia Town, Changping District 554 Beijing, 102209 555 Email: dingpeng.bri@chinatelecom.cn