Subject: [BEHAVE] Getting pairs of ports for RTP using TURN

From: Cullen Jennings <[email-masked]>
Date: Mon, 28 Jan 2008 19:18:40 -0800

RTP has an unfortunately design attribute that in some cases it  
expects the RTCP to be on the odd port above the RTP and RTP to be on  
an even port. We don't have other protocols like this and I really  
doubt we would want to design things this way in the future but none  
the less, there is a strong desire for TURN to support all forms of  
RTP including this. This leads to the need for a TURN client to be  
able to request an even port number in it's allocations and also for a  
TURN client to be able to request a pair of ports for use with RTP.

Another key design principal of TURN has been to maximize the odds the  
firewall administrators allowing it thought he firewall by not  
subverting the will of the firewall admins which will simply result in  
it being blocked. One of the aspects of this has been to not allow  
TURN to be used to run general purpose servers without the consent of  
the firewall admin.

The 06 draft is a bit broken with respect to all this but I have a  
proposal that I think would be very easy to implement, would  
simultaneously meet all these concerns, and is pretty easy to  
understand.

My suggestion is that we remove the REQUEST-PORTS-PROPS and REQUEST-IP  
and add add two new attributes. REQUEST-EVEN-PORT and REQUEST-PORT- 
PAIR. Neither of these have any data and the presence of them is  
simply treated as a flag by the TURN server. Only one of them should  
be in a request. The REQUEST-EVEN-PORT causes the server to only  
allocate an even port. The REQUEST-PORT-PAIR causes the server to  
allocate a consecutive even port and the odd port that is one greater.  
The response returns the even port that was allocated along with ODD- 
PORT-PAIR-TOKEN attribute that caries a 32 bit identifier. When the  
client receives this token, it can perform another allocate that  
includes the ODD-PORT-PAIR-TOKEN. The server will recognize that the  
same user is requesting an allocation with the TOKEN that pairs it  
with the previous allocation and the TURN server will  return the odd  
port that was allocated with the previous even port.

The TURN server needs to ensure that it reserves the port pair for at  
least 30 seconds after the initial allocation and that it only  
allocates the port to a ALLOC request that was made by the same user  
as the initial allocation and where the request has the token that was  
returned in the original ALLOC. The token does not need to have any  
security properties - anyone can see it - the server can use an  
incrementing counter if it wishes. The security comes from only giving  
out the port to a user with the same credentials as the client that  
made the initial request. The token is purely used as a way of helping  
a client that is performing multiple allocations associated the  
correct pairs of allocations together.

Cullen <with my individual contributor hat on>

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 29 Jan 2008 09:27:11 -0500

I like this proposal. I think it gives us what we need without adding  
extra complexity.

I have one small suggested change. I suggest that the ODD-PORT-PAIR- 
TOKEN be a random number and perhaps be 64 bits rather than 32. This  
is because I feel it is likely that some organizations will pass out  
the same credentials (i.e., username and password) to a large number  
of devices.

- Philip

On 28-Jan-08, at 22:18 , Cullen Jennings wrote:

> expects the RTCP to be on the odd port above the RTP and RTP to be  
> on an even port. We don't have other protocols like this and I  
> really doubt we would want to design things this way in the future  
> but none the less, there is a strong desire for TURN to support all  
> forms of RTP including this. This leads to the need for a TURN  
> client to be able to request an even port number in it's  
> allocations and also for a TURN client to be able to request a pair  
> of ports for use with RTP.
>
> Another key design principal of TURN has been to maximize the odds  
> the firewall administrators allowing it thought he firewall by not  
> subverting the will of the firewall admins which will simply result  
> in it being blocked. One of the aspects of this has been to not  
> allow TURN to be used to run general purpose servers without the  
> consent of the firewall admin.
>
> My suggestion is that we remove the REQUEST-PORTS-PROPS and REQUEST- 
> IP and add add two new attributes. REQUEST-EVEN-PORT and REQUEST- 
> PORT-PAIR. Neither of these have any data and the presence of them  
> is simply treated as a flag by the TURN server. Only one of them  
> should be in a request. The REQUEST-EVEN-PORT causes the server to  
> only allocate an even port. The REQUEST-PORT-PAIR causes the server  
> to allocate a consecutive even port and the odd port that is one  
> greater. The response returns the even port that was allocated  
> along with ODD-PORT-PAIR-TOKEN attribute that caries a 32 bit  
> identifier. When the client receives this token, it can perform  
> another allocate that includes the ODD-PORT-PAIR-TOKEN. The server  
> will recognize that the same user is requesting an allocation with  
> the TOKEN that pairs it with the previous allocation and the TURN  
> server will  return the odd port that was allocated with the  
> previous even port.
>
> The TURN server needs to ensure that it reserves the port pair for  
> at least 30 seconds after the initial allocation and that it only  
> allocates the port to a ALLOC request that was made by the same  
> user as the initial allocation and where the request has the token  
> that was returned in the original ALLOC. The token does not need to  
> have any security properties - anyone can see it - the server can  
> use an incrementing counter if it wishes. The security comes from  
> only giving out the port to a user with the same credentials as the  
> client that made the initial request. The token is purely used as a  
> way of helping a client that is performing multiple allocations  
> associated the correct pairs of allocations together.
>
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 29 Jan 2008 07:37:44 -0800

