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

Simon Perreault <> Wed, 07 April 2010 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 669613A672F; Tue, 6 Apr 2010 17:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5rgBMB3Rv4c; Tue, 6 Apr 2010 17:27:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CD803A62C1; Tue, 6 Apr 2010 17:27:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 37B7E21C38; Tue, 6 Apr 2010 20:27:50 -0400 (EDT)
Message-ID: <>
Date: Tue, 06 Apr 2010 20:27:49 -0400
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3
MIME-Version: 1.0
To: Richard Barnes <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Apr 2010 05:39:12 -0700
Cc:, "" <>,,
Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Apr 2010 00:27:55 -0000

On 03/29/2010 05:45 PM, Richard Barnes wrote:
> 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.

(See bottom of this email.)

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

Agreed, fixed.

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

STUN attributes must be padded to a multiple of 4 bytes. (Reference: RFC
5389, section 15.)

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

Agreed, fixed.

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

I have no idea. I'll change it to a MUST NOT unless I receive more info
from my co-authors.

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

The client can indeed send/receive traffic with any node (as long as it
is allowed by local security policy).

Could you please explain the restrictions you have in mind?

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

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

I have no idea if that would be right or not. Can somebody with a clue
please weigh in?

NAT64/DNS64 open-source -->
STUN/TURN server        -->
vCard 4.0               -->