Subject: Re: [BEHAVE] TURN Issue #5: Port Range

From: Philip Matthews <[email-masked]>
Date: Mon, 14 Jan 2008 17:34:32 -0500

On 14-Dec-07, at 18:00 , Jonathan Rosenberg wrote:

>
>
> Lars Eggert wrote:
>> On 2007-12-14, at 7:15, ext Jonathan Rosenberg wrote:
>>> This would put a serious dent in the capacity of a TURN server.  
>>> As far as I know there is nothing that actually breaks by reusing  
>>> the registered ports for a dynamic allocation.
>> If TURN grabs a port that my app has registered, I can't run my  
>> app on the TRUN server. Preventing this is exactly why port  
>> registries exist.
>
> As you state below, my assumption is that TURN is the only thing  
> running. Or, if there are things, they are known and probably up  
> and running before the TURN process starts (like SNMP).
>
>> (A minor related issue is that if TURN uses a port registered to  
>> my app, and there are firewalls that have rules for my app based  
>> on that port, the TURN traffic will get that treatment.)
>
> Well, we can have a conversation on the efficacy of port-based  
> treatment of traffic in a firewall. But I do agree firewalls do  
> block specific ports.
>
>>> Since TURN can't be used to run traditional servers, and the IP  
>>> and port must be exchanged with peers through a rendezvous  
>>> protocol, the typical issue of port conflict doesn't come up.  
>>> What am I missing?
>> I think you assume that the TURN server will be the only thing  
>> running on an IP address. That's not a safe assumption.
>
> Right.
>
> OK, so how about this.
>
> The spec says SHOULD be limited to the dynamic range as you  
> suggest. However, as with other SHOULDs, it gives conditions under  
> which you can violate this should. Then it talks about cases where  
> no other applications run on the server, and where firewalls aren't  
> blocking ports, and if you know these aren't problems it is OK to  
> grab other ports. This would allow vendors of standalone TURN  
> servers to use the full range since both of these conditions exist  
> there. However, if TURN is run in an endpoint like a p2psip peer,  
> it would use the more limited range, which is fine anyway for that  
> use case.
>
> Sound OK?

As I read this over again, I see an issue that I hadn't seen before.

Say a TURN server allocates a port P in the Registered port range.  
How can the TURN server know that one or more peers are not behind  
firewalls that block access to this port?

So I don't see the firewall part of this SHOULD condition.

- Philip

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 15 Jan 2008 09:31:19 +0200

> firewalls that block access to this port?

It cannot. Don't even try to solve the problem.

Yes, some registered ports are routinely firewalled. The Battle.net ports and 
the Valve/Steam games ports are good examples from the registered port range. 
So is any port that has been used by a well publicized trojan horse.

If your peer cannot reach some registered ports, your peer is broken. You will 
have the same problem whether you use plain SIP (or plain XMPP), or STUN or 
TURN or UPnP or NAT-PMP or anything.

The only solution is to run everything on port TCP/443 over TLS, if you want 
to be sure your peer can reach you.

> So I don't see the firewall part of this SHOULD condition.

No. I don't think it's very appropriate for TURN to specify firewalling. Even 
if it did, it would not really help anyway.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 15 Jan 2008 09:52:16 -0500

After thinking about this for a bit, and taking Remi's comments into  
account, I have come up with the following proposed text for this:

    The server SHOULD only allocate ports from the range 49152 - 65535
    (the Dynamic and/or Private Port range [IANA]), unless the following
    conditions are met:

    o  The TURN server application knows, through some means not
       specified here, that other applications running on the same host
       as the TURN server application will not be impacted by allocating
       ports outside this range, AND

    o  The TURN server application believes, through some means not
       specified here, that firewalls between it and any peers are
       unlikely to block the port allocated.

    The first condition can often by satisfied by running the TURN  
server
    application on a dedicated machine and/or by arranging that any  
other
    applications allocate ports before the TURN server application
    starts.  The second condition is harder to satisfy, but
    administrators MAY decide that certain ports outside the Dynamic
    and/or Private Port range are unlikely to be blocked by firewalls  
and
    are thus safe to use for TURN allocations.  In any case, the TURN
    server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-
    Known Port range) to discourage clients from using TURN to run
    standard services.

Comments?

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 15 Jan 2008 18:02:20 +0200

>     (the Dynamic and/or Private Port range [IANA]), unless the following

Makes sense, though I expect servers will rather allocate from the locally 
configured dynamic port ranges (many OSes have this as configurable values).

