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

Robert Raszuk <robert@raszuk.net> Thu, 17 October 2019 23:22 UTC

Return-Path: <robert@raszuk.net>
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 810E9120805 for <idr@ietfa.amsl.com>; Thu, 17 Oct 2019 16:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 G_qGV05PKscF for <idr@ietfa.amsl.com>; Thu, 17 Oct 2019 16:22:36 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3F712080C for <idr@ietf.org>; Thu, 17 Oct 2019 16:22:35 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id t20so6211079qtr.10 for <idr@ietf.org>; Thu, 17 Oct 2019 16:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=coArRFvb2hvT+wqiOxe5KR1mahgzaFoe8+RdLoyjzOU=; b=b9bedn2yr6r+q8+fIkIe4foN2Thp5oEpPlnLWhqQfOIEn8vbGbxTX68nCXNIUR1omf PKEwsFeabshek8tRnZBHkRtnbghxc0tYKviyFj6ol2eyyE1kH4zOvV8YYnSC8yVx3EW+ gwkYWfc/GS8zbKU5Nm54ZzVxEGklA1iS0Xntb/vI92IePaZXISI0Gw4xAsT1x5opSHkB 4lGSg6KWAR/9PN0EkMnxJHJ9GmKN3lA2JBDvS0sPUxpgwTlOiuK7WWn8dB+Vii24X+xa ycOhE416QuOnIW/Xvorm+DSE6396Jda67/yuh2UlnSWCJ6LRXOzHyn78FHndqdW+mLw4 k0nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=coArRFvb2hvT+wqiOxe5KR1mahgzaFoe8+RdLoyjzOU=; b=anYB8Ppwb0UBxqIgeQ3bCwnHHILeMrfQhqnha/H85HNQ94B/CRzDyaO7h/x0pNN3Ra YHRwiu+ygyZU4suv1Zav5v23W03dv9aVCuKelVAjx9u8yN1LVCnCtUWSj83oUzPvz9+N U1WTQRQAAGLzXRgOlpHSRxhiWyBnS6m7ePrNIAsUAkAMnrUrXx0qOetzB8/07HRUyheO JK6bkr/qj1vts4u6IFysH8Bq2xbeo0odVGgNqTvUAOfxlEavFav1+EGFC5juD8/L+XRo pjFak1I0dhyxfgIhBFEOVjDv0ppEf6z7K+TyZhXYo9g0vyehyHDMyPEAgLb91amPSXz4 hMjQ==
X-Gm-Message-State: APjAAAU/k8f9bhzC4dLtpc8VfWFefU91Y3YtHju5i9HrBADSSCGFnJ2I rhNQ/fJQw/CRFsoPsHj/WMJAG3W57XoLcG7GMEn0qE1TSJM=
X-Google-Smtp-Source: APXvYqw+GzEeazEVFjETm6cmYBOubEc4/tFVlE+yd8HXgBl/XwCS5TSxukq2ulULmEWKktut4122fvaCIkM4GiWNfdY=
X-Received: by 2002:ac8:6f2b:: with SMTP id i11mr3322634qtv.343.1571354554500; Thu, 17 Oct 2019 16:22:34 -0700 (PDT)
MIME-Version: 1.0
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> <2A6A8F0A-82B2-4016-9148-10B4FC75FC03@cisco.com>
In-Reply-To: <2A6A8F0A-82B2-4016-9148-10B4FC75FC03@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 18 Oct 2019 01:22:25 +0200
Message-ID: <CAOj+MMECVbe-VOP2D5mB+zZWjLh_igOefeFYbK-OMtJ+bY9EGA@mail.gmail.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Cc: Ondrej Zajicek <santiago@crfreenet.org>, "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>
Content-Type: multipart/alternative; boundary="000000000000099d4d0595237e8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/R59lM5lk0UkZohwbRcYUuyWrNEc>
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:22:39 -0000

Great point Rajiv !

Security consideration section lightly suggests to use BGP Origin
Validation or even BGPSEC... well great !

But it does not define any behaviour when result of BGP Origin validation
against tunnel attribute will now be different from results when compared
against NLRI validation.

What do we do then ?

Not only this breaks all current show commands and accept/reject policies
being applied to NLRI Origin Validation, but also reopens all
implementations how Origin Validation works and how do we mark validated
routes.

- - - -

So for all proponents of Tunnel Encapsulation Attribute - I would like to
post a single question:

Why don't we use basic BGP recursion (in any AFI/SAFI required) and simply
advertise within each applicable SAFI an NLRI = NH of endpoint/customer
routes with NH = Tunnel Endpoint while attaching to such
UPDATE  Encapsulation Extended Community indicating type of tunnels and
parameters required ?

What use cases would not be addressed by doing just that ?

Thx,
R.





On Fri, Oct 18, 2019 at 1:06 AM Rajiv Asati (rajiva) <rajiva@cisco.com>;
wrote:

>
>
> 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>;
> 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)
>
>