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

Christopher Morrow <> Wed, 02 September 2020 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F7153A0C2A for <>; Wed, 2 Sep 2020 10:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rFxq33eMnrNX for <>; Wed, 2 Sep 2020 10:39:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAD1D3A0C15 for <>; Wed, 2 Sep 2020 10:39:51 -0700 (PDT)
Received: by with SMTP id z2so4204169qtv.12 for <>; Wed, 02 Sep 2020 10:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0ycXhAcFWUXi0t2j0OKTMls9td9y/AflP+8xXK/K3Ow=; b=KP0VaDjM7iwad8Ebx6z5tYYhmY2MCab+PJ+8dQlokEf4VSj2hVZP9I6OuHuoTX71Nt GzuX3mowDDN9b0ZWaV8rf4m6Iwbbshq3MHEvA/AYtk0oJ32du8YT8/p+xUmpO9vNVfBl xaIuTn3ExAY3QGdnVPxVOJpPerDmvUOIqmcn5zogvMI/ceQpfNc7bnBCToo8LG+mtHPU KDoXgLnlh4/9x7qCpBi4AuIpc+w4EFSoGfrSnz0W6E0jFe5r5hme7ly6pwgB1gxD3SWU zyA9T6/5C8xNKv2dpIWgKA6LO/rMD9CuR7bRUfa2KlBhcgLVwDX/NXstgwhexyPie303 qvzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0ycXhAcFWUXi0t2j0OKTMls9td9y/AflP+8xXK/K3Ow=; b=V2IQTsb9f6EZUS83HNKvaUPvcH9IHslK8CNIueFVrUf0BDCbDicgQf92YyqwLBp/ej xA1AO6AlEr0XNs3aqHB++NUhiaZEn1CSiAKgMiDipIbe654SAVzxWK4KtJq8AIX+esqr wRlrEi0Lec5yVD7lxF7IcNGqd4DscJfjKmIHYdR6XwFgoOfmXjHWzCkCaP9ngFnCKozk U6YB/iYSlgkwoO9jGIadwbogdoYjG/q/rSfpC6kPXNgwsi7HixcGHjWygYl+FtfrzEXn YU9jv9MI1A+iYpnekIl47B67zx3wTks1eGu7Y39bUzM+w6N93phmPDC+ufdC7t998ZZM qA9A==
X-Gm-Message-State: AOAM53360gY6oFd92zXGt2AazqmeDCTnLDhpOrf+7HKQlP7LKrSGGYYj Pq+o7XW07KfcKOEthgaVFvcmzumSemHnDMAC+ragrEVNxT2SKg==
X-Google-Smtp-Source: ABdhPJwkEVnnFjID/K8e+TT1ZcnuK5cQeDRaYrL6fIMIJPBgWYFeYPhAoNHujVJ4VkEj1aNBtt3eBV2yJu5yvcGsTPE=
X-Received: by 2002:ac8:37bb:: with SMTP id d56mr7725078qtc.222.1599068390693; Wed, 02 Sep 2020 10:39:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Christopher Morrow <>
Date: Wed, 02 Sep 2020 13:39:39 -0400
Message-ID: <>
To: Randy Bush <>
Cc: Keyur Patel <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Sep 2020 17:39:53 -0000

asking as a wg participant...

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' ?

2) I think the purpose proposed is basically:
    "the speaker may be overloaded and not processing bgpsec
functions, it could tell neighbors that this is happening"
    *** "neighbors" here meaning ibgp(and confed) only neighbors.***

3) the proposal is to add some 'add magic/standard community to all
routes processed, regardless of validation processing'
     where 1 value could be: "i could not process this route for
validation... good luck fellow traveler!"

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?

How would you know if I added the 'can not process' or you did? or
someone else did?
How would you know what to do based on the community in question?
(because you have no idea who added/removed/etc it)
At best this becomes (across ebgp boundaries) useless info, since the
speaker SHOULD just process the route normally (and if invalid drop).


there's this quote from the document:

On Wed, Aug 26, 2020 at 1:07 PM Randy Bush <> wrote:
> > A working group last call has been requested for
> > draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State
> > Signaling”. Please reply to the list with your comments. The WGLC will
> > end on August 25, 2020.
> i think this is as good as we will do in this area.  sad to say, among
> other things, we are going to have rov incapable devices in our networks
> for some years.
> but yes nick, perhaps sec cons could be sterner about filtering the
> community.  as you know, i am not fond of communities and leakage
> thereof.  but we're not going over to idr and creating an attribute.
> randy
> _______________________________________________
> Sidrops mailing list