Re: [secdir] review of draft-ietf-mpls-gmpls-lsp-reroute-04

Lou Berger <lberger@labn.net> Fri, 28 August 2009 11:45 UTC

Return-Path: <lberger@labn.net>
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 7341428C235 for <secdir@core3.amsl.com>; Fri, 28 Aug 2009 04:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 n+0kkUuWqj51 for <secdir@core3.amsl.com>; Fri, 28 Aug 2009 04:45:29 -0700 (PDT)
Received: from outbound-mail-114.bluehost.com (outbound-mail-114.bluehost.com [69.89.24.4]) by core3.amsl.com (Postfix) with SMTP id 9F36D28C20C for <secdir@ietf.org>; Fri, 28 Aug 2009 04:45:29 -0700 (PDT)
Received: (qmail 5013 invoked by uid 0); 28 Aug 2009 11:45:36 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 28 Aug 2009 11:45:36 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ja23Y9OSic60Ew5ygHikz+261M61HQXDNLR6KRsyJck0IeuzNMCAAm8vdg9GRDIA4Cmjwbs9yWitQ1Y0oJ6fWyi9OJQos0Oid+7y9VqVX4Be7u1AImNDPQBizPBOOcYw;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from <lberger@labn.net>) id 1Mgztg-0004jD-7A; Fri, 28 Aug 2009 05:45:36 -0600
Message-ID: <4A97C363.5030809@labn.net>
Date: Fri, 28 Aug 2009 07:45:39 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: "Scott G. Kelly" <scott@hyperthought.com>
References: <4A974FA1.6010400@hyperthought.com>
In-Reply-To: <4A974FA1.6010400@hyperthought.com>
X-Enigmail-Version: 0.96a
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: iesg@ietf.org, mpls-chairs@tools.ietf.org, Dimitri.Papadimitriou@alcatel-lucent.be, jpv@cisco.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-mpls-gmpls-lsp-reroute-04
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: Fri, 28 Aug 2009 11:45:30 -0000

Thank you for the review!

Lou

On 8/27/2009 11:31 PM, Scott G. Kelly 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.
>  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.
> 
> The abstract does a good job of summarizing: This document describes how
> Resource ReserVation Protocol (RSVP) PathErr Messages may be used to
> trigger rerouting of Multi-Protocol Label Switching (MPLS) and
> Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label
> Switched Paths (LSPs) without first removing LSP state or resources.
> 
> The security considerations section says the document introduces no new
> security considerations as it describes usage of existing formats and
> mechanisms, and I agree. It also points the reader to the security
> considerations sections of RFC4920 and RFC4736, and these do seem to do
> a reasonable job of summarizing.
> 
> I see no issues of concern for the security area ADs with this document.
> 
> --Scott
> 
> 
>