>        unlikely to block the port allocated.

On the Internet, the TURN server can now for sure that this is false for any 
given port. That makes no sense to me.

It is already too big a restriction for a TURN server to know a non-firewalled 
ports range for its clients. It is pretty impossible to know a non-firewalled 
ports range for its client's peers.

I repeat, you cannot fix this problem with any dynamic port allocation scheme. 
Some firewalls do block the ephemeral port range, e.g. to prevent traceroute.

> Comments?

I think the only solution to the firewalled ports issue is would be to 
allocate a fixed port (or set thereof) for whatever protocol you want to run.

In the case of TURN, and NAT traversal this is simply impossible. If the peer 
has a restrictive firewalling ruleset, it's its duty to use a TURN or SOCKS 
server or anything on its side, to work around the problem. In my humble 
opinion, there is no need to specify anything, *and* specifying anything 
around this issue would be useless.

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jan 2008 12:28:36 -0500

inline:

>       unlikely to block the port allocated.

I think the right wording here is that the administrator believes that 
the firewalls in its own administrative domain are unlikely to block 
this port - thats the best we can do. I think its also worth nothing 
that there is basically NO way to know what your peer's firewalls may 
block; that this is highly variable. It is something to consider but it 
is not something that recommendations can be made on.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Philip Matthews <[email-masked]>
Date: Tue, 15 Jan 2008 15:55:07 -0500

I think we are all saying the same thing: to wit, there is no way to  
know for sure which ports are blocked by firewalls between the server  
and the peers.

I tried to capture this in the following sentence (which you cut off  
in your reply):
                          The second condition is harder to satisfy, but
    administrators MAY decide that certain ports outside the Dynamic
    and/or Private Port range are unlikely to be blocked by firewalls  
and
    are thus safe to use for TURN allocations.

- Philip

On 15-Jan-08, at 12:28 , Jonathan Rosenberg wrote:

> inline:
>
> Philip Matthews wrote:
>> After thinking about this for a bit, and taking Remi's comments  
>> into account, I have come up with the following proposed text for  
>> this:
> I think the right wording here is that the administrator believes  
> that the firewalls in its own administrative domain are unlikely to  
> block this port - thats the best we can do. I think its also worth  
> nothing that there is basically NO way to know what your peer's  
> firewalls may block; that this is highly variable. It is something  
> to consider but it is not something that recommendations can be  
> made on.
>
> -Jonathan R.
> --

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jan 2008 20:29:15 -0800

>      unlikely to block the port allocated.

I think you should drop all the text on firewalls - there is no more  
guarantee that port 49153 will get through any given firewall than  
port 49150. The topic of the firewalls is an operation concern and not  
a protocol specification issue here - the fact that the firewall has  
to be configured to allow access to ports the TURN server needs to use  
barely seems worth mentioning.  The harm in this text is that it  
requires TURN server to not use a large portion of the address space.  
I suspect you are going outside what Lars was looking for here - you  
might want to sync up with him.

Cullen with my individual contributor hat on

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Jan 2008 17:26:03 +0100

Cullen Jennings skrev:
> guarantee that port 49153 will get through any given firewall than port 
> 49150. The topic of the firewalls is an operation concern and not a 
> protocol specification issue here - the fact that the firewall has to be 
> configured to allow access to ports the TURN server needs to use barely 
> seems worth mentioning.  The harm in this text is that it requires TURN 
> server to not use a large portion of the address space. I suspect you 
> are going outside what Lars was looking for here - you might want to 
> sync up with him.
> 

I think I have to agree with Cullen here. I supports Lars's 
recommendation to first use the dynamic range. And I think the proposed 
text minus the firewall related will be sufficient around this.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 12:05:14 -0500

A number of people have now told me, either publicly or privately,  
that they would be happy with the text if I simply removed the  
discussion on firewalls. So here is my revised text:

    The server SHOULD only allocate ports from the range 49152 - 65535
    (the Dynamic and/or Private Port range [Port-Numbers]), unless the
    TURN server application knows, through some means not specified  
here,
    that other applications running on the same host as the TURN server
    application will not be impacted by allocating ports outside this
    range.  This condition can often be satisfied by running the TURN
    server application on a dedicated machine and/or by arranging that
    any other applications on the machine allocate ports before the TURN
    server application starts.  In any case, the TURN server SHOULD NOT
    allocate ports in the range 0 - 1023 (the Well-Known Port range) to
    discourage clients from using TURN to run standard services.

Comments?

- Philip