Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Fri, 28 June 2019 00:35 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 34067120169; Thu, 27 Jun 2019 17:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.399
X-Spam-Level:
X-Spam-Status: No, score=-14.399 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, 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=k0Mbnenf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=az2jvCuJ
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 1o5032sbqI3S; Thu, 27 Jun 2019 17:35:06 -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 0CF4E1200CD; Thu, 27 Jun 2019 17:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34155; q=dns/txt; s=iport; t=1561682105; x=1562891705; h=from:to:subject:date:message-id:mime-version; bh=WBZVOqLUYIBX01yTsZYxgav/wYSjtzhX5FEUF4Jzp3I=; b=k0Mbnenf9lYQnkcQk/Sz7qsZ0YWDSK0Lc2+hiPvCGxNpJrNSsWHgVPHU to5OijGvt6FhDtQvQ5JoJj8TZF6JwY/swoM5XuKsa5/xl+2yw5OAXlIuS 8awgS6VSWJv50KRKRSrIplYnsvMRGhjQeDTLjdl51ZfE8L6pL694wDQX1 4=;
IronPort-PHdr: 9a23:kvDbSxyZ0JQ/cyDXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZueAE/yN+XrRyc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AUAAApYBVd/5ldJa1mGwEBAQEDAQEBBwMBAQGBUwYBAQELAYEUL1ADag5HIAQLKAqED4FfgWgDhFKKCkyBaiWXP4EuFIEQA1QJAQEBDAEBJgMEAgEBgQVdgl4CF4JpIzQJDgEDAQEEAQECAQVtijcMhUoBAQUSER0BASUTEQEIEQMBAQEhBwMCBDAUCQoEARIignsEAQGBHU0DHQECDJsSAoE4iGBxgTKCeQEBBYE2AoNWAxWCEQMGgTQBi0EdF4F/gRABJwwTgh4uPoJhAQECAReBFAESASYQCQYGAQkCglIygiaMD4ELgUSEe5VmawkCgheGUo0jG4IrhxdzjSmKAIMpgTCGCI9mAgQCBAUCDgEBBYFQOA1acXAVZQGCQQkKggokERIUgzqFFIU/cgEBAQEICYEUi1qBIgExbwEB
X-IronPort-AV: E=Sophos;i="5.63,425,1557187200"; d="scan'208,217";a="571879535"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jun 2019 00:35:03 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5S0Z4XG004477 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jun 2019 00:35:04 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 19:35:03 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 19:35:03 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 19:35:03 -0500
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=DJ3wS52oYPosXhlO2AEuN4K77HvPvRW2GAGE4Ztp6NToZAVBg7n1nKWTgINXZw3ej7JZe5Epf6gBojWJMVJWK2W9q0Sh5xSxWsJvYjW3jX9M44dWx48ekl3Wf5I22Ya6cRSzPPBsoHx22lOlKrCrSnxLtVrE0qXKTSBkoUWOFWs=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WBZVOqLUYIBX01yTsZYxgav/wYSjtzhX5FEUF4Jzp3I=; b=c5BC/TRAwYEVqybC5Cn5jJ7ODcvVSaWzWm1ITc4xI53EdROXW6LBNdwcH6eqU1vADU6JcbWTh6DziFTGAmnIuY1LhavU+x8Hp7sQIPo15wYANFCWEzz/y3zHAmqj0urqZufXoEFuYniPM2DuoyfS4PwW/zeLvMyc3Av/f6kSgQU=
ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;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=WBZVOqLUYIBX01yTsZYxgav/wYSjtzhX5FEUF4Jzp3I=; b=az2jvCuJyFfBlPlSTNfrXe1Aieb6h8M5yGEyj+C4sfk9FLTmWut/9npSoawYWEFxGfKeZ/5jfd7G06KlPbTpOxg11ULMcQbgd/B4XoAToymq7I4S92R1O7k2BdhvWAPt4lM/mfmV0h8kzGnHwP+ktYuNfVzzT7J2GGYnRN3Ek+Y=
Received: from BN8PR11MB3699.namprd11.prod.outlook.com (20.178.220.95) by BN8PR11MB3555.namprd11.prod.outlook.com (20.178.218.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 00:35:01 +0000
Received: from BN8PR11MB3699.namprd11.prod.outlook.com ([fe80::bd14:30eb:9d07:7d29]) by BN8PR11MB3699.namprd11.prod.outlook.com ([fe80::bd14:30eb:9d07:7d29%6]) with mapi id 15.20.2008.018; Fri, 28 Jun 2019 00:35:01 +0000
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, John E Drake <jdrake@juniper.net>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
Thread-Index: AQHVLUlS5/02ziYTkkCgPd3xz89iuQ==
Date: Fri, 28 Jun 2019 00:35:01 +0000
Message-ID: <09D67082-2BFC-4448-BF45-7DAE2A6A9A38@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190609
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=jdrake@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-06-20T19:11:03.7993880Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=02a3f884-fb1d-482b-98e6-b0a47699f04b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sajassi@cisco.com;
x-originating-ip: [128.107.241.164]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2bc7ce04-3cfd-4cd8-3004-08d6fb607510
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN8PR11MB3555;
x-ms-traffictypediagnostic: BN8PR11MB3555:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BN8PR11MB355540F589E235772F0A9ED2B0FC0@BN8PR11MB3555.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00826B6158
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(346002)(39860400002)(396003)(136003)(376002)(366004)(199004)(189003)(8936002)(2616005)(71200400001)(71190400001)(64756008)(7736002)(66556008)(2906002)(81166006)(81156014)(8676002)(99286004)(26005)(53546011)(6506007)(3846002)(186003)(66946007)(6116002)(476003)(486006)(5024004)(76116006)(86362001)(236005)(73956011)(256004)(66476007)(102836004)(6486002)(229853002)(36756003)(66574012)(6512007)(2201001)(53936002)(5660300002)(1941001)(6306002)(6436002)(54896002)(91956017)(68736007)(25786009)(58126008)(6246003)(14444005)(606006)(316002)(66446008)(33656002)(110136005)(478600001)(66066001)(14454004)(2501003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3555; H:BN8PR11MB3699.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: IjWk7un8dn0t9AK+v0I8v2bF6SQiDiFYnlrMKZAEZ0+8PfG700Y187fR1dm3osgezSqvLMY9imYmT6iUm5NZqPRB7Vw2dNpPDhGOopRvyJoC8hck0avxqT3cZhTPgk4oh5BErefAEvNT61QK5HqzsTvcBZ3GizN9yoMXuqTHsUV9vE4LVwlBzs+6B8u66jso5QRyE2k0p4ZeFwYJjOWE3JWS3u3IZ+6SyvmkRDF0z6tD1bnIkvAlG/1/mcZlU73tSvJupxMBVICMJLWM6trQcs+IsyWgdx+vtviGCF0MgqbltLSFd14YaLewBktijaYPq0/tWOXGo9UJh2g7k7PZzAVZizbeBaY9qZMfVLZS2fdpLNaYWpH8f6NbXaVqAhaEfmxEsjEAOw4GJ9G7JnIzTlqud29b+UStPasqItgRJZE=
Content-Type: multipart/alternative; boundary="_000_09D670822BFC4448BF457DAE2A6A9A38ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bc7ce04-3cfd-4cd8-3004-08d6fb607510
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 00:35:01.6772 (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: sajassi@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3555
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BTgmEMAh-ClSqWb2tfQaXiYxHqo>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
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: Fri, 28 Jun 2019 00:35:10 -0000

Linda,

Those addresses stated in quoted paragraph are NOT all Client Routes  - AFI/SAFI 1/1 and 2/1 are not VPN routes. The routes can represent BGP IPv4 or IPv6 routes as well. Please refer to section 7 of [Tunnel-Encap]. It provides a nice example. You can consider U1 as VPN4/v6 route update and U2 and IPv4/v update.

Cheers,
Ali

From: Idr <idr-bounces@ietf.org> on behalf of Linda Dunbar <linda.dunbar@futurewei.com>
Date: Thursday, June 20, 2019 at 4:09 PM
To: John E Drake <jdrake@juniper.net>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

Those addresses stated in the quoted paragraphs are for Clients Routes, i.e. the routes attached to the PE, not the PE’s lookback address, correct?
The Loopback Address is specified in the “Remote Endpoint” SubTLV, so that receivers of the UPDATE can establish the Encapsulation with the outer destination address equal to the one specified by the “Remote endpoint” SubTLV.

That was discussed in the long email discussion thread last week.

We can ask the Tunnel-Encap authors to confirm.

Linda

From: John E Drake <jdrake@juniper.net>
Sent: Thursday, June 20, 2019 5:50 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; rtgwg@ietf.org; idr@ietf.org
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda,

From section 5 on the Tunnel Encapsulation Attribute draft:

“[RFC5512] specifies the use of the Tunnel Encapsulation attribute in
BGP UPDATE messages of AFI/SAFI 1/7 and 2/7.  That document restricts
the use of this attribute to UPDATE messsages of those SAFIs.  This
document removes that restriction.

The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
or 25/70 (Ethernet VPN, usually known as EVPN)).  Use of the Tunnel
Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
outside the scope of this document.”

What this means is that the tunnel encapsulation draft can be use exactly
as I described in my previous email to describe the characteristics of
of an SD-WAN port.

Yours Irrespectively,

John



Juniper Internal
From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Thursday, June 20, 2019 6:08 PM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

Thank you very much for the feedback.
Comments are inserted below:

From: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
<Snip>

-------------------------------------------

-       [Tunnel-Encap] doesn’t have the functionality that would help the C-PE to register its WAN Port properties.

-       A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between the tunnel’s end points for supported encryption algorithms and tunnel types before it can be properly established, whereas [Tunnel-Encap]  only allow the announcement of one endpoint’s supported encapsulation capabilities for specific attached routes and no negotiation between tunnel end points is needed.

[JD]  What you need to do is implement the model described in  the Secure EVPN draft (https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-01<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint..com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dsajassi-2Dbess-2Dsecure-2Devpn-2D01-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C28557a27c1c64de4997708d6f5b30f7f-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C1-257C636966546754208641-26sdata-3DqLd2LVx5Lng7QccAIB0weIfpXE3IBOQfq0kiLUJqFMs-253D-26reserved-3D0%26d%3DDwMFAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3Dv-ZrS-NTEa3rPqhwNaoM5gNU8iL1zGd7DutDZaH0C4w%26s%3DnivOMac2lUDvbaJX-GTBeiLAWMqfyKOsTpqvG3AB27A%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C944aca0c6afc4b5223e708d6f5d199ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636966677919821937&sdata=1Qp5WaPz5IaGkNDjG%2B5AcmYePzW9fzHh3fpkmaJkBqw%3D&reserved=0>)  Viz, the SD-WAN C-PEs are attached to a route reflector and each uses the route reflector to advertise its security-related  information the other C-PEs.  As we discussed in Prague the tunnel encapsulation attribute is not associated with client routes.  Rather it is associated with the loopback or interface addresses of the advertising SD-WAN C-PE.  I.e., IPv4/IPv6 addresses rather than VPN IPv4/IPv6 addresses

[Linda]Yes, using Loopback address would be a good way for tunnel, but that is not what Tunnel-Encap specified. The draft Tunnel-Encap is to advertise supported Encap capabilities for specified routes.
I have another section (4.3) on the gap analysis for SECURE-EVPN, specifically, Secure-EVPN does not address the scenario of C-PE having some ports facing trusted MPLS VPN and other ports facing the untrusted public Internet. The document assumes that a client route is either forwarded all encrypted through one tunnel, or not encrypted at all through a different tunnel. In SD-WAN, one client route can be forwarded encrypted at one time through the untrusted network and be forwarded unencrypted at different time through MPLS VPN.
If you think the secure-evpn has addressed those scenarios, can you please indicate which section? Thank you.


The establishment of a SD-WAN tunnel can fail, e.g., in case the two endpoints support different encryption algorithms. That is why a SD-WAN tunnel needs to be established and maintained independently from advertising client routes attached to the edge node.

[JD]  See above

-       [Tunnel-Encap] requires all tunnels updates are associated with routes. There can be many client routes associated with the SD-WAN IPsec tunnel between two C-PEs’ WAN ports; the corresponding destination prefixes (as announced by the aforementioned routes) may also be reached through the VPN underlay without any encryption.. A more realistic approach to separate SD-WAN tunnel management from client routes association with the SD-WAN tunnels.

[JD]  See above

-       When SD-WAN tunnel and clients routes are separate, the SD-WAN Tunnel establishment may not have routes associated.
There is a suggestion on using a “Fake Route” for a SD-WAN node to use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points properties. However, using “Fake Route” can raise some design complexity for large SD-WAN networks with many tunnels. For example, for a SD-WAN network with hundreds of nodes, with each node having many ports & many endpoints to establish SD-WAN tunnels with their corresponding peers, the node would need as many “fake addresses”. For large SD-WAN networks (such as those comprised of more than 10000 nodes), each node might need 10’s thousands of “fake addresses”, which is very difficult to manage and requires lots of configuration tasks to get the nodes properly set up.

[JD]  There is no need for a ‘Fake Route’.  We advertise a tunnel encapsulation attribute with security-related information for a specific SD-WAN port on the C-PE as identified by its IPv4/IPv6 interface address.  If a set of SD-WAN ports have common security-related information a tunnel encapsulation attribute can be advertised with a C-PE’s loopback address.

[Linda] this section is for Tunnel-Encap, which doesn’t allow Loopback address to be associated with the tunnel. If you think it does, can you please indicate which section? Thank you.

Linda