Last Call Review of draft-ietf-l3vpn-mvpn-considerations-
review-ietf-l3vpn-mvpn-considerations-secdir-lc-kelly-2010-03-15-00

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
   considerations."

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).

--Scott