--- 1/draft-ietf-rtcweb-ip-handling-05.txt 2018-03-01 18:13:08.886487789 -0800 +++ 2/draft-ietf-rtcweb-ip-handling-06.txt 2018-03-01 18:13:08.914488456 -0800 @@ -1,19 +1,19 @@ Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track G. Shieh -Expires: August 15, 2018 Facebook - February 11, 2018 +Expires: September 2, 2018 Facebook + March 1, 2018 WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-05 + draft-ietf-rtcweb-ip-handling-06 Abstract This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 15, 2018. + This Internet-Draft will expire on September 2, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,27 +48,29 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5 6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 6 + 6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 6 + 6.2. Determining Host Candidates . . . . . . . . . . . . . . . 6 7. Application Guidance . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 11.2. Informative References . . . . . . . . . . . . . . . . . 7 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction One of WebRTC's key features is its support of peer-to-peer connections. However, when establishing such a connection, which involves connection attempts from various IP addresses, WebRTC may allow a web application to learn additional information about the user compared to an application that only uses the Hypertext Transfer @@ -207,88 +209,101 @@ Mode 2: Default route + associated local addresses: WebRTC MUST follow the kernel routing table rules, which will typically cause media packets to take the same route as the application's HTTP traffic. In addition, the private IPv4 and IPv6 addresses associated with the kernel-chosen interface MUST be discovered and provided to the application. This ensures that direct connections can still be established in this mode. Mode 3: Default route only: This is the the same as Mode 2, except - that the associated private addressses MUST NOT be provided; + that the associated private addresses MUST NOT be provided; the only IP addresses gathered are those discovered via mechanisms like STUN and TURN (on the default route). This may cause traffic to hairpin through a NAT, fall back to an application TURN server, or fail altogether, with resulting quality implications. Mode 4: Force proxy: This is the same as Mode 3, but all WebRTC media traffic is forced through a proxy, if one is configured. If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy. Use of TCP will result in reduced media quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. - The recommended defaults are as follows: - - Mode 1 MUST only be used when user consent has been provided; this - allows trusted WebRTC applications to achieve optimal network - performance, but significanly limites the network information exposed - to arbitrary web pages. The details of this consent are left to the - implementation; one potential mechanism is to tie this consent to - getUserMedia consent. + Mode 1 MUST only be used when user consent has been provided. The + details of this consent are left to the implementation; one potential + mechanism is to tie this consent to getUserMedia consent. In cases where user consent has not been obtained, Mode 2 SHOULD be - used. This allows applications to still achieve direct connections - in many cases, even without consent (e.g., streaming or data channel - applications). However, implementations MAY choose a stricter - default policy in certain circumstances. + used. - Note that these defaults can still be used even for organizations - that want all external WebRTC traffic to traverse a proxy, simply by - setting an organizational firewall policy that allows WebRTC traffic - to only leave through the proxy. This provides a way to ensure the - proxy is used for any external traffic, but avoids the performance - issues of Mode 4 (where all media is forced through said proxy) for - intra-organization traffic. + These defaults provide a reasonable tradeoff that permits trusted + WebRTC applications to achieve optimal network performance, but gives + applications without consent (e.g., 1-way streaming or data channel + applications) only the minimum information needed to achieve direct + connections, as defined in Mode 2. However, implementations MAY + choose stricter modes if desired, e.g., if a user indicates they want + all WebRTC traffic to follow the default route. + + Note that the suggested defaults can still be used even for + organizations that want all external WebRTC traffic to traverse a + proxy, simply by setting an organizational firewall policy that + allows WebRTC traffic to only leave through the proxy. This provides + a way to ensure the proxy is used for any external traffic, but + avoids the performance issues associated with Mode 4 (where all media + is forced through said proxy) for intra-organization traffic. 6. Implementation Guidance This section provides guidance to WebRTC implementations on how to implement the policies described above. +6.1. Ensuring Normal Routing + When trying to follow typical IP routing, the simplest approach is to - bind the sockets used for p2p connections to the wildcard addresses - (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC - traffic the same way as it would HTTP traffic. STUN and TURN will - work as usual, and host candidates can be determined as mentioned - below. + bind the sockets used for peer-to-peer connections to the wildcard + addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to + route WebRTC traffic the same way as it would HTTP traffic. STUN and + TURN will work as usual, and host candidates can still be determined + as mentioned below. - In order to discover the correct local IP addresses, implementations - can use the common trick of binding sockets to the wildcard - addresses, connect()ing those sockets to the IPv4/IPv6 addresses of - the web application (obtained by resolving the host component of its - URI [RFC3986]) and then reading the bound local addresses via - getsockname(). This requires no data exchange; it simply provides a - mechanism for applications to retrieve the desired information from - the kernel routing table. +6.2. Determining Host Candidates - Use of the web application IPs ensures the right local IPs are - selected, regardless of where the application is hosted (e.g., on an - intranet). If the client is behind a proxy and cannot resolve the - IPs via DNS, the IPv4/v6 addresses of the proxy can be used instead. - If the web application was loaded from a file:// URI [RFC8089], the - implementation can fall back to a well-known DNS name or IP address. + When binding to a wildcard address, some extra work is needed to + determine a suitable host candidate, which we define as the source + address that would be used for any packets sent to the web + application host (assuming that UDP and TCP get the same routing). + Use of the web application host as a destination ensures the right + source address is selected, regardless of where the application + resides (e.g., on an intranet). + + First, the appropriate remote IPv4/IPv6 address is obtained by + resolving the host component of the web application URI [RFC3986]. + If the client is behind a proxy and cannot resolve these IPs via DNS, + the address of the proxy can be used instead. Or, if the web + application was loaded from a file:// URI [RFC8089], rather than over + the network, the implementation can fall back to a well-known DNS + name or IP address. + + Once a suitable remote IP has been determined, the implementation can + create a UDP socket, bind it to the appropriate wildcard address, and + tell it to connect to the remote IP. Generally, this results in the + socket being assigned a local address based on the kernel routing + table, without sending any packets over the network. + + Finally, the socket can be queried using getsockname() or the + equivalent to determine the appropriate host candidate. 7. Application Guidance The recommendations mentioned in this document may cause certain WebRTC applications to malfunction. In order to be robust in all scenarios, the following guidelines are provided for applications: o Applications SHOULD deploy a TURN server with support for both UDP and TCP connections to the server. This ensures that connectivity can still be established, even when Mode 3 or 4 are in use, @@ -377,20 +391,26 @@ Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, . Appendix A. Change log + Changes in draft -06: + + o Clarify recommendations. + + o Split implementation guidance into two sections. + Changes in draft -05: o Separated framework definition from implementation techniques. o Removed RETURN references. o Use origin when determining local IPs, rather than a well-known IP. Changes in draft -04: