Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09
Simon Perreault <simon.perreault@viagenie.ca> Wed, 07 April 2010 00:27 UTC
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669613A672F; Tue, 6 Apr 2010 17:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5rgBMB3Rv4c; Tue, 6 Apr 2010 17:27:54 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 2CD803A62C1; Tue, 6 Apr 2010 17:27:54 -0700 (PDT)
Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 37B7E21C38; Tue, 6 Apr 2010 20:27:50 -0400 (EDT)
Message-ID: <4BBBD185.7090606@viagenie.ca>
Date: Tue, 06 Apr 2010 20:27:49 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3
MIME-Version: 1.0
To: Richard Barnes <rbarnes@bbn.com>
References: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com>
In-Reply-To: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com>
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: draft-ietf-behave-turn-ipv6@tools.ietf.org, "behave@ietf.org" <behave@ietf.org>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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: > <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. (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? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
- [secdir] secdir review of draft-ietf-behave-turn-… Richard Barnes
- Re: [secdir] secdir review of draft-ietf-behave-t… Simon Perreault
- Re: [secdir] secdir review of draft-ietf-behave-t… Richard L. Barnes
- Re: [secdir] secdir review of draft-ietf-behave-t… Simon Perreault
- [secdir] secdir review of draft-ietf-isis-ieee-aq… Richard L. Barnes