Re: [secdir] draft-ietf-isis-ipv6-te-07

Stewart Bryant <stbryant@cisco.com> Mon, 12 July 2010 14:39 UTC

Return-Path: <stbryant@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 3EB183A67DB; Mon, 12 Jul 2010 07:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.502
X-Spam-Level:
X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 z4LVbCQFBHnj; Mon, 12 Jul 2010 07:39:34 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 548643A6971; Mon, 12 Jul 2010 07:39:09 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGXGOkxAZnwN/2dsb2JhbACgPnGkYYF+CwGYP4J6gi0EiEw
X-IronPort-AV: E=Sophos; i="4.55,188,1278288000"; d="scan'208,217"; a="131379619"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2010 14:33:34 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6CEXX9R012909; Mon, 12 Jul 2010 14:33:33 GMT
Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o6CEXU601231; Mon, 12 Jul 2010 15:33:30 +0100 (BST)
Message-ID: <4C3B27BA.7050200@cisco.com>
Date: Mon, 12 Jul 2010 15:33:30 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1
MIME-Version: 1.0
To: Donald Eastlake <d3e3e3@gmail.com>
References: <AANLkTinzL1pzDfWsnHCjgwvkYeqyLqZ-eOuE1ebJWpUz@mail.gmail.com>
In-Reply-To: <AANLkTinzL1pzDfWsnHCjgwvkYeqyLqZ-eOuE1ebJWpUz@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------050305060307020304070605"
Cc: David Ward <dward@juniper.net>, jon.berger@dataconnection.com, Christian Hopps <chopps@rawdofmt.org>, secdir@ietf.org, mike.bartlett@dataconnection.com, jon.harrison@dataconnection.com, iesg@ietf.org
Subject: Re: [secdir] draft-ietf-isis-ipv6-te-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: stbryant@cisco.com
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: Mon, 12 Jul 2010 14:39:36 -0000

  On 12/07/2010 04:57, Donald Eastlake wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> This document primarily specifies the IS-IS code points and
> TLV/sub-TLV data structures for IS-IS support of traffic engineering
> and generalized multi-protocol label switching. The Security
> Considerations section is probably correct when it says that it raises
> no new security considerations. However, I would like to see a
> Reference to RFC 5304 added as pertaining to general IS-IS Security
> Considerations.
>
> Thanks,
> Donald
> =============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street
>   Milford, MA 01757 USA
>   d3e3e3@gmail.com
If we replace the security text with:

    This document raises no new security issues for IS-IS; for general
    security considerations for IS-IS see [RFC5304  <http://tools.ietf.org/html/rfc5304>].

Will that  address this concern?

(i.e. make it the same as RFC 5305 <http://tools.ietf.org/html/rfc5307>)

- Stewart