Subject: Regarding Turn channel in first octet demultiplex

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Nov 2017 14:41:12 +0800

Hi,

I wanted to follow up my comment at the mic today.

So the inclusion of the TURN channel space in the RFC 7983 
demultiplexing table is really to make some implementation choices easier.

So, many ICE implementation uses a single source port per interface 
(A:P1) . That source port is used both to send STUN connectivity checks 
(A:P1 -> C:P3) as well as TURN packets to a TURN server (A:P1 -> B:P2). 
The IP address of the TURN server is known. But, in context of ICE, it 
is not uncommon to receive STUN packets from previously unknown peer IP 
addresses (D:P4) that was sent to the client's NATed address (N:P9). 
Thus it is common to filter first on protocol then figure out what the 
information means for that address.

C A:P1 -----N:P9 -------> B:P2 (TURN server)
                  \
                   \----> C:P3 (Peer candidate address)
                    \
                     \--> D:P4 (Other Peer candidate address)

So, TURN channel demultiplexing is not needed if one restrict the 
implementation so that it first look at the source address of incoming 
IP/UDP packets and then use that to determine that it is STUN/TURN 
packets from the TURN server. But, it is restricting the implementation 
in a way that hasn't been common before.

 From my perspective, it is not important to maintain TURN channels in 
the demultiplexing.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Nov 2017 14:50:51 +0800

Thanks for the explanation Magnus.  I now understand the problem and
can see how this design could be advantageous.

On Tue, Nov 14, 2017 at 2:41 PM, Magnus Westerlund
<[email-masked]> wrote:
> So the inclusion of the TURN channel space in the RFC 7983 demultiplexing
> table is really to make some implementation choices easier.
>
> So, many ICE implementation uses a single source port per interface (A:P1) .
> That source port is used both to send STUN connectivity checks (A:P1 ->
> C:P3) as well as TURN packets to a TURN server (A:P1 -> B:P2). The IP
> address of the TURN server is known. But, in context of ICE, it is not
> uncommon to receive STUN packets from previously unknown peer IP addresses
> (D:P4) that was sent to the client's NATed address (N:P9). Thus it is common
> to filter first on protocol then figure out what the information means for
> that address.
>
> IP/UDP packets and then use that to determine that it is STUN/TURN packets
> from the TURN server. But, it is restricting the implementation in a way
> that hasn't been common before.
>
> From my perspective, it is not important to maintain TURN channels in the
> demultiplexing.
>
> Cheers
>
> Magnus Westerlund
>