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

"Lizhong Jin" <lizho.jin@gmail.com> Thu, 17 April 2014 15:29 UTC

Return-Path: <lizho.jin@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477561A01DE for <secdir@ietfa.amsl.com>; Thu, 17 Apr 2014 08:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM_Vv_NOaH4c for <secdir@ietfa.amsl.com>; Thu, 17 Apr 2014 08:29:36 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 795421A015D for <secdir@ietf.org>; Thu, 17 Apr 2014 08:29:34 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id w10so478783pde.24 for <secdir@ietf.org>; Thu, 17 Apr 2014 08:29:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=8U6s/nmWn4yy5V7nr/j6vNGEove11D4fswIHhxexbC0=; b=MAGXF/I9hYfZWvSmEfRZPuhOCxexls4RGvZtTIGbv8E2zgx0mX0NU12nq9h+LVsMDC 7Hj5MtzafI9r6xDHrUB6fny5DxDTEGy4TqhYlF9H5zgpVtmjoWvFee+r309PqMMqfPX6 aGni3eKtP+2YWQw04UYLtLw9Y7cEzRINHH/wr0j8I7JaPhKMjkmKxtgDsCfMgtXZl7EF sCwCJBQodPku7y0vK5lB7EIg98ob/RYxJPKXebIMHC7CHZ/8cxCDwlUIiRuSBPwt6Zei vv1rhgUW2Ux7R1rAxjNJ3v9nb5Jd3Ffu39TQ/rg5UPmyf579U4Cz57ARzbqcy+yWFYnp pRHw==
X-Received: by 10.68.178.131 with SMTP id cy3mr16460279pbc.146.1397748570973; Thu, 17 Apr 2014 08:29:30 -0700 (PDT)
Received: from LizhongPC ([140.206.240.249]) by mx.google.com with ESMTPSA id wp3sm54192468pbc.67.2014.04.17.08.29.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Apr 2014 08:29:30 -0700 (PDT)
From: Lizhong Jin <lizho.jin@gmail.com>
To: 'Stephen Kent' <kent@bbn.com>, 'secdir' <secdir@ietf.org>, zhliu@gsta.com, chen.ran@zte.com.cn, dcai@cisco.com, ssalam@cisco.com, 'Adrian Farrel' <adrian@olddog.co.uk>, giheron@cisco.com, nabil.n.bitar@verizon.com
References: <534D9EF6.4060106@bbn.com> <534ea310.ea42420a.3358.1b44@mx.google.com> <534FDD4E.10708@bbn.com>
In-Reply-To: <534FDD4E.10708@bbn.com>
Date: Thu, 17 Apr 2014 23:29:15 +0800
Message-ID: <534ff35a.63f2440a.2a54.101f@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01CF5A94.DF8A82D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9aRLZPmwbZvW+8TQKZ2K2m8bRlagABT50g
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/614SJ2z6BFuWdCPvN-I5BYIp5vY
Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 15:29:41 -0000

Hi Stephen,

See my reply inline below. Thank you.

 

Regards

Lizhong

 

 

From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Thursday, April 17, 2014 9:55 PM
To: Lizhong Jin; 'secdir'; zhliu@gsta.com; chen.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; 'Adrian Farrel'; giheron@cisco.com; nabil.n.bitar@verizon.com
Subject: Re: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

 

Lizhong,


Thanks for the quick reply.

Hi Stephen,

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

 

Regards

Lizhong

 

From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; zhliu@gsta.com; lizho.jin@gmail.com; chen.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; nabil.n.bitar@verizon.com
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.

[Lizhong] I see the first use of ASBR now. Will fix it.





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.
[Lizhong] accepted, thank you.

 

 

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. 
[Lizhong] hope you are OK with Adrian’s proposal.

 

... 

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.

OK.



... 

 

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

Steve