idnits 2.17.1 draft-reddy-tram-turn-ipaddress-privacy-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 4, 2015) is 3367 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) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-10 == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-01 == Outdated reference: A later version (-06) exists of draft-schwartz-rtcweb-return-04 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track Cisco 5 Expires: August 8, 2015 February 4, 2015 7 IP address privacy by TURN server 8 draft-reddy-tram-turn-ipaddress-privacy-00 10 Abstract 12 A TURN server allocates an IP address for a user. If this address is 13 dis-associated from the user's actual network, the allocated IP 14 address increases the user's privacy. This document describes a 15 means for an client to discover that the TURN server can provide IP 16 address privacy. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 8, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 54 3. IP address privacy determination procedure . . . . . . . . . 3 55 3.1. The ADDRESS-PRIVACY attribute in request . . . . . . . . 4 56 3.2. The ADDRESS-PRIVACY attribute in response . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Disclosing a host's IP address and connected network's IP address can 68 disclose the user's location or network connection point, which is a 69 privacy concern. These addresses are disclosed during normal 70 operation of WebRTC [I-D.ietf-rtcweb-overview]. To prevent this 71 disclosure, the local address (called "host address" by ICE 72 [RFC5245]) and the connected network's IP address (called "server 73 reflexive" by ICE) cannot be disclosed to the remote peer. Instead, 74 only the address allocated by a TURN (Traversal Using Relays around 75 NAT) [RFC5766] server is disclosed to the remote peer. However, if 76 the TURN server is dedicated to a specific network (e.g., it is 77 deployed by a network operator for the sole use of users on that 78 network), that TURN server will similarly leak information about the 79 user's connected network. 81 Using any of the discovery mechanisms described in 82 [I-D.ietf-tram-turn-server-discovery], a client may discover multiple 83 Traversal Using Relays around NAT (TURN) servers. The TURN servers 84 discovered could be provided by an enterprise network, an access 85 network, an application service provider or a third party provider. 86 Therefore, the client needs to be able to choose a TURN server that 87 can provide IP address privacy. 89 The ADDRESS-PRIVACY attribute introduced in this specification can be 90 used by the client to determine if the TURN server can provide IP 91 address privacy from the remote peer. 93 This technique also solves the following other problems: 95 o User may or may not trust the calling service or WebRTC 96 application. [I-D.ietf-rtcweb-security-arch] discusses users 97 using privacy techniques like Tor so that malicious calling 98 service does not learn the user's IP address. The Poker example 99 given in section 4 of [I-D.ietf-rtcweb-security-arch]discusses 100 that the users in the call do not trust the calling service. In 101 this scenario if the user wants IP address privacy then the TURN 102 server provided by the calling service must be avoided and the 103 client must only select a TURN server whose authenticity can be 104 ascertained and can offer IP address privacy. 106 o Enterprise Firewall policy typically has a white-list of permitted 107 outside applications/sites and can blacklist HTTP(S) connections 108 via various forms of detections (DNS lookup, ALPN, HTTP URL 109 Filtering, DPI proxy that at least performs HTTPS inspection of 110 SNI in TLS exchange and validates SSL records, HTTP(S) proxy 111 etc.). Firewall in this configuration would block TCP/UDP 112 connection to external peers in the Internet and arbitrary TURN 113 servers. For example firewall would block usage of STUN with 114 external peers and force the clients to use enterprise provided 115 TURN server for all external WebRTC media communications. 116 Enterprise network could leverage firewall and TURN services 117 provided by a third party provider. If the third party offered 118 TURN server can provide IP address privacy then the application 119 can avoid TURN-in-TURN mechanism discussed in 120 [I-D.schwartz-rtcweb-return] and thus avoid the overhead of using 121 RETURN proxying. 123 2. Notational Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 This note uses terminology defined in STUN [RFC5389]. 131 3. IP address privacy determination procedure 133 If a client wants IP address privacy, it includes the ADDRESS-PRIVACY 134 attribute in its TURN Allocate request. If the server can provide IP 135 address privacy then it would echo back ADDRESS-PRIVACY attribute in 136 the Allocate response. 138 This specification defines a new comprehension-optional STUN 139 attribute ADDRESS-PRIVACY will have a STUN Type TBD-CA. This type is 140 in the comprehension-optional range, which means that TURN servers 141 can safely ignore the attribute if they do not understand it. 143 3.1. The ADDRESS-PRIVACY attribute in request 145 This attribute is used by the client to ask the server if it can 146 provide IP address privacy. This attribute has no value part and 147 thus the attribute length field is 0. 149 3.2. The ADDRESS-PRIVACY attribute in response 151 When a server receives a STUN request that includes a ADDRESS-PRIVACY 152 attribute, it processes the request as per the STUN specification 153 [RFC5389] plus the specific rules mentioned here. The server checks 154 the following: 156 o If the ADDRESS-PRIVACY attribute is not recognized, ignore the 157 attribute because its type indicates that it is comprehension- 158 optional. This should be the existing behavior as explained in 159 section 3.1 of [RFC5389]. 161 o If the server can provide IP address privacy then it will include 162 ADDRESS-PRIVACY attribute in the response. 164 o If the server determines that the relayed address it will allocate 165 and client IP address are in the same geolocation then the server 166 will redirect the client to another server that can provide IP 167 address privacy by replying to the request message with an error 168 response with error code 300 (Try Alternate). (TBD: Is there a 169 need for privacy levels ? (same country different town, same 170 continent different country, different continent etc)). 172 o If the server cannot provide IP address privacy or does not want 173 to provide IP address privacy then it will ignore this attribute. 175 4. IANA Considerations 177 [Paragraphs in braces should be removed by the RFC Editor upon 178 publication] 180 [The ADDRESS-PRIVACY attribute requires that IANA allocate a value in 181 the "STUN attributes Registry" from the comprehension-optional range 182 (0x8000-0xBFFF), to be replaced for TBD-CA throughout this document] 184 This document defines the ADDRESS-PRIVACY STUN attribute, described 185 in Section 3. IANA has allocated the comprehension-optional 186 codepoint TBD-CA for this attribute. 188 5. Security Considerations 190 It is possible the TURN server provides inadequate IP address privacy 191 to meet the client's needs. For example, the TURN server might be 192 located in the same city as the client, but the client wants to 193 obfuscate its location to the same continent or to a different 194 continent or a different planet. The client should find its 195 geolocation using server-reflexive candidate. The client should also 196 determine the geolocation of the relayed address learned from the 197 TURN server and compare with its geolocation to determine if the TURN 198 server is indeed providing IP address privacy. 200 Security considerations discussed in [RFC5766] are to be taken into 201 account. 203 6. Acknowledgements 205 Thanks to Dan Wing and Pal Martinsen for the review and comments. 207 7. References 209 7.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 215 (ICE): A Protocol for Network Address Translator (NAT) 216 Traversal for Offer/Answer Protocols", RFC 5245, April 217 2010. 219 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 220 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 221 October 2008. 223 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 224 Relays around NAT (TURN): Relay Extensions to Session 225 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 227 7.2. Informative References 229 [I-D.ietf-rtcweb-overview] 230 Alvestrand, H., "Overview: Real Time Protocols for 231 Browser-based Applications", draft-ietf-rtcweb-overview-13 232 (work in progress), November 2014. 234 [I-D.ietf-rtcweb-security-arch] 235 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 236 rtcweb-security-arch-10 (work in progress), July 2014. 238 [I-D.ietf-tram-turn-server-discovery] 239 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 240 Discovery", draft-ietf-tram-turn-server-discovery-01 (work 241 in progress), January 2015. 243 [I-D.schwartz-rtcweb-return] 244 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 245 (RETURN) for Connectivity and Privacy in WebRTC", draft- 246 schwartz-rtcweb-return-04 (work in progress), November 247 2014. 249 Authors' Addresses 251 Tirumaleswar Reddy 252 Cisco Systems, Inc. 253 Cessna Business Park, Varthur Hobli 254 Sarjapur Marathalli Outer Ring Road 255 Bangalore, Karnataka 560103 256 India 258 Email: tireddy@cisco.com 260 Prashanth Patil 261 Cisco Systems, Inc. 262 Bangalore 263 India 265 Email: praspati@cisco.com