Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F9D128959; Thu, 30 Nov 2017 10:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hk_bkUfoI2Xu; Thu, 30 Nov 2017 10:46:10 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3981126CC4; Thu, 30 Nov 2017 10:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20951; q=dns/txt; s=iport; t=1512067570; x=1513277170; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ol6D9FUwoPLjxzzBTg4UFhUsxG2plLpL4e+nDp9oGqU=; b=bgNMa7SULeunVc5xJnS9EkZ4EiZw45Gxe0bVxZpDQ+M8RNr6jiRFEhOq xdU9RnR96CSei/2lA1/vq9yr7/3S6Ssc/9CkXSidw9fo8NCpOA/TJm9sJ EQcuT+xl5SO90+pSQjqec4RQguHXDOfK1jwwlKaO4qmazNePUollN8Ni0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAwBjUSBa/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuFRIHnG0egX2Ia44bggEKI4UYAoUhQxQBAQEBAQEBAQF?= =?us-ascii?q?rKIUfAQEBBHkQAgEIEQMBAigHIREUCQgCBAENBRuJI0wDFRCoOCaHDw2DJAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFg0GBYCmDP4MrgmtHgTsBEgE/hVgFikGOcIh?= =?us-ascii?q?tPQKHcoNrhDiEeoIWhg+LLox6PYhhAhEZAYE5ATYiYVgYbxWCY1+BeBeBZ3gBh?= =?us-ascii?q?0qBJIEUAQEB?= X-IronPort-AV: E=Sophos; i="5.45,341,1508803200"; d="scan'208,217"; a="38034180" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 18:46:08 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAUIk8ab029207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 18:46:08 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 13:46:07 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1320.000; Thu, 30 Nov 2017 13:46:07 -0500 From: "Ali Sajassi (sajassi)" To: "Ali Sajassi (sajassi)" , Eric Rescorla , The IESG , Alvaro Retana CC: "thomas.morin@orange.com" , "bess-chairs@ietf.org" , "draft-ietf-bess-evpn-etree@ietf.org" , "bess@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS) Thread-Index: AQHTKZpraKgO8hij10mk8mmYwytVR6LHTAkAgAAzgwCAMJeXAIAUqrUAgCDPmoA= Date: Thu, 30 Nov 2017 18:46:07 +0000 Message-ID: References: <150498212906.8167.3812629658977416528.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/alternative; boundary="_000_D6458F0D22DF89sajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 18:46:13 -0000 --_000_D6458F0D22DF89sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alvaro, I have addressed all the comments from IESG (including Eric Rescorla=92s co= mments) but the status of this draft still shows "AD Followup". Can you ple= ase progress this draft and let me know if there is anything else you need = from me. Regards, Ali From: Cisco Employee > Date: Thursday, November 9, 2017 at 1:42 PM To: Cisco Employee >, Eric Resc= orla >, The IESG >, Alvaro Retana > Cc: "thomas.morin@orange.com" >, "bess-chairs@ietf.org" >,= "draft-ietf-bess-evpn-etree@ietf.org" >, "bess@ietf.org" > Subject: Re: Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (wit= h DISCUSS) Hi Eric, Let me know if you have any further questions/comments. Cheers, Ali From: Cisco Employee > Date: Friday, October 27, 2017 at 10:06 AM To: "Alvaro Retana (aretana)" >= , Eric Rescorla >, The IESG > Cc: "thomas.morin@orange.com" >, "bess-chairs@ietf.org" >,= "draft-ietf-bess-evpn-etree@ietf.org" >, "bess@ietf.org" > Subject: Re: Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (wit= h DISCUSS) Resent-From: > Resent-To: Cisco Employee >, >, >, >, >, > Resent-Date: Friday, October 27, 2017 at 10:06 AM Hi Eric, The =93leaf=94 or =93root=94 designation of an Attachment Circuit (AC) is d= one by the operator / service provider on the PE device (and not on a CE). = So, CE device has no control in changing a =93leaf=94 designation to a =93r= oot=94. I added =93the network operator / service provider=94 to the text. = Furthermore, I added additional text to address your second concern (e.g., = regarding how to avoid any exchange among leaf ACs): "Furthermore, this document provides additional security check by allowing = sites (or ACs) of an EVPN instance to be designated as "Root" or "Leaf" by = the network operator/ service provider and thus preventing any traffic exch= ange among "Leaf" sites of that VPN through ingress filtering for known uni= cast traffic and egress filtering for BUM traffic. Since by default and for= the purpose of backward compatibility, an AC that doesn't have a leaf desi= gnation is considered as a root AC, in order to avoid any traffic exchange= among leaf ACs, the operator SHOULD configure the AC with a proper role (l= eaf or root) before activating the AC." Cheers, Ali From: "Alvaro Retana (aretana)" > Date: Tuesday, September 26, 2017 at 6:03 AM To: Eric Rescorla >, The IESG > Cc: "thomas.morin@orange.com" >, "bess-chairs@ietf.org" >,= "draft-ietf-bess-evpn-etree@ietf.org" >, "bess@ietf.org" > Subject: Re: Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (wit= h DISCUSS) Resent-From: > Resent-To: Cisco Employee >, >, >, >, >, > Resent-Date: Tuesday, September 26, 2017 at 6:03 AM Hi! I don=92t have anything in my archive either. :-( I just poked the authors=85 Alvaro. On 9/26/17, 5:59 AM, "Eric Rescorla" > wr= ote: I have some memory that someone responded that this wasn't a security requi= rement, but I can't find that now. -Ekr On Sat, Sep 9, 2017 at 11:35 AM, Eric Rescorla > wrote: Eric Rescorla has entered the following ballot position for draft-ietf-bess-evpn-etree-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It's not clear to me if the prohibition on leaf-to-leaf communications is intended to be a security requirement. If so, it seems like it needs to explicitly state why it is not possible for ACs which are leaf to pretend t= o be root. If not, then it should say so. Additionally, this solution appears to rely very heavily on filtering, so I believe some text about what happens during periods of filtering inconsistency (and what the impact on the secur= ity is). --_000_D6458F0D22DF89sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Alvaro, 

I have addressed all the comments from IESG (including Eric Rescorla= =92s comments) but the status of this draft still shows "AD Followup&q= uot;. Can you please progress this draft and let me know if there is anythi= ng else you need from me.

Regards,
Ali

From: Cisco Employee <sajassi@cisco.com>
Date: Thursday, November 9, 2017 at= 1:42 PM
To: Cisco Employee <sajassi@cisco.com>, Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>
Cc: "thomas.morin@orange.com" <thomas.morin@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "draft-ietf-be= ss-evpn-etree@ietf.org" <draft-ietf-bess-evpn-etree@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: Eric Rescorla's Discus= s on draft-ietf-bess-evpn-etree-13: (with DISCUSS)

Hi Eric,

Let me know if you have any further questions/comments.

Cheers,
Ali

From: Cisco Employee <sajassi@cisco.com>
Date: Friday, October 27, 2017 at 1= 0:06 AM
To: "Alvaro Retana (aretana)&q= uot; <aretana@cisco.com>, Er= ic Rescorla <ekr@rtfm.com>, The I= ESG <iesg@ietf.org>
Cc: "thomas.morin@orange.com" <thomas.morin@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "draft-ietf-be= ss-evpn-etree@ietf.org" <draft-ietf-bess-evpn-etree@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: Eric Rescorla's Discus= s on draft-ietf-bess-evpn-etree-13: (with DISCUSS)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Cisco Employee <sajassi@cisco.com>, <ssalam@cisco.com>, <jdrake@juniper.net>, <ju1738@att.com>, <sboutros@vmware.com>, &l= t;jorge.rabadan@nokia.com>= ;
Resent-Date: Friday, October 27, 20= 17 at 10:06 AM

Hi Eric,

The =93leaf=94 or =93root=94 designation of an Attachment Circuit (AC)= is done by the operator / service provider on the PE device (and not on a = CE). So, CE device has no control in changing a =93leaf=94 designation to a= =93root=94. I added =93the network operator / service provider=94 to the text. Furthermore, I added additional text to address y= our second concern (e.g., regarding how to avoid any exchange among leaf AC= s): 

"Furthermore, this document provides additional security check by= allowing sites (or ACs) of an EVPN instance to be designated as "Root= " or "Leaf" by the network operator/ service provider and th= us preventing any traffic exchange among "Leaf" sites of that VPN through ingress filtering for known unicast traffic and egress fi= ltering for BUM traffic. Since by default and for the purpose of backward c= ompatibility, an AC that doesn't have a leaf designation is considered as a= root AC, in order to avoid any  traffic exchange among leaf ACs, the operator SHOULD configure the A= C with a proper role (leaf or root) before activating the AC."

Cheers,
Ali

From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Tuesday, September 26, 2017 a= t 6:03 AM
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Cc: "thomas.morin@orange.com" <thomas.morin@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "draft-ietf-be= ss-evpn-etree@ietf.org" <draft-ietf-bess-evpn-etree@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: Eric Rescorla's Discus= s on draft-ietf-bess-evpn-etree-13: (with DISCUSS)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Cisco Employee <sajassi@cisco.com>, <ssalam@cisco.com>, <jdrake@juniper.net>, <ju1738@att.com>, <sboutros@vmware.com>, &l= t;jorge.rabadan@nokia.com>= ;
Resent-Date: Tuesday, September 26,= 2017 at 6:03 AM

Hi!

 

I don=92t have anything in my archive either. :-(

 

I just poked the authors=85

 

Alvaro.

 

On 9/26/17, 5:59 AM, "Eric Rescorla" <<= a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com> wrote:

 

I have some memory that someone responded that this = wasn't a security requirement, but I can't find that now.

 

-Ekr

 

 

On Sat, Sep 9, 2017 at 11:35 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :

Eric Rescorla has ent= ered the following ballot position for
draft-ietf-bess-evpn-etree-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It's not clear to me if the prohibition on leaf-to-leaf communications is intended to be a security requirement. If so, it seems like it needs to
explicitly state why it is not possible for ACs which are leaf to pretend t= o be
root. If not, then it should say so. Additionally, this solution appears to=
rely very heavily on filtering, so I believe some text about what happens during periods of filtering inconsistency (and what the impact on the secur= ity
is).



 

 --_000_D6458F0D22DF89sajassiciscocom_--