Last Call Review of draft-ietf-l3vpn-mvpn-considerations-

Request Review of draft-ietf-l3vpn-mvpn-considerations
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-09
Requested 2010-02-20
Authors Raymond Zhang, Nabil Bitar, Thomas Morin, Ben Niven-Jenkins, Nicolai Leymann, Yuji Kamite
Draft last updated 2010-03-15
Completed reviews Secdir Last Call review of -?? by Scott Kelly
Assignment Reviewer Scott Kelly
State Completed
Review review-ietf-l3vpn-mvpn-considerations-secdir-lc-kelly-2010-03-15
Review completed: 2010-03-15


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 defines a set of mandatory-to-implement features for L3 mcast BGP/MPLS VPN implementations, with the underlying motivation being that due to the current lack of a minimal necessary and sufficient set of mandatory features, currently deployed implementations may be compliant, yet not interoperate. 

I think the security ADs will want to pay attention to this document. The security considerations section is very brief:

  "This document does not by itself raise any particular security

After reading this, I was surprised to find a page-and-a-half discussion earlier in the document entitled "3.3.5  Security and robustness". This section seems to indicate that there *are* security considerations, although the section could really use some editorial attention. 

I would suggest a couple of things: first, thoroughly review 3.3.5 to ensure that it is complete. Second, try to make this section more intelligible. For example, here is the first paragraph:

   BGP supports MD5 authentication of its peers for additional security,
   thereby possibly benefit directly to multicast VPN customer multicast
   routing, whether for intra-AS or inter-AS communications.  By
   contrast, with a PIM-based approach, no mechanism providing a
   comparable level of security to authenticate communications between
   remote PEs has been yet fully described yet
   [I-D.ietf-pim-sm-linklocal][], and in any case would require
   significant additional operations for the provider to be usable in a
   multicast VPN context.

I've read this several times, yet I still have no idea what this is meant to communicate.

Third, it wouldn't hurt to refer the reader to other places where relevant security requirements are already discussed (e.g., RFC4834).