Re: [BEHAVE] WGLC: TURN and TURN-IPv6 (draft-ietf-behave-turn-11, draft-ietf-behave-turn-ipv6-05)

[Magnus Westerlund <[e-mail]>]

Dan Wing skrev:
> BEHAVE is initiating working group last call (WGLC) on TURN and TURN-IPv6.
> This is the first WGLC for these documents.  The WGLC will finish in three
> weeks on Friday, November 28.  Please send comments to the BEHAVE mailing
> list, [e-mail].
> 
>   * draft-ietf-behave-turn-11.txt 
>     http://tools.ietf.org/html/draft-ietf-behave-turn-11

Here is my review of the TURN main spec. I have some comments:

1. In figure 2, shouldn't the allocation return a port from the dynamic
range? Using the CSlistener port (9000) may be interpreted in this case
to have meaning and also don't follow the recommenation.

2. Section 11: Channel data bit-error vulnerability. For stream
transport there seems to be a bit-error vulnerability. If an error gets
through the internet checksum and strikes the length field then the
receiver will become out of synch with the sender and only provide
garbage packets. To me it looks like there is no possibility to get into
synch other than closing the TCP connection and restart from scratch.
This issue seems to belong in the TURN TCP spec but the text here might
prevent certain type of solutions.

3. TURN Loop attack:

This seems to be a bad attack, but not that simple to perform.
Prerequisite for the attack is the following:
- Two Turn servers A and B
- If the servers require authentication the attacker (C) needs valid
credentials on each of them.
- C needs to be able to spoof source address of IP/UDP packets
- C need to be able to read the response from both servers when sending
spoofed request to either of A and B
- At least one the TURN servers implement the alternative TTL behavior

Attack flow:
1. C->A: Allocation Request (Src=B's server transport address)
2. A->B: Allocation response (C needs allocation address) B receives the
 response which lacks context.
3. C->B: Allocation Request (Src=A's server transport address)
4. B->A: Allocation Response (C needs allocation address)
5. C->A: Channelbinding request Src=B (Channelnr=X,
Peer-address=Allocation on B)
6. C->B: Channelbinding request Src=A (channelnr=X,
Peer-address=Allocation on A)
7. C->A: Channeldata with channel nr =X and Src=B

If one is allowed to setup this loop then the data packet in step 7 will
loop until it is lost or bindings timeout. Due to the following process:

1. arriving at A's server transport address it contains channelnr=X.
2. A sends out the packet without the channelheader to B's relayed address.
3. Packet arrive at B's relayed address
4. Packet sent by B to A's server transport address with a Channel
header with channel number X
5. Return to 1

Thus amplification of this attack is in theory infinite but depends on
the packet drop rate and that at least one of the TURN server use the
alternative TTL behavior. But for a modest continued flow of spoofed
data packets and channel and allocation refresh this data loop can
maintained at high load for the servers.

To me it seems the obvious mitigation to this attack is to disallow the
5-tuple remote IP-address to equal any peer IP address. This will
potentially create problems if IP addresses are shared. And it will also
fail as mitigation when you have IPv4 and IPv6 capable TURN relays.
Because then you have one data leg over IPv4 and one over IPv6
preventing the matching operation to be done. Mitigation would also fail
if the TURN server uses multiple IP addresses.

Another mitigation for this attack is to have traffic policiers in the
the relay that discard unusual high traffic volumes over any allocation.

I also found an alternative version of this attack that requires that
one guess what the allocation is going to be on one of the servers. In
fact if one can guess the allocation and the server doesn't require
authorization from the client then this attack can be setup by an
off-path attacker. Which seems to be a really serious attack. Should we
consider mandating the usage of authorization? As a minimum we need to
be clear that this risk exist.

I also think we should be clearer on the recommendation for
randomization of the port in the allocation. In this case port
randomization is reasonably strong. As you need to close the loop for
the attack to be effective you need to correctly setup state that
include the guess of each TURN server allocation. So for each attempt to
build a loop you need to correct guess both ports and then build a
channel towards each of the allocation on the other server. So the
number of channels needed to be setup on each server becomes N^2. The
question here is how big N is and that depends on the TURN servers
allocation policy and how hard is it is to guess what possible port
number ones allocation gets.

4. Section 12: IPv4 fragmentation field:

I think the preferred behavior needs to mention the need to refuse
sending a packet if it requires fragmentation and the DF was set on the
incoming packet. Which also includes the need to generate an ICMP
message. This should never happen in the client to peer direction but
may happen in the reverse direction due to the encapsulation.

5. The Don't Fragment mechanism should have a explicit mention that it
will not get a ICMP message for the packet, instead it may be lost due
to the DF setting. Thus path MTU discovery using this mechanism needs to
implement a mechanism like the one in RFC 4821.

6. Section 1:

   A client using TURN must have some way to communicate the relayed-
   transport-address to its peers.  How this is done is out of the scope
   of the TURN protocol.  One way this might be done is for the client
   to post the relayed-transport-address up on a web page.  Another way
   is for the client to send an e-mail message containing the relayed-
   transport-address to its peers.  A third way is for the client and
   its peers to use a special-purpose 'introduction' or 'rendezvous'
   protocol (see [RFC5128] for more details).

I think the first two ways really works. There needs to be a two way
communication channel between the TURN client and the Peer. Email would
allow for a return channel, but not the webpage.


Editorial:

E1. Figure 1:
Seem to have some remnant of a width checking bar.

E2. Section 12, ECN:
I think the text should use the names Congestion Experienced (CE),
ECN-Capabalt Transport ECT) for the code-points.

E3. Section 14.3 and 14.5: Please put in a reference to where
XOR-MAPPED-ADDRESS is defined.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave