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

[Philip Matthews <[e-mail]>]

On Tue, 11-Nov-08, at 05:12 , Magnus Westerlund wrote:

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

Good catch.
Though port 9000 is allowed if the TURN server is running on a  
dedicated platform, I agree that the example is better if we don't  
assume this. I have fixed both Figures 1 and 2, changing the client  
and peer ports as well as the relayed-transport-address port in the  
examples to make sure they are in a sensible range. I have also  
updated the detailed example, since it uses the port numbers of Figure  
1.

The revised figure 1 looks as follows:

                                         Peer A
                                         Server-Reflexive    +---------+
                                         Transport Address   |         |
                                         192.0.2.150:32102   |         |
                                             |              /|         |
                           TURN              |            / ^|  Peer A |
     Client's              Server            |           /  ||         |
     Host Transport        Transport         |         //   ||         |
     Address               Address           |       //     |+---------+
    10.1.1.2:49721       192.0.2.15:3478     |+-+  //     Peer A
             |               |               ||N| /       Host Transport
             |   +-+         |               ||A|/        Address
             |   | |         |               v|T|      
192.168.100.2:49582
             |   | |         |               /+-+
  +---------+|   | |         |+---------+   /              +---------+
  |         ||   |N|         ||         | //               |         |
  | TURN    |v   | |         v| TURN    |/                 |         |
  | Client  |----|A|----------| Server  |------------------|  Peer B |
  |         |    | |^         |         |^                ^|         |
  |         |    |T||         |         ||                ||         |
  +---------+    | ||         +---------+|                |+---------+
                 | ||                    |                |
                 | ||                    |                |
                 +-+|                    |                |
                    |                    |                |
                    |                    |                |
              Client's                   |            Peer B
              Server-Reflexive    Relayed             Transport
              Transport Address   Transport Address   Address
              192.0.2.1:7000      192.0.2.15:50000     192.0.2.210:49191

                                  Figure 1


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

This situation can happen any time TCP transport is used between the  
client and the server, so it affect the base spec as well. I have  
added the following paragraph to the spec:

    When TCP or TLS over TCP transport is used between the client and  
the
    server, it is possible that a bit error will cause a length field in
    a TURN packet to become corrupted, causing the receiver to lose
    synchronization with the incoming stream of TURN messages.  A client
    or server which detects a long sequence of invalid TURN messages  
over
    TCP or TLS over TCP transport SHOULD close the corresponding TCP
    connection to help the other end detect this situation more rapidly.



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

As agreed to in the recent BEHAVE session at Minneapolis, the spec now  
contains the following description of the attack and its mitigation:

17.1.7.  TURN loop attack

    An attacker might attempt to cause data packets to loop indefinitely
    between two TURN servers.  The attack goes as follows.  First, the
    attacker sends an Allocate request to server A, using the source
    address of server B. Server A will send its response to server B,  
and
    for the attack to succeed, the attacker must have the ability to
    either view or guess the contents of this response, so that the
    attacker can learn the allocated relayed-transport-address.  The
    attacker then sends an Allocate request to server B, using the  
source
    address of server A. Again, the attacker must be able to view or
    guess the contents of the response, so it can send learn the
    allocated relayed-transport-address.  Using the same spoofed source
    address technique, the attacker then binds a channel number on  
server
    A to the relayed-transport-address on server B, and similarly binds
    the same channel number on server B to the relayed-transport-address
    on server A. Finally, the attacker sends a ChannelData message to
    server A.

    The result is a data packet that loops from the relayed-transport-
    address on server A to the relayed-transport-address on server B,
    then from server B's transport address to server A's transport
    address, and then around the loop again.

    This attack is mitigated as follows.  By requiring all requests to  
be
    authenticated and/or by randomizing the port number allocated for  
the
    relayed-transport-address, the server forces the attacker to either
    intercept or view responses sent to a third party (in this case, the
    other server) so that the attacker can authenticate the requests and
    learn the relayed-transport-address.  Without one of these two
    measures, an attacker can guess the contents of the responses  
without
    needing to see them, which makes the attack much easier to perform.
    Furthermore, by requiring authenticated requests, the server forces
    the attacker to have credentials acceptable to the server, which
    turns this from an outsider attack into an insider attack and allows
    the attack to be traced back to the client initiating it.

    The attack can be further mitigated by imposing a per-username limit
    on the bandwidth used to relay data by allocations owned by that
    username, to limit the impact of this attack on other allocations.
    More mitigation can be achieved by decrementing the TTL when  
relaying
    data packets (if the underlying OS allows this).


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

This was in the text in this section in TURN-09, and I considered  
keeping it in TURN-11. However, in my opinion, the text in section 12  
of TURN-11 describes the forwarding behavior from the point-of-view of  
an application that sits on top of the OS, whereas the behavior you  
describe would be implemented by the OS itself. But, if you can  
provide me a reference to a section of an RFC that describes this  
behavior, I will be happy to insert the reference.

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

I have added a sentence discussing this to the discussion of Path MTU  
discovery in section 2.6:

     Note that, because the server does not relay ICMP messages,
     the client will have to use a Path MTU discovery algorithm
     based on 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.

Good catch -- the client must not only communicate the relayed- 
transport-address to the peers, but must also learn the (server- 
reflexive) IP addresses of the peers so that permissions can be  
installed for these addresses. Though this could conceivably be done  
by posting both values to webpages, this is somewhat unrealistic.

I have changed the text to read:

    A client using TURN must have some way to communicate the relayed-
    transport-address to its peers, and to learn each peer's IP address
    and port (more precisely, each peer's server-reflexive transport
    address, see Section 2).  How this is done is out of the scope of  
the
    TURN protocol.  One way this might be done is for the client and
    peers to exchange e-mail messages.  Another way is for the client  
and
    its peers to use a special-purpose 'introduction' or 'rendezvous'
    protocol (see [RFC5128] for more details).

    If TURN is used with ICE [I-D.ietf-mmusic-ice], then the relayed-
    transport-address and the IP addresses and ports of the peers are
    included in the ICE candidate information which the rendezvous
    protocol must carry.  For example, if TURN and ICE are used as part
    of a multimedia solution using SIP [RFC3261], then SIP serves the
    role of the rendezvous protocol, carrying the ICE candidate
    information inside the body of SIP messages.  If TURN and ICE are
    used with some other rendezvous protocol, then
    [I-D.rosenberg-mmusic-ice-nonsip] provides guidance on the services
    the rendezvous protocol must perform.


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

Thanks. Removed.

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

OK. I have changed the text to read as follows:

    Explicit Congestion Notification (ECN) field [RFC3168]

       Preferred Behavior: Set the outgoing value to the incoming value,
       UNLESS the server is doing Active Queue Management, the incoming
       ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server
       wishes to indicate that congestion has been experienced, in which
       case set the outgoing value to CE (=0b11).

       Alternate Behavior: Set the outgoing value to Not-ECT (=0b00).

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

I have inserted references to RFC 5389.

>
>
> Cheers
>
> Magnus Westerlund

- Philip
_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave