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