John, On Apr 2, 2013, at 11:22 AM, John Curran <[email protected]> wrote: > On Apr 2, 2013, at 12:27 PM, Shane Amante <[email protected]> wrote: >> IMO, there is still one key difference. ISP's are _directly_ involved in >> receiving such orders, evaluating them for validity, applicability and then >> carrying them out. This can also include providing a heads-up to operations >> teams, in that SP, that a change in configuration to effect it was >> "purposeful", thus saving substantial time + OpEx not trying to track down a >> "general connectivity issue" that a customer calls in and reports to the SP. >> >> OTOH, with the RPKI ... the actions carried out by, for example, an RIR will >> have to be without consultation of the ISP(s) with the directly attached >> customer, in the case of sealed orders. How does the SP know that a >> certificate was revoked due: a) a bug; b) lack of payment to their RIR; or, >> c) a lawful order? And, more importantly, could/should/would ISP's act >> differently, in terms of routing on their networks in any of those cases? > > That would suggest that monitoring and alerting aspects of these services > are indeed important, but that doesn't appear to be materially different > than the risks associated with relying on third-party filter lists, anti- > spam blocklists, or IRR data for delivering reliable services today.
In today's world, if a resource holder doesn't "like" the services provided by an IRR (perhaps, the IRR is unreliable, not cost-effective, etc.), then there's very low-bar for that resource-holder to register their resources in one or more third-party IRR's they consider "better", for some value of better. I think we would agree that the advantage here is a resource-holder gets to "shop around" for Routing Registry Services based on what attributes in a registry the resource holder considers important, (price, availability, susceptibility to LEA), etc. The one, not insignificant, downside is that those (third-party) registries do not, at the moment, provide rigorous authentication of the resources that are registered, (but clearly that's a known risk that exists and is "accepted" today -- whether that continues to be true and/or less acceptable in the future is clearly unknown). So, in the future of the RPKI, as a resource holder, how am I able to "shop around" as per the above, to mitigate one or more of the concerns that I've illustrated above? Hint: given the, at present, limited number of RIR's near the top of the allocation hierarchy, there would appear to be little choice. -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
