Subject: secdir review of draft-ietf-l2vpn-vpls-mcast-reqts-05.txt

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 9 Nov 2007 16:52:07 -0500

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf