WebRTC IP Address Handling Requirements
RFC 8828

Document Type RFC - Proposed Standard (January 2021; No errata)
Author Justin Uberti 
Last updated 2021-01-18
Replaces draft-shieh-rtcweb-ip-handling
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Sean Turner
Shepherd write-up Show (last changed 2018-04-11)
IESG IESG state RFC 8828 (Proposed Standard)
Action Holders
(None)
Consensus Boilerplate Yes
Telechat date
Responsible AD Adam Roach
Send notices to Sean Turner <sean@sn3rd.com>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions


Internet Engineering Task Force (IETF)                         J. Uberti
Request for Comments: 8828                                        Google
Category: Standards Track                                       G. Shieh
ISSN: 2070-1721                                             January 2021

                WebRTC IP Address Handling Requirements

Abstract

   This document provides information and requirements for how IP
   addresses should be handled by Web Real-Time Communication (WebRTC)
   implementations.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8828.

Copyright Notice

   Copyright (c) 2021 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Problem Statement
   4.  Goals
   5.  Detailed Design
     5.1.  Principles
     5.2.  Modes and Recommendations
   6.  Implementation Guidance
     6.1.  Ensuring Normal Routing
     6.2.  Determining Associated Local Addresses
   7.  Application Guidance
   8.  Security Considerations
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Authors' Addresses

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
   Protocol (HTTP) [RFC7230].  This may be problematic in certain cases.
   This document summarizes the concerns and makes recommendations on
   how WebRTC implementations should best handle the trade-off between
   privacy and media performance.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Problem Statement

   In order to establish a peer-to-peer connection, WebRTC
   implementations use Interactive Connectivity Establishment (ICE)
   [RFC8445].  ICE attempts to discover multiple IP addresses using
   techniques such as Session Traversal Utilities for NAT (STUN)
   [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] and
   then checks the connectivity of each local-address-remote-address
   pair in order to select the best one.  The addresses that are
   collected usually consist of an endpoint's private physical or
   virtual addresses and its public Internet addresses.

   These addresses are provided to the web application so that they can
   be communicated to the remote endpoint for its checks.  This allows
   the application to learn more about the local network configuration
   than it would from a typical HTTP scenario, in which the web server
   would only see a single public Internet address, i.e., the address
   from which the HTTP request was sent.

   The additional information revealed falls into three categories:

   1.  If the client is multihomed, additional public IP addresses for
       the client can be learned.  In particular, if the client tries to
       hide its physical location through a Virtual Private Network
       (VPN), and the VPN and local OS support routing over multiple
       interfaces (a "split-tunnel" VPN), WebRTC can discover not only
       the public address for the VPN, but also the ISP public address
       over which the VPN is running.

   2.  If the client is behind a Network Address Translator (NAT), the
       client's private IP addresses, often [RFC1918] addresses, can be
       learned.

   3.  If the client is behind a proxy (a client-configured "classical
Show full document text