Last Call Review of draft-ietf-behave-turn-ipv6-

Request Review of draft-ietf-behave-turn-ipv6
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-31
Requested 2010-03-12
Authors Gonzalo Camarillo, Simon Perreault, Oscar Novo
Draft last updated 2010-04-01
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Secdir Telechat review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Review review-ietf-behave-turn-ipv6-secdir-lc-barnes-2010-04-01
Review completed: 2010-04-01


I have reviewed this document as part of the security directorate's  

ongoing effort to review all IETF documents being processed by the  

IESG.  These comments were written primarily for the benefit of the  

security area directors.  Document editors and WG chairs should treat  

these comments just like any other last call comments.

This document defines an extension to the TURN protocol, a relay  

protocol for NAT traversal, that allows endpoints to request that the  

TURN server allocate them an IPv4 or IPv6 address (the protocol  

currently supports only IPv4).  On important feature of this extension  

is that it allows a TURN server to act as a relay in all four  

combinations of protocols (4-4, 4-6, 6-4, 6-6), depending on which  

protocol the TURN request is carried in and which address family is  


As the Security Considerations correctly note, TURN with this  

extension is basically equivalent to TURN without it, with the  

exception that certain routing loop attacks inherent to TURN could be  

easier with this mechanism.  My only significant concern that is not  

addressed in the document is how this mechanism relates to the routing  

loop attacks introduced by other forms of v4/v6 translation and  

tunneling, e.g., as discussed in this paper:



It's not immediately obvious to me that extending TURN in this way  

makes these (currently non-TURN-related) attacks viable, but I would  

encourage the authors to consider the issue and add some text to the  

document explaining how the attacks do or do not apply here.

A few specific comments follow.


Comments on draft-ietf-behave-turn-ipv6

S.3, Paragraph "Assuming the request..."

The server doesn't "assume" that the request is authenticated.   

Suggest rephrasing as "After the request has been successfully  

authenticated, ..."


Why not just make this option one byte long?  If you're already  

anticipating a usage for the reserved space, you should just specify it.

S4.2, First paragraph

As above, suggest rephrasing as "Once a server has verified that the  

request is authenticated and has not been tampered with, ..."


Why is this a SHOULD NOT and not a MUST NOT?  What's the exceptional  


Section 9, First para

It seems overly broad to say that "an IPv4-only client having access  

to ... this specifictation is now able to access the IPv6 Internet".   

The client can't just send/receive traffic with any node, right?   

Explain the restrictions in place here.

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

If there is some risk here, you might consider saying something like  

"Server MUST NOT allocate 6to4 or Teredo addresses or accept them as