Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Ben Maddison benm at workonline.africa
Wed Oct 7 08:21:37 UTC 2020


Hi Jordi, all,

Sorry for the long delay in responding.
In-line again.

On 09/18, JORDI PALET MARTINEZ via RPD wrote:

> Hi Ben,

>

> Tks for the complete clarification!

>

> Below, in-line.

>

> Regards,

> Jordi

> @jordipalet

>

>

>

> El 18/9/20 10:31, "Ben Maddison" <benm at workonline.africa> escribió:

>

> 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] In all those cases, the whois is impacted first, and following the RSA and internal procedures, the de-registation will go for many steps (and time) before that actually happens. Remember that the separate TAL is opt-in, so in this case, if AFRINIC is really enforced to do that by a court-order (which I can't believe it may happen, to be honest, and if it happens, AFRINIC at least should appeal that order, so will get some additional time), AFRINIC board can take the decision (as stated in by-laws) to make an urgent policy to drop the AS0 TAL, inform the community about it, etc. This doesn't need to be said in the policy, is already possible today. AFRINIC board then will need to get that endorsed by the PDP (again, all this is in the bylaws) in the next meeting. Of course, meanwhile the community is informed and the community can also work in alternative solutions.

>

The issues with this approach include:
- the terms of the order may prevent AFRINIC from disclosing its
existence
- the terms of the order may prevent the board from acting to mitigate
in the way you propose
- any mitigation that the board may put in place would likely incur some
delay, during which the impacted members still take an outage


> [Jordi] Now, about the billing disputes, if that happens, they we have a *different* problem, but against the bylaws and RSA are the ones that govern that, and the whois and *all the other services* like RDNS will be impacted. For example, we all know that if your email servers, and many others, don't have proper RDNS, they are useless. So, this situation is not created by this proposal, but the other existing documents, and *this* is what the other proposal (dashboard) is also trying to fix, providing a timeline, set of steps, etc., etc., instead of relying on the chances that the bylaws and RSA are taken as a "one immediate and single action". I think breaking down the problem in smaller ones (as we are doing with two different proposals), helps to resolve all them.

>

For us, at least (and probably many others too), RDNS going away would be a moderate inconvenience. An
AS0 ROA covering our address space would be a large outage. The
difference is very large, and grows every time someone moves their mail
off-net.


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

>

> [Jordi] Sorry, I misunderstood you here then ... I think reclaimed and returned space should also be part of the AS0 ROAs, otherwise some of the issues aren't resolved. May be is a matter of defining a time frame. I don't think we have any "dispute" about returned space, right? So, the time frame for coming into the AS0 ROAs *maybe* only in the case of reclaimed space. However, I still think that this is *another* policy (the dashboard) because the bylaws/RSA consequences in case of reclaimed space are not *just* for the AS0 ROAs, but also for many other points in the CPM.

>

As I have pointed out, the consequences - especially in the short term -
of this measure are much greater than any existing consequence of
de-registration.

The fundamental point that I am trying to make throughout all of this is
that the current operational impact of the problem of bogon routes appears
to be very small, whilst the potential impact of this policy for current
members and their end-users could be very large.

Given that imbalance, we should choose the side of "safety" over that of
a "complete" solution.


> 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] I've not major problem on that, but I think we should leave it to the implementation. As said, this comes from the APNIC implementation, and I think LACNIC is doing the same way. We should follow that model, but I'm not convinced should "enforce it", because in the future we may think that is not the best. Of course, we can then also make a new proposal to change it ... I'm half convinced, will need the check with my co-authors and hear more opinions.

>

You will notice that my proposed text did not say "you must use another
TA". It said RPs must be able to opt-out easily. This probably means
another TAL today, but that could change as the result of new
technology.


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

>

> [Jordi] I think the only real case here is lack of payment. I think and external resolution process may be difficult and expensive. If we agree that it is a wider CPM problem (RDNS, whois, myAfrinic, etc.), would you agree to resolve that in the other proposal? One possible "trustable" external way to resolve it, is to make sure that those cases come into courts by AFRINIC claim. Could AFRINIC staff tell us if this is a viable path? So, in case of lack of payment (and other cases that need reclamation of resources, member closure), depending on the Mauritius laws there is a procedure (and average time it takes) to allow AFRINIC to take the relevant actions?.

>

I agree that external mediation is a poor choice. That is why I suggest
giving the previous holder an effective veto.

To re-iterate the point above, I believe that ensuring minimum
disruption to existing networks is far more important than cleaning
bogons out of the DFZ.


> [Jordi] I'm also thinking in a member that is in bankrupt, that will clearly be a case for reclamation and I don't think in that case you object to have the resources in AS0 ROAs ...

>

Perhaps. There may be a mechanism to allow for the situation where a
member ceases to exist and therefore cannot give consent.
However, such a mechanism must allow for the fact that a member may not
know what is about to happen, because AFRINIC is *not allowed* to tell
them.
I think this is a harder problem than you give it credit for.


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

> have with the current version?

>

> [Jordi] Not at all, tks a lot for all the detailed inputs, pity that we got them too late, as we could have considered this 10 days before the meeting and made an alternative version and may be have reached consensus already !

>

Point taken. I will try be faster in future ;-)

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/20201007/749eeb06/attachment.sig>


More information about the RPD mailing list