[secdir] SecDir review of draft-ietf-l2vpn-evpn-req-05

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Thu, 28 November 2013 02:33 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.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 796361AE074; Wed, 27 Nov 2013 18:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pDBom3riniKG; Wed, 27 Nov 2013 18:33:06 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AF1AE013; Wed, 27 Nov 2013 18:33:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYJ81789; Thu, 28 Nov 2013 02:33:04 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 02:32:33 +0000
Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 02:33:03 +0000
Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.242]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 18:32:55 -0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "Org Iesg@Ietf." <iesg@ietf.org>, "Org Secdir@Ietf." <secdir@ietf.org>, "draft-ietf-l2vpn-evpn-req.all@tools.ietf.org" <draft-ietf-l2vpn-evpn-req.all@tools.ietf.org>
Thread-Topic: SecDir review of draft-ietf-l2vpn-evpn-req-05
Thread-Index: Ac7r4iSTTLuLU6ECRayqapxZmS2AZQ==
Date: Thu, 28 Nov 2013 02:32:54 +0000
Message-ID: <36B74C19-0B78-40BC-8B7E-A161AD644DB3@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <535BD9AA8DFFA242BAAAD022513EAC31@huawei.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [secdir] SecDir review of draft-ietf-l2vpn-evpn-req-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, 28 Nov 2013 02:33:08 -0000

Dear all,
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 last call comments.

This document specify the requirement for an Ethernet VPN (EVPN) solution, to address the issues mentioned in this draft.

Some comments are below.

1. In Section 4.2, it says: 
 "The solution MUST also be able to leverage 
 work in the MPLS WG that is in progress to improve the load balancing 
 capabilities of the network based on entropy labels [RFC6790]." 

 Since this work is already published as RFC, the sentence should be rewritten as: 
 "The solution MUST also be able to leverage the MPLS load balancing 
 capabilities based on entropy labels [RFC6790]." 

2. In Section 4.2, it says: 
 "For example consider a scenario in which CE1 is multi-homed to PE1 
 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active 
 mode. Furthermore, consider that there exist three ECMPs between any 
 of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can 
 be forwarded on twelve different paths over MPLS/IP core as follow: 
 CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and 
 PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths. 
 Finally, when traffic arrives at PE3 and PE4, it gets forwarded to 
 CE2 over the Ethernet channel (aka link bundle)." 

 It seems "ECMP", "ECMP path" and "path" are messed up in this paragraph. To make it straight, the following is suggested: 
 "For example consider a scenario in which CE1 is multi-homed to PE1 
 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active 
 mode. Furthermore, consider that there exist three ECMP paths between any 
 of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can 
 be forwarded on twelve different paths over MPLS/IP core as follow: 
 CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and 
 PE2 have three paths to PE3 and PE4 for the total of twelve paths. 
 Finally, when traffic arrives at PE3 and PE4, it gets forwarded to 
 CE2 over the Ethernet channel (aka link bundle)." 

3. In Section 12 "Security Considerations", it says: 
 "...The requirement is to introduce no 
 new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC 
 learning is performed in data-plane and beyond that of [RFC4364] when 
 MAC learning is performed in control plane." 

Though BGP is used similarly in E-VPN, some new vulnerabilities will inevitably be introduced, such as MAC forgery in BGP, and how to protect against individual MACs may pose a challenge. 

4.  Section 12 "Security Considerations"
It is very brief. It does not mention when using multi-homing.


Thank you,
Tina