Last Call Review of draft-ietf-l2vpn-vpls-mcast-14
review-ietf-l2vpn-vpls-mcast-14-secdir-lc-meadows-2013-09-26-00

Request Review of draft-ietf-l2vpn-vpls-mcast
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-23
Requested 2013-09-05
Authors Chaitanya Kodeboniya, Rahul Aggarwal, Yakov Rekhter, Yuji Kamite, Luyuan Fang
Draft last updated 2013-09-26
Completed reviews Genart Telechat review of -15 by Wassim Haddad (diff)
Secdir Last Call review of -14 by Catherine Meadows (diff)
Tsvdir Last Call review of -14 by David Black (diff)
Assignment Reviewer Catherine Meadows
State Completed
Review review-ietf-l2vpn-vpls-mcast-14-secdir-lc-meadows-2013-09-26
Reviewed rev. 14 (document currently at 16)
Review result Ready
Review completed: 2013-09-26

Review
review-ietf-l2vpn-vpls-mcast-14-secdir-lc-meadows-2013-09-26

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 ID describes a method by which service providers for Virtual Private LANs can use multicast trees for routing
muilticast messages to customers in VPLS.  This extends RFC's  4761 "Virtual Private LAN Service using
BGP for Auto-Discovery and Signaling" and 4762, "Virtual Private LAN Services
over MPLS Label Distribution Protocol (LDP) Signaling".  In these RFC's, the ingress Provider Edge Device (ingress PE)
replicates a copy of the message for each relevant exit PE.  This can become a performance bottleneck when the
number of recipients is large.  This ID addresses this problem.

This ID addresses mainly internal network management, and so, as the authors point out in the Security Considerations Section,
it does not introduce many security problems other than already discussed in those RFC's, which are mainly addressed by the
security features of BGP, upon which the protocols rely.  The main security issue introduced by this draft is that neither
BGP nor VPLS provide for secrecy of the multicast tree data.  However, as the authors point out, providing such security
is the responsibility of the Service Provider managing the LAN, and this is beyond the scope of VPLS.

I do not think any modifications or extensions need to be made to the security section, but I have a couple of other questions:

This ID is described as being intended for use with RFC's 4761 and 4762, but when I checked on 4761 in the ID tracker,
it said that it is updated by 4762, although 4762 itself says nothing about this.  In that case, is there any reason to provide support for 4761?  Or was this an error in the ID tracker?

Likewise, the ID refers to both 4761 and 4762 for definitions of terms.  What happens if the two RFC's don't agree on
a definition?  Should one default to 4762, or to the RFC the implementer is using?  According to RFC 4762, the protocol
defined by the two RFC's, although they perform similar functions, are independent and incompatible, so this could
make possibly a difference.


Cathy Meadows