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

Chris Lonvick <clonvick@cisco.com> Mon, 02 February 2009 21:16 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 B4D7A3A6B32; Mon, 2 Feb 2009 13:16:37 -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 876173A6B32; Mon, 2 Feb 2009 13:16:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.414
X-Spam-Level:
X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 GBnF3DZuFxB0; Mon, 2 Feb 2009 13:16:35 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BFF1C3A68C2; Mon, 2 Feb 2009 13:16:35 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,367,1231113600"; d="scan'208";a="62050602"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2009 21:16:16 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n12LGG9d023197; Mon, 2 Feb 2009 13:16:16 -0800
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n12LGGB3001051; Mon, 2 Feb 2009 21:16:16 GMT
Date: Mon, 02 Feb 2009 13:16:16 -0800
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>
Message-ID: <Pine.GSO.4.63.0902020939370.10577@sjc-cde-011.cisco.com>
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1548; t=1233609376; x=1234473376; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20<clonvick@cisco.com> |Subject:=20SECDIR=20review=20of=20draft-ietf-ccamp-path-ke y-ero-03 |Sender:=20; bh=Fu1DrJ7M9GFi41J3NMGLdGpfhnJYNMt6t7vlA7h1knI=; b=yot9hA+fuUQV52KTwVkxjzi8ktZU4Fg2uY3v3IMxygXgyOicVndTgwCKaX N2+Qmv9L0VcMAwx+tdbM3xXJdMsqN20xABTfX1thOUb0kz6WnJ5tdVqOTN53 2bgIGdDj8v;
Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Subject: [secdir] SECDIR review of draft-ietf-ccamp-path-key-ero-03
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/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

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