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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Dec 2007 17:45:40 -0500

This was not discussed in the WG meeting and had a brief discussion in 
the ad-hoc.

TURN currently says that a TURN server SHOULD only utilize ports in the 
range 1024-65535, avoiding the well-known ports from 1-1023. There was a 
request from Derek to make this a MUST. Note, however, that it is not 
this restriction, but the server behavior around permissions, which 
makes it impossible to run a general purpose server on a specific port.

Most everyone still felt SHOULD is fine. My litmus test for SHOULD vs. 
MUST is, would the protocol cease to interoperate, lose functionality, 
or otherwise not work if the SHOULD were not followed. That is clearly 
not the case here, so a SHOULD is appropriate.

Please respond if you agree (or if you don't).

Thanks,
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

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

---

From: "Derek MacDonald" <[email-masked]>
Date: Sat, 8 Dec 2007 15:48:34 -0800

I'm ok w/ this result.  I just thought a MUST was cleaner if we were trying
to make non-threatening.  I also don't think well known ports have much
meaning any more.

-Derek

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Dec 2007 15:02:27 +0200

On 2007-12-8, at 0:45, ext Jonathan Rosenberg wrote:
> TURN currently says that a TURN server SHOULD only utilize ports in  
> the range 1024-65535, avoiding the well-known ports from 1-1023.

Given that the registered port range extends from 1024-49151, TURN  
should limit itself to using the Private Ports from 49152-65535, in  
order to avoid using ports registered to other applications.

Lars (as an individual)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 00:15:24 -0500

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

-Jonathan R.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Dec 2007 11:09:47 +0200

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.

(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.)

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

Lars

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 18:00:19 -0500

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

> 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?

-Jonathan R.

---

From: Lars Eggert <[email-masked]>
Date: Sat, 15 Dec 2007 10:01:14 +0200

On 2007-12-15, at 1:00, ext Jonathan Rosenberg wrote:
> However, as with other SHOULDs, it gives conditions under which you  
> can violate this should. Then it talks about cases where no 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?

Yes, this is a good resolution.

Thanks,
Lars

---

From: Philip Matthews <[email-masked]>
Date: Mon, 17 Dec 2007 19:45:55 -0500

I like this resolution as well.
- Philip

On 15-Dec-07, at 03:01 , Lars Eggert wrote:

>> 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?
>