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

[lucilla fornaro]

Thank you for the clarification Ben.

I agree with your clear notes, most of them correspond with my objections
toward the proposal.
I hope your suggestions will be taken into consideration.

Lucilla

Il giorno ven 18 set 2020 alle ore 17:31 Ben Maddison via RPD <
rpd at afrinic.net> ha scritto:


> Hi Jordi,

>

> On 09/17, JORDI PALET MARTINEZ via RPD wrote:

> > Hi Ben,

> >

> > Please see below, in-line as [Jordi]

> >

> > Regards,

> > Jordi

> > @jordipalet

> >

> >

> >

> > El 17/9/20 11:15, "Ben Maddison via RPD" <rpd at afrinic.net> escribió:

> >

> >     Hi all,

> >

> >     I am currently undecided on this policy.

> >     As others have pointed out, the objections to the proposal on the

> basis

> >     of centralization of control are bogus: the current policy does not

> add

> >     any additional control over the routing system beyond that which

> AFRINIC

> >     already has as the result of RPKI origin validation deployment today.

> >

> >     I agree with the fundamental basis of the proposal that:

> >     a)  it is generally undesirable to route traffic for bogon

> destinations;

> >         and

> >     b)  the RPKI is the best fit we have to securely communicate what is

> and

> >         isn't a bogon to relying parties in order to implement the

> necessary

> >         routing policy.

> >

> >     However, it is also the case that the consequences (in terms of

> service

> >     availability for end users) of a de-registration would be

> substantially

> >     greater if the de-registration is accompanied by the issuance of an

> AS0

> >     ROA for that address space.

> >

> > [Jordi] I don't think that's so problematic. If you followed Madhvi

> explanation, the mistake will come from the whois, so this may affect

> already other non-RIR managed databases, etc., and then will be propagated

> to the AS0 TAL, which will take 5 minutes to be re-generated but then, as

> Mark explained, it takes hours to reach the ISPs systems. You don't think

> that the time to detect the error will be faster, if correctly implemented,

> than the time to update the ISPs ? Should not AFRINIC (as already the staff

> indicated in the impact assessment) to ensure that everything is correct

> with a double check, even if instead of 5 minutes takes longer? Note that

> the 5 minutes come from the operational decision from APNIC, they already

> implemented this. Do you think they did wrong? Also, before this becomes

> implemented in AFRINIC, LACNIC is already implementing it as well. You

> don't think that there are 3 sets of "RIR-staff" looking at the same thing,

> from different perspectives, so to avoid anything wrong?

> >

> I should have explained, in my original email, the scenarios in which I

> believe this policy

> could create unintended issues. Apologies for not making this clear.

>

> I am not particularly concerned by the possibility for operational

> mistakes. As you point out these can be resolved relatively quickly, and

> systems can be put in place to catch them.

>

> The scenarios that concern me are ones in which a *contested*

> de-registration occurs, because the impacted resource holder is unable

> to take action without the cooperation of AFRINIC.

> A few examples that I can think of:

> - A third party actor successfully gets a court-order that compels

>   AFRINIC to de-register the resources of a member or group of members

> - A set of sanctions come into force compelling AFRINIC to de-register

>   resources

> - A billing dispute arises between AFRINIC and a member, during which

>   AFRINIC de-registers that member's resources prior to the dispute

>   being resolved

>

> I'm sure that others can think of similar problematic cases.

>

> In each of these, AFRINIC would be either unable or unwilling to assist

> the impacted member(s) in ensuring their resources remain routable.

>

> > [Jordi] Also if you look at the APNIC videos (see the links in the

> slides) you will see that big networks are already using the TAL for the

> AS0 of APNIC. For me it is obvious that we will have several months of

> verification, before AFRINIC implementation, so longer time to make sure

> that nothing is done in a "broken" way.

> >

> Agreed. As I mentioned above, the operational error case is not the one

> that concerns me greatly.

>

> > [Jordi] Last, but not least, having the AS0 in a separate TAL becomes an

> opt-in service, so if any ISP is not "sure" he can just not use it and even

> if you're using it, and an error is created, you just need to temporarily

> disable that TAL in your systems, problem gone!.

> >

> As I tried to point out at the mic, this is a very small part of the

> issue. If a member's resources have a AS0 ROA issued for them, the

> impact is determined by whether *other* operators are using data issued

> under that TAL.

