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 late last call comments. This document describes requirements for multicast support in Virtual Private LAN Services (VPLS). This is not an area of particular expertise for me but I have considerable experience with multicast and security so I think this analysis is at least worthy of consideration. *Overall Clarity and Quality* The document is fairly clear in its description of requirements. The reader must consult a large number of referenced documents but this is not unusual in modern IETF specifications. I'm pleased to see this relative clarity since vagueness can easily lead to misunderstandings, interoperability problems, and security holes. *Security Analysis* Unfortunately, the document does not contain a systematic security analysis of the problem. The Security Considerations section consists of two brief paragraphs. These paragraphs refer to other sections in the document where security requirements are listed and to RFC 4665, which also lists security requirements. However, I could not find any methodical threat analysis listing the possible threats relevant to the system and stating which ones are protected against and which are not. Without a thorough threat analysis, I have little confidence that the authors have thought carefully about the possible threats to the system. I would expect this to lead to large gaps in the security requirements and this seems to be borne out in practice. For example, there is no discussion of threats due to compromise of components within the service provider network. Even more troublesome, I think that a single node at a customer site (presumably untrusted) can mount dangerous attacks. For example, a node that joins many multicast groups can cause a large amount of state to be maintained in the L2VPN. While section 6.6 of the document says that "a multicast VPLS solution SHOULD have mechanisms to protect a SP network from [...] high volumes of valid/invalid customer control packets", it is not clear how this protection will be provided. If it takes the form of limiting the number of control packets, one node can exhaust the customer's quota and effectively shut down the ability for other nodes at that site to join multicast groups. In fact, later in that section it is stated that "policing [to limit unwanted data traffic] MAY be configurable to the sum of unicast, multicast, broadcast and unknown unicast traffic". If this was implemented, one node at a customer site could bring down all incoming multicast AND unicast traffic to the site by joining a few high-traffic multicast groups. I expect that this is not what the authors had in mind but it's permissible according to the requirements contained in this document. Section 6.6 of the document contains most of the security requirements in the document. However, many of these are SHOULDs or even MAYs. At least, the document should describe the negative effects of not meeting these weak requirements. What threats are not protected against? I suspect that when this is done, the Working Group may reconsider the weakness of these requirements. Although I recognize that unicast traffic to unknown destinations is out of scope for this document, it is mentioned. I am concerned that security issues related to such traffic may be falling through the cracks and not be covered by any specification. If this traffic can cause flooding and then state maintenance in the L2VPN, there may be threats where a malicious node sends such traffic to a variety of unknown destinations to cause excess traffic and state in the L2VPN. *Conclusion* I recommend that a thorough security analysis be conducted for this document and included in the document. All threats identified in this analysis should be addressed by adding a requirement pertaining to them or by explicitly stating that the threat will not be addressed and why and what the ramifications are. Until this is done, this document should not progress. To do otherwise might cause substantial damage to the security of customer networks that employ L2VPN services. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf