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

["Lizhong Jin" <[e-mail]>]

Hi Stephen,

Thank you for the detail review. See my reply inline below.

 

Regards

Lizhong

 

From: Stephen Kent [mailto:[e-mail]] 
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Adrian Farrel; [e-mail]; [e-mail]
Subject: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

 

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.

[Lizhong] I try to rephrase the abstract below to make it more clear. I will check again for the acronyms in detail. BTW, the ASBR has been expanded in section 3 line 193.

In many existing RFC 4762 based Virtual Private LAN Service (VPLS) inter-domain deployments, the pseudowire (PW) connectivity has been deployed without node redundancy, or with node redundancy only in a single domain. That will take high risk of service interruption, since at least one domain will not have PW node redundancy.  This document describes a inter-domain VPLS solution which could provide PW node redundancy in both domains.

 

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.

 [Lizhong] I think the text is OK. If you insist, I could remove.

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.

 [Lizhong] accepted.

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?

 [Lizhong] I will check again, some is intentional, but some is not.

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).

 [Lizhong] RFC6870 SC is only valid for PW control plane. The second, third and fourth paragraph is described for ICCP control plane. I will make that clear in the text.

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 

 

[Lizhong] thank you for the comments. I tend to remove the conflict parts with [I-D.ietf-pwe3-iccp], and only describe the new security considerations. Please help to review the following text:

Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this document will have additional security consideration for ICCP control plane.

 

In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed and highly monitored network. This should be ensured by the operator.

 

The state flapping on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial of service attacks.  For example, excessive pseudowire state flapping (e.g., by malicious peer PE's implementation) may lead to excessive ICCP exchanges. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate such types of attacks.