Magnus: Why TURN channels were included in RFC 7983 multiplexing

[aboba]

Comment from Magnus describing why TURN channel multiplexing is not relevant:
https://www.ietf.org/mail-archive/web/quic/current/msg02471.html

---------- Forwarded message ----------
From: Magnus Westerlund [email protected]
Date: Mon, Nov 13, 2017 at 10:41 PM
Subject: Regarding Turn channel in first octet demultiplex
To: IETF QUIC WG [email protected]

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