<div dir="ltr"><div dir="ltr"><div>Thank you for the clarification Ben.</div><div><br></div><div>I agree with your clear notes, most of them correspond with my objections toward the proposal.</div><div>I hope your suggestions will be taken into consideration. </div><div><br></div><div>Lucilla </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno ven 18 set 2020 alle ore 17:31 Ben Maddison via RPD <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Jordi,<br>
<br>
On 09/17, JORDI PALET MARTINEZ via RPD wrote:<br>
> Hi Ben,<br>
> <br>
> Please see below, in-line as [Jordi]<br>
> <br>
> Regards,<br>
> Jordi<br>
> @jordipalet<br>
> <br>
> <br>
> <br>
> El 17/9/20 11:15, "Ben Maddison via RPD" <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>> escribió:<br>
> <br>
> Hi all,<br>
> <br>
> I am currently undecided on this policy.<br>
> As others have pointed out, the objections to the proposal on the basis<br>
> of centralization of control are bogus: the current policy does not add<br>
> any additional control over the routing system beyond that which AFRINIC<br>
> already has as the result of RPKI origin validation deployment today.<br>
> <br>
> I agree with the fundamental basis of the proposal that:<br>
> a) it is generally undesirable to route traffic for bogon destinations;<br>
> and<br>
> b) the RPKI is the best fit we have to securely communicate what is and<br>
> isn't a bogon to relying parties in order to implement the necessary<br>
> routing policy.<br>
> <br>
> However, it is also the case that the consequences (in terms of service<br>
> availability for end users) of a de-registration would be substantially<br>
> greater if the de-registration is accompanied by the issuance of an AS0<br>
> ROA for that address space.<br>
> <br>
> [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?<br>
> <br>
I should have explained, in my original email, the scenarios in which I believe this policy<br>
could create unintended issues. Apologies for not making this clear.<br>
<br>
I am not particularly concerned by the possibility for operational<br>
mistakes. As you point out these can be resolved relatively quickly, and<br>
systems can be put in place to catch them.<br>
<br>
The scenarios that concern me are ones in which a *contested*<br>
de-registration occurs, because the impacted resource holder is unable<br>
to take action without the cooperation of AFRINIC.<br>
A few examples that I can think of:<br>
- A third party actor successfully gets a court-order that compels<br>
AFRINIC to de-register the resources of a member or group of members<br>
- A set of sanctions come into force compelling AFRINIC to de-register<br>
resources<br>
- A billing dispute arises between AFRINIC and a member, during which<br>
AFRINIC de-registers that member's resources prior to the dispute<br>
being resolved<br>
<br>
I'm sure that others can think of similar problematic cases.<br>
<br>
In each of these, AFRINIC would be either unable or unwilling to assist<br>
the impacted member(s) in ensuring their resources remain routable.<br>
<br>
> [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.<br>
> <br>
Agreed. As I mentioned above, the operational error case is not the one<br>
that concerns me greatly.<br>
<br>
> [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!.<br>
> <br>
As I tried to point out at the mic, this is a very small part of the<br>
issue. If a member's resources have a AS0 ROA issued for them, the<br>
impact is determined by whether *other* operators are using data issued<br>
under that TAL.<br>
With the possible exception of the very largest operators in the world,<br>
no-one will be able to convince *every other operator* to ignore the TAL<br>
in a reasonable timeframe.<br>
I strongly support the use of a separate TA for this policy, but it<br>
doesn't resolve the problematic cases that I have outlined above.<br>
<br>
> This is true for the following reasons:<br>
> - Non-RIR managed IRR databases exist that allow the creation of<br>
> route(6) objects that are not covered by an RIR allocation<br>
> - Many networks do not filter by prefix based on IRR data at all<br>
> - Those that do generally do not filter their transits by prefix<br>
> - Transit-free networks generally do not filter their peers (or at least<br>
> their transit-free peers) by prefix<br>
> <br>
> Thus, today, a de-registration probably results in a partial outage that<br>
> can be worked-around, rather than a near-total outage that cannot.<br>
> This is either a feature or a bug in the policy, depending on your point<br>
> of view regarding a specific de-registration case!<br>
> <br>
> [Jordi] I will say it greatly depends on many operational details, so purely case by case bases ...<br>
> <br>
I think you misunderstand what I mean when I said "feature or a bug in the policy,<br>
depending on your point of view". Allow me to clarify:<br>
<br>
The mechanism of issuing AS0 ROAs to make space un-usable is likely to<br>
be *very* effective.<br>
In many cases, where it is clear that the space has no rightful holder,<br>
this is desirable, and it is a *feature*.<br>
In some (hopefully few) cases, such as the examples I have provided, it<br>
is less clear that the de-registration should result in the impacted<br>
address space becoming unusable, breaking the services of possibly<br>
millions of end-users in the process. In that case the effectiveness is<br>
a *bug*.<br>
<br>
I mentioned at the mic that the real operational impact of traffic to<br>
and from bogon space appears to be low. There are other operational<br>
interventions available to operators in specific cases where an impact<br>
does exist.<br>
Therefore, while I agree that it is generally desirable that operators<br>
have an easy way to filter bogon routes, the adverse side-effects must<br>
be kept near-zero in order for the benefits to out-weigh the costs:<br>
hence my suggestions below.<br>
<br>
> I would suggest the following modifications, in order to alleviate some<br>
> of the risks inherent in the current draft:<br>
> 1. The automatic creation of AS0 ROAs should be limited to space that<br>
> has never been allocated by an RIR or part of a legacy allocation.<br>
> 2. AFRINIC should require the explicit consent of the previous holder<br>
> to issue AS0 ROAs in respect of re-claimed, returned, etc, space.<br>
> 3. Any ROAs issued under this policy should be issued and published in<br>
> a way that makes it operationally easy for an relying party to<br>
> ignore them (probably by issuing under a separate TA)<br>
> <br>
> With the above amendments I would be inclined to support the proposal.<br>
> <br>
> [Jordi] 1 and 3 are already in the proposal, the staff already confirmed their interpretation on that.<br>
> <br>
On point #1:<br>
I believe the current wording in the draft is ambiguous here.<br>
The staff assessment[0], however, states:<br>
"Any prefixes returned by or reclaimed from members will also have AS0 ROAs"<br>
To be clear, I am suggesting that AS0 ROAs should only be issued without<br>
the consent of a previous holder when *there is no previous holder*:<br>
i.e. the space in question has never been delegated by any RIR or any<br>
predecessor.<br>
<br>
On point #3:<br>
This is in the current draft as a suggestion, not a requirement.<br>
I would prefer that is a requirement.<br>
If you are uncomfortable with mandating a specific implementation<br>
detail, I would suggest:<br>
"ROAs issued under this policy must be issued and published in a<br>
manner that allows a relying party to rapidly opt-in or out of the<br>
use of such ROAs, without impact to that relying party's use of the<br>
remainder of the data in the RPKI system."<br>
<br>
> [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?<br>
> <br>
This is an extension to the safeguard that I suggested in point #1.<br>
If the space has never been delegated, then no problem, the ROA can be<br>
issued without breakage.<br>
If there is a previous holder (i.e. the de-registration case), then a<br>
ROA should be issued only when the de-registration is uncontested.<br>
This will probably result in AFRINIC being unable to issue AS0 ROAs in<br>
some case (non-payment is likely to be a good example).<br>
However I believe this is a price worth paying to avoid the cases that I<br>
have pointed out above.<br>
<br>
An alternative which I considered might be some sort of dispute<br>
resolution process, but that:<br>
- adds complexity<br>
- requires some party responsible for adjudicating<br>
- doesn't deal with the first two examples I raised<br>
<br>
Sorry for the long response. Hopefully this clarifies the problems I<br>
have with the current version?<br>
<br>
Cheers,<br>
<br>
Ben<br>
<br>
[0]: <a href="https://afrinic.net/policy/proposals/2019-gen-006-d2#impact" rel="noreferrer" target="_blank">https://afrinic.net/policy/proposals/2019-gen-006-d2#impact</a><br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>