[secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt

Klaas Wierenga <klaas@cisco.com> Fri, 14 October 2011 15:07 UTC

Return-Path: <klaas@cisco.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 3F3ED21F87C9 for <secdir@ietfa.amsl.com>; Fri, 14 Oct 2011 08:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZHuFWOOEXvW for <secdir@ietfa.amsl.com>; Fri, 14 Oct 2011 08:07:00 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6505F21F87D3 for <secdir@ietf.org>; Fri, 14 Oct 2011 08:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=2069; q=dns/txt; s=iport; t=1318604820; x=1319814420; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=0A4dD/z0eeBNpNBc7zPqpEYW4thx4M4OYTaASyal7xw=; b=HL3FZBDDkr+F7KZLn1jTSAdp8mXsSAq9Y7HhhLejzS5GYNqYaMuiMzIZ /oy4I6GocNWADMJ5Ru1Kdj8A1/wvfJ+8Zs8DQZa4CrEZ//H9rShrFMq0Q Hdjhkkhg+6DGAJmUzDa6q0j1VbmjwHBpzUFA3dGiYfSUsBeiEL7onybGq w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEANFPmE6tJXG8/2dsb2JhbABDqGOBBYIHASctBIFNNKBTAZ5Ghk1LYQSTd5FX
X-IronPort-AV: E=Sophos;i="4.69,346,1315180800"; d="scan'208";a="28490984"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 Oct 2011 15:06:59 +0000
Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9EF6vD7017461; Fri, 14 Oct 2011 15:06:58 GMT
From: Klaas Wierenga <klaas@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 14 Oct 2011 17:06:56 +0200
Message-Id: <CB75297E-A65B-4D16-B09A-DD16A7F79CC1@cisco.com>
To: secdir@ietf.org, draft-ietf-ccamp-attribute-bnf@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1244.3)
X-Mailer: Apple Mail (2.1244.3)
X-Mailman-Approved-At: Fri, 14 Oct 2011 08:39:29 -0700
Subject: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt
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: Fri, 14 Oct 2011 15:07:01 -0000

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.

This (short) document specifies how LSP (Label Switched Path) attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form, and clarifies related Resv message formats. The document updates RFC 4875 and RFC 5420. Section 9 of RFC5420 contains a narrative description of the message formats for the definition of the object carrying information on the LSP.  This document provides the BNF for Path and Resv messages carrying the LSP Attributes related object. 

Given my lack of expertise in MPLS I have not much to offer in terms of general comments on the draft for the draft authors to take into consideration, but here goes:

- Section 1

Gives a short explanation as to why you need to update 5420, but not why the same goes for 4875, this may be obvious for most, but it was not for me. I think it would help to add a sentence on the necessary changes for 4875.

- Section 1, p3 states: 
"The current message format description has led
   to an issue in how the LSP Attributes related objects are to be
   processed in Resv messages of P2MP LSPs."

Is this just the fact that the lack of a formal definition of the message format leads to inconstant implementations? If so, why not state just that? If not, what is the problem?

- The security considerations section states:
"This document clarifies usage of objects defined in [RFC5420].  No
   new information is conveyed and therefore neither are there any
   additional security considerations. "

Which I think that is a fair statement. So concerning the security considerations part I see no objection for this document to advance.

Regards,

Klaas