Subject: [BEHAVE] TURN 07: Channel ID collisions with usage

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Feb 2008 14:32:26 +0100

Hi,

In the review of TURN 07 I found that the draft doesn't at all take care 
of a case I asked about previous.

The allocation response include the server reflexive address to the TURN 
client. The only reason for doing this is to enable a client to 
co-locate both a TURN client and a direct STUN+UDP based protocol, for 
example RTP, on the same port.

However, the TURN channel header has overlap with RTP thus causing a 
demultiplexing collision when channel numbers in the 8000-8FFF range is 
used.

This seriously need to be taken care of. I think the simplest thing is 
to stop co-locating the TURN client with anything else. And thus also 
the XOR-MAPPED-ADDRESS should not be returned in the allocate response 
either.

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

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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 29 Feb 2008 06:35:16 -0800

Hi Magnus,

The main motivation to return XOR-MAPPED-ADDRESS is so the client can  
issue one request which provides the equivalent of a STUN response  
and a TURN response at the same time.  Then ICE will usually pick the  
server reflexive address from XOR-MAPPED-ADDRESS instead of the  
relayed address, and either explicitly deallocate the relayed address  
or let it time out.

thanks,
-rohan

On Feb 29, 2008, at 5:32 AM, Magnus Westerlund wrote:

> Hi,
>
> In the review of TURN 07 I found that the draft doesn't at all take  
> care of a case I asked about previous.
>
> The allocation response include the server reflexive address to the  
> TURN client. The only reason for doing this is to enable a client  
> to co-locate both a TURN client and a direct STUN+UDP based  
> protocol, for example RTP, on the same port.
>
> However, the TURN channel header has overlap with RTP thus causing  
> a demultiplexing collision when channel numbers in the 8000-8FFF  
> range is used.
>
> This seriously need to be taken care of. I think the simplest thing  
> is to stop co-locating the TURN client with anything else. And thus  
> also the XOR-MAPPED-ADDRESS should not be returned in the allocate  
> response either.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Feb 2008 15:44:07 +0100

Rohan Mahy skrev:
> issue one request which provides the equivalent of a STUN response and a 
> TURN response at the same time.  Then ICE will usually pick the server 
> reflexive address from XOR-MAPPED-ADDRESS instead of the relayed 
> address, and either explicitly deallocate the relayed address or let it 
> time out.

But my point is that you can't reliable demultiplex TURN with channel 
bindings and RTP/UDP being delivered directly to the port. Thus if one 
use TURN to get both a relayed and server reflexive candidate in ICE one 
can shoot oneself in the foot unless one have completed ICE and 
deallocated the other candidate prior to doing a channel binding.

This needs to be resolved somehow!

>> TURN client. The only reason for doing this is to enable a client to 
>> demultiplexing collision when channel numbers in the 8000-8FFF range 
>> is used.
>>

-- 

Magnus Westerlund

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 29 Feb 2008 07:19:16 -0800

Hi Magnus,

With this feature, there is no multiplexing of TURN and another  
protocol.

A softphone application on Alice's PC goes sends a TURN Allocate  
Request through her home NAT to turn.example.net.  She takes the  
RELAYED-ADDRESS and the XOR-MAPPED-ADDRESS and puts these in ICE  
candidates in an offer that she sends to Bob's UA.  She could have  
also sent a STUN Binding Request to stun.example.net instead to get  
the XOR-MAPPED-ADDRESS, but that would require an additional  
transaction for Alice's UA.

This convenience feature has nothing to do with ICE connectivity  
checks which are different STUN requests sent either directly to  
Alice's UA or forwarded through a relayed address used by Alice on  
the TURN server.  ICE does not suggest in any way that Alice or Bob  
will accept *TURN* requests on the same port used for RTP.

Does this make sense?

thanks,
-rohan

