[secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

[Stephen Kent <[e-mail]>]

I 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 is a very brief document, just 12 pages. The Abstract for this 
document, n its entirety, says: "In many existing Virtual Private LAN 
Service (VPLS) deployments based on RFC 4762, inter-domain connectivity 
has been deployed without node redundancy, or with node redundancy in a 
single domain. This document describes a solution for inter-domain VPLS 
based on RFC 4762 with node and link redundancy in both domains."

Unfortunately, this confusing wording is typical of the writing in 
several areas of this document. The RFC Editor will need to work closely 
with the authors to make this document easier to read. Also, there are 
several instances of acronyms used without expansion (e.g., ASBR), 
making reading even harder.

I like the fact that the document includes a "Motivation" section. It 
provided a good description of why a new approach to achieving 
redundancy in the VPLS context is needed.

Section 5 ends with a curious statement:

There are two PW redundancy modes defined in [RFC6870]:

Independent mode and Master/Slave mode.For the inter-

domain four-PW scenario, it is required for PEs to ensure

that the same mode is supported on the two ICCP peers in

the same RG.One method to ensure mode consistency is by

manual operation.Other methods are also possible and are

out of the scope of this document.

This says that two ASes have to ensure that both employ the same 
redundancy mode choice, notes that they can verify this manually, and 
that says there are other options to meet this requirement, but provides 
no description of the other options.Not very useful.

Sections 5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1 
and 5.1.2 both include SHOULDs, but 5.1.3 contains no analogous RFC 2119 
key words. This lack of parallelism is confusing.

Section 5.3 describes switchover operation in the more complex four PW 
cases. It contains some RFC 2119 key words, but there are several 
instances of lowercase "should". Is this intentional?

The Security Considerations section is brief, only 4 short paragraphs.It 
cites the Security Considerations sections of RFCs 4762 and 6870, plus 
the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the 
solution described here.

RFC 4762 also contains a brief Security Considerations section, 
referring the reader to RFC 4111, the PPVPN Security Framework. That 
document discusses security in detail, although most of the discussion 
does not appear to be directly applicable to the redundancy mechanisms 
of this document.

RFC 6870 is directly relevant. It contains a two-sentence Security 
Considerations section (almost a record for brevity?) with a lowercase 
"must" for emphasis? This section refers to RFC 4447, which contains a 
meaningful SC section (finally). That document mandates use of the 
TCP/MD5 option for LDP. This is almost consistent with the second 
paragraph of the SC section in this document (which weakens this to a 
MAY), but not with the third paragraph (which seems to call for TCP-AO).

The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), 
which reinforces the references in the third paragraph of this SC, but 
is inconsistent with the second paragraph!

The second paragraph in the SC section of this document uses a lowercase 
"could." I wonder if this should be uppercase, as per RFC 6919 J? The 
next paragraph directs implementers to three RFCs (6941, 6952, and 
5925), and specifically cites TCP-AO. This is confusing guidance, given 
the MAY for TCP/MD5 use with LDP in the previous paragraph. Merely 
calling attention to these docs is not useful guidance.

The final paragraph of this section contains two obvious spelling errors 
in the first sentence:

The *activitiy* on the inter-domain and intra-domain

pseudowire may cause security threats or be exploited to

create denial of service *attackes*.

Even if the spelling errors are corrected, it is not clear what value 
this sentence adds. The remaining two sentences of the paragraph provide 
useful guidance, and thus should be retained.

My bottom line: the SC section of this document is internally 
inconsistent and conflicts with SC guidance in several of the other docs 
cited in the SC section. This needs