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

[Richard Barnes <[e-mail]>]

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

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:
<http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf>
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.

--Richard

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

S4.1.1
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, ..."

S4.3
Why is this a SHOULD NOT and not a MUST NOT?  What's the exceptional  
case?

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  
peers"?