1100121 - A way to make WebRTC STUN more friendly to port forwarding.

Status: NEW

(Core :: WebRTC: Networking, enhancement, P5)

Description

[Mario Carbajal]

I'm developing a multiplayer game using WebRTC. I depend on users being able to connect using STUN ICE candidates alone, which is sadly quite unreliable. TURN isn't an option because of latency requirements.
 
It's very common for users behind a NAT to have access to the port forwarding settings of their routers. If there was a way for users to make WebRTC try a specific port range, they could use port forwarding to greatly improve the chance of a successful connection.
 
For example, a browser setting "preferred WebRTC port range" that does the following:
When the browser gets a STUN ICE candidate it adds that candidate as normal. However, it also creates a new candidate with the same IP address but changes the port to one inside the preferred range.

Comment 1

[Eric Rescorla (:ekr)]

Are you talking about remote or local candidates. If the former, you
can just do the surgery yourself in JS.

If the latter, I'm not sure how well this would work, but in any case
you should submit it to the webrtc working group, since we generally
try to implement the standard. See:

http://www.w3.org/2011/04/webrtc/

Comment 2

[Mario Carbajal]

(In reply to Eric Rescorla (:ekr) from comment #1)
> Are you talking about remote or local candidates. If the former, you
> can just do the surgery yourself in JS.
> 
> If the latter, I'm not sure how well this would work, but in any case
> you should submit it to the webrtc working group, since we generally
> try to implement the standard. See:
> 
> http://www.w3.org/2011/04/webrtc/

Just modifying the remote ice candidates would not be enough, since WebRTC would not be listening in those ports on the other end. Unless I'm missing something?

Comment 3

[Eric Rescorla (:ekr)]

That's what I assumed as well, but I was just making sure. You need to engage
with the W3C group to move this forward.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

I would suggest this is not a W3 API issue at the core - it's a local network configuration issue, which depends on the user configuring a port-forward range and telling the UA about that.  I can't see a useful way for the W3 spec to speak to this other than to mention this might be a good idea to support in UAs.  It's not in any way specific to the application, nor can the browser do anything about it at the application's request (except maybe tell you if the user configured a preferred range, which still doesn't help the application to know).

This is very common in SIP devices that don't depend on SBCs, doubly so for those with STUN support but not TURN or ICE support.

I.e. it's the rough equivalent to a local TURN server for a organization sitting at their firewall.

For users with symmetric firewalls (and that includes a lot), this can be a major win in reduced latency and setup time (avoiding needing to use a TURN relay).

The NAT rule would be something like "forward 7000-7999 UDP to 192.168.1.100", and then a browser config that says "preferred WebRTC port range".  This is something of a power-user feature, but could be useful both for businesses and for users who can go manage to do router config (which with online guides is in the reach of a fair number of people, and many in certain communities that care about this, like games).

Comment 5

[Mario Carbajal]

I think my idea of how to solve it was overcomplicated.

Instead of creating extra ice candidates with modified ports, it would be sufficient to just have the option to limit the port range with which the browser communicates with the STUN/TURN server.

Users could then set the limit to a reasonably sized range and configure their routers to port forward that range to them. I believe routers will leave the source port untouched for outgoing messages if they are being sent by the destination of the forward rule. Which means the STUN server would produce ICE candidates in the forwarded range as desired.

Comment 6

[Eric Rescorla (:ekr)]

(In reply to Mario Carbajal from comment #5)
> I think my idea of how to solve it was overcomplicated.
> 
> Instead of creating extra ice candidates with modified ports, it would be
> sufficient to just have the option to limit the port range with which the
> browser communicates with the STUN/TURN server.
> 
> Users could then set the limit to a reasonably sized range and configure
> their routers to port forward that range to them. I believe routers will
> leave the source port untouched for outgoing messages if they are being sent
> by the destination of the forward rule. Which means the STUN server would
> produce ICE candidates in the forwarded range as desired.

Anything that requires users to manually configure their browsers seems
like it's going to be a fairly low-leverage proposition.

Comment 7

[Mario Carbajal]

I've found this open issue in chromium: https://code.google.com/p/chromium/issues/detail?id=342476
Although it's intended for enterprise this is exactly the thing I last suggested.

about:config could have media.webrtc.minport media.webrtc.maxport

How things are now, users with routers that don't play well with NAT punch-through are doing things like enabling DMZ with their computers as host, this solves makes the connections succeed but makes their computers more vulnerable to attacks. Port forwarding an udp port range would be a lot more secure.

Comment 8

[Maire Reavy [:mreavy]]

Note: would be relatively easy technically; if the config vars exist in about:config it becomes easy to write an extension that gives UI for setting them (better than about:config).

Comment 9

[Luca Barbato]

The issue had been fixed already in Chrome.

Would be nice to have this fixed in Firefox and possibly provide a mean to set a port range in the js code.

Comment 10

[Nils Ohlmeier [:drno]]

Attachment: Bug 1100121: allow setting a min and max port range for TCP ports

Review commit: https://reviewboard.mozilla.org/r/132566/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/132566/

Comment 11

[Nils Ohlmeier [:drno]]

Comment on attachment 8860548 [details]
Bug 1100121: allow setting a min and max port range for TCP ports

Do you think this is good enough?

Comment 12

[Byron Campen [:bwc]]

Comment on attachment 8860548 [details]
Bug 1100121: allow setting a min and max port range for TCP ports

https://reviewboard.mozilla.org/r/132566/#review137730

::: media/mtransport/third_party/nICEr/src/ice/ice_component.c:341
(Diff revision 1)
>      _status=0;
>  abort:
>      return(_status);
>    }
>  
> +static int nr_ice_component_get_port_from_range(uint16_t *port)

I think this would be simpler and easier to understand if we treated the |max| as inclusive here. That way we could use UINT16_MAX and avoid the special case for 0.

::: media/mtransport/third_party/nICEr/src/ice/ice_component.c:371
(Diff revision 1)
> +
> +    if (max) {
> +      *port = min + (*port % (max - min));
> +    }
> +    else {
> +      *port |= min;

Huh?

Comment 13

[Byron Campen [:bwc]]

Comment on attachment 8860548 [details]
Bug 1100121: allow setting a min and max port range for TCP ports

MozReview doesn't seem to grok feedback...

Comment 14

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.