Requirements for Multicast Support in Virtual Private LAN Services
Note: This ballot was opened for revision 07 and is now closed.
(Sam Hartman) Discuss
Discuss (2007-12-19 for -** No value found for 'p.get_dochistory.rev' **)
The security directorate review from Stephen Hanna has received no response. Please respond. I consider the following blocking: >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. Please provide a threat analysis and please work to address or document the specific security concerns cited.
(Mark Townsley) Yes
(Jari Arkko) No Objection
(Ron Bonica) (was Discuss, No Objection) No Objection
You say " "Furthermore, in some cases, IP service providers might expect operational simplicity of VPLS. That is, they avoid direct and detailed knowledge of IP routing. In this case, the multicast delivery mechanism is expected to have not only efficiency but also simplicity. Generally speaking, there is a trade-off between efficiency and simplicity in terms of bandwidth usage and state maintenance, so the optimum trade-off will vary depending on the requirements of each IP service provider." The argument about "operational simplicity of VPLS" relative to layer 3 service is difficult to support, as instead of "direct and detailed knowledge of IP routting", one has to deal with direct and detailed knowledge of MAC addresses (including MAC address learning), and layer 2. Consider removing the entire paragraph Also, you say: "A solution SHOULD honor customer multicast domains." Perhaps replace with "A solution SHOULD NOT alter customer multicast domains' boundaries", as it is not clear what "honor .. multicast domains" really means. Otherwise, clarify what "honor" means. Also, you say: "Multicast forwarding restoration time MUST NOT be greater than the restoration time of a customer's Layer-3 multicast protocols. For example, if a customer uses PIM with default configuration, hello hold timer is 105 seconds, and solutions are required to detect a failure no later than this period." The above mixes *restoration* time at layer 3 with *detection* time at the VPLS infrastructure. Does not seems to be correct. Also, you say: Therefore, in addition to the L2VPN discovery requirements in [RFC4665], a multicast VPLS solution SHOULD provide a method that dynamically allows multicast membership information to be discovered by PEs. Such membership information is, for example, a set of multicast addresses. What information is provided dynamically is solution specific." This paragraph mixes several issues that should probably be unbundled. First of all, unless a solution supports (A), as defined in 3.2, there is little point in PEs' dynamically discovering multicast membership info. So, "SHOULD" be conditioned on supporting (A). Second in one scenario a PE discovers multicast membership info from only the sites connected to that PE, while in another scenario in addition to the previous scenario the PE discovers multicast membership info from other PEs as well. The spec needs to spell out what exactly it means by "dynamically allow multicast membership information to be discovered by PEs".
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
(Dan Romascanu) No Objection
I have a number of comments, none of them is blocking, but I would suggest to consider them before the document is published. 1. Section 1.1: > It is also necessary as customer routers are now likely to be running IP multicast protocols and those routers and connected to switches that will be handling large amounts of multicast traffic. This phrase is incomplete, needs some edits to clarify syntax. 2. In section 1.2 and a couple of more places the word NOT is capitalized without being part of a capitalized key-word as per RFC 2119 - like in 'Also, this document does NOT aim to express ...'. I suggest to renounce this capitalization. 3. Section 5.1.1 refers to 'Ethernet control protocols employed by customers (e.g. Spanning Tree Protocol [802.1D])' There is no such thing as 'Ethernet control protocols' and IEEE 802.1D does not apply to Ethernet only. I suggest to use a different terminology - for example 'layer 2 control plane protocols running on Local Area Networks (LAN) such as Ethernet (e.g. Spanning Tree Protocol [802.1D])' 4. Sections 5.4 and 6.5.3 use the term 'standard SNMP MIB'. In the IETF management framework MIB modules are not necessarily used only with SNMP (SNMP being the protocol, and MIB modules being written in SMI). I suggest to use 'standard MIB modules' instead. 5. Section 6.5.3 includes: > - Multicast traffic statistics (total traffic forwarded, incoming, outgoing, dropped, etc., by period of time) We usually discourage devices to make computation of statistic counters by period of time, retrieval by management aplications being a better solution for several reasons. I suggest to drop 'by period of time' 6. In section 6.5.4 I suggest to replace 'SNMP-trap' by 'SNMP Notification' which is the more recent and more general term used in SNMP. 7. I suggest to use the newer IEEE 802.1D-2004 revision of the standard as a reference rather than the 1998 revision 8. IEEE 802.1ag - CFM is not longer work on progress - it was approved as IEEE 802.1ag-2007. Please update the reference.