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

From: "Dan Wing" <[email-masked]>
Date: Thu, 6 Nov 2008 08:23:02 -0800

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, [email-masked].

  * draft-ietf-behave-turn-11.txt 
    http://tools.ietf.org/html/draft-ietf-behave-turn-11
  * draft-ietf-behave-turn-ipv6-05.txt
    http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6-05

-d

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Nov 2008 11:12:16 +0100

>     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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Nov 2008 13:05:19 +0100

>     http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6-05
Hi,

Here are my comments on the TURN IPv6 document:

1. See TURN last call comment about loop attack if address checking as
mitigation is written into the TURN spec, then this needs to be marked
as non effective when implementing this extension.

2. Section 3:
   TURN servers allocate a single relayed-transport-address per
   allocation request.  Therefore, Allocate Requests cannot carry more
   than one REQUESTED-ADDRESS-TYPE attribute.  Consequently, a client
   that wishes to allocate more than one address at a TURN server (e.g.,
   an IPv4 and an IPv6 address) needs to perform several allocation
   requests (one allocation request per address).

It is not clear how this relates to the rule about a single allocation
per 5-tuple? Is this changing that?

3. Section 4.1:

   Reserved: at this point, the 24 bits in the reserved field SHOULD be
   set to zero by the client and MUST be ignored by the server.

I don't like the SHOULD in this sentence. That makes it impossible for
future revisions to be certain that these bits are set to 0. Thus it
makes them unusable for extension.

4. Section 6:

   TURN
   relays performing an IPv4-to-IPv6 or an IPv6-to-IPv4 translations
   SHOULD translate other header fields following SIIT (Stateless IP/
   ICMP Translation Algorithm) as described in Sections 3 and 4 of
   [RFC2765] respectively.

I think there need to be some exceptions to this:

- Source address when translating from v4 to v6: SIIT specifies:
         Source Address:
                 The low-order 32 bits is the IPv4 source address.
                 The high-order 96 bits is the IPv4-mapped prefix
                 (::ffff:0:0/96)

  To me it seem that the allocation's relayed IPv6 address should be
  used in the client-> peer direction and the servers transport address
  in the other.

- Destination address:
                 The low-order 32 bits is the IPv4 destination
                 address.  The high-order 96 bits is the IPv4-
                 translated prefix (0::ffff:0:0:0/96)

  Also in this case it seem that the peer address or the client's server
reflexive address is the one to use.

In the reverse direction you also to change the address field
specifications:

        Source Address:
                 If the IPv6 source address is an IPv4-translated
                 address then the low-order 32 bits of the IPv6 source
                 address is copied to the IPv4 source address.
                 Otherwise, the source address is set to 0.0.0.0.  The
                 use of 0.0.0.0 is to avoid completely dropping e.g.
                 ICMPv6 error messages sent by IPv6-only routers which
                 makes e.g. traceroute present something for the
                 IPv6-only hops.

         Destination Address:
                 IPv6 packets that are translated have an IPv4-mapped
                 destination address.  Thus the low-order 32 bits of
                 the IPv6 destination address is copied to the IPv4
                 destination address.

I also think some remarks or reduced scoping is needs as Section 3.4 and
4.4 are not applicable to TURN address family translations.

Cheers

Magnus Westerlund

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Nov 2008 15:42:12 +0100

On Thu, Nov 06, 2008 at 08:23:02AM -0800,
 Dan Wing <[email-masked]> wrote 

> BEHAVE is initiating working group last call (WGLC) on TURN and TURN-IPv6.
...
>     http://tools.ietf.org/html/draft-ietf-behave-turn-11

I have read this document and finds it quite good. I specially focused
on section 12, "IP header fields" and the current model ("preferred
behavior" and "alternate behavior") is OK for me. I like the fact that
it will be possible to run a TURN server on any Unix machine without
being root.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Nov 2008 14:08:02 -0700

Stephane Bortzmeyer wrote:
> I have read this document and finds it quite good.

Ditto. I have a few minor comments:

1. There a number of typographical errors, of the kind that can be fixed
in AUTH48. However, I could provide a list of them to the authors if
desired.

2. In the discussion of RESERVATION-TOKEN in Section 6.2, the authors
note that the 5-tuple for the Allocate request can specify a different
server IP address and port -- "provided, of course, that the server IP
address and port is one that the server is listening for TURN requests
on". Does this introduce the possibility that a rogue server could send
clients to other TURN servers (or just IP+port pairs) without their
permission (the "of course" here is a rather weak proviso)?

3. In the final bullet-point of Section 11.2, I think it would be
clearer to specify that "the transport address is not currently bound to
a different channel number _within_this_allocation_" (otherwise a TURN
server might enforce this server-wide, not in the context of a given
allocation).