Cullen Jennings wrote:
> 
> RTP has an unfortunately design attribute that in some cases it expects
> the RTCP to be on the odd port above the RTP and RTP to be on an even
> port. We don't have other protocols like this and I really doubt we
> would want to design things this way in the future but none the less,
> there is a strong desire for TURN to support all forms of RTP including
> this. This leads to the need for a TURN client to be able to request an
> even port number in it's allocations and also for a TURN client to be
> able to request a pair of ports for use with RTP.
> 
> it being blocked. One of the aspects of this has been to not allow TURN
> to be used to run general purpose servers without the consent of the
> firewall admin.
> 
> simultaneously meet all these concerns, and is pretty easy to understand.
> 
> and add add two new attributes. REQUEST-EVEN-PORT and REQUEST-PORT-PAIR.
> Neither of these have any data and the presence of them is simply
> treated as a flag by the TURN server. Only one of them should be in a
> request. The REQUEST-EVEN-PORT causes the server to only allocate an
> even port. The REQUEST-PORT-PAIR causes the server to allocate a
> consecutive even port and the odd port that is one greater. The response
> returns the even port that was allocated along with ODD-PORT-PAIR-TOKEN
> attribute that caries a 32 bit identifier. When the client receives this
> token, it can perform another allocate that includes the
> ODD-PORT-PAIR-TOKEN. The server will recognize that the same user is
> requesting an allocation with the TOKEN that pairs it with the previous
> allocation and the TURN server will  return the odd port that was
> allocated with the previous even port.

I am not sure to understand how that it is better than the current text,
assuming that REQUESTED-IP and REQUEST-PORTS-PROPS with specific port
can only refer to an IP address/port allocated previously by the same
user on the same tuple as the second port of a pair.

Also the REQUESTED-IP attribute alone permitted to request a port on a
specific IP address on a TURN server that have multiple interfaces.  I
do not know if there is SIP endpoints that are broken in presence of SDP
with different IP addresses for different m= lines, but the REQUESTED-IP
would help to fix this.

> least 30 seconds after the initial allocation and that it only allocates
> the port to a ALLOC request that was made by the same user as the
> initial allocation and where the request has the token that was returned
> in the original ALLOC. 

The problem of the 30 seconds is that an additional timer is needed in
the implementation.  Why do not just reserve the port for the duration
of the allocation?

> The token does not need to have any security
> properties - anyone can see it - the server can use an incrementing
> counter if it wishes. The security comes from only giving out the port
> to a user with the same credentials as the client that made the initial
> request. The token is purely used as a way of helping a client that is
> performing multiple allocations associated the correct pairs of
> allocations together.
> 
> 

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 29 Jan 2008 22:29:29 +0000

> of ports for use with RTP.

While I don't doubt that there are many RTP implementations that  
still require port pairs, RFC 3605 is over four years old now. The  
TURN draft should make it clear that the ability to request odd or  
even port numbers is for backwards compatibility only, and that new  
RTP implementations need to be more flexible in how they allocate and  
signal ports (i.e. they SHOULD use RFC 3605 mechanisms to signal the  
port, and ideally should multiplex RTP and RTCP onto the same port as  
outlined in draft-ietf-avt-rtp-and-rtcp-mux-07.txt -- with the RFC  
Editor now).

-- 
Colin Perkins
http://csperkins.org/

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Jan 2008 15:43:26 -0800

Sure. I choose 32 bits fairly arbitrarily and see no problems with  
using 64 bits. It's not a way I had imagined using it but I agree, If  
we want to use it tis way in some cases, then I agree 32 bits would be  
too small.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Jan 2008 15:43:42 -0800

On Jan 29, 2008, at 2:29 PM, Colin Perkins wrote:

> RTP implementations need to be more flexible in how they allocate  
> and signal ports (i.e. they SHOULD use RFC 3605 mechanisms to signal  
> the port, and ideally should multiplex RTP and RTCP onto the same  
> port as outlined in draft-ietf-avt-rtp-and-rtcp-mux-07.txt -- with  
> the RFC Editor now).

I completely agree - I should have been clearer about that.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Jan 2008 15:56:46 -0800

Good questions - inline ...

On Jan 29, 2008, at 7:37 AM, Marc Petit-Huguenin wrote:

> expects
> the
> TURN
> PAIR.

My experience has been that UA that support audio and video have a  
pretty high degree of being ok with different IP address in the m  
lines for these. This is because some of the common conferencing  
mixers to have different IPs for the audio mixer and video mixer so if  
you want to work with these audio/video conferencing systems you UA  
needs to support that.

That said, if folks feel there is a need to be able to say "please put  
this allocation on the same IP as a previous allocation", I'm fine to  
work out a way to do that. Thoughts on if we have real example where  
we need that or not?
> at
> allocates

I should have been clearer here. I choose the "at least 30 seconds"  
way or wording this so that an implementation could choose to just  
have it valid for the length of the original allocation if it wished  
to implement it that way.

I would like to have something that is implementable without adding  
more timers because timers seem to always be a hassle. I can also  
imagine an implementation could be done by just having a time-stamp  
with the allocation record, and when the 2nd allocate came along, the  
code could check if the current time was within 30 seconds of original  
time stamp. At the same time the reserved ports that had not been  
allocated yet could be kept in a list and when trying to find a new  
port, the oldest entry on the list could be reused as long as it was  
older than 30 seconds.  This would allow the ports to be "freed" if  
they were not going to be used after 30 seconds and they were needed  
for other allocations and still not require a timer.