[secdir] Review of draft-ietf-pce-pcep-p2mp-extensions-10.txt

Russ Mundy <mundy@sparta.com> Wed, 21 April 2010 05:51 UTC

Return-Path: <mundy@sparta.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 3AE503A6A30; Tue, 20 Apr 2010 22:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
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 3IXwkn8t5h5m; Tue, 20 Apr 2010 22:51:49 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8248B3A6A04; Tue, 20 Apr 2010 22:51:45 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3L5pZwV013289; Wed, 21 Apr 2010 00:51:35 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3L5pWLk005845; Wed, 21 Apr 2010 00:51:32 -0500
Received: from calvin.home.tislabs.com ([69.250.64.147]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 01:51:32 -0400
Received: from calvin.home.tislabs.com (localhost [127.0.0.1]) by calvin.home.tislabs.com (Postfix) with ESMTP id 4DBE72221C43; Wed, 21 Apr 2010 01:51:11 -0400 (EDT)
Message-ID: <4BCE924F.8000003@sparta.com>
Date: Wed, 21 Apr 2010 01:51:11 -0400
From: Russ Mundy <mundy@sparta.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 SeaMonkey/2.0.4
MIME-Version: 1.0
To: ietf@ietf.org, secdir@ietf.org, draft-ietf-pce-pcep-p2mp-extensions.txt.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Apr 2010 05:51:32.0447 (UTC) FILETIME=[B1F27EF0:01CAE116]
Cc: Russ Mundy <mundy@sparta.com>
Subject: [secdir] Review of draft-ietf-pce-pcep-p2mp-extensions-10.txt
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: Wed, 21 Apr 2010 05:51:50 -0000

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 document presented an interesting challenge for a security review
in that it is building on several other referenced RFCs [1] each of
which has it's own set of references and security consideration
section.  Also, the .10 version of the ID was posted on the 19 Apr and
the security ADs recently posted some comments for discussion.

I have not previously had the opportunity (or need) to examine the
fairly large set of documents that this ID builds upon and could be
missing (or mis-understanding) some important aspects. I tried to do
the review as someone that wanted to "do the right security thing" for
implementing or deploying this capability.  Given these caveats,
following are my comments on the document:

- Resolution of Tim's 'Discuss (2010-04-19)' comment should provide
   additional information in this document.  However, it's not clear to
   me that the security considerations section of this document and
   RFC5440 and RFC5671 (individually or jointly) provide what the PCE
   Architecture document [RFC4655] says will be expected for each PCE
   solution.

-- Although the need for Applicability statements to detail security
    related issues and techniques is stated in 4655, the word
    'Applicability' is not in 5440 and is only in the title and
    abstract of 5671.  The 5671 applicability examination is related to
    "the applicability of PCE to path computation for P2MP TE LSPs in
    MPLS and GMPLS networks." but does not provide security related
    applicability specifics as expected in 4655.

--- Although this may seem like "spec legalism", I think this lack of
     specification will likely have direct impacts on implementations
     and will result in the lack of interoperability between
     implementations (except for TCP-AO (or TCP-MD5)).

--- This may be my lack of background in this area but 4655 has a
     number of statements that there are different security concerns
     when the PCE architecture is used in an intra-domain case vs an
     inter-domain (or multi-domain) cases.  I was not able to find
     enough guidance in this document (or 5440 or 5671) that would
     identify what information elements would be more (or less?)
     sensitive in inter-domain or multi-domain use cases.  Neither was
     there any useful guidance on what different security techniques
     should be applied in these different cases/environments.

---- This is further complicated in that RFC5440 enumerates several
      security vulnerabilities but only identifies TCP-MD5 as a MUST be
      implemented.  Other security techniques are described but it's
      unclear when (or if) these should be used.  Without any other
      MUST implement requirements or use case recommendations, it's
      unclear whether or not any of the other mechanisms will be
      implemented.

--- RFC4875 Security Considerations requires that the ingress LSR of a
     P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor
     deployments.  Although it's not clear that this document needs to
     provide this requirement, I wanted to flag the requirement in case
     that it had been overlooked.


Russ


[1] nice technology list by Sandy Murphy in an earlier email to the
secdir & iesg lists