Re: [secdir] secdir review of draft-ietf-v6ops-tunnel-loops-01

Fred Baker <fred@cisco.com> Thu, 30 December 2010 07:42 UTC

Return-Path: <fred@cisco.com>
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 21B183A67F2; Wed, 29 Dec 2010 23:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.385
X-Spam-Level:
X-Spam-Status: No, score=-110.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 BPGZA1um5122; Wed, 29 Dec 2010 23:42:18 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C16283A6889; Wed, 29 Dec 2010 23:42:18 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAA7HG02rRN+J/2dsb2JhbACkOnOkcZodhUoEhGWGH4sy
X-IronPort-AV: E=Sophos;i="4.60,248,1291593600"; d="scan'208";a="643025754"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 30 Dec 2010 07:44:24 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oBU7iOkk026516; Thu, 30 Dec 2010 07:44:24 GMT
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Fred Baker <fred@cisco.com>
In-Reply-To: <ldvhbdv29lz.fsf@cathode-dark-space.mit.edu>
Date: Wed, 29 Dec 2010 23:44:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <64AE925C-9A79-433C-A3A7-90FF523C0321@cisco.com>
References: <ldvhbdv29lz.fsf@cathode-dark-space.mit.edu>
To: Tom Yu <tlyu@mit.edu>
X-Mailer: Apple Mail (2.1082)
Cc: IPv6 Operations Chairs <v6ops-chairs@tools.ietf.org>, "iesg@ietf.org IESG" <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-v6ops-tunnel-loops-01
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: Thu, 30 Dec 2010 07:42:20 -0000

Question for you. I have left the authors off the paper for the moment.

Mr Gont has recently posted a draft:

http://tools.ietf.org/html/draft-gont-6man-teredo-loops
  "Mitigating Teredo Rooting Loop Attacks", Fernando Gont, 7-Sep-10,
  <draft-gont-6man-teredo-loops-00.txt>

and is pushing for adoption as a working group draft. When asked to consider merging his paper with this or another draft, he has been unwilling. The chairs have basically told him to discuss his draft on the list "and we'll see where it goes". 

One of your criticisms of this draft is that it doesn't cover his USENIX material. Would you prefer that this and Mr Gont's draft be merged? 

On Dec 29, 2010, at 8:00 PM, Tom Yu wrote:

> This document describes routing loop vulnerabilities inherent in the
> existing design of IPv6-in-IPv4 tunneling protocols, and suggests
> mitigation strategies.
> 
> While the Security Considerations section of this document claims that
> the recommended checks do not introduce new security threats, Section
> 3.1 mentions that the additional processing overhead for checking
> destination and source addresses may be considerable.  It would be
> useful to have measurements or estimates of how this additional
> processing overhead compares to the effects of the routing loop attack
> that it is intended to mitigate.
> 
> This document makes no mention of the Teredo attacks that are
> discussed in the USENIX WOOT paper.  The authors may wish to mention
> draft-gont-6man-teredo-loops-00 for the sake of completeness.
> 
> Editorial:
> 
> Section 3 lists three categories of mitigation measures but the
> accompanying text states that they fall under two categories.
> 
> In Section 3.1, in the sentence "However, this approach has some
> inherit limitations", replace "inherit" with "inherent".
> 
> In Section 4, in the sentence "...other mitigation measures may be
> allowed is specific deployment scenarios", replace "may be allowed is"
> with "may be feasible in".