On 11/8/12 6:01 AM, Shane Amante wrote: > 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.
I think these are very valid points from an operational standpoint, but that is not the concern regarding the third-party indemnification clause. The third-party indemnification means that I have to assume all of ARIN's liability arising from *my* use of the RPKI, if I choose to use it. IANAL, so it is not clear to me if that covers cases where clearly ARIN is at fault. I assume that the legitimate intention is to avoid a MAPS-like situation, where the RIR gets sued because I choose not to carry ISP-X's routes because of invalid ROAs. But what if the RIR does something stupid and breaks RPKI and I stop carrying ISP-X's routes? Do I have to assume the RIR's liability? My layman's perspective on this is that we should ditch the indemnification clause and each have to assume our own risks--and that seems to be consistent with your argument. At any rate, I am pretty sure this issue isn't an IETF concern, and I will raise this on arin-discuss@ later today or tomorrow. ARIN members are welcome to join me there. michael _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
