Subject: [BEHAVE] TURN: Why TURN allows servers to restrict peer transport address

From: Philip Matthews <[email-masked]>
Date: Wed, 19 Nov 2008 11:17:38 -0500

Cullen asked a question at today's BEHAVE meeting:  Why did TURN-11  
add text that allows a server to restrict the IP address and ports  
that relaying is allowed to?

Specifically, TURN-11 added the following:

(Section 9.2 Receiving a CreatePermission request)
    The server MAY impose restrictions on the range of values allowed  
for
    the IP address contained in one of the XOR-PEER-ADDRESS attributes.

(Section 10.2.  Receiving a Send Indication)
    The server MAY impose additional restrictions on the range of values
    allowed for the IP address and port contained in the XOR-PEER- 
ADDRESS
    attribute.

(Section 11.2.  Receiving a ChannelBind Request)
    The server MAY also impose restrictions on the range of IP addresses
    and ports allowed in the XOR-PEER-ADDRESS attribute.

The answer is that this text was added in response to an attack  
pointed out by Cullen and described in my e-mail to the mailing list  
on Oct 3:
http://www.ietf.org/mail-archive/web/behave/current/msg04397.html

This attack and its mitigation is described in section 17.1.4. Fake  
Data:

    In some situations, the TURN server may be situated in the network
    such that it is able to send to hosts that the client cannot  
directly
    send to.  This can happen, for example, if the server is located
    behind a firewall that allows packets from outside the firewall to  
be
    delivered to the server, but not to other hosts behind the firewall.
    In these situations, an attacker could send the server a Send
    indication with an XOR-PEER-ADDRESS attribute containing the
    transport address of one of the other hosts behind the firewall.  If
    the server was to allow relaying of traffic to arbitrary peers, then
    this would provide a way for the attacker to attack arbitrary hosts
    behind the firewall.

    To mitigate this attack, TURN requires that the client establish a
    permission to a host before sending it data.  Thus an attacker can
    only attack hosts that the client is already communicating with,
    unless the attacker is able to create authenticated requests.
    Furthermore, the server administrator may configure the server to
    restrict the range of IP addresses and ports that it will relay data
    to.  To provide even greater security, the server administrator can
    require that the client use TLS for all communication between the
    client and the server.

I hope this answers the question.

- Philip

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Nov 2008 17:08:48 -0600

Yes, that answers the question. I don't think the restriction policy  
helps much with the attack I was worried about but I fine with it  
being there and the other things you did around permissions did solve  
the problem so all looks reasonable to me. Thanks.