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

Stephen Kent <> Thu, 17 April 2014 13:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 017B81A016D for <>; Thu, 17 Apr 2014 06:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q8ITWbMbvFPp for <>; Thu, 17 Apr 2014 06:55:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B3B391A0180 for <>; Thu, 17 Apr 2014 06:55:41 -0700 (PDT)
Received: from ([]:55113 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1Wammx-0006z8-3I; Thu, 17 Apr 2014 09:55:39 -0400
Message-ID: <>
Date: Thu, 17 Apr 2014 09:55:27 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Lizhong Jin <>, 'secdir' <>,,,,, 'Adrian Farrel' <>,,
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060704020708070501060607"
Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Apr 2014 13:55:49 -0000


Thanks for the quick reply.
> Hi Stephen,
> Thank you for the detail review. See my reply inline below.
> Regards
> Lizhong
> *From:*Stephen Kent []
> *Sent:* Wednesday, April 16, 2014 5:05 AM
> *To:* secdir;;; 
>;;; Adrian Farrel; 
> *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.
The first use of ASBR is before then, I believe.
The convention is to expand an acronym on first use.
> 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 think it would be clearer to say:

In many existing Virtual Private LAN Service (VPLS) inter-domain 
deployments (based on RFC 4762), pseudowire (PW) connectivity offers no 
node redundancy, or offers node redundancy only with a single domain. 
This deployment approach incurs a high risk of service interruption, 
since at least one domain will not offer PW node redundancy. This 
document describes an inter-domain VPLS solution that provides PW node 
redundancy across 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.
the text is not OK, because its states that there are multiple ways to 
ensure consistency, but  identifies only one.
> ...
> 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.
If you are defining rules for how to achieve switchover, use of 
non-normative text is not
of much value.
> 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.
> ...
> [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.
This is clearer.