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

From: Christopher Morrow <[email-masked]>
Date: Wed, 2 Sep 2020 13:39:39 -0400

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

-chris

there's this quote from the document:
  "

On Wed, Aug 26, 2020 at 1:07 PM Randy Bush <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Sep 2020 10:46:40 -0700

of course, i have no idea what the authors meant

>    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]

> Why wouldn't they just perform BGPSEC validation on their own?

lack of horsepower, expecially as the use case seems to be bgpsec

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 2 Sep 2020 15:01:28 -0400

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

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