rtcweb-wg / ip-handling Goto Github PK
View Code? Open in Web Editor NEWWebRTC IP Address Handling Requirements
WebRTC IP Address Handling Requirements
It might be useful to be more clear that this is an OS command (not a protocol
one). If the particular semantics of this command are relevant, that should be
noted as well.
You could just add “Unix” or “Unix-like” to before “connect”, or refer to these calls as “bind()” and “connect()”.
It is important that these are the semantics of Unix-like sockets; other APIs may not have a corresponding mechanism. Further, the UDP source address might change later (i.e., in TCP the “connect” always forces a static source IP address selected at the initiation of the TCP connection; in UDP, there’s no need for this to happen only once at the time the “connect()” is issued.
Sounds good.
#2 is considered to be a less significant concern, given that the
local address values often contain minimal information (e.g.,
192.168.0.2), or have built-in privacy protection (e.g., the
[RFC4941] IPv6 addresses recommended by
[I-D.ietf-rtcweb-transports]).That's a bit confused. There is nothing local about RFC4941 addresses;
they are global. They are correctly called "temporary" addresses, because
their only privacy property is that they change from time to time.
And they have nothing to do with #2 which is about "being behind a NAT",
because whether they are revealed or not is independent of whether there's
a NAT in the path. From that point of view they are just like any other
globally-routeable IPv6 address.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here.
Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
S 3.
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 will discover not only
This might be simpler if you said "route traffic over" rather than
"support routing"Also, do you want to say "may discover" because the guidelines below
would potentially stop that.
This is the problem statement section; I think it is expected that the proposed guidelines would invalidate some of the problem definition.
That said, I could get behind switching 'will' to 'can', as is used in S3, category #2.
S 6.2.
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.
6.2. Determining Host Candidates
This is framed a little confusingly, because all host candidates are
suitable in mode 1. Perhaps add "In modes XXX..."
This seems like a good addition.
COMMENT:
I agree with Ben about the STUN/TURN normativity.
Section 5.1
- By default, WebRTC should be able to negotiate direct peer-to-
peer connections between endpoints (i.e., without traversing a
NAT or relay server). [...]I'm not sure how to interpret "be able to", here, with respect to
"without traversing a NAT", since if one endpoint is behind a NAT w.r.t.
the public Internet, that's not possible.
There is an implicit "where possible" here. The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others' addresses; in this case, a direct connection should be possible, which implies that there needs to be some way for the two sides to share their machine addresses. Naturally, devices behind different NATs will not be able to do this.
Section 5.2
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.nit: we may not have left a big enough breadcrumb trail for the reader
to find "getUserMedia consent".
Noted.
(nit) §3: Please expand "RTMFP" on first mention.
(nit) §5.2: "Mode 1 MUST only be used when user consent has been provided"
Please consider "... MUST NOT be used unless user consent has been provided."
§11.2: It seems like the references for STUN and TURN should be normative.
S8: Perhaps a short sentence like the following one is a bit more
descriptive than the current text in the section. (Please feel free to
use your editorial discretion to disregard this comment, just that it
does not hurt to be explicit in standard documents. At least that is my
opinion.)This document has described leak of IP address privacy when WebRTC
engages in peer-to-peer connections. This document suggests
mitigations against the leak of this privacy in the form of
four different modes of WebRTC communications that explicitly guide
the WebRTC developer in making an informed choice on how private the
peer-to-peer communication should be.
Sure - happy to add text of this sort if we think it would be valuable.
Nits/editorial comments:
- S3: s/private physical/virtual/private physical or virtual/
- S3:
OLD:
...exposed upwards to the web application, so that they can be
communicated to the remote endpoint for its checks.
NEW:
...provided to the web application so they can be communicated to
the remote endpoint for connectivity checks.- S3: s/concerns, #1/concerns, the first/
(Similarly for other places where you have #2, etc. Better to be
pedantic and minimize colloquialism when writing RFCs.)
OK.
- S4: s/As a result, we want to avoid blunt solutions/As a result, the
preference is to avoid blunt solutions/
(Reason: Pronouns like "We" are fine for academic paper, but perhaps
avoided in RFCs.)
:-)
- S6.2:
- s/sent to the web application host/sent to the remote web application host/
- s/and TCP get the same routing/and TCP get the same routing treatment/
OK.
In Section 5.2 it states that:
"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. "
I'm not sure what "getUserMedia consent" refers to.
I can add a reference to security-arch, e.g. https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#section-6.2
Section 3
Not sure how the use of temporary addresses in IPv6 [RFC4941] is relevant at
all to a discussion of NAT usage (#2). Can you please clarify?"#2 is a less significant but valid concern. While the [RFC4941] IPv6
addresses recommended by [I-D.ietf-rtcweb-transports] are fairly
benign due to their intentionally short lifetimes"
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.