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

[Simon Perreault <[e-mail]>]

On 06/25/2010 02:49 PM, Richard L. Barnes wrote:
> 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.

Thanks, I understand now. I'll include a summary of the attack in the text.

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

Agreed.

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org