Re: [Idr] IPSec Tunnels and draft-sajassi-bess-secure-evpn

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Sat, 01 August 2020 01:18 UTC

Return-Path: <sajassi@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7A73A0E39; Fri, 31 Jul 2020 18:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=hwSkzFhP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AkFYhk/f
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 wvtpe9YeFHQH; Fri, 31 Jul 2020 18:18:19 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266893A0E31; Fri, 31 Jul 2020 18:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28139; q=dns/txt; s=iport; t=1596244699; x=1597454299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gU7TbdgkljqarJ2HRQf7xWiHM9DFg0Z5pWl7glHHpRk=; b=hwSkzFhPo9rVI0LUAcZahK7Q2PfKQGrZPuSlRnp2ThxCkzwmS941V45T g0zS36fGzVzht3Sp5DOtcvi4Q76eDp1tu2urIYj3smI7v4xjfUXUkSrXF hf5hYPZHhvwUp0ZG++hs5dHBiqePde4XqNdfM624RASEtEEER2d3z8aaS E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AgRQIUxSkjAnDuC2DP6ygLEBLT9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J7f5Wi6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutYVHAoju56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClBQAfwiRf/4ENJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoEjLykoB29YLyyENYNGA41QgQKXYIFCgREDVQsBAQEMAQE?= =?us-ascii?q?lCAIEAQGETAIXghwCJDgTAgMBAQsBAQUBAQECAQYEbYUvCCUMhXEBAQEEEgs?= =?us-ascii?q?GHQEBNwEPAgEIDgMDAQEBKAMCAgIwFAkIAQEEAQ0FFAcHgwQBgX5NAy4BDqZ?= =?us-ascii?q?kAoE5iGF2gTKDAQEBBYFHQUKCWxiCDgMGgTiCcINfhj8aggCBESccgU9JNT6?= =?us-ascii?q?CXAEBAgEBgUE6DQmCYDOCLY9IGAojgmaGXZs5gQUKgmCIXJEoAx6Ce4lMg0S?= =?us-ascii?q?PbI1ehEWBaohJlHACBAIEBQIOAQEFgWojgVdwFTsNDRABgj5QFwINjCyBcww?= =?us-ascii?q?FEoECAQEHgkOCQoJShUJ0NwIGAQcBAQMJfI9nAQE?=
X-IronPort-AV: E=Sophos;i="5.75,420,1589241600"; d="scan'208,217";a="788895527"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Aug 2020 01:18:16 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0711IGrl024718 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 1 Aug 2020 01:18:16 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 20:18:16 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 20:18:16 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 20:18:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=csrBcKvUlHf4pzcQSJr+enAUhGRQS99qlM/n85WJqoEYb5zo98CUTh+ZkJdYmoKlJaWP8F/5N0RyoSqwyJwkXfLxpU6XnZlD/63Tsep16TUCTcrvlAbVzEnUMalLMaHwgLgoJvQv6JB73X6an7PcIKvkpTTQqtF0lboxeaFy0X1Jg1eXmLiDWM3vTHyqJ/G9f+QTgD/ZXxDNQ4Gk4ZzuCueYzzJNJNxqPiXvcHMRvLDeP7W8SSgLviB5EPh7/uk6rb0GvJDsuPIL6qxlwX3xo0A8ztDFFNWR9EOyQCmcYFsV9y5nEaMgF4CP6FC2RBrvheoVQnsZpDyhIlHmdARrtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gU7TbdgkljqarJ2HRQf7xWiHM9DFg0Z5pWl7glHHpRk=; b=WBen/GT86MEo57bgDnxWiBL5Gz1CWVPNstnZcfPlnf3t8qIv8WED5RvmXXm/F2e3B55KnYe2xL+YHWWaSnp+uAeSDJ94gsTOE99+aBk/pAWw812hbvCD1x8egaUNcsIbfpYgwipawc+2X25+1PkCuB+GAc7fRAtVygUewqhcEf7OxivVKA6RXh7Dtvvkss2mUKn4DKrIwofTG7rsMhmO+I7wONk3U1bRE6lu9Xv8CTb3fzT08xBeYq4OaHnfQDupBU5BT4nXGk5438iamNOksc+TeKsTmg1oh4Zh0SKJKEGRTCCBlqQs654tIaMuyEaCcbGtzrvUgN5PBx616od8qg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gU7TbdgkljqarJ2HRQf7xWiHM9DFg0Z5pWl7glHHpRk=; b=AkFYhk/f1xvkC0HNgfsJHc3Jxgra0Dq14sfmg3BqFnV+PXmtWlAEjnGzgByA/bzeI28JFkB7KrtxLuJ5XvV8/11gELCb6wcdEhAd1XMxrDwLqsUcpX35sQ25NpgBvM3F1Km17ioQg36bbD6v+O1r80M5iitgpYs+74qrSyPFzMc=
Received: from BY5PR11MB4260.namprd11.prod.outlook.com (2603:10b6:a03:1ba::30) by BY5PR11MB3974.namprd11.prod.outlook.com (2603:10b6:a03:183::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Sat, 1 Aug 2020 01:18:15 +0000
Received: from BY5PR11MB4260.namprd11.prod.outlook.com ([fe80::7d6c:d61b:95de:2f7c]) by BY5PR11MB4260.namprd11.prod.outlook.com ([fe80::7d6c:d61b:95de:2f7c%6]) with mapi id 15.20.3239.020; Sat, 1 Aug 2020 01:18:15 +0000
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Susan Hares <shares@ndzh.com>, "bess@ietf.org" <bess@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: IPSec Tunnels and draft-sajassi-bess-secure-evpn
Thread-Index: AdZk8izhjCdDx5/XSYuR36KvQpfiTAB0hUQAABuHzYAADSRigA==
Date: Sat, 1 Aug 2020 01:18:15 +0000
Message-ID: <81323BB6-3CB2-4D95-BAAE-12B798267FB8@cisco.com>
References: <007f01d664f3$e2b14ff0$a813efd0$@ndzh.com> <8A0EAEEB-52CA-48CB-BA5E-C64DFED1EEEF@cisco.com> <00ff01d66732$61fc9fe0$25f5dfa0$@ndzh.com>
In-Reply-To: <00ff01d66732$61fc9fe0$25f5dfa0$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:648:8800:39a0:58b5:2f9:7863:2cd5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 22ae94fa-79a6-4ab9-7270-08d835b8c410
x-ms-traffictypediagnostic: BY5PR11MB3974:
x-microsoft-antispam-prvs: <BY5PR11MB3974F4DD1221054EB71B3CE6B04F0@BY5PR11MB3974.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1PFrI6atP+OYdQkZqOKVHVH5YNUoEU5Z/95KoTtxLpJf8Ob/JpTirJ2pif0T6GTBGTxYaQcs0M7QldTCiezfUIXOsGqcEwz0P5rWxWGR6Ei6MchXzMAHlBPWE/dZ2q+gtqZOjIisNaUgUj05bX2YvGK41qgyOg8oUmrJcA89dK4Q+7c0NR4fIPIBNKVzvLtKtbn4sG9myj9NH2BXXW5ZEfHTBfXbbzvSXHvOCA+InFhI7+eUn7ZnGxKYow//NPSBCW1a1gFutsoZUvSfV5bHYwGqHfL6DgzRawO/y5rLdGoDyxu1lBygvfRhHT/TN/QBQ3DIC0S5tm/GHwmyUqQdYHvLUsGoxNuQwk6dc+Mncfz402lDfeLqv6e1Pn0p3byKatT7vBXu12jOfU9TlAYs7Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4260.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(64756008)(186003)(6506007)(6512007)(4326008)(316002)(5660300002)(6486002)(8676002)(53546011)(71200400001)(110136005)(8936002)(66946007)(2616005)(83380400001)(966005)(76116006)(478600001)(166002)(66476007)(66446008)(66556008)(33656002)(86362001)(36756003)(4743002)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: CVkEIokTXXfnxNJI4XzsgtcQ0c7QOssXm4OIoRzZyKmE/pfUxUHgQP2DyYqz32JohpQlIBuU025kKNGqvRfUg2V8pdYrGorhtkelmHwQsJV+3lRMwj7y9NNQaZWOpYg8CKVtxYYUVxR3UKgrqDtRZmMUe7iHtEsEHS54kvJRbD2h5hyADiPCUgFFdCHXeN8D2r3AE5HjtZyo/eTp/TcHbA/wfKFrVt+qnrV97e2sBRO1LU55XUPyEiT5bp3CONFHSyND8DX+T+wehnAJRzcCLPbLBut/iIENxSMvaexCX7dFen3kzFD8/Pfu4bN2uZg7JA0A13a2S7VxtNLihY3P7aZdkmwNVbRKzOg7ggAuiYO1vWFT4v2ZiGxjZPZwQ9E+5sVrucIDKg8Otew9HVRE4XMDuD5EWzi3yY9fsxgTho1G3MiTNkgnfRp1Ihr9ru0s+8ZWraTErBHFMWDwx/vNA6aHEbwPzU9WO+gFT4HtfUNnynAMWXmFxuasf+AY4x9UNyAasvgAwPME8W9TkX+fpi9QBPyDs6ubKOXgsdlHXi1xJRUNJM/oQiHq2PHxNNLIfBtbhG6sBTSggSPqTWEmc/nLoL4ZbatvcRkoCsZ90+Qym7gQix440vOjoMRUP3FSCSr9zOdZPJ4HYtyrgs/0kwkNT3m1M9VbpOEOZXvjN+Z95Xlw3zirPGXyautaxeep9jp2VFpuKuslWcWGa8Va9g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_81323BB63CB24D95BAAE12B798267FB8ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4260.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22ae94fa-79a6-4ab9-7270-08d835b8c410
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2020 01:18:15.1652 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MRSTtnbq6vOQBx/jYkOPOz00g86Hi7gTyaQpM/KkxXdAMGX2YDQy9DvVcjotxiIqlWDA5NM5fVoq930fI/xFxA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3974
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HCEhAnE400nV3ZyLBLUpZrWQVcg>
Subject: Re: [Idr] IPSec Tunnels and draft-sajassi-bess-secure-evpn
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Aug 2020 01:18:23 -0000

Sue,

I am afraid if we don’t clean up the draft, it can cause confusion as it has already and result in immediate errata filing for it after publication. A sub-bullet got added to the latest rev (rev17) that is not correct. It says that the VxLAN sub-tlv is sent with EVPN route when V bit not set. However, EVPN never uses this sub-tlv as its routes has all the needed info. Furthermore, RFC 8365 is very clear that EVPN uses Tunnel Encapsulation Extended Community (per section 4.1). As I said, I am not aware of any of the vendors using these sub-TVLs and it is easy to have a quick poll.

Regarding the paragraph that got omitted, it is making it much more ambiguous than it used to. I would opt for clarifying the paragraph rather than removing it. If needed I can provide an updated paragraph. Section 9 of RFC 8365 specifies how a VPN multicast route can be advertised with PMSI tunnel attribute and Encapsulation extended community and has been implemented by many vendors.

Cheers,
Ali


From: Susan Hares <shares@ndzh.com>
Date: Friday, July 31, 2020 at 5:02 AM
To: Cisco Employee <sajassi@cisco.com>om>, "bess@ietf.org" <bess@ietf.org>rg>, "idr@ietf.org" <idr@ietf.org>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <jun.hu@nokia.com>
Subject: RE: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali:

It is wise to start with the RFC6514 and the draft-ietf-idr-tunnel-encapsulation draft.

[WG chair hat on]
The tunnel-encapsulation draft has passed general WG LC – so it is inappropriate to call for the request to remove these sections.  The WG LC that is currently running is whether to remove the “AS” field from the tunnel endpoint field, and replace it with a reserved field.

The implementation page is on:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations

If you wish to provide information on the cisco implementation, you are welcome to add information on the page.
I can call for an update to the page from vendors.

[WG chair hat off[
[Document shepherd hat on]

The issue is during the edits the text from RFC6514 from Eric Rosen was unclear.  The text was:



   It has been suggested that it may sometimes be useful to attach a
   Tunnel Encapsulation attribute to a BGP UPDATE message that is also
   carrying a PMSI (Provider Multicast Service Interface) Tunnel
   attribute [RFC6514<https://datatracker.ietf.org/doc/html/rfc6514>]4>].  If the PMSI Tunnel attribute specifies an IP
   tunnel, the Tunnel Encapsulation attribute could be used to provide
   additional information about the IP tunnel.  The usage of the Tunnel
   Encapsulation attribute in combination with the PMSI Tunnel attribute
   is outside the scope of this document.

Since the text itself was unclear what additional information could be provided, the authors removed it from the draft.

As we had not received any feedback about active RFC6514 interactions on the list.

[document shepherd off]

If you have an implementation of the interaction between the RF6514 and tunnel encapsulation, it would be valuable to provide:

a)  either a draft specifying the interaction you wish to IDR WG, or
b)  comments that could replace the original the original text.

Since the IDR draft has gone through multiple WG LC and a very complete review from Alvaro – so a quick response would be appreciated.   IMHO a draft on the interaction between RFC6514 and the tunnel-encapsulation draft – would be the best thing at this point.  Let me know if you are interested in working on such a draft.

Sue


From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Friday, July 31, 2020 1:54 AM
To: Susan Hares; bess@ietf.org; idr@ietf.org
Cc: 'Hu, Jun (Nokia - US/Mountain View)'
Subject: Re: IPSec Tunnels and draft-sajassi-bess-secure-evpn

<added idr@ietf.org>

Sue,

Before getting to the discussions of the three IPsec proposals, there are some elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have caused some confusions and I’d like to get those sorted out first.

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has implemented these sub-tlvs because the info in these sub-tlv already exist in EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have implemented it. Therefore, all the vendors that I am aware of use Extended Community  defined in section 4.1  along with EVPN routes to signal VxLAN and GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE encap! So, as the first step, we should remove these three sections from the draft if there is no objection.

Cheers,
Ali

From: Susan Hares <shares@ndzh.com>
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee <sajassi@cisco.com>om>, "bess@ietf.org" <bess@ietf.org>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <jun.hu@nokia.com>
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

IDR has 3 proposals for IPsec tunnels that impact draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have been discussing these three drafts (Ali and two other authors sets) to try to find out if we can have one general solutions.

The discussion has been very fruitful to point up BGP issues of interoperability, security, privacy, manageability, and scaling.  For example, there is a lack of a clear specification between RFC6514 (PMSI tunnel attribute) and the tunnel-encaps draft that specifies how these drafts interoperate.  I suspect the bess and idr chairs will need to discuss if tunnel-encaps has to address this point.

I wrote up my ideas in draft-hares-idr-bgp-ipsec-analysis-00.txt so the authors could tell me what I misunderstood.   You’ll find this draft stops half way.  I have the rest of the draft written, but I wanted feedback from all the author teams before sending it out.

After hearing some of the details from the authors, I would like to sponsor an IDR interim so we could discuss these issues at length.   If you think this is a good idea, please let me know.

One other thing… unfortunately, I scheduled a set of meetings for EDT time after IETF meetings this week.   Your next response will occur from 11-16 UTC on Wednesday.

Cheerily, Sue