idnits 2.17.1 draft-patil-tram-turn-serv-selection-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-07 == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-00 == Outdated reference: A later version (-04) exists of draft-petithuguenin-tram-stun-dane-02 == Outdated reference: A later version (-06) exists of draft-schwartz-rtcweb-return-03 == Outdated reference: A later version (-03) exists of draft-wing-tram-turn-mobility-02 ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Patil 3 Internet-Draft T. Reddy 4 Intended status: Informational G. Salgueiro 5 Expires: April 29, 2015 Cisco 6 October 26, 2014 8 Traversal Using Relays around NAT (TURN) Server Selection 9 draft-patil-tram-turn-serv-selection-00 11 Abstract 13 A TURN client may discover multiple TURN servers. In such a case, 14 there are no guidelines that a client can follow to choose or prefer 15 a particular TURN server among those discovered. This document 16 details selection criteria, as guidelines, that can be used by a 17 client to perform an informed TURN server selection decision. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 29, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. TURN Server Selection Criteria . . . . . . . . . . . . . . . 3 56 3.1. Local Configuration . . . . . . . . . . . . . . . . . . . 3 57 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2.1. Location Privacy . . . . . . . . . . . . . . . . . . 4 59 3.2.2. Authentication . . . . . . . . . . . . . . . . . . . 4 60 3.3. User Experience . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.5. Mobility Support . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Using any of the discovery mechanisms described in 73 [I-D.ietf-tram-turn-server-discovery], a client may discover multiple 74 Traversal Using Relays around NAT (TURN) servers. The TURN servers 75 discovered could be provided by an enterprise network, an access 76 network, an application service provider or a third party provider. 77 Therefore, the client needs to be able to choose a TURN server that 78 best suits its needs. 80 Selection criteria could be based on parameters such as: 82 o Security 84 o Location Privacy 86 o Authentication 88 o User Experience 90 o Interface Selection (if the client is multi-interfaced) 92 o Mobility Support 94 This document describes procedures that a client can use to choose 95 the most appropriate TURN server based on any one or more 96 combinations of the above parameters. A client could also use the 97 aforementioned selection criteria to prioritize the discovered TURN 98 servers based on these parameters if backup servers are implemented 99 for added resiliency and robustness. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. TURN Server Selection Criteria 109 The accessibility of possible TURN servers SHOULD be tested and 110 verified prior to beginning Interactive Connectivity Establishment 111 (ICE) [RFC5245]. Any TURN servers that fail such accessibility tests 112 (including credentials verification) SHOULD be excluded. These early 113 tests are an often an optimal opportunity to calculate performance 114 metrics, such as the round-trip time (RTT), that might be used as 115 TURN server prioritization factors, as discussed in Section 3.3. 116 Throughout the lifetime of the application, it is RECOMMENDED to 117 periodically test the entire selection list, in case better TURN 118 servers suddenly appear or connectivity to others is unexpectedly 119 lost. 121 The parameters described in this Section are intended as TURN server 122 selection criteria or as weighting factors for TURN server 123 prioritization. 125 3.1. Local Configuration 127 Local or manual configuration takes precedence for TURN server 128 selection. A client could be configured with an explicit preferred 129 list of TURN servers. Local configuration could list servers in 130 order of preference. For example, a TURN client could opt for a TURN 131 server offered by the Enterprise and fall back to a TURN server 132 offered by the Internet Service Provider (ISP) or a cloud service if 133 the Enterprise TURN server wasn't available. 135 An implementation MAY give the user an opportunity (e.g., by means of 136 configuration file options or menu items) to specify this preference. 138 3.2. Security 140 If a TURN client wants security for its connections, it should opt 141 for a TURN server that supports the usage of Transport Layer Security 142 (TLS) [RFC5246] and Datagram Transport Layer Security (DTLS) 143 [RFC6347] as a transport protocol for Session Traversal Utilities for 144 NAT (STUN), as defined in [RFC5389] and [RFC7350]. If multiple 145 servers offer this support, the client could use Location Privacy 146 (Section 3.2.1) and Authentication (Section 3.2.2) criteria to 147 determine which among the list is most suitable. 149 The need for security depends on the type of connected network (i.e., 150 whether the host is connected to a home network versus an Enterprise 151 network versus a coffee shop network). It is recommended that a 152 client always choose security, but this condition could vary 153 depending on the degree of trust with the connected network. 155 3.2.1. Location Privacy 157 In addition to security, a TURN client may require additional 158 location privacy from an external peer. 160 Scenario 1: A client may not wish to use a TURN server in its 161 Enterprise or access network because the client location could be 162 determined by the external peer. In such a case, the client may 163 choose to use a distributed multi-tenant or a cloud-based TURN 164 server that can provide privacy by obscuring the network from 165 which the client is communicating with the remote peer. 167 Scenario 2: A TURN client that desires to perform Scenario 1, but 168 cannot because of firewall policy that forces the client to pick 169 Enterprise-provided TURN server for external communication, can 170 use TURN-in-TURN through the enterprise's TURN server as described 171 in [I-D.schwartz-rtcweb-return]. 173 Location privacy may not be critical if the client attempts to 174 communicate with a peer within the same domain. 176 3.2.2. Authentication 178 A TURN client should prefer a TURN server whose authenticity can be 179 ascertained. A simple certificate trust chain validation during the 180 process of (D)TLS handshake should be able to validate the server. 182 A TURN client could also be pre-configured with the names of trusted 183 TURN servers. When connecting to a TURN server, a TURN client should 184 start with verifying that the TURN server name matches the pre- 185 configured list of TURN servers, and finally validating its 186 certificate trust chain. For TURN servers that don't have a 187 certificate trust chain, the configured list of TURN servers can 188 contain the certificate fingerprint of the TURN server (i.e., a 189 simple whitelist of name and certificate fingerprint). 191 DNS-based Authentication of Named Entities (DANE) can also be used to 192 validate the certificate presented by TURN server as described in 193 [I-D.petithuguenin-tram-stun-dane]. 195 3.3. User Experience 197 All else being equal (or if a TURN client is able to converge on a 198 set of TURN servers based on parameters described in Section 3.2), a 199 TURN client should choose a TURN server that provides the best user 200 experience at that point in time (based on factors such as RTT, real- 201 time clock (RTC), etc). 203 If using ICE regular nomination, ICE connectivity check round-trip 204 time can influence the selection amongst the valid pairs. This way a 205 candidate pair with relayed candidate could be selected even if it 206 has lower-priority than other valid pairs. 208 3.4. Interface 210 With a multi-interfaced node, selection of the correct interface and 211 source address is often crucial. How to select an interface and IP 212 address family is out of scope for this document. A client could 213 account for the provisioning domain described in 214 [I-D.ietf-mif-mpvd-arch] to determine which interface to choose. 216 3.5. Mobility Support 218 If a TURN client is aware that the host is mobile, and all other 219 parameters being equal, the client SHOULD choose a TURN server that 220 supports mobility [I-D.wing-tram-turn-mobility]. 222 4. Security Considerations 224 This document does not itself introduce security issues, rather it 225 merely presents best practices for TURN server selection. Security 226 considerations described in [RFC5766] are applicable to for all TURN 227 usage. 229 5. Acknowledgements 231 The authors would like to thank Dan Wing, Marc Petit-Huguenin for 232 their review and valuable comments. 234 6. References 235 6.1. Normative References 237 [I-D.ietf-mif-mpvd-arch] 238 Anipko, D., "Multiple Provisioning Domain Architecture", 239 draft-ietf-mif-mpvd-arch-07 (work in progress), October 240 2014. 242 [I-D.ietf-tram-turn-server-discovery] 243 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 244 Discovery", draft-ietf-tram-turn-server-discovery-00 (work 245 in progress), July 2014. 247 [I-D.petithuguenin-tram-stun-dane] 248 Petit-Huguenin, M. and G. Salgueiro, "Using DNS-based 249 Authentication of Named Entities (DANE) to validate TLS 250 certificates for the Session Traversal Utilities for NAT 251 (STUN) protocol", draft-petithuguenin-tram-stun-dane-02 252 (work in progress), October 2014. 254 [I-D.schwartz-rtcweb-return] 255 Schwartz, B., "Recursively Encapsulated TURN (RETURN) for 256 Connectivity and Privacy in WebRTC", draft-schwartz- 257 rtcweb-return-03 (work in progress), September 2014. 259 [I-D.wing-tram-turn-mobility] 260 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 261 "Mobility with TURN", draft-wing-tram-turn-mobility-02 262 (work in progress), September 2014. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 268 Relays around NAT (TURN): Relay Extensions to Session 269 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 271 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 272 Layer Security (DTLS) as Transport for Session Traversal 273 Utilities for NAT (STUN)", RFC 7350, August 2014. 275 6.2. Informative References 277 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 278 (ICE): A Protocol for Network Address Translator (NAT) 279 Traversal for Offer/Answer Protocols", RFC 5245, April 280 2010. 282 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 283 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 285 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 286 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 287 October 2008. 289 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 290 Security Version 1.2", RFC 6347, January 2012. 292 Authors' Addresses 294 Prashanth Patil 295 Cisco Systems, Inc. 296 Bangalore 297 India 299 Email: praspati@cisco.com 301 Tirumaleswar Reddy 302 Cisco Systems, Inc. 303 Cessna Business Park, Varthur Hobli 304 Sarjapur Marathalli Outer Ring Road 305 Bangalore, Karnataka 560103 306 India 308 Email: tireddy@cisco.com 310 Gonzalo Salgueiro 311 Cisco 312 7200-12 Kit Creek Road 313 Research Triangle Park, NC 27709 314 US 316 Email: gsalguei@cisco.com