Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020

Christopher Morrow <christopher.morrow@gmail.com> Wed, 02 September 2020 19:02 UTC

Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C26A3A0CBA for <sidrops@ietfa.amsl.com>; Wed, 2 Sep 2020 12:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Mg1Pl-EqIT93 for <sidrops@ietfa.amsl.com>; Wed, 2 Sep 2020 12:02:25 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 D37973A0D0E for <sidrops@ietf.org>; Wed, 2 Sep 2020 12:01:40 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id o2so113470qvk.6 for <sidrops@ietf.org>; Wed, 02 Sep 2020 12:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3GaSHwVpFojZJWerQaVSleVaPEpkDobSB5cbV0PYP/U=; b=t6bwiVXcPehNQQ+jx+/mArKrATvObbCE0oWVvuECOWNDKAoMn9tRmeypo3A6GHRrpU iHJPSAgQ4fWBUMcioNpfrPRJyVwyoWXUNtrAjt2IKbFg/4w6L+UGXs8E7wQ+ijCILSeX pRqdvZKTETEMWLV/G8oqoAAqMTqvf3YBgMxj2K5jkaFjWsopY92XFpv8ZO7yQPKFFQVs hNqdIpFf5awY4DPIesBuWox01PtY09w+XVcRJ5TUUMkcAtJFvYa8Xcx6BYiEGrGkomF1 3SnmLjuAG/t27P6Z0K1llpi23LKeucqdoVRnYLCqfSXGpgVpMnzWuILBmGeaIpPHtsXX nGCw==
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=3GaSHwVpFojZJWerQaVSleVaPEpkDobSB5cbV0PYP/U=; b=mIb+j3O2eooMmFtCkbY5OHknibdDnL2Iitz5hQTuvpNc5EneP0qihnibicAGlepJDb GNRr1l6+WsavpcoYzoRfn89N4k6HdltCgRAHNxrg8Dia3+anNtViyzGIc7fDVIEwmjX5 oefAfkBE0dR8QEHqKCl7/LWBjlAAw2wLF28VLU792p8k3c/1Hbrum2R3txEn5JVvfFdF 7UcIv7eIkiOgitXtcuKLveJdNfZexO7bs+zLiERXo4Ow/QGTbUT96/xUfAN2wAlpVJJt FJYFXd/hXF/IhYB2KyawrHV2V9KQuKawjlDfxcL5ZPijRRAaJGXu0bSn8MfAGr9DGegE XEmA==
X-Gm-Message-State: AOAM531/1/20LKA5JSj4rbWMxpRSs5cD4EX2JkVPg3bucXvnF29UKKQ8 0OUcO+RvMRpPnmfU79zuEL4RgnKjTM27DwOVU9M=
X-Google-Smtp-Source: ABdhPJyzsk+/FlLVkgWWVIF0rzaSsce1f8oPXVKS86XQbEhHaWLhAwsiKe+igv2NgHbzbTuxtZsvIGcMDlwDSxe9118=
X-Received: by 2002:a0c:ea34:: with SMTP id t20mr7964480qvp.233.1599073299691; Wed, 02 Sep 2020 12:01:39 -0700 (PDT)
MIME-Version: 1.0
References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> <m2blixz67w.wl-randy@psg.com> <CAL9jLabE9SSPXAXyH5E90E_C0Bi0hjMXkdVX+bt48_QZp=iLjQ@mail.gmail.com> <m2d034nkan.wl-randy@psg.com>
In-Reply-To: <m2d034nkan.wl-randy@psg.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Wed, 2 Sep 2020 15:01:28 -0400
Message-ID: <CAL9jLabMqxcRYmdzK6V_gDo4otbHb+bvOMrXy48u4QZ6w7qy=Q@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Cc: Keyur Patel <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3E3eagmFi7cmJ2pV7kJqjR2Pgtk>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 19:02:26 -0000

On Wed, Sep 2, 2020 at 1:46 PM Randy Bush <randy@psg.com> wrote:
>
> of course, i have no idea what the authors meant
>
> > 1) I think some of the friction here is the use of eBGP in the
> > document. This particular quote:
> >    (section 4)
> >     "(including a trusted EBGP peer for
> >    instance controlled by the same operator as lined out in Section 3)"
> >    PERHAPS this means 'confed boundary' not 'eBGP' ?
>
> yes, confed is ebgp.  but there are providers with multiple ASs which
> might trust eachother, e.g. the classic 70[1-4]

Sure, but I think confed boundary passes non-transitive communities...
so that should 'just work'.
For cases of: "my 2 asn are not confed, but mine and I trust myself"
I'd just signal across the boundary with some set of communities
outside this set... heck, you probably have to
already do that today, so this is just par-for-the-course. (I would
think anyway)

> > I think leaking this outside your ibgp (or confed) boundary changes
> > from having a simple metric system to a mess.
> >   If you want this for internal debug/metrics great.
> >   If you want your iBGP neighbors to perform validation on the routes
> > because the edge-speaker skipped out on that... ok.
> >   If you want to send this knowledge along to your external peers, no.
> > Why wouldn't they just perform BGPSEC validation on their own?
>
> lack of horsepower, expecially as the use case seems to be bgpsec

Sure, that was the reason the original speaker tacked on the community,  right?
the next neighbor though may not be in the same bind?

> randy