[c-nsp] RPKI extended-community RFC8097
Ben Maddison
benm at workonline.africa
Sat Apr 18 08:44:53 EDT 2020
Hi,
On Sat, 2020-04-18 at 14:03 +0200, Gert Doering wrote:
> Hi,
>
> On Sat, Apr 18, 2020 at 01:20:58PM +0200, Robert Raszuk wrote:
> > Using BGP predefined ext communities is one way to enable origin
> > validation
> > on all your routers. Then if you do you may want to enable or
> > disable
> > invalid paths to be best path eligible. By default they would not
> > be part
> > of best path.
> >
> > If you like to only deprefer them I am marking them with local pref
> > and do
> > not need to touch any of the IBGP routers.
>
> For "more specific announcement" attacks, local-pref'ing the RPKI
> invalids
> to "ineligible" isn't going to work, as there are no valid
> alternates.
>
> Ceterum censeo, the only reasonable approach to RPKI OV seems to be
> "drop invalids" or "do not bother" (except for a certain phase in
> between where you want to monitor first to see if it has any
> noticeable
> effect on production traffic).
>
Even then, setting LP is a bit of a waste of time. For an interim
monitoring phase, what you probably want is a community (8097 or
otherwise) to correlate with flow data.
Going back to the OP's question, though: we (AS37271) use 8097.
Not because I think that it's a particularly sensible design (I don't),
but because we have IOS-XE bgp-speakers, and you can't do ROV on XE or
Classic without it. At least, if you want routing to work ;-)
On XE and Classic:
1. you can only preform validation on eBGP-received routes;
2. any iBGP-received route will get marked "Valid" unless it has a 8097
extcomm to the contrary; and
2. bestpath selection will prefer "Valid" to "Unknown", at the first-
step in the selection process.
Thus, without 8097 extcomms to mark validation status, you get a
forwarding loop for every prefix that a) you learn at two-or-more ASBRs
and b) has no covering ROA.
That's the majority of the DFZ table for any multihomed AS.
Feel free to tell your Cisco SE if you think that's dumb.
Cheers,
Ben
More information about the cisco-nsp
mailing list