[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

[Ben Maddison]

Hi Nishal,

On 09/17, Nishal  Goburdhan wrote:
> On 17 Sep 2020, at 11:08, Ben Maddison via RPD wrote:
> 
> hi ben,
> 
> > Thus, today, a de-registration probably results in a partial outage that
> > can be worked-around, rather than a near-total outage that cannot.
> 
> this was definitely true 5 years ago.

I agree that the size of the hypothetical outage has grown over that
timeframe, but the ability to work around the issue hasn't changed very
much.
> 
> but it is less true every day now;  pick your favourite modern
> network/CDN/IXP and i bet that they are busy implementing, if they already
> haven’t done this.  and even if you discount the “large” networks, there are
> many folks that spend their time teaching networks/ixps in-region how to do
> this (guilty!) to improve the state of overall network filtering.  even
> afrinic does this now ;-)
> 
> and let’s be clear about “the workaround” - there’s the same level of work
> required to get a missing IRR entry installed, *for an allocation that has
> gone missing at RIR level*, or to fix an AS0 ROA.   in fact, since most
> networks have automatic retrieval, a new ROA is likely to be updated
> *FASTER* than an errant IRR object  (where filters are built usually once a
> day)
> 
That is certainly true in most cases. The point that you're missing is
that it remains possible to create a route(6) object despite the lack of
a covering RIR registration in several widely mirrored IRR databases.

For most purposes, this is a serious deficiency in the IRR system. For
the current topic, however, it increases the blast radius when something
goes wrong.

> but that’s not really the genesis of the argument, and i am sure we’ll meet
> somewhere and can continue this .. :-)
> 
Fingers crossed... One day!
> 
> > This is either a feature or a bug in the policy, depending on your point
> > of view regarding a specific de-registration case!
> > 
> > I would suggest the following modifications, in order to alleviate some
> > of the risks inherent in the current draft:
> > 1.  The automatic creation of AS0 ROAs should be limited to space that
> >     has never been allocated by an RIR or part of a legacy allocation.
> > 2.  AFRINIC should require the explicit consent of the previous holder
> >     to issue AS0 ROAs in respect of re-claimed, returned, etc, space.
> > 3.  Any ROAs issued under this policy should be issued and published in
> >     a way that makes it operationally easy for an relying party to
> >     ignore them (probably by issuing under a separate TA)
> 
> rather than nitpick, i think that these are implementation issues, and that
> there is sufficient clue in this community to put in checks and balances
> like this, in an _implementation_ plan, which need not be codified in a
> policy statement.  i mean, just in the past two days alone, a whole new crop
> of RPKI experts has shown up ..
> 
I was proposing the above as safeguards to be built into the policy
itself, not as implementation details. I will explain further in another
email shortly...

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200918/0eea04c0/attachment.sig>