Re: [bess] Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS)

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Fri, 27 October 2017 18:06 UTC

Return-Path: <sajassi@cisco.com>
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 D115B13F088; Fri, 27 Oct 2017 11:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 CQu1F0YhEU25; Fri, 27 Oct 2017 11:06:41 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB8E138BE7; Fri, 27 Oct 2017 11:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13043; q=dns/txt; s=iport; t=1509127601; x=1510337201; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KkwlVkB+fcrORLusTSgtKi9jIegD56KRNAgKDhMVPJI=; b=YbkDgXkAfn+O81Qcwo1mQSmwmidFnFOpepfU5oPlIpwgcVMxNZxGcgbQ 6B/RjJpBAgpbFIylsqH9cfMwclartXOMue/LZe3yI0NTC7oU17YdZSDTG RfnN0nvQ9moVc49atnO3fI/g0Yjwin/xaFaieuORucna21/47W4RqGHJ8 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DrAQDzdPNZ/40NJK1cGQEBAQEBAQEBAQEBBwEBAQEBgm9wZG4nB50mgXqQfYVVggEKI4UYAoRLQxQBAgEBAQEBAQFrKIUdAQEBAQN5EAIBCBEDAQIoBzIUCQgCBAENBRuJJGQQqywmikQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMuggeDOYMqhFIBEgE/hVYFiiWIAoZbiQECh2SDZ4kvghWGAIsYjF+JBAIRGQGBOAE2IYEDTBl6FYMtaYF4F4FndwGJL4EkgREBAQE
X-IronPort-AV: E=Sophos; i="5.44,304,1505779200"; d="scan'208,217"; a="23093105"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2017 18:06:40 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9RI6deB032432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2017 18:06:40 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 14:06:39 -0400
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; Fri, 27 Oct 2017 14:06:39 -0400
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, 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-bess-evpn-etree@ietf.org" <draft-ietf-bess-evpn-etree@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS)
Thread-Index: AQHTKZpraKgO8hij10mk8mmYwytVR6LHTAkAgAAzgwCAMJeXAA==
Date: Fri, 27 Oct 2017 18:06:39 +0000
Message-ID: <D618BF3A.227070%sajassi@cisco.com>
References: <150498212906.8167.3812629658977416528.idtracker@ietfa.amsl.com> <CABcZeBP=vnWupC2FAw51M1MYPyc0kPt+xx5d3T1Q8soPC6rHkQ@mail.gmail.com> <BA928107-421C-4A37-8ADC-3041E8DDF054@cisco.com>
In-Reply-To: <BA928107-421C-4A37-8ADC-3041E8DDF054@cisco.com>
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.53]
Content-Type: multipart/alternative; boundary="_000_D618BF3A227070sajassiciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/zQDDoPLDf-VPxeQ-qg-Le9cTIZQ>
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 <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2017 18:06:44 -0000

Hi Eric,

The "leaf" or "root" 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 "leaf" designation to a "root". I added "the network operator / service provider" 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 exchange among "Leaf" sites of that VPN through ingress filtering for known unicast 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 designation 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 (leaf or root) before activating the AC."

Cheers,
Ali

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

Hi!

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

I just poked the authors...

Alvaro.

On 9/26/17, 5:59 AM, "Eric Rescorla" <ekr@rtfm.com<mailto: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 <ekr@rtfm.com<mailto:ekr@rtfm.com>> 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 to 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 security
is).