Last Call Review of draft-ietf-pce-pcep-p2mp-extensions-
review-ietf-pce-pcep-p2mp-extensions-secdir-lc-mundy-2010-04-25-00

Request Review of draft-ietf-pce-pcep-p2mp-extensions
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-04-20
Requested 2010-04-02
Draft last updated 2010-04-25
Completed reviews Secdir Last Call review of -?? by Russ Mundy
Assignment Reviewer Russ Mundy
State Completed
Review review-ietf-pce-pcep-p2mp-extensions-secdir-lc-mundy-2010-04-25
Review completed: 2010-04-25

Review
review-ietf-pce-pcep-p2mp-extensions-secdir-lc-mundy-2010-04-25

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