idnits 2.17.1 draft-wang-rtcweb-oars-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 125 has weird spacing: '...fferent add...' == Line 126 has weird spacing: '...warding capa...' == Line 140 has weird spacing: '...success of c...' == Line 141 has weird spacing: '...locates diffe...' == Line 146 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 (April 6, 2017) is 2569 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 370, but not defined == Unused Reference: 'RFC5389' is defined on line 528, 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 (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTCWEB 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 April 6, 2017 10 Expires: October 5, 2017 12 Operator-Assisted Relay Service Architecture (OARS) 13 draft-wang-rtcweb-oars-02.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 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, and it may not be 23 published except as an Internet-Draft. 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, except to publish it 28 as an RFC and to translate it into languages other than English. 30 It is for publication as an RFC or to translate it into languages 31 other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on October 5, 2017. 52 Copyright Notice 54 Copyright (c) 2017 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. 64 Abstract 66 This document proposes a new relay-based NAT traversal architecture 67 called OARS which could simplify the data communication process 68 between two hosts that locates behind some non-BEHAVE compliant 69 [RFC4787] [RFC5382] NAT devices. The key mechanism in OARS is the 70 newly defined "Couple" message which allows the Relay servers to be 71 easily incorporated into existing CGN/CDN nodes which are already 72 deployed within the network in a distributed manner. 73 Table of Contents 75 1. Introduction ................................................ 3 76 1.1. Motivations ............................................ 3 77 1.2. Relationship with TURN.................................. 5 78 2. Conventions used in this document............................ 5 79 3. Solution Overview ........................................... 6 80 3.1. Reference Architecture of OARS ..........................6 81 3.2. Solution Rationale...................................... 7 82 3.2.1. Get_RS_Token()..................................... 7 83 3.2.2. Get_Optimal_Relay()................................ 7 84 3.2.3. Get_Relay_Reflex()................................. 7 85 3.2.4. Couple() .......................................... 7 86 3.2.5. Data() ............................................ 8 87 4. Detailed Example ............................................ 8 88 4.1. Procedures of Communication between two IPv4 hosts.......8 89 4.2. Procedures of IPv4 and IPv6 Host Communication...........9 90 5. OARS Benefits .............................................. 10 91 6. OARS Deployment Considerations.............................. 11 92 7. Security Considerations..................................... 11 93 8. IANA Considerations ........................................ 11 94 9. Conclusions ................................................ 11 95 10. Acknowledgements .......................................... 11 97 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 98 11. References ................................................ 12 99 11.1. Normative References.................................. 12 100 11.2. Informative References................................ 12 102 1. Introduction 104 1.1. Motivations 106 This document proposes a new relay-based NAT traversal architecture 107 called OARS based on the following motivations. 109 1) Leverage ISPs' infrastructures 111 Currently, the deployment of TURN [RFC5766] is very limited and most 112 of the application providers use their own platform to transfer the 113 data between two hosts that behind NATs and to translate the 114 communication packets between two hosts in different address families. 116 The relay devices deployed centrally by various application providers 117 often lead to inefficient data transmit between two hosts and it must 118 deal with complex network layer problems which the application 119 providers are not familiar with. 121 On the other hand, service providers have deployed many CGN/CDN nodes 122 in a distributed manner within their networks. If the service 123 providers can use these CGN devices/CDN nodes as the relay devices 124 for communication between two hosts behind NATs or that from 125 different address family, and provide their data 126 translation/forwarding capability to the application providers, the 127 host to host communication will be more efficient. Given most of the 128 CGNs are capable of translating packets between IPv4 and IPv6, the 129 adoption of IPv6 technology will also be accelerated. 131 2) Simplify the communication procedures 133 OARS needs less communication procedures than TURN of which the 134 procedures are considered very complex to be integrated into the 135 ISPs' infrastructure, for example: 137 o TURN solution has to closely interact with ICE 138 Within current TURN solution, there are scenarios where the ICE 139 or other NAT-hole punching procedures must be included for the 140 success of communication via TURN servers. The key point is 141 that TURN allocates different relay transport address-port 142 pairs for different hosts. 144 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 145 Each client must first use TURN allocation request to get their 146 transport relay address-port pairs, and then must use ICE 147 procedure (connectivity check) or other similar signaling to 148 punch holes for these transport relay addresses on the 149 alongside NAT devices. Or else the relayed UDP/TCP packet will 150 be blocked. 152 Even with the above procedures, there still exist some risks 153 that the packets be rejected by TURN server due to the 154 permission list that created by client via "CreatePermission 155 Request" before it sending data to the peer. In order to 156 mitigate such issues, current TURN solution requires the TURN 157 servers only check the IP address part of the relay transport 158 address, and ignore the port portion. But this will again 159 introduce some attack risks because different host may share one 160 public IP address when the CGN device is deployed within network. 162 o IPv4/IPv6 Relay Address/Port Reservation and Allocation 164 Another drawback of different relay transport addresses for 165 different host is that the TURN server must reserve some IPv4/ 166 IPv6 address block for the allocation and plan the TCP/UDP port 167 usage for each host. When TURN servers are deployed in a 168 distribute manner (For example when they are incorporated into 169 the CGN devices), there will be much coordination work to do 170 for the address/port reservation and allocation on the TURN 171 servers. 173 o Simultaneous TCP/UDP connections burden on TURN server 175 Current TURN solution requires the TURN servers to open and 176 listen on many TCP/UDP ports at the same time, Under TURN solution 177 for TCP[RFC6062], each host requires two connections to the TURN 178 server. This will increase the burden on TURN server and the 179 complexity to incorporate them into the CGN/CDN devices. 181 o Different procedures for TCP/UDP communication 183 Current TURN solution adopts different procedures for the TCP 184 and UDP communication channel. So for one TURN server to 185 provide the TCP/UDP relay function, it must implement two 186 different procedures. This again increases the complexity of 187 the TURN server implementation, especially in CGN devices. 189 o Communication complexity between two different TURN servers 191 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 193 Current TURN solution cannot assure two hosts select the same 194 TURN server, and then it must deal with the communication 195 situation between two different TURN servers. This scenario 196 has not been covered by the current TURN related drafts. The client 197 must reuse the XOR-PEER-ADDRESS attribute to include the relay 198 address of the peer to reach the second TURN server. 200 On the other hand, because the hosts select their own TURN 201 server, there is no mechanism to assure the relayed path is 202 most optimal for them. The application latency will be 203 increased when this occurs. 205 OARS solution will simplify the above mentioned complexity and make 206 the TCP/UDP data relay function be easily incorporated into the 207 existing distributed CGN devices or other kinds distributed devices 208 i.e. the CDN nodes etc. 210 1.2. Relationship with TURN 212 This document doesn't intent to replace TURN with OARS, but 213 consider OARS as a complementary solution along with TURN for some 214 specific scenarios. 216 If one SP wants to open its infrastructure to accelerate their 217 customers' (mainly regarding to application providers) client-to- 218 client communications within the SP's domain, OARS could be a good 219 candidate. 221 2. Conventions used in this document 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in RFC 2119 [RFC2119]. 227 O Relay Selector: which is in charge of selecting a proper relay 228 device (CGN or CDN nodes) for the communicating hosts behind NATs. 229 Normally, the RS is a function located in the network's management 230 plane and possibly a part of the NMS server 232 O OARS: Operator-Assisted Relay Service. Compared with the relay 233 services that implemented independently by each TURN client, OARS can 234 simplify the relay procedures in central control mode via the 235 assistance of network operator. 237 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 239 o OARS Client: The client that initiated the Couple() message to bind 240 two TCP/UDP sessions on one relay device or two different relay 241 devices. 242 . 243 o OARS Server: The server that implemented the Couple() message to 244 bind two TCP/UDP sessions on one relay device or two different relay 245 devices. 247 3. Solution Overview 249 3.1. Reference Architecture of OARS 251 +-----------+----------+ 252 | RS | 253 | (Relay Selector) | 254 +-----------+----------+ 255 / | \ 256 / | \ 257 / | \ 258 / | \ 259 +------------------+ +---------+--------+ +------------------+ 260 | CGN-1 | | CGN-X | | CGN-2 | 261 | (OARS Server) | | (OARS Server) |...| (OARS Server) | 262 +-------------+----+ +------------------+ +----+-------------+ 263 | | 264 | | 265 | | 266 +----+----+ +----+----+ 267 | | | | 268 | NAT | | NAT | 269 | | | | 270 +----+----+ +----+----+ 271 | | 272 +----+---+ +---+----+ 273 | Host A | | Host B | 274 |(v4/v6) | |(v4/v6) | 275 +--------+ +--------+ 276 (OARS Client) (OARS Client) 278 Fig. 3-1: OARS Architecture 280 As depicted in above figure, the application clients that located on 282 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 283 hosts act as the OARS clients while the CGNs act as OARS Servers. 284 There is a Relay Selector (RS) for choosing a proper CGN to relay 285 traffic between the two hosts. In practice, the RS could be a 286 dedicated server or a function located in the management plane 287 servers such as NMS server or SDN Controller. 289 RS has the intelligent route selection capability to choose a proper 290 CGN for a given host pair. It generate the communication token upon 291 the request of Application server, transfer these tokens to the relay 292 devices to authenticate and authorize the communication between OARS 293 clients(host) and OARS server(Relay/CGN devices). 295 BEHAVE compliant and non-BEHAVE compliant NAT traverse [RFC4787] 296 [RFC5382] is supported in OARS. IPv6 and IPv4 host communication is 297 also supported. 299 3.2. Solution Rationale 301 The solution could be briefly described in the following sections. 303 3.2.1. Get_RS_Token() 305 When clients register to their server, they will get the ip address 306 of appropriate Relay Selector from the service provider, together 307 with the token for the further usage of relay(CGN device)service. The 308 token is generated dynamically via the communication between 309 application server and RS, which is out the scope of this draft. 311 3.2.2. Get_Optimal_Relay() 313 Upon receiving the RS information, the clients will send 314 Get_Optimal_Relay(RS,AP_Reflex_Pair,Token) message to the RS, with 315 the AP_Reflex_Pair(client's reflective address to the App server) and 316 allocated token as the parameters, to let the RS select on optimal 317 relay device for the clients. 319 3.2.3. Get_Relay_Reflex() 321 Client will send the Get_Relay_Reflex(Optimal_Relay, Token) message 322 to the optimal relay, get its reflective address to this relay, and 323 exchange such information with the peer via the Application server. 325 3.2.4. Couple() 327 Client then send the 329 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 330 Couple(Relay_A,Reflex_Relay_A,Relay_B,Reflex_Relay_B,Token) message 331 to the optimal relay, build the mapping table on such relay, with the 332 relay address, the reflective address to them and token as the 333 parameter. 335 3.2.5. Data() 337 Client can now send data directly to relay via Data(Relay,Token) 338 message. Upon receiving the user data, the relay will change the 339 source and destination address of the data packet respectively 340 according to the mapping table built by previous Couple message. The 341 return data will follow the same procedure. 343 The procedure is same regardless of the communication peer are 344 located in the same SP or different SPs. 346 4. Detailed Example 348 4.1. Procedures of Communication between two IPv4 hosts 350 When one of the communication hosts located behind the symmetric NAT 351 device, the host-to-host communication must via one relay device. 352 Below are the key procedures of OARS solution, we use the Fig3-1 to 353 describe the example. 355 1) If Host A and Host B want to communicate with each other, they 356 will send Get_RS_Token() message to the application server, to get 357 the IPv4 address/port of RS and the token for further 358 communication with the relay device. 360 2) Host A and Host B will request the RS to select one optimal relay 361 device for their communication, based on the host's reflective 362 address to the Application server. In this example, we assume the 363 CGN-1 is selected for Host A and CGN-2 is selected for Host B. 365 3) Host A and Host B will send Get_Relay_Reflex message to CGN-1 and 366 CGN-2 respectively, get their relay address to CGN[REFLX-Relay] 367 and exchange them via the Application server. 369 4) Host will send the Couple message to the optimal relay, which 370 includes mainly the [REFLX-Relay] addresses of Host A and Host B 371 and their communication protocol, here we assume they use TCP to 372 communicate. 374 5) Upon receiving the Couple message, the CGN device will form 375 one forwarding table that look like below: 377 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 379 +--------------------------------------------------------------+ 381 |Reflex_A|Relay_1|T_Relay_1|Reflex_B|Relay_2|T_Relay_2|Protocol| 383 +--------------------------------------------------------------+ 385 Table 5-1: Couple Table Example (symmetric case) 387 6) Host A will send the application data to the relay transport 388 address in CGN-1(Relay_1). 390 7) CGN-1 device will look up the Couple table, use the source address 391 of received packet(Reflex_A in this example) to get the 392 reflex IPv4 address of Host B. 394 8) It then will change the source address of the packet to the relay 395 transport address in CGN-2 device (Relay_2), the destination 396 address of this packet to the IPv4 reflex address of Host 397 B(Reflex_B), then encapsulated in the tunnel, with T_Relay_1 as 398 the tunnel source address and T_Relay_2 as tunnel destination 399 address. The translated and tunneled packet will be forwarded to 400 CGN-2(Relay 2). 402 9) CGN-2 device will decapsulate the packet, send the decapsulate 403 packet to Reflex_B. This packet will pass the NAT device, be 404 translated by the NAT and then be forwarded to the Host2. 406 10) The return traffic will be sent to CGN-2(Relay_2). Upon receiving 407 the return packet, CGN-2(Relay_2) will change the source address 408 to Relay_1, the destination address to Reflex_A, according to the 409 mapping table, and then encapsulate it into one tunnel packet, 410 with the T_Relay_2 as tunnel source address and T_Relay_1 as 411 tunnel destination address. 413 11) Relay_1 will decapsulate the packet, send the decapsulate packet 414 to Reflex_A. This packet will pass the NAT device, be translated 415 by the NAT and then forward to the Host1. 417 4.2. Procedures of IPv4 and IPv6 Host Communication 419 If Host A is one IPv4 node and Host B is one IPv6 node. The 420 communication process is similar, except that the relay address of 421 Host A is the IPv4 address of the CGN-1 and the relay address of the 422 Host B is the IPv6 address of the CGN-2. Host A and Host B will not 423 notice that they are talking to one node that in different address 424 family. 426 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 427 The mapping table is same except that the Reflex_A/Relay_1 is belong 428 to IPv4 address family and the Reflex_B/Relay_2 is belong to IPv6 429 address family. The T_Relay_1 and T_Relay_2 should be in the same 430 address family, and are determined by the operator themselves. 432 5. OARS Benefits 434 Comparing to TURN, OARS could provide following benefits: 436 o Decoupled from ICE 438 TURN is tightly coupled with ICE. Operations like NAT punching, 439 create permission .etc all require ICE connectivity check packets. 440 Benefited from the couple operation, OARS doesn't necessarily need 441 ICE interaction. 443 o Less Relay Address/Port Consumption and Management 445 OARS doesn't need to allocate different address-port pair for each 446 session initiated from the hosts. Thus, it could obviously reduce 447 the resource consumption and the human burden for planning the 448 resource allocation. 450 o Unified solution for TCP/UDP and IPv4(6)-IPv6(4) data relay 451 OARS supports the data relay for the communication between two hosts, 452 uses same mechanism for TCP and UDP transport protocol, even for the 453 communication between different address families. 455 o Support for optimal relay selection 457 Because of the central deployed RS could have the whole 458 network's routing/path knowledge, OARS is more likely to 459 achieve an optimal relay (OARS server) selection based on 460 various information such as the reflective transport addresses 461 of the two communicating peers, the link usage information 462 between two peers and the load status of the candidate TURN- 463 Lite servers etc. 465 With the RS's knowledge, OARS is also more likely to achieve better 466 relay selection for some specific requirements. For example, if one 467 peer wants to hide its ip address to protect its privacy, the RS in 468 OARS architecture could possibly select one OARS server that located 469 far away from the host. 471 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 472 6. OARS Deployment Considerations 474 The OARS Server can be deployed in distributed manner. The most 475 appropriate devices for incorporating this function are the CGN 476 devices that have been deployed distributed by the service provider. 477 Each distributed OARS Server has one unique public IPv4/IPv6 478 transport address. 480 The RS can select the appropriate OARS Server based on the 481 proximity of the OARS server with the communication hosts and can 482 also use other criteria to influence the selection procedure, as 483 described in Section 3. 485 7. Security Considerations 487 The additional requirement of OARS is authenticating the messages 488 between the OARS Client, RS and Relay device. Currently, we use the 489 RS allocated token to accomplish this task. Because such token is 490 allocated dynamically, such security risks can be mitigated 491 accordingly. 493 8. IANA Considerations 495 TBD. 497 9. Conclusions 499 Currently, the communication between two hosts that located behind 500 NAT devices, especially that behind the symmetric NAT devices is 501 emerging. With the development of IPv6 technology, the communication 502 between two hosts that in different address families needs also be 503 considered. Under the OARS architecture, the communication requests 504 for IPv4/IPv4, IPv4/IPv6 scenario can be met in one general solution. 505 Such solution can alleviate the burden of various CP/SP to deploy the 506 TURN server by themselves, exploit and open the capabilities of CGN 507 device that deployed by service provider to the third party(CP/SP), 508 make the host-to-host communication more efficient. 510 10. Acknowledgements 512 Many valuable comments were received from Brandon Williams, Oleg 513 Moskalenko, Jonathan Rosenberg, and Dan Wing etc. 515 This document was produced using the xml2rfc tool [RFC2629]. 517 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 518 11. References 520 11.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, July 1997. 525 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 526 June 1999. 528 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 529 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 530 October 2008. 532 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 533 Relays around NAT (TURN): Relay Extensions to Session 534 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 536 11.2. Informative References 538 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 539 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 540 RFC 4787, January 2007. 542 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 543 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 544 RFC 5382, October 2008. 546 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 547 around NAT (TURN) Extensions for TCP Allocations", RFC 548 6062, November 2010. 550 Authors' Addresses 552 Aijun Wang 553 China Telecom 554 Beiqijia Town, Changping District 555 Beijing, 102209 556 Email: wangaj.bri@chinatelecom.cn 558 Internet-Draft Operator-Assisted Relay Service Architecture (OARS) 559 Bing Liu 560 Huawei Technologies 561 Q14, Huawei Campus, No.156 Beiqing Road, Hai-Dian District 562 Beijing, 100095 563 P.R. China 564 Email: leo.liubing@huawei.com 566 Justin Uberti 567 Google 568 747 6th Ave S 569 Kirkland, WA 98033 570 USA 571 Email: justin@uberti.name 573 Peng Ding 574 China Telecom 575 Beiqijia Town, Changping District 576 Beijing, 102209 577 Email: dingpeng.bri@chinatelecom.cn