On Feb 29, 2008, at 6:44 AM, Magnus Westerlund wrote:
> Rohan Mahy skrev:
>> Hi Magnus,
>> The main motivation to return XOR-MAPPED-ADDRESS is so the client  
>> can issue one request which provides the equivalent of a STUN  
>> response and a TURN response at the same time.  Then ICE will  
>> usually pick the server reflexive address from XOR-MAPPED-ADDRESS  
>> instead of the relayed address, and either explicitly deallocate  
>> the relayed address or let it time out.
>
> But my point is that you can't reliable demultiplex TURN with  
> channel bindings and RTP/UDP being delivered directly to the port.  
> Thus if one use TURN to get both a relayed and server reflexive  
> candidate in ICE one can shoot oneself in the foot unless one have  
> completed ICE and deallocated the other candidate prior to doing a  
> channel binding.
>
>>> In the review of TURN 07 I found that the draft doesn't at all  
>>> take care of a case I asked about previous.
>>>
>>> The allocation response include the server reflexive address to  
>>> the TURN client. The only reason for doing this is to enable a  
>>> client to co-locate both a TURN client and a direct STUN+UDP  
>>> based protocol, for example RTP, on the same port.
>>>
>>> However, the TURN channel header has overlap with RTP thus  
>>> causing a demultiplexing collision when channel numbers in the  
>>> 8000-8FFF range is used.
>>>
>>> This seriously need to be taken care of. I think the simplest  
>>> thing is to stop co-locating the TURN client with anything else.  
>>> And thus also the XOR-MAPPED-ADDRESS should not be returned in  
>>> the allocate response either.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Feb 2008 10:36:16 -0500

Magnus:

Thanks for point out this issue, which I had not previously  
considered. As I see it, there are a number of ways that a client can  
solve this problem:

1) Since the choice of channel numbers is totally under the control  
of the client, the client can avoid channel numbers that make  
demuxing a problem. In the case of RTP, this would mean that the  
client should avoid channel numbers that have the first two bits as  
either 00 or 10 (the first is used by STUN and the second is used by  
RTP). This still leaves 2^31 possible channel numbers. For  
application protocols other than RTP, the client may have to avoid  
other channel numbers.

2) If the client knows that, for a given call, its peers will either  
all use the direct path or all use the TURN server, then it can  
simply wait to allocate channel numbers until it knows which case it  
is dealing with. If all peers are going via the TURN server, then  
there can be no conflict with the application protocol (e.g. RTP)  
since all application protocol packets arrive at the client  
encapsulated inside either a Data indication or a ChannelData  
message, so all channel numbers except those starting with 00 can be  
used.

3) If the client is dealing with an application protocol where the  
demux problem is harder (for example, a protocol which allows  
arbitrary values in the first 32 bits), then the client must use a  
different client transport address to talk to the TURN server. In  
this case, the XOR-MAPPED-ADDRESS in the Allocate response is not  
useful.

On a separate thread, we are discussing whether ESP falls into case (3).

In terms of the document, I suggest adding text that basically says  
the above. I would make it general (i.e., not specific to RTP), but  
we could add an appendix that discusses the issue for certain  
specific application protocols.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Feb 2008 10:48:53 -0500

> will accept *TURN* requests on the same port used for RTP.

This is not quite true. If the client tries to use the same transport  
address for both direct connections and indirect connections via the  
TURN server, then the client will receive 4 different types of  
packets on the same transport address:
1) STUN-formatted TURN packets
2) STUN connectivity packets from the peer
3) RTP packets
4) ChannelData messages

The client can demux these by looking at the first two bits in the  
packets:
00 - Packet is either case (1) or (2), and must be further demuxed by  
looking at the source transport address
01 - Packet is a ChannelData message
10 - Packet is an RTP packet
11 - Packet is a ChannelData message
This only works if the client refrains from using channel numbers  
that start with 10.

- Philip

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Feb 2008 16:45:03 +0100

Rohan Mahy skrev:
> Hi Magnus,
> 
> With this feature, there is no multiplexing of TURN and another protocol.
> 
> A softphone application on Alice's PC goes sends a TURN Allocate Request 
> through her home NAT to turn.example.net.  She takes the RELAYED-ADDRESS 
> and the XOR-MAPPED-ADDRESS and puts these in ICE candidates in an offer 
> that she sends to Bob's UA.  She could have also sent a STUN Binding 
> Request to stun.example.net instead to get the XOR-MAPPED-ADDRESS, but 
> that would require an additional transaction for Alice's UA.
> 
> This convenience feature has nothing to do with ICE connectivity checks 
> which are different STUN requests sent either directly to Alice's UA or 
> forwarded through a relayed address used by Alice on the TURN server.  
> ICE does not suggest in any way that Alice or Bob will accept *TURN* 
> requests on the same port used for RTP.
> 
> Does this make sense?

