Encrypting ICE candidates to improve privacy and connectivity
draft-wang-mmusic-encrypted-ice-candidates-00
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Alex Drake , Justin Uberti , Qingsi Wang | ||
Last updated | 2020-05-04 (Latest revision 2019-11-01) | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections. To maximize the probability of a direct peer-to-peer connection, client private IP addresses can be included in this candidate collection, but this has privacy implications. This document describes a way to share local IP addresses with local peers without compromising client privacy. During the ICE process, local IP addresses are encrypted and authenticated using a pre-shared key and cipher suite before being put into ICE candidates as hostnames with an ".encrypted" pseudo-top- level domain. Other peers who also have the PSK are able to decrypt these addresses and use them normally in ICE processing.
Authors
Alex Drake
Justin Uberti
Qingsi Wang
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)