> With the possible exception of the very largest operators in the world,

> no-one will be able to convince *every other operator* to ignore the TAL

> in a reasonable timeframe.

> I strongly support the use of a separate TA for this policy, but it

> doesn't resolve the problematic cases that I have outlined above.

>

> >     This is true for the following reasons:

> >     - Non-RIR managed IRR databases exist that allow the creation of

> >       route(6) objects that are not covered by an RIR allocation

> >     - Many networks do not filter by prefix based on IRR data at all

> >     - Those that do generally do not filter their transits by prefix

> >     - Transit-free networks generally do not filter their peers (or at

> least

> >       their transit-free peers) by prefix

> >

> >     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 is either a feature or a bug in the policy, depending on your

> point

> >     of view regarding a specific de-registration case!

> >

> > [Jordi] I will say it greatly depends on many operational details, so

> purely case by case bases ...

> >

> I think you misunderstand what I mean when I said "feature or a bug in the

> policy,

> depending on your point of view". Allow me to clarify:

>

> The mechanism of issuing AS0 ROAs to make space un-usable is likely to

> be *very* effective.

> In many cases, where it is clear that the space has no rightful holder,

> this is desirable, and it is a *feature*.

> In some (hopefully few) cases, such as the examples I have provided, it

> is less clear that the de-registration should result in the impacted

> address space becoming unusable, breaking the services of possibly

> millions of end-users in the process. In that case the effectiveness is

> a *bug*.

>

> I mentioned at the mic that the real operational impact of traffic to

> and from bogon space appears to be low. There are other operational

> interventions available to operators in specific cases where an impact

> does exist.

> Therefore, while I agree that it is generally desirable that operators

> have an easy way to filter bogon routes, the adverse side-effects must

> be kept near-zero in order for the benefits to out-weigh the costs:

> hence my suggestions below.

>

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

> >

> >     With the above amendments I would be inclined to support the

> proposal.

> >

> > [Jordi] 1 and 3 are already in the proposal, the staff already confirmed

> their interpretation on that.

> >

> On point #1:

> I believe the current wording in the draft is ambiguous here.

> The staff assessment[0], however, states:

>     "Any prefixes returned by or reclaimed from members will also have AS0

> ROAs"

> To be clear, I am suggesting that AS0 ROAs should only be issued without

> the consent of a previous holder when *there is no previous holder*:

> i.e. the space in question has never been delegated by any RIR or any

> predecessor.

>

> On point #3:

> This is in the current draft as a suggestion, not a requirement.

> I would prefer that is a requirement.

> If you are uncomfortable with mandating a specific implementation

> detail, I would suggest:

>     "ROAs issued under this policy must be issued and published in a

>     manner that allows a relying party to rapidly opt-in or out of the

>     use of such ROAs, without impact to that relying party's use of the

>     remainder of the data in the RPKI system."

>

> > [Jordi] 2. This doesn't make sense in my opinion, otherwise, we are

> contradicting the RSA and the PDP. There is a clear example if you don’t

> pay the bills, AFRINIC will try to contact you by all means, recover the

> situation, wait some time, etc., etc (this is also what we try improve with

> the policy compliance dashboard). But if all that fails, the RSA already

> allows AFRINIC to recover the resources, so obviously a “bad guy” will not

> authorize AFRINIC to publish in the AS0 … What I’m missing or

> misunderstanding? Can the staff confirm that this is right, so is not just

> my "words" on the understanding of the RSA?

> >

> This is an extension to the safeguard that I suggested in point #1.

> If the space has never been delegated, then no problem, the ROA can be

> issued without breakage.

> If there is a previous holder (i.e. the de-registration case), then a

> ROA should be issued only when the de-registration is uncontested.

> This will probably result in AFRINIC being unable to issue AS0 ROAs in

> some case (non-payment is likely to be a good example).

> However I believe this is a price worth paying to avoid the cases that I

> have pointed out above.

>

> An alternative which I considered might be some sort of dispute

> resolution process, but that:

> - adds complexity

> - requires some party responsible for adjudicating

> - doesn't deal with the first two examples I raised

>

> Sorry for the long response. Hopefully this clarifies the problems I

> have with the current version?

>

> Cheers,

>

> Ben

>

> [0]: https://afrinic.net/policy/proposals/2019-gen-006-d2#impact

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200921/ca0df533/attachment-0001.html>