Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09

["Richard L. Barnes" <[e-mail]>]

Hi Simon,

Just following up, since this draft is up for telechat next week.   
Still waiting to see a revision with the agreed comments.

>> Section 9,
>> Might some of the Teredo / 6to4 loop attacks apply as well?  If  
>> not, why
>> not?
>> -- Spoof 4-to-6 allocate request from relay's v4 address
>> -- Spoof authorization relay's v6 address
>> -- Spoof packet from either of relay's addresses
>
> Sure, these are ways of spoofing IPv6 packets that are enabled by  
> Teredo
> and 6to4. There are many others. Is there a reference we can cite?  
> Would
> citing the Usenix paper be OK?

I think it makes sense to describe the attack here, because it's not  
the same as the Usenix attack.  Here's how it works.  Consider the  
following setup:

               +--------------------------------+
               |                                |
               | 2001:DB8::1        2001:DB8::2 |
+-----------------+                        +------------+
| Tunnel Endpoint |                        | TURN Relay |
+-----------------+                        +------------+
               | 192.0.2.1            192.0.2.2 |
               |                                |
               +--------------------------------+

Suppose an attacker knows that a tunnel endpoint will forward  
encapsulated packets from a given IPv6 address (this doesn't  
necessarily need to be the tunnel endpoint's address).  Suppose he  
then spoofs two packets from this address:
1. An allocate request asking for a v4 address, and
2. A ChannelBind request establishing a channel to the IPv4 address of  
the tunnel endpoint

Then he has set up an amplification attack:
-- The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it  
to the tunnel endpoint
-- The tunnel endpoint will decapsulate packets from the v4 interface  
and send them to v6
So if the attacker sends a packet of the following form...

IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP:  <ports>
TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP:  <ports>
TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP:  <ports>
TURN: <channel id>
...

Then the TURN relay and the tunnel endpoint will send it back and  
forth until the last TURN header is consumed, at which point the TURN  
relay will send an empty packet, which the tunnel endpoint will drop.

The amplification potential here is limited by the MTU, so it's not  
huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one  
amplification out of a 1500-byte packet.  But the attacker could still  
increase traffic volume by sending multiple packets or by establishing  
multiple channels spoofed from different addresses behind the same  
tunnel endpoint.

This attack is kind of like the TURN loop attack in RFC 5766 (which  
definitely still applies here!), but nicer for the attacker, since the  
attacker never needs to see the response to a spoofed packet, since he  
doesn't care about the relayed-transport address.

I think the moral here is that TURN relays shouldn't be involved in  
tunnels -- no need for two v4/v6 compatibility measures at once.  So I  
would suggest the document say something like:
"
It is RECOMMENDED that TURN relays not accept allocation or channel  
binding requests from addresses known to be tunneled, and that they  
not forward data to such addresses.  In particular, a TURN relay MUST  
NOT accept Teredo or 6to4 addresses in these requests.
"