4. In Section 17.1.4, the authors mention that it is possible for an
attacker to send a fake ChannelData message if it knows the IP addresses
of the peers, but no mention is made of the possibility that an attacker
could learn the IP addresses if the signalling channel, STUN, ICE (etc.)
are unprotected. Is this a valid attack vector?

5. In general, I found the use of TURN over TLS ("turns") to be a bit
under-specified.

Peter

---

From: Philip Matthews <[email-masked]>
Date: Wed, 26 Nov 2008 09:27:15 -0500

> 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

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

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

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

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

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

> Seem to have some remnant of a width checking bar.

Thanks. Removed.

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

> XOR-MAPPED-ADDRESS is defined.

I have inserted references to RFC 5389.

> Magnus Westerlund

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 27 Nov 2008 06:45:35 -0500

Thanks for your comments. Detailed responses inline.
- Philip

> in AUTH48. However, I could provide a list of them to the authors if

Yes, please! You can just send them to me privately.

> permission (the "of course" here is a rather weak proviso)?

What the paragraph says is that the incoming Allocate request (sent  
from the client to the server) that has the RESERVATION-TOKEN  
attribute can come from a different client port (the typical  
situation), a different client IP address (for example, if the client  
is multi-homed), use a different transport protocol, and arrive at a  
different TURN server transport address (for example, if the server is  
multi-homed).

I don't see how RESERVATION-TOKEN can be used by the server to  
redirect the client to another server. Can you explain further?

Redirection _can_ be done using ALTERNATE-SERVER, and the spec is  
careful to give conditions on how this is done to prevent problems.

> server might enforce this server-wide, not in the context of a given

The introduction to Section 11 already says that channel binding are  
specific to an allocation, so I don't want to have to repeat this in  
subsections.  However, to make this even clearer, I have reworded the  
paragraph in the introduction to read as follows:

    Channel bindings are specific to an allocation, so that
    the use of a channel number or peer transport address in
    a channel binding in one allocation has no impact on their
    use in a different allocation.  If an allocation expires,
    all its channel bindings expire with it.

> are unprotected. Is this a valid attack vector?

In the scenario of an attacker eavesdropping on a wireless LAN, the  
attacker can hear the packets sent by a TURN client on the LAN, and  
can learn the peer's IP addresses in that way. There is no need to  
listen in on the signaling channel. The exact same problem exists if  
the client is not using TURN, but sending packets to the peers  
directly. A good way to protect against such attacks is for the client  
and peers to encrypt and integrity-check their communication packets,  
and for the client and peers to discard packets where decryption and  
integrity-checks fail.

Or am I misunderstanding your comment?

> 5. In general, I found the use of TURN over TLS ("turns") to be a bit

Do you have some specific suggestions for improvements?

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Nov 2008 13:21:10 +0100

Hi,

See comments inline:

Philip Matthews skrev:
> 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
>    or server which detects a long sequence of invalid TURN messages over

When using TLS over TCP bit-errors shouldn't be an issue. The messages
are inside TLS and are protect from bit-errors by TLS integrity mechanism.

>    address of server B. Server A will send its response to server B, and
>    attacker then sends an Allocate request to server B, using the source
>    address technique, the attacker then binds a channel number on server
>    This attack is mitigated as follows.  By requiring all requests to be
>    authenticated and/or by randomizing the port number allocated for the
>    measures, an attacker can guess the contents of the responses without
>    More mitigation can be achieved by decrementing the TTL when relaying

Looks okay.

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

The reference would be to 1812 and the need to support both
fragmentation and the capability of sending ICMP, i.e. section 5.2.7.1
of RFC 1812.

In general I don't think there is a good reference because we are moving
router functionality partially into an end-host. Thus things like this
needs to be clearly defined. That is why I do like this to be explicitly
mentioned as expected behavior.

Cheers

Magnus Westerlund

---

From: Philip Matthews <[email-masked]>
Date: Fri, 28 Nov 2008 12:23:39 -0500

> are inside TLS and are protect from bit-errors by TLS integrity  

Good point. I'll remove TLS from the paragraph.

>> provide

I have two concerns:
*) First, in most implementations, the code to do fragmentation will  
be inside the kernel and not under the control of the implementor of  
the TURN server.
*) Second, this code will not send any ICMP error message, because it  
views the IP packet as originating from the server itself.

So I propose to add the following sentence:
      In both the Preferred and Alternate Behaviors, the resulting
      packet may be too large for the outgoing link. If this is the
      case, then the normal fragmentation rules apply [RFC1122].

The Host Requirements RFC seems to me to be the most appropriate  
reference for this behavior.

Is this acceptable?

- Philip