Re: Restrict local UDP ports in browser "advanded settings"

On 10/15/2013 08:14 AM, Iñaki Baz Castillo wrote:
> 2013/10/14 Harald Alvestrand <harald@alvestrand.no>:
>> On 10/14/2013 06:34 AM, Iñaki Baz Castillo wrote:
>>
>> Hi,
>>
>> I have public IP in my computer which runs some UDP daemons (i.e. a
>> SIP server). I don't want to expose such a SIP server to all the world
>> so I set iptables to block incoming UDP traffic (unless it is in
>> response to UDP traffic send from my computer to the exact origin of
>> the incoming one).
>>
>> The problem is that with WebRTC I must be able to listen in any local
>> UDP port, and thus I cannot set iptables.
>>
>>
>>> WebRTC initialization should always begin with an ICE packet coming from
>>> your computer.
>>> Doesn't it work to set "related" for UDP?
>>>
>>> http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS shows some
>>> description (and says that the default timeout is 180 seconds, which should
>>> be enough for WebRTC's choice of keepalives).
>
> Hi Harald, perhaps I did not explain well. Let me expose a REAL case:
>
> - Alice's browser with public IP.
>
> - Bob's browser behind NAT.
>
> - Alice runs a SIP server in its computer, and blocks incoming UDP
> traffic to port 5060 unless it comes for some trusted IPs.
>
> - So Alice does not want to expose its UDP 5060 to all the world.
>
> - Alice neither wants to expose all its UDP ports to the world, but
> just 10000-10100 for WebRTC, and leave others for other purposes.
>
>
> Now imagine that Alice blocks all the incoming UDP traffic (yes I
> know, it would not block the "related" incoming traffic):
>
> - Alice and Bob start ICE stuff.

>
> - Alice cannot reach Bob (behind NAT).
>
> - Bob cannot reach Alice (iptables).
>
> - No ICE success.
> 

Here's where I get lost.

"ICE stuff" means:

- Bob does the usual UNSAF dance (STUN with a STUN server) and gets to
know an external IP and port where he can possibly be reached.  He
packages this into a "candidate" and sends it to Alice.

- Alice sends Bob an UDP packet (first ICE packet). This is allowed by
its firewall, since it's an outgoing packet. This may or may not get to
Bob (in fact it's likely to get there, since Bob already did the STUN
dance, but it doesn't matter for this argument).

- Bob sends Alice an UDP packet (Bob's first ICE packet, or a later
retransmission). It comes from the source port that Alice just sent a
packet to, and goes to the destination port that Alice just sent a
packet from.

- Bob's UDP packet hits Alice's iptables. It's classified as "related".

Now, does Alice's firewall allow this because it's "related" (no
problem), or block it because it's an UDP packet (a problem)?

This cannot work if Bob's behind a "symmetric NAT" (per-destination
portmapper). But in that case, STUN candidates basically don't work
anyway; you need TURN.


>
> This is, it seems that WebRTC is made by assuming that all the
> browsers are behind NAT. That is not true, and will be even less true
> when IPv6 arrives. And people with public IP should not just leave all
> the UDP ports open (because there is people running UDP services in
> personal computers).
>
> And thus, the need for rtp-port-min and rtp-port-max in browser settings.
>
> Regards.
>
>
>


-- 
Surveillance is pervasive. Go Dark.

Received on Tuesday, 15 October 2013 06:49:11 UTC