Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Thu, 17 October 2019 23:06 UTC

Return-Path: <rajiva@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 90254120168; Thu, 17 Oct 2019 16:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kO6PocG8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ksdeWkGx
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 U90DZWVg7nzV; Thu, 17 Oct 2019 16:06:50 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C841120805; Thu, 17 Oct 2019 16:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13351; q=dns/txt; s=iport; t=1571353610; x=1572563210; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WVd9oOyL4IEhKMYx2jOEeutMPDvqaYimutYFxXV99xE=; b=kO6PocG8aZ7EoKjk0QPeOn9DnDRFK+I4jg3VoOkVIo8VkKEmJ6679wpF RNtKfcr1ifUti+APnw61No3cOBSgUXLz8XHoAZHQ0nm9t4CVdvowDyoHa kWAK3WwL/rrVuUH0mfcHjtmA0++WJXWKenC07ItGbqTNYUIgbuofhhXNg I=;
IronPort-PHdr: 9a23:UN+XABYcr98C/ux2K6tRX2j/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20Q6bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavwZi47As1qX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AnAABm86hd/4wNJK1lGQEBAQEBAQEBAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWoBAQEBAQELAYEbL1AFbFcgBAsqhCWDRwOKUII3JZMdhGGBQoEQA1QJAQEBDAEBLQIBAYRAAheCbyQ3Bg4CAwEDAgMBAQQBAQECAQUEbYUtDIVLAQEBAQMSER0BATcBDwIBCBEDAQIBJwMCAgIwFAkIAgQBDQUigwABgXlNAy4BpTkCgTiIYXWBMoJ9AQEFhQoYghcJgTQBiUSCSRiBQD+BEScME4IeLj6CYQSBLAESAT8WglgygiyPdYU5mCcKgiKVIRuZRy2KM4NQmT8CBAIEBQIOAQEFgWgjZ3FwFWUBgkFQEBSBUDiDO4pTdAGBKI0qDRcHgicBAQ
X-IronPort-AV: E=Sophos;i="5.67,309,1566864000"; d="scan'208,217";a="359480682"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Oct 2019 23:06:48 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x9HN6mkW011335 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2019 23:06:48 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 18:06:47 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 17 Oct 2019 18:06:46 -0500
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 17 Oct 2019 18:06:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xj4J2Cr6ewzQwka1bx7OHAfQU184m2WyaV760o1eyObJgYHP7ym6nBoWD7ZjbuW08Vx3k+nDr3RVpt5fDK1mM8KArFp6Iqfejla1iWllSDT6NceU776AMTkBaAgvcxCQ5CPTESqvDBz38McbAP2FzTUe023rRhAnjN4dX982iIpmwSHTSPZYBItqlQhd3ysvZAMLEfIegxB1k/dof+6enF/1QNTSVPy1rvWph6nu/ukl3AqOTWZLTZ5gfv+D9gYdJvHCwBtQ3jX9J+cp1fQFfUr+Y+3xxpJwyKjRF8nyP43kjJzn0Pix5zhhNy2ykINpp4u0Ha96+4oQzASYo8qDtA==
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=WVd9oOyL4IEhKMYx2jOEeutMPDvqaYimutYFxXV99xE=; b=F+c1ITl8MHDWWk2C/280LcqaHXOuOjzvMj0PkXn4r3epQ3YEL/YSY77fIXMAlm5G2pcoVHj9P/MpZYR+dCdNWVcsZp3v9TwbMGIasRQOlMTVYhmFRPoEbGyWTtDYsq5DJ8KPQzjsKKJCOzNSBE6nulVEchZV86s1DQ+MD15TslwjxS/nu2I3VJZpfIpGAGz5QE8LvOelNgCkaCxaj0EFoP+r+EJKFFrg4H5PIPhHT76FvrD7L5DZuqOCU/d/lx69zLOMxhcDibNPuXTfgsdQHnKVJqKDVcl1mLTh308xCOrUqx3PVJh/FzpbaReotiA8WUe0/eBjMhMH6n6+CCycMg==
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=WVd9oOyL4IEhKMYx2jOEeutMPDvqaYimutYFxXV99xE=; b=ksdeWkGxz7+WmQRLizjUWluB31DmVzd6E6rHLjX4QOfzGa23UtS+nSRu1scdbRgQj4TB6NE+uyMBOtaUOd+yISGydxbPAsxWLpS+CflxHLjWN6yrLbT8a427vkOziw7ThPY0u+J9zEBruI5MGXEoJ2CTPzlfE9ZP8olQWOwQg7U=
Received: from BL0PR11MB3268.namprd11.prod.outlook.com (10.167.234.158) by BL0PR11MB3121.namprd11.prod.outlook.com (20.177.205.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 17 Oct 2019 23:06:45 +0000
Received: from BL0PR11MB3268.namprd11.prod.outlook.com ([fe80::59c2:3137:b490:298e]) by BL0PR11MB3268.namprd11.prod.outlook.com ([fe80::59c2:3137:b490:298e%7]) with mapi id 15.20.2347.024; Thu, 17 Oct 2019 23:06:45 +0000
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Ondrej Zajicek <santiago@crfreenet.org>
CC: "idr@ietf.org" <idr@ietf.org>, Linda Dunbar <linda.dunbar@futurewei.com>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Thread-Topic: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
Thread-Index: AdV+31YOey/wlRogSQu2ak3Czg/rBgF+t6wA///JwgCAAAXdgIAABMKAgAAS+gCAABAkAIAAkB8A
Date: Thu, 17 Oct 2019 23:06:45 +0000
Message-ID: <2A6A8F0A-82B2-4016-9148-10B4FC75FC03@cisco.com>
References: <MN2PR13MB3582A1E1FE3441CDD54A101985950@MN2PR13MB3582.namprd13.prod.outlook.com> <78F7A474-6F86-4EA3-93A3-001B4E2C2116@juniper.net> <CAOj+MMGqKj=zKbws92ni1fL2O-So=dbcW-mb02uRnQ+G55xm_w@mail.gmail.com> <0B48E5E7-3A1F-45C0-ACF9-B9A0FA323ED4@juniper.net> <CAOj+MMHs91BoMpgrN2-qtMAgVtiUE_e2bm=BG=+xVnfU9-6Aaw@mail.gmail.com> <20191017093308.GB2427@feanor.crfreenet.org> <CAOj+MMFs=StpLvK1dZO+ChBUN5i2AYq+CrhHMfMxifpxqegwiw@mail.gmail.com>
In-Reply-To: <CAOj+MMFs=StpLvK1dZO+ChBUN5i2AYq+CrhHMfMxifpxqegwiw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rajiva@cisco.com;
x-originating-ip: [2001:420:c0c4:1007::24f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a3925ec8-ef79-4705-492b-08d75356ae70
x-ms-traffictypediagnostic: BL0PR11MB3121:
x-microsoft-antispam-prvs: <BL0PR11MB31217CC04E17EBE662698BFDC76D0@BL0PR11MB3121.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01930B2BA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(189003)(199004)(6512007)(236005)(7736002)(256004)(33656002)(478600001)(6436002)(66946007)(5660300002)(76116006)(66556008)(64756008)(54896002)(66476007)(6306002)(58126008)(6116002)(110136005)(4326008)(66446008)(2906002)(6246003)(46003)(316002)(25786009)(54906003)(476003)(86362001)(446003)(11346002)(102836004)(76176011)(486006)(53546011)(81156014)(81166006)(186003)(6486002)(6506007)(8676002)(8936002)(14454004)(2616005)(71190400001)(71200400001)(229853002)(36756003)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3121; H:BL0PR11MB3268.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ViUfdqyfSbePb0lKZcvJMl73nWgXQI0eDUflGvMUb6ob/vE+v4Cu6mLedtoi9w7ee7qlhDcRiSYoIpANHo/tZo1pw0yUO75xsVW2+nxi32hj1WjTJxkAJnZ/qbkWbBA893sHT3+HEbXoKHWYGf/Hni/f19aDcd/TaFH6DL0iV0qvnoQdmBH+WOaDRshechW6SEYxZGJ/Rf9uGchd1Lv9qu7NTnkr9OyULP3D4GycT37KnuWRQIZBGv/SZysnnYm7HOPMfCqm5BPgXyikEp5FvPzAoMiDg7w5sYPeDKKWqRC0r9uJRP4lEb7sR5h7XnbGrpljEoP/xszxEAD27aShTWEwCinYjBjNEBKvh5wiP7INJ3HZoELPPVTF2QH5G+BRR2BlncdMs2Iba9+OweO9txvEBX59+xbCNBKIQouMraQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2A6A8F0A82B24016914810B4FC75FC03ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a3925ec8-ef79-4705-492b-08d75356ae70
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 23:06:45.3042 (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: hHlOkTMgSsPdTIlcU/spkywtNYV8zfS/ATCqBbjzHvxZ4Tl8BTDcKwEccgk0AodWsRZF7DgokVhUGAtl0WXcKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3121
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MfYd1JQof21Ea5le0ZCMARH3GBw>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
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: Thu, 17 Oct 2019 23:06:55 -0000

One of the things that is strikingly problematic in allowing BGP NH and Tunnel Endpoint to be different is that it could be used as an attack vector (node A advertises a route with NH =A & tunnel endpoint = node B, so node B gets bombarded with unwanted traffic (in fact, node B may not even have any BGP, or not have a particular BGP route, or..).

This would be a big red flag for many of us.

--
Cheers,
Rajiv

PS: Now, what if node A uses two IPv6 addresses – one as the NH, and the other as the tunnel endpoint. That’s a legit case, one could argue.


From: Idr <idr-bounces@ietf.org> on behalf of "robert@raszuk.net" <robert@raszuk.net>
Date: Thursday, October 17, 2019 at 6:32 AM
To: Ondrej Zajicek <santiago@crfreenet.org>
Cc: "idr@ietf.org" <idr@ietf.org>, Linda Dunbar <linda.dunbar@futurewei.com>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Well indeed the draft is very underspecified in this space..

The fun starts when next hop from NLRI is unreachable while tunnel end point is. Does it mean that given path is not going to be considered for best path selection ?

And we can go further ... say bgp uses selective next hops and is set to only consider /24 and higher and NH from NLRI does not meet those criteria ... but tunnel endpoint is reachable over default route - what happens then ?

See what strikes me the most is the mandatory nature of endpoint TLV and no good description of various cases when NH in NLRI != Tunnel endpoint address. If there are equal tunnel endpoint may be optional.

Thx,
R.

On Thu, Oct 17, 2019 at 5:33 AM Ondrej Zajicek <santiago@crfreenet.org<mailto:santiago@crfreenet.org>> wrote:
On Thu, Oct 17, 2019 at 10:25:13AM +0200, Robert Raszuk wrote:
> Srihari,
>
> Can you comment on the expected BGP next hop validation behaviour ?
>
> Can you also comment on the next hop BGP is installing the prefixes to RIB
> with ?
>
> Is tunnel endpoint now the NH BGP is asking RIB to track ?

My impression of the draft is that handling of BGP NH and address from
Tunnel Encap attribute is different. BGP NH is tracked in RIB and
recursivery resolved, could be used to daisy-chain encapsulation in RIB
(section 7). In contrast, the address from the Tunnel attribute is just
passed to FIB as encapsulation action argument.

But it is true that this part of the draft is a bit blurry and would
definitely need more clear wording.

--
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org<mailto:santiago@crfreenet.org>)