Re: [secdir] SECDIR review of draft-ietf-ccamp-path-key-ero-03

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 02 February 2009 23:32 UTC

Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FF93A699F; Mon, 2 Feb 2009 15:32:54 -0800 (PST)
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 A05AD3A699F; Mon, 2 Feb 2009 15:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.811
X-Spam-Level:
X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.788, 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 9+SUXe3INKLQ; Mon, 2 Feb 2009 15:32:52 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id EEE1F3A67B5; Mon, 2 Feb 2009 15:32:51 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n12NWBmn010330; Mon, 2 Feb 2009 23:32:11 GMT
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n12NW9Cm010308; Mon, 2 Feb 2009 23:32:10 GMT
Message-ID: <BE3E47886AC4459B871105680FF0218D@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Chris Lonvick <clonvick@cisco.com>, iesg@ietf.org, secdir@ietf.org, jpv@cisco.com, Rich Bradford <rbradfor@cisco.com>, Deborah Brungard <dbrungard@att.com>
References: <Pine.GSO.4.63.0902020939370.10577@sjc-cde-011.cisco.com>
Date: Mon, 02 Feb 2009 23:32:02 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [secdir] SECDIR review of draft-ietf-ccamp-path-key-ero-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Sure thing, Chris.

The references would be to RFC 5440 and to 
draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt

Cheers,
Adrian
----- Original Message ----- 
From: "Chris Lonvick" <clonvick@cisco.com>
To: <iesg@ietf.org>; <secdir@ietf.org>; <jpv@cisco.com>; "Rich Bradford" 
<rbradfor@cisco.com>; <adrian@olddog.co.uk>; "Deborah Brungard" 
<dbrungard@att.com>
Sent: Monday, February 02, 2009 9:16 PM
Subject: SECDIR review of draft-ietf-ccamp-path-key-ero-03


> Hi,
>
> 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.
>
> Overall, the document appears to be well written and comprehensive and I 
> have no problem with it proceeding to become an RFC.
>
> I do have one editorial comment.  In Section 4, Security Considerations, 
> the following bullet appears.
> ===
>    - Authenticity of the path key. A concern is that the path key in the
>      PKS will be altered or faked leading to erroneous path key
>      expansion and the use of the wrong CPS. The consequence would be a
>      bad ERO in a Path message causing the LSP to be set up incorrectly
>      resulting in incorrect network resource usage, diversion of traffic
>      to where it can be intercepted, or failure to set up the LSP. These
>      problems can be prevented by protecting the protocol exchanges in
>      PCEP and RSVP-TE using standard security techniques.
> ===
> I feel that the term "standard security techniques" is too vague for a 
> standards track document and would ask you to rephrase the last sentence 
> to be:
> "These problems can be prevented by protecting the protocol exchanges in 
> PCEP and RSVP-TE using the techniques described in [PSEC] and [RFC2205]."
> Or reference other techniques if you have them in mind.
>
> Best regards,
> Chris
> 

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir