Subject: RE: [Ietf-behave] TURN Issue #6: port numbers

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Dec 2005 18:00:53 -0800 (PST)

I agree.

I think it facilitates integration of STUN server and TURN server on
Enterprise Firewalls.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jonathan Rosenberg
> Sent: Monday, December 05, 2005 12:34
> To: Behave
> Subject: [Ietf-behave] TURN Issue #6: port numbers
> 
> 
> Right now, TURN has no default port. Its marked as XXXX in the spec. 
> With the view that TURN would be a stun usage, its not clear that it 
> needs a separate port from the STUN port. The only reason to 
> have that 
> is if folks think there is a desire from firewall admins to 
> block TURN 
> by disabling its port, but allow STUN. There are a few options here:
> 
> 1. TURN will reuse the STUN default port. DNS procedures also 
> exist to 
> detect the udp, tcp, etc. ports for STUN/TURN, but they are 
> always shared.
> 
> 2. TURN has a separate default port. DNS procedures also 
> exist to detect 
> the udp, tcp, etc. ports for STUN, and there is also a procedure to 
> detect them for TURN. This would be done by defining a separate NAPTR 
> service for Allocate requests.
> 
> 3. TURN will reuse the STUN default port. DNS procedures also 
> exist to 
> detect the udp, tcp, etc. ports for STUN, and there is also a 
> procedure 
> to detect them for TURN. This would be done by defining a 
> separate NAPTR 
> service for Allocate requests.
> 
> 4. TURN has a separate default port, and there are no DNS procedures 
> defined at all for STUN or TURN. This would imply a specific 
> solution to 
> the TLS problem in Issue #5 (in particular, would imply no DNS-based 
> solutions). Why do this? The only reason is to force usage of 
> TURN over 
> a specific port since no discovery mechanism would exist. This would 
> facilitate firewall port-blocking. Of course, its easily circumvented 
> through configuration of the TURN port (which is what is done today), 
> but its an option.
> 
> 
> I tend to prefer #1 for simplicity. Unless there is a compelling 
> argument brought about why the TURN and STUN requests NEED to run on 
> different ports, I see no reason for anything else.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 14 Dec 2005 12:07:12 -0800 (PST)

Yes, you are right. I keep forgetting TURN uses the same port on the
server 
for signaling and media.

I guess we'll have to use the magic cookie thing. 

> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
> Sent: Wednesday, December 14, 2005 11:44
> To: Audet, Francois [SC100:9T51:EXCH]; Jonathan Rosenberg; Behave
> Subject: Re: [Ietf-behave] TURN Issue #6: port numbers
> 
> 
> 
> Hmm - I might be missing what you are saying. The signaling 
> would be over the same TCP flow as the media on that side of 
> the turn server.
> 
> 
> On 12/14/05 8:25 AM, "Francois Audet" <audet@xxxxxxxxxx> wrote:
> 
> > You mean the same signalling port, right, not the same tunnelled 
> > packets?
> > 
> > Being on the same signalling port makes sense. For 
> tunnelled packets, 
> > probably not.
> > 
> >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Cullen 
> >> Jennings
> >> Sent: Tuesday, December 13, 2005 19:35
> >> To: Jonathan Rosenberg; Behave
> >> Subject: Re: [Ietf-behave] TURN Issue #6: port numbers
> >> 
> >> 
> >> 
> >> If STUN and TURN are on the same port, it make it much harder to 
> >> right rate limiting rules for them. I don't know if this 
> matters much 
> >> but worth a bit of thought.
> >> 
> >> 
> >> On 12/5/05 12:33 PM, "Jonathan Rosenberg" 
> <jdrosen@xxxxxxxxx> wrote:
> >> 
> >>> needs a separate port from the STUN port. The only reason
> >> to have that
> >>> 1. TURN will reuse the STUN default port. DNS procedures
> >> also exist to
> >>> detect the udp, tcp, etc. ports for STUN/TURN, but they 
> are always 
> >>> shared.
> >>> 
> >>> 2. TURN has a separate default port. DNS procedures also exist to 
> >>> procedure to detect them for TURN. This would be done by 
> defining a 
> >>> separate NAPTR service for Allocate requests.
> >>> 
> >>> 3. TURN will reuse the STUN default port. DNS procedures
> >> also exist to
> >>> procedure to detect them for TURN. This would be done by 
> defining a 
> >>> separate NAPTR service for Allocate requests.
> >>> 
> >>> defined at all for STUN or TURN. This would imply a
> >> specific solution
> >>> to the TLS problem in Issue #5 (in particular, would imply no 
> >>> DNS-based solutions). Why do this? The only reason is to
> >> force usage
> >>> of TURN over a specific port since no discovery mechanism
> >> would exist.
> >>> This would facilitate firewall port-blocking. Of course, 
> its easily 
> >>> circumvented through configuration of the TURN port (which
> >> is what is
> >>> done today), but its an option.
> >>> 
> >>> 
> >> _______________________________________________
> >> Ietf-behave mailing list