Sandy, On Nov 8, 2012, at 6:25 AM, "Murphy, Sandra" <sandra.mur...@sparta.com> wrote: > Speaking as regular ol' member > > On Wednesday, November 07, 2012 10:48 PM, Shane Amante > [sh...@castlepoint.net] said: > >> Commercial operators, in particular, should carefully evaluate the risks >> posed to >> their core business (selling Internet transit) by now being reliant on >> certificate >> information that directly affects _reachability_information_ carried within >> their >> network. That certificate information is maintained by an outside party >> that's >> outside the operator organization's _direct_ (immediate) control and for >> which they, seemingly, have no recourse if (when?) something goes wrong. > > I think the Internet is already there. > > There are ISPs that spend considerable energy creating prefix filters from > IRR data and strongly encourage their customers to register in IRRs. Those > registers are maintained by an outside party that's outside the operator > organization's direct control. Those registered objects directly affect > reachability information carried within their network. > > Commercial operators have been comfortable with this mode of operation for > many years. I doubt whether any of them have felt the need to carefully > evaluate the risks or consult their legal departments. It has been best > current practice and urged on operators at *OG meetings. > > I don't think we want people asking ISPs that use IRRs why they run such a > risky operation. > > --Sandy, speaking as regular ol' member
There is not, in my understanding, a single root for the IRR's. Although RIR's for a particular region do allocate and register those resources (IP prefixes, ASN's, etc.) into their respective IRR instance ... there is absolutely nothing stopping the resource holder from registering their resources in one, or more, "3rd-party IRR" instances /not/ run or controlled by any RIR, i.e.: RADB, ALT.DB, etc. IMO, the ability to do that constitutes "risk mitigation" on the part of the resource holder who publishes their objects (customer) as well as the _direct_ ISP's (from whom their buy service) that consume those objects, since there is no single, central authority with direct control over their business. That said, I acknowledge the downside with the present IRR model is that, in most instances, no IRR can express authority for the resources held in their IRR DB. IMO, that creates a problem for /3rd-parties/ -- researchers, LEO, etc. -- who have no direct (contractual) relationship with both the ISP and their customer, since those third-parties have a difficult time in understanding which IRR to believe has the most up-to-date copy of resources. However, keep in mind (and this is key here), that each ISP *does* have a direct contractual relationship with its customers. At the time such contracts are signed, the customer must tell the ISP which specific IRR instance(s) the customer has registered and maintains their IRR objects, which gets around at least /part/ (but, not all) of the problem. Before you respond with: each RP (ISP) in the RPKI system is free to choose whatever TA's they want to mitigate such risks -- I would ask: if ISP's did that, how is that /any/ different from the operation of the present-day IRR model? IMO, it's not clear that the RPKI is "fixing" anything, unless everyone voluntarily or _involuntarily_ accepts a single-rooted RPKI as the sole source of resource information ... As with many things, risk is subjective and each party in a system should decide for themselves what constitutes acceptable risk for their operations. -shane P.S. -- I apologize for having veered off of technical topics for an IETF mailing list. I will refrain from responding to this thread further. > ________________________________________ > From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Shane Amante > [sh...@castlepoint.net] > Sent: Wednesday, November 07, 2012 10:48 PM > To: Michael Sinatra > Cc: sidr@ietf.org; Murphy, Sandra > Subject: Re: [sidr] additions and changes to agenda on Friday > > Michael, > > On Nov 7, 2012, at 7:48 PM, Michael Sinatra <mich...@burnttofu.net> wrote: >> On 11/07/2012 10:29, Danny McPherson wrote: >> >>> Sandy, Can you elaborate what your "concerns about this agreement's >>> impact on the envisioned RPKI architecture and dominant use" are? Do >>> you have a reference or outline we can review prior to the discussion >>> in order to keep this from being a >>> bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuff >>> fest? >> >> In addition to Sandy's concerns, the agreement contains a third-party >> indemnification clause (as do other ARIN RPKI-related agreements) that makes >> it difficult for many state and federal government (and large EDUs) to >> simply click through and sign. In most of these environments, the network >> engineers who would be wanting to try out RPKI would not be permitted to >> agree to such indemnification. This may also be true at large corporations. >> >> This, I think, has very little architectural impact, but it does mean >> additional hoops for operators (like myself) to experiment with RPKI and/or >> put it in production. As such, further discussion is probably out of scope >> for SIDR, and I will take this to arin-discuss@ accordingly. But I did want >> to give this group an FYI that this may be at least a speed-bump on the >> deployment front. > > > I (also) commend ARIN for their due diligence on this matter. Commercial > operators, in particular, should carefully evaluate the risks posed to their > core business (selling Internet transit) by now being reliant on certificate > information that directly affects _reachability_information_ carried within > their network. That certificate information is maintained by an outside > party that's outside the operator organization's _direct_ (immediate) control > and for which they, seemingly, have no recourse if (when?) something goes > wrong. That risk without remedies/recourse is not something commercial > entities are prone to voluntarily accept. > > Obviously, each operator should seek advice from their own legal counsel as > to the risks and make their own decisions. > > -shane > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
