[secdir] secdir review of draft-ietf-v6ops-6to4-to-historic-04

Tina Tsou <tena@huawei.com> Mon, 20 June 2011 21:43 UTC

Return-Path: <tena@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9625B11E80C5; Mon, 20 Jun 2011 14:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.532
X-Spam-Level:
X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upUYEdgl4Wa9; Mon, 20 Jun 2011 14:43:02 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id D3D6611E808E; Mon, 20 Jun 2011 14:43:02 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN300BMIYZPUA@usaga04-in.huawei.com>; Mon, 20 Jun 2011 16:43:01 -0500 (CDT)
Received: from TingZousc1 ([10.193.34.147]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN300LG1YZOEC@usaga04-in.huawei.com>; Mon, 20 Jun 2011 16:43:01 -0500 (CDT)
Date: Mon, 20 Jun 2011 14:43:00 -0700
From: Tina Tsou <tena@huawei.com>
In-reply-to: <alpine.BSF.2.00.1106171231010.58859@fledge.watson.org>
To: secdir-secretary@mit.edu, secdir@ietf.org
Message-id: <008901cc2f93$0796e7d0$16c4b770$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: en-us
Content-transfer-encoding: 7BIT
Thread-index: AcwtDFGsXC3d3P44T5at7uPQ49mLbACgoNfw
x-cr-hashedpuzzle: H5Hw H/OP Jcky Jqg4 NuzK Pfzl Uv50 U4oQ U+GS XF8w bqMQ ckeZ em4l hr5q lTz7 rV23; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAHYANgBvAHAAcwAtADYAdABvADQALQB0AG8ALQBoAGkAcwB0AG8AcgBpAGMAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAEAAaQBlAHQAZgAuAG8AcgBnADsAcwBlAGMAZABpAHIALQBzAGUAYwByAGUAdABhAHIAeQBAAG0AaQB0AC4AZQBkAHUAOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {64D14EA9-10AA-4AAF-AB23-ED6F55E78AEA}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 20 Jun 2011 21:42:52 GMT; cwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQB2ADYAbwBwAHMALQA2AHQAbwA0AC0AdABvAC0AaABpAHMAdABvAHIAaQBjAC0AMAA0AA==
x-cr-puzzleid: {64D14EA9-10AA-4AAF-AB23-ED6F55E78AEA}
References: <alpine.BSF.2.00.1106171231010.58859@fledge.watson.org>
Cc: draft-ietf-v6ops-6to4-to-historic@tools.ietf.org, 'IESG' <iesg@ietf.org>
Subject: [secdir] secdir review of draft-ietf-v6ops-6to4-to-historic-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 21:43:03 -0000

Hi Sam et al,
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 requests that RFC3056 and the companion document "An Anycast
Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.
I have some minor nits below, but overall the document seems in fine shape.

3.  6to4 operational problems
"In any case this model has the same
   operational burden has manually configured tunnels and has seen no
   deployment in the public Internet."
Should be
"In any case this model has the same
   operational burden as manually configured tunnels and has seen no
   deployment in the public Internet."

As the author said, 
   There are no new security considerations pertaining to this document.
   General security issues with tunnels are listed in
   [I-D.ietf-v6ops-tunnel-security-concerns] and more specifically to
   6to4 in [RFC3964] and [I-D.ietf-v6ops-tunnel-loops].

By the way, it is proposed to use 6rd replacing 6to4. 6rd is a good
technology, but cannot involve to IPv6. There are experiments on IPoE based
6rd, a little on PPPoE based 6rd.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html