Skip to main content

Last Call Review of draft-ietf-behave-turn-ipv6-
review-ietf-behave-turn-ipv6-secdir-lc-barnes-2010-04-01-00

Request Review of draft-ietf-behave-turn-ipv6
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-behave-turn-ipv6 by Security Area Directorate Assigned
Completed 2010-04-01
review-ietf-behave-turn-ipv6-secdir-lc-barnes-2010-04-01-00
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"?