rtcweb-wg / ip-handling Goto Github PK

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

2. 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.