> On Aug 28, 2019, at 20:37 , Aftab Siddiqui <aftab.siddi...@gmail.com> wrote: > > > Hi Owen, > cutting some stuff out, just to keep the thread small. > > Anyone can very quickly put just about anything in RADB if they want to. It’s > also relatively easy to put nearly anything in the current ARIN IRR (not to > be confused with the ARIN RIR database). There are also some other IRRs that > accept almost anything at face value. > > Exactly, thats why you have so much garbage in RADB and other IRR db.
It’s also why the RIR withdrawing an entry isn’t as likely to cause an unmitigable outage than would occur under this policy. > > > Finally, route object based filters tend to get updated rather slowly and not > everyone updates in sync, so it’s a gradually progressing outage that allows > some reaction time before becoming completely catastrophic. > > Similarly, not everyone is doing ROV. But for the first time people are > worried about consequences of their laziness because RPKI is going to work > much better than IRR based filtering. I’m not sure that’s a completely fair characterization of the situation, but for whatever reason, despite its inability to do more than provide a really good cryptographically signed hint at what to forge in your hijacking announcements, RPKI is spreading like an unstoppable cancer and more and more people are beginning to do ROV in a mode which permits unknowns, but rejects known invalids. RIRs implementing AS0 raises the stakes by giving RIRs the power to create “known invalids” where the previous state would be “unknown”. > >> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA >> for the entire netback, then you’re (potentially) talking about near total >> catastrophic routing failure for this ISP and all of his customers. >> >> Let’s assume they accidentally delete the registration for any reason there >> are cooling off periods in place which goes up to 60 days or we can put >> measures in place through policy to have decent cooking off periods. Also >> let’s talk about stats, how many times how many RIRs have deleted their >> members by mistake? Do you have any case? > > Honestly, I have no way to know. Such an event would likely not be made > particularly public. The RIR would consider it confidential to the affected > party and the affected party would have little motivation to announce it to > the world after the fact. > > So we are debating a scenario which we are not even aware ever happened. I'm > still not saying that it never happened and will not happen but likelihood of > such incident is just very small. No… You asked for an example of how an AS0 ROA could get into the wild erroneously and I presented one scenario which you are now arguing is unlikely. I agree that particular scenario may well be unlikely, but I’m not convinced it is the only circumstance in which such an event could occur. Depending on how AS-0 ROAs are generated, I see lots of possible ways for fat-finger incidents at the RIR to result in dangerous issuances. > > >>> So I am not in favor of asking the RIR to create AS0 ROA. >>> >>> Thats absolutely fine we can agree to disagree but let’s have a clear >>> understanding of the policy. >> >> What makes you think he does not understand the policy? >> >> Because the policy only addresses the bogon, how an address space becomes a >> bogon is APNIC operating procedure. Do you see the problem of understanding >> here? > > Yes, but it’s not his. The policy creates new more severe consequences for > things moving “routable” -> “bogon”. When you increase the consequences of an > action, it’s often a good idea to review the potential causes of that action > and consider what avenues exist for erroneous triggers. > > Absolutely, its a good idea to have measures in place to avoid any erroneous > triggers and thats why I said APNIC can put operational practices in place > for that. Its shouldn't be part of the policy. I never advocated for making it part of the policy. I advocated for reviewing it as part of the considerations BEFORE consenting to implementation of the policy. I never asked for a change to the policy text. I asked for APNIC to publish their anticipated operational procedures for review so that the community can consider them in determining whether or not to come to consensus on this policy proposal. In other words, I agree they shouldn’t be part of the policy, but they MUST be part of the policy deliberation, IMHO. >> Also it’s seems you are fine with people advertising bogons just because >> fixing it might make one/two people unhappy. > > I’m not necessarily fine with people advertising bogons, but I’m also not > necessarily convinced that I want the RIRs to become the routing police. > > This proposal literally moves the routing police role from the hands of those > who run routers into the hands of the RIRs (well, specifically it moves part > of that role in one region into the hands of one RIR). > > This policy is not doing anything special and giving extra powers to RIR. It > happened when we (the community) agreed to move forward with RPKI. Any > consequences you are relating to AS0 are also true for any other ROA. Whether > its a good thing or bad, we can all have different opinion but its a reality. If you believe that first sentence, then you really don’t understand the current operational state of the internet. While you are correct about other ROAs, those other ROAs are not originated by RIRs and cannot come into existence as a result of disagreement between an ISP and an RIR (e.g. a billing dispute with an RIR). This does, in fact, substantially expand the power of the RIR to impact ROAs. That is reality. I haven’t decided whether that’s a good ting or bad, but it’s definitely a question that the community should carefully consider in evaluating this policy. I’m not saying the potential outcomes are necessarily bad, but whatever they may be, I want to maximize the probability that they are intended rather than unintended consequences. Owen
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
