Re: [sig-policy] prop-132-v002: AS0 for Bogons
Dear all,
I've yet to make up my mind about this proposal, but I wanted to point
out an error in the interpretation of how RPKI based BGP Origin
Validation works.
On Wed, Aug 28, 2019 at 04:04:25PM -0700, Owen DeLong wrote:
> > On Aug 28, 2019, at 13:44 , Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:
> > On Thu, 29 Aug 2019 at 6:33 am, Javed Khan <javedkhankh@outlook.com <mailto:javedkhankh@outlook.com>> wrote:
> > We may think we are living in a perfect world but we are not.
> >
> > of course
> >
> > With this proposal I'm more worried about the network downtime as
> > managing an AS0 ROA by an RIR may be prone to errors as we all do
> > regardless if its a manual or automated solution.
> >
> > Would you like to explain how AS0 ROA can create network downtime?
>
> One possible way I can think of (I’m sure there are others)…
>
> ISP Q is issued 2001:db8::/32 by APNIC.
>
> ISP Q does not participate in RPKI and does not create ROAs.
>
> APNIC accidentally issues an incorrect AS 0 ROA for
> 2001:db8:8000::/33, taking down some fraction (up to half) of ISP Q’s
> customers and possibly their infrastructure.
Correction:
In the above example, if ISP Q announces 2001:db8::/32 in the BGP
Default-Free Zone, the presence (or absense) of a ROA covering only
2001:db8:8000::/33 (or longer) will not influence the propagation of the
2001:db8::/32.
Should APNIC create a ROA "2001:db8:8000::/33, maxlength 128, origin AS
0" this ROA will *not* take down some fraction of ISP Q's customers. A
ROA covering only a *fraction* of a covering "VALID" or "UNKNOWN" BGP
announcement does not influence said covering BGP route.
Now, it's of course another story if APNIC creates an AS 0 ROA for
2001:db8::/32, or if ISP Q wants to announce 2001:db8:8000::/33 for
traffic-engineering reasons.
ROAs only influence BGP announcements where the NLRI in the BGP UPDATE
is an exact match, or where the BGP NLRI is a more-specific of the ROA.
Not the other way around.
Kind regards,
Job