Okay, take 3 to explain my headache. Alice's PC sends a TURN allocate 
request from port P on interface X to turn.example.net. It gets back two 
addresses: R:rp and S:sp, i.e. a relayed and a server reflexive address 
that both has X:P as base for them.

This have the implications that when BOB sends his STUN checks to R:rp 
they will arrive at X:P in either a DATA indication or with a 
channelbinding header. BOB can also send his STUN check to S:sp that 
arrives at X:P without a TURN header. So far no major problems. The X:P 
can demultiplex directly arriving STUN requests and the ones that first 
goes to the TURN client. But we also have the capability to handle data 
on this socket. In fact one could illustrate the multiplexing like this:

                         /-- Data receiver
                        /
        /- TURN Client ---- STUN Server
       /
X:P ----- STUN server
       \
        \- Data receiver

The issue is that a RTP data receiver both would like to have data with 
payloads starting with 10 in the first octet. Thus you are unable to 
decide what the correct demultiplexing in this case is, at least as long 
as you are using channelID in the 8000-8FFF range with RTP.

Do you now see the issue?

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Feb 2008 16:47:38 +0100

Philip Matthews skrev:
> Magnus:
> 
> Thanks for point out this issue, which I had not previously considered. 
> As I see it, there are a number of ways that a client can solve this 
> problem:
> 
> 1) Since the choice of channel numbers is totally under the control of 
> the client, the client can avoid channel numbers that make demuxing a 
> problem. In the case of RTP, this would mean that the client should 
> avoid channel numbers that have the first two bits as either 00 or 10 
> (the first is used by STUN and the second is used by RTP). This still 
> leaves 2^31 possible channel numbers. For application protocols other 
> than RTP, the client may have to avoid other channel numbers.
> 
> 2) If the client knows that, for a given call, its peers will either all 
> use the direct path or all use the TURN server, then it can simply wait 
> to allocate channel numbers until it knows which case it is dealing 
> with. If all peers are going via the TURN server, then there can be no 
> conflict with the application protocol (e.g. RTP) since all application 
> protocol packets arrive at the client encapsulated inside either a Data 
> indication or a ChannelData message, so all channel numbers except those 
> starting with 00 can be used.
> 
> 3) If the client is dealing with an application protocol where the demux 
> problem is harder (for example, a protocol which allows arbitrary values 
> in the first 32 bits), then the client must use a different client 
> transport address to talk to the TURN server. In this case, the 
> XOR-MAPPED-ADDRESS in the Allocate response is not useful.
> 
> In terms of the document, I suggest adding text that basically says the 
> above. I would make it general (i.e., not specific to RTP), but we could 
> add an appendix that discusses the issue for certain specific 
> application protocols.
> 

Yes, I think it is important to point out the issue clearly. I think 
another thing that the client can do is to not use channelbindings until 
one has promoted a single candidate and closed down the other 
multiplexing points. First when this is accomplished can one start using 
channelbindings.

Cheers

Magnus Westerlund

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Feb 2008 11:49:00 -0500

On Fri, 29-Feb-08, at 10:47 , Magnus Westerlund wrote:
> I think another thing that the client can do is to not use  
> channelbindings until one has promoted a single candidate and  
> closed down the other multiplexing points. First when this is  
> accomplished can one start using channelbindings.

I am sorry, but I don't see why binding a channel before a candidate  
is promoted could be a problem. Would you explain a bit more?

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Feb 2008 15:30:31 -0500

On Fri, 29-Feb-08, at 10:36 , Philip Matthews wrote:
> RTP). This still leaves 2^31 possible channel numbers.

Correction: "This still leaves 2^15 (32K) channel numbers." Channel  
numbers are only 16 bits long.
                                ====
- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Feb 2008 16:56:05 -0500

I had thought that the client would FIRST demux packets from the TURN 
server, vs. those not from the TURN server. For stuff coming from the 
TURN server, it is always TURN or channeldata, and we know how to demux 
that. For stuff not coming from the TURN server, its never channeldata, 
and never TURN; it can be RTP or STUN. ANd those are easy to demux.

So I think this needs to be explained but I see no need to constrain 
channel numbers or any other such thing.

Think of what would happen in the case of tcp from client to turn 
server; everything over that connection is clearly TURN and treated as 
such. Just do the same for UDP.

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://www.ietf.org/mailman/listinfo/behave