ARIN's RPKI Relying agreement
Greetings: In the past few months, I've spoken with, or heard second hand, from a number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement. Acceptance of this agreement is required in order to gain access to ARIN's Trust Anchor Locator (TAL). Given the size and number of these organizations that can't or wont accept the agreement makes me wonder if this is a show stopper that will prevent the adoption of this technology. I've created a quick survey to get an idea of the community's take on this agreement with the idea that if enough organizations indicate it is unacceptable, maybe we can get this agreement changed, or as with other regions, not explicitly required to use the TAL. https://docs.google.com/forms/d/10RLBBpL05n1c_H4unHitlsVqNM3rZI5aXAX8iSBc_Kk... Thank you.
On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said:
In the past few months, I've spoken with, or heard second hand, from a number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement.
Do we have a handle on *why* organizations are having issues with the agreement?
On Thu, Dec 4, 2014 at 10:04 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said:
In the past few months, I've spoken with, or heard second hand, from a number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement.
Do we have a handle on *why* organizations are having issues with the agreement?
wes outlined some of his reasons here: https://www.nanog.org/sites/default/files/wednesday_george_adventuresinrpki_... michael sinatra did a reasonable coverage as well in a previous nanog meeting (I think?)
On Thu, Dec 4, 2014 at 10:21 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Dec 4, 2014 at 10:04 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said:
In the past few months, I've spoken with, or heard second hand, from a number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement.
Do we have a handle on *why* organizations are having issues with the agreement?
wes outlined some of his reasons here: https://www.nanog.org/sites/default/files/wednesday_george_adventuresinrpki_...
michael sinatra did a reasonable coverage as well in a previous nanog meeting (I think?)
also, john curran covers some of the legal indemnification stuff about here: <https://www.youtube.com/watch?v=uGSo4uiYyAc#t=1868> in the video of the slide presentation above.
Honestly, that's what I'm trying to figure out as well. In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it, otherwise, the agreement will stand. On 12/4/2014 10:04 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said:
In the past few months, I've spoken with, or heard second hand, from a number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement. Do we have a handle on *why* organizations are having issues with the agreement?
On Dec 4, 2014, at 7:35 AM, Andrew Gallo <akg1330@gmail.com> wrote: In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it,
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that? -Bill
On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock <woody@pch.net> wrote:
On Dec 4, 2014, at 7:35 AM, Andrew Gallo <akg1330@gmail.com> wrote: In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it,
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that?
-Bill
This is the same legal feedback most lawyers will give you about settlement free peering as well. CB
----- Original Message -----
From: "Ca By" <cb.list6@gmail.com>
On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock <woody@pch.net> wrote:
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that?
This is the same legal feedback most lawyers will give you about settlement free peering as well.
And this delightfully illustrates what IMG's Mark MacCormack is pleased to call "the Terrible Truth About Lawyers", to wit: Lawyers believe that their job is to tell you what not to do. Their *actual job* is to tell where risks lie, so that you can make informed business decisions about which risks to take, and how to allow for them. If you as a businessman believe the lawyers' point of view, though, you will never accomplish anything. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock <woody@pch.net> wrote:
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it.
WG] Has there been any actual discussion about how much "nobody" would have to pay for ARIN (or another party) to fix the balance of liability and provide a proper SLA that led to "no, I don't want to pay for that" responses from those who are expressing the concern, or is this just conjecture on your part? I know that despite being fairly vocal on the matter, I've not been party to any such discussion, though I know that ARIN fees and what services they provide for those fees is an ongoing discussion in other forums. The problem with free services is that often you get what you pay for when it comes to support, warranty, etc. There are plenty of models where you take something free, say FOSS, and then pay someone (Red Hat, ISC) to support it in order to manage the risk associated with putting it in the middle of your business-critical system. It gives you some determinism about what happens when it breaks or you need a feature, and recourse when it goes pear-shaped. I think there's room for discussion around how much an SLA-backed RPKI service might be worth to its potential customers, given its ability to either protect or badly break global routing. On 12/4/14, 11:33 AM, "Jay Ashworth" <jra@baylink.com> wrote:
Lawyers believe that their job is to tell you what not to do.
Their *actual job* is to tell where risks lie, so that you can make informed business decisions about which risks to take, and how to allow for them
WG] FWIW, I believe that my lawyers did their "actual" job. But as I said in my presentation, the combination of technical fragility and liability risk I incur if it breaks in a way that impacts my customers led me to decide that I'm not yet willing to bet my continued gainful employment on Route Origin Validation working well enough that the benefit of having it outweighs the risks. INAL, YMMV, void where prohibited, caveat lector, of course. Fixing the liability issues certainly removes one barrier to entry, but it's not the only one, and the technical issues are being worked in parallel. Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On Dec 4, 2014, at 10:17 AM, George, Wes <wesley.george@twcable.com> wrote: WG] Has there been any actual discussion about how much "nobody" would have to pay for ARIN (or another party) to fix the balance of liability and provide a proper SLA that led to "no, I don't want to pay for that" responses from those who are expressing the concern, or is this just conjecture on your part?
I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI services,” and the answer has always been “no.” Until I get a “yes,” it’s hard to put a number (other than zero) on how the market values RPKI. So, asking how much more risk ARIN is willing to take on seems a little premature.
The problem with free services is that often you get what you pay for when it comes to support, warranty, etc.
Yep. -Bill
On Dec 4, 2014, at 1:34 PM, Bill Woodcock <woody@pch.net> wrote:
On Dec 4, 2014, at 10:17 AM, George, Wes <wesley.george@twcable.com> wrote: WG] Has there been any actual discussion about how much "nobody" would have to pay for ARIN (or another party) to fix the balance of liability and provide a proper SLA that led to "no, I don't want to pay for that" responses from those who are expressing the concern, or is this just conjecture on your part?
I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI services,” and the answer has always been “no.” Until I get a “yes,” it’s hard to put a number (other than zero) on how the market values RPKI. So, asking how much more risk ARIN is willing to take on seems a little premature.
I suspect you would get a similar answer if you asked people "Would you be willing to pay ARIN for whois services" or "would you be willing to pay ARIN for in-addr.arpa services". I've always been under the impression that the fees charged annually to my orgid were in part to cover the costs associated with running the registry, which by definition involves a certain amount of risk. Am I mistaken? -r
On Dec 4, 2014, at 11:11 AM, Robert Seastrom <rs@seastrom.com> wrote: I suspect you would get a similar answer if you asked people "Would you be willing to pay ARIN for whois services" or "would you be willing to pay ARIN for in-addr.arpa services”.
Actually, since those are relatively inexpensive, I suspect there are plenty of people who’d be willing to cover those costs, if they needed to be paid separately. However...
I've always been under the impression that the fees charged annually to my orgid were in part to cover the costs associated with running the registry, which by definition involves a certain amount of risk.
…the RPKI costs are many orders of magnitude higher, and that’s before anyone sues us. So, the question is how much of your fees you want to see going toward RPKI, and how much of that you want to go toward trying to make it functional, versus mitigating the risk when it’s not. -Bill
On Dec 4, 2014, at 11:21 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 04 Dec 2014 11:17:34 -0800, Bill Woodcock said:
the RPKI costs are many orders of magnitude higher
Orders of magnitude? Seriously? I can buy it costs 2x or 3x. But an additional 2 or 3 zeros on the price?
Yep, that’s why all this is at issue. If it were cheap, and worked, like in-addr or whois, there wouldn’t be an issue, would there? -Bill
On Thu, 04 Dec 2014 11:28:42 -0800, Bill Woodcock said:
On Dec 4, 2014, at 11:21 AM, Valdis.Kletnieks@vt.edu wrote: Orders of magnitude? Seriously? I can buy it costs 2x or 3x. But an additional 2 or 3 zeros on the price?
Yep, thats why all this is at issue. If it were cheap, and worked, like in-addr or whois, there wouldn't be an issue, would there?
So why does an RPKI request cost *500 times* as much as (say) a request to assign an address block? Why is it *that* much more expensive to handle?
This pig is less aerodynamic, and fewer people are pushing. In-addr DNS and whois are simple and well-understood protocols, with many programmer-years of software development behind them. The problem isn't the marginal cost of a single transaction, that might only be one or two orders of magnitude higher. The problem is the overhead cost of trying to force a poorly-architected system into a semblance of production-quality. If you want something that anyone can _actually rely upon_, that's a precursor to doing the incremental transactions. -Bill
On Dec 4, 2014, at 11:49, "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 04 Dec 2014 11:28:42 -0800, Bill Woodcock said:
On Dec 4, 2014, at 11:21 AM, Valdis.Kletnieks@vt.edu wrote: Orders of magnitude? Seriously? I can buy it costs 2x or 3x. But an additional 2 or 3 zeros on the price?
Yep, thats why all this is at issue. If it were cheap, and worked, like in-addr or whois, there wouldn't be an issue, would there?
So why does an RPKI request cost *500 times* as much as (say) a request to assign an address block? Why is it *that* much more expensive to handle?
On 12/4/14, 1:34 PM, "Bill Woodcock" <woody@pch.net> wrote:
I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI services,” and the answer has always been “no.” Until I get a “yes,” it’s hard to put a number (other than zero) on how the market values RPKI.
WG] well, if it wasn't clear from my previous message, you've gotten a yes, but it's a qualified yes, and the timeframe, as well as what I'm paying for, matters. We need to put some daylight between "how the market values RPKI" and "whether RPKI is ready for wide-scale deployment" and "what the market expects from ARIN as a service provider for a critical piece of that system when it's in wide-scale deployment". You can see multiple folks expressing concern about other aspects of RPKI beyond ARIN's RPA and liability. Those problems have to be solved before we can have a real discussion about how the market values RPKI, because prior to that it's simply not ready for wide-scale deployment. Additionally, we have a catch-22 in that most of RPKI's benefit is not realized until there are enough prefixes signed and enough large networks validating signatures and dropping invalid announcements, which means the incentive for early adopters is hard to quantify. In other words, the benefits of deploying RPKI that we have to use to justify the costs, whether it's increased ARIN fees or the hardware, complexity, and headcount costs associated with deploying and maintaining it, cannot be realized yet. So, the only thing I know to do is to make sure that I'm working these issues in parallel so that we don't remove one barrier to entry only to crash into the next one. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On Dec 4, 2014, at 7:35 AM, Andrew Gallo <akg1330@gmail.com> wrote: In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it,
Hi Andrew, The short version is that the would-be consumers of the RPKI data want the data published in much the same way that whois data is published. Many of the organizations aren't even in the ARIN region. Virtually any formal contract ARIN is able to offer will be a non-starter for these folks. On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock <woody@pch.net> wrote:
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that?
Hi Bill, No, nothing more useful. I've seen a lot of hand waving, but I still have no clue how the publication of RPKI data places ARIN at a different risk than publication of whois data. I think if we could better understand that, we'd be better able assess what the next steps are. Do we beat down ARIN's door and insist they publish the data? Do we pursue the creation of some new organization to manage RPKI, one with intentionally shallow pockets, and ask ARIN to cede the function? Something else? I think we all need a better understanding of the alleged legal issue before we can zero in on what should come next. For sure ARIN's current solution, a contract few will sign, is unsatisfactory. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?
On 12/4/2014 11:22 AM, William Herrin wrote:
On Dec 4, 2014, at 7:35 AM, Andrew Gallo <akg1330@gmail.com> wrote: In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it, Hi Andrew,
The short version is that the would-be consumers of the RPKI data want the data published in much the same way that whois data is published. Many of the organizations aren't even in the ARIN region. Virtually any formal contract ARIN is able to offer will be a non-starter for these folks.
Understood and good point. I've heard rumblings of setting up a non-ARIN TAL, though I wonder what the value is in separating RPKI from the registry. Wouldn't this put us in the same position we're in with routing registries (with respect to data quality)?
On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock <woody@pch.net> wrote:
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that? Hi Bill,
No, nothing more useful. I've seen a lot of hand waving, but I still have no clue how the publication of RPKI data places ARIN at a different risk than publication of whois data. I think if we could better understand that, we'd be better able assess what the next steps are. Do we beat down ARIN's door and insist they publish the data? Do we pursue the creation of some new organization to manage RPKI, one with intentionally shallow pockets, and ask ARIN to cede the function? Something else? I think we all need a better understanding of the alleged legal issue before we can zero in on what should come next.
For sure ARIN's current solution, a contract few will sign, is unsatisfactory.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?
Hello, On 12/4/2014 2:33 PM, Andrew Gallo wrote:
On 12/4/2014 11:22 AM, William Herrin wrote: Understood and good point. I've heard rumblings of setting up a non-ARIN TAL, though I wonder what the value is in separating RPKI from the registry. Wouldn't this put us in the same position we're in with routing registries (with respect to data quality)?
Exactly the same. RPKI without the tie-in to the registration database is just another random database, like the dozens that are out there, bound to suffer from exactly the same problems current IRRs suffer. Disclaimer: I work for LACNIC, but in this case, if I was a beggar playing music at subway stations my opinion would be exactly the same. Cheers! Carlos
Hello, On 12/4/2014 2:33 PM, Andrew Gallo wrote:
On 12/4/2014 11:22 AM, William Herrin wrote: Understood and good point. I've heard rumblings of setting up a non-ARIN TAL, though I wonder what the value is in separating RPKI from the registry. Wouldn't this put us in the same position we're in with routing registries (with respect to data quality)?
Exactly the same. RPKI without the tie-in to the registration database is just another random database, like the dozens that are out there, bound to suffer from exactly the same problems current IRRs suffer. Disclaimer: I work for LACNIC, but in this case, if I was a beggar playing music at subway stations my opinion would be exactly the same. Cheers! Carlos
On Thu, Dec 4, 2014 at 11:22 AM, William Herrin <bill@herrin.us> wrote:
On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock <woody@pch.net> wrote:
All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that?
<snip>
No, nothing more useful. I've seen a lot of hand waving, but I still have no clue how the publication of RPKI data places ARIN at a different risk than publication of whois data. I think if we could better understand that,
(oops, I assumed that the decision to have the rpa implemented in the way it is is due to 'arin counsel') Maybe it would be helpful for the ARIN Counsel to document in a more public way (than the RPA) what the concerns are and how that translates into 'different risk than the publication of whois data' ?
we'd be better able assess what the next steps are. Do we beat down ARIN's door and insist they publish the data? Do we pursue the creation of some new organization to manage RPKI, one with intentionally shallow pockets, and ask ARIN to cede the function? Something else? I think we all need a better understanding of the alleged legal issue before we can zero in on what should come next.
One of the complaints I've heard is that for out-of-region folk to get the TA details they need to sign the RPA, and potentially be bound by a contract that they can't be bound by anyway... so the process is looked upon as a bit 'foolish' or perhaps: "over-reaching" is the more polite term used. First though I think Bill's point about: "How did we get into this mess? could someone walk us through the process/steps taken to get here?" maybe we zigged when we ought to have zagged? -chris
On Dec 4, 2014, at 11:35 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
... Maybe it would be helpful for the ARIN Counsel to document in a more public way (than the RPA) what the concerns are and how that translates into 'different risk than the publication of whois data' ?
This is apparently being discussed on two different lists (PPML and NANOG) at the same time, so apologies for the cross-posting... The reason that the RIRs have disclaimer of warranty and indemnification clauses for RPKI services is actually quite simple: despite striving to deliver highly available RPKI services, you are supposed to be using best practices in use of the service, and this include recognizing that failures can occur and such should not result in operation impact (i.e. exactly the opposite of your “my routing decisions are affected and breakage happens” statement in your prior email.) Specifically, your RPKI deployment approach should be following known operational best practices for RPKI, such as those in RFC 7115 / BCP 185, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)” - “… Local policy using relative preference is suggested to manage the uncertainty associated with a system in early deployment; local policy can be applied to eliminate the threat of unreachability of prefixes due to ill-advised certification policies and/or incorrect certification data. “ Note that the claims that could ensue from an operator failing to follow best practices and then third-parties suffering an major operational outage is likely to be large and extremely protracted, with potential for endangering the registry itself due to the nature of litigation and its requirement to actually go to all the way to trial in order to be able to then introduce evidence and prove that the RPKI services were operating properly at the time of the event. If the RIRs did not seek indemnification for use of the RPKI services, then all of their other registry services could potentially be put at risk due to the need to defend errant litigation, even presuming perfect RPKI service delivery. Undertaking that risk to the other services that everyone else presently rely upon (Whois, reverse DNS) is not reasonable particularly during this time when the RPKI parties are supposed to be deploying via conservative routing preference practices. ARIN does make the expectations very clear and explicit in its agreements, and that is different from the other RIRs. Again, are the other RIR RPKI non-warranty and indemnification clauses equally problematic for you, or is the fact that they are implicitly bound address your concerns? This has come up before on the NANOG mailing list (see attached) but it was unclear if the outcome was an expectation that all RIRs should drop these clauses, or that ARIN should make agreement to them be implicit. Thanks! /John John Curran President and CEO ARIN
=== Begin forwarded message:
Subject: Re: APNIC RPKI TAL agreement From: John Curran <jcurran@arin.net> Date: October 16, 2014 at 7:30:48 PM EDT Cc: Wes George <wesley.george@twcable.com>, Randy Bush <randy@psg.com>, "Geoff Huston" <gih@apnic.net> To: Michael Sinatra <michael@burnttofu.net>
On Oct 16, 2014, at 3:19 PM, Michael Sinatra <michael@burnttofu.net> wrote:
Hi John:
At NANOG 62, you mentioned that APNIC has a similar agreement as ARIN to use its trust-anchor locator (TAL), but that it is not a click-through agreement like ARIN's. I have searched using basic google-foo for this agreement, and have also looked on APNIC's certificate rsync server (which also has an HTTP interface) and I can't find it. Can you, or any other recipient of this message who is familiar with the APNIC agreement, point me in the right direction?
Michael -
Review <http://www.apnic.net/services/manage-resources/digital-certificates/terms-and-conditions> wherein there is a limitation of liability and requirement that a recipient of any digital certificate will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate. (last two bullets)
/John
John Curran President and CEO ARIN ===
On Dec 4, 2014, at 12:39 PM, John Curran <jcurran@arin.net> wrote:
On Dec 4, 2014, at 11:35 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
Note that the claims that could ensue from an operator failing to follow best practices and then third-parties suffering an major operational outage is likely to be large
Undertaking that risk to the other services that everyone else presently rely upon (Whois, reverse DNS) is not reasonable
Which begs the question for me -- ARIN already operates services that operators rely upon. Why are they different? Does ARIN run no risk of litigation due to some perceived involvement of those services in someone's operational outage? Has there been litigation against ARIN tied to, for example, reverse DNS? Or the IRR? --Sandy
Am I correct in thinking that the SIDR work going on in the IETF takes the registries out of the real-time processing of route authentication/attestation? Is RPKI a stop-gap while we wait for full path validation? Should we be focusing our energies in that area? On Thu, Dec 4, 2014 at 2:19 PM, Sandra Murphy <sandy@tislabs.com> wrote:
On Dec 4, 2014, at 12:39 PM, John Curran <jcurran@arin.net> wrote:
On Dec 4, 2014, at 11:35 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
Note that the claims that could ensue from an operator failing to follow best practices and then third-parties suffering an major operational outage is likely to be large
Undertaking that risk to the other services that everyone else presently
rely upon
(Whois, reverse DNS) is not reasonable
Which begs the question for me -- ARIN already operates services that operators rely upon. Why are they different? Does ARIN run no risk of litigation due to some perceived involvement of those services in someone's operational outage?
Has there been litigation against ARIN tied to, for example, reverse DNS? Or the IRR?
--Sandy
On 12/4/14, 2:34 PM, "Andrew Gallo" <akg1330@gmail.com> wrote:
Am I correct in thinking that the SIDR work going on in the IETF takes the registries out of the real-time processing of route authentication/attestation? WG] no, but they're at least discussing ways of making the dependencies less fragile and more scalable (e.g. Eliminating rsync).
Is RPKI a stop-gap while we wait for full path validation? Should we be focusing our energies in that area?
WG] Path Validation is a completely separate pig, one which may require significantly more thrust to achieve escape velocity when compared with Origin Validation. Origin Validation isn't a stop gap, as much as it is an incremental step that Path Validation builds on to provide more additional protection that Origin Validation alone cannot provide. They're intended to coexist, not replace. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On 12/4/14, 2:19 PM, "Sandra Murphy" <sandy@tislabs.com> wrote:
Which begs the question for me -- ARIN already operates services that operators rely upon. Why are they different? Does ARIN run no risk of litigation due to some perceived involvement of those services in someone's operational outage?
WG] I'm hard-pressed to come up with a case where packets stop flowing or flow to the wrong party because whois is down. *Maybe* you can make that case for reverse DNS since lots of anti-spam/anti-spoof relies on forward/reverse DNS agreement, but that doesn't affect routing. RPKI ups the ante considerably. I believe ARIN when they say that the liability risks are higher for this. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On Dec 4, 2014, at 2:19 PM, Sandra Murphy <sandy@tislabs.com> wrote:
... Which begs the question for me -- ARIN already operates services that operators rely upon. Why are they different? Does ARIN run no risk of litigation due to some perceived involvement of those services in someone's operational outage?
Sandra - From the discussion over on PPML... Parties are likely to use RPKI services such that (as someone put it recently) - "routing decisions are affected and breakage happens” While such impacts could happen with whois, parties would have to create the linkages themselves, whereas with RPKI it is recognized that the system is designed to provide information for influencing of routing decisions (a major difference, and one that a judge could be made to recognize if some service provider has a prolonged outage due to their own self-inflicted Whois data wrangling into routing filters.) Given the nature of RPKI, it is clear that ARIN needs to engineer the service with full awareness of the potential risks (even though such risks are predominantly the result of parties using RPKI data without appropriate best practices.) We have no problem offering a highly- reliable service; the risk of concern stems from third-parties who suffer major damages and want to assert that it was the result of an ISP’s misusage of ARIN’s RPKI service or ARIN’s RPKI service itself, even if the underlying cause in truth was completely unrelated to ARIN’s RPKI services. Recognize that large harmed parties tend to litigate everyone, with the innocent parties extracting themselves only after lengthy battles, and such battles are very difficult when it comes to proving the proper state of technical service at a given point in time. I hope this helps in outlining some of the significant differences. /John John Curran President and CEO ARIN
i run rtconfig to take irr data and auto-install the fiter in my router i run rpki-rtr to take rpki date and auto-install the fiter in my router and the difference is? you ean we made the second easier and more automatable? well then run the rpki data into the handy dandy roa to irr filter and stuff it up rtconfig. randy
and the difference is? rpki might work at scale.
ohhh noooooooooo! fwiw, we had a script set running which took a route views dump, created an ersatz roa set covering the whole table, and fetched it into a small router or two. it got boring, so i am not sure it's still there. if you want, we can probably dig it up and put it on a rpki-rtr port again. may take a few weeks as ENOTIME. randy
On Fri, 5 Dec 2014, Randy Bush wrote:
and the difference is? rpki might work at scale.
ohhh noooooooooo!
fwiw, we had a script set running which took a route views dump, created an ersatz roa set covering the whole table, and fetched it into a small router or two.
which implementation? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
On 05/12/2014 11:47, Randy Bush wrote:
and the difference is? rpki might work at scale.
ohhh noooooooooo!
rtconfig + prefix lists were never going to work at scale, so rpsl based filters were mostly only ever deployed on asn edges rather than dfz core inter-as bgp sessions. This meant that the damage that a bad update might cause would be relatively limited in scope. RPSL's scaling limitations do not apply to rpki, so in theory the scope for causing connectivity problems is a good deal greater. So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability. Nick
rpki might work at scale. ohhh noooooooooo!
rtconfig + prefix lists were never going to work at scale, so rpsl based filters were mostly only ever deployed on asn edges rather than dfz core inter-as bgp sessions. This meant that the damage that a bad update might cause would be relatively limited in scope. RPSL's scaling limitations do not apply to rpki, so in theory the scope for causing connectivity problems is a good deal greater. So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability.
if it works, it is scary and must be stopped! and arin is doing such a great job of that. randy
On 5 Dec 2014, at 18:00, Nick Hilliard <nick@foobar.org> wrote:
On 05/12/2014 11:47, Randy Bush wrote:
and the difference is? rpki might work at scale.
ohhh noooooooooo!
So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability.
If ARIN (or another other RIR) went offline or signed broken data, all signed prefixes that previously has the RPKI status "Valid", would fall back to the state "Unknown", as if they were never signed in the first place. The state would NOT be "Invalid". What is the likelihood of Joe's Basement ISP being filtered by anyone because their BGP announcements are RPKI "Unknown", as if they weren't participating in the opt-in system? It seems as if the argumentation is built around "RIR messes up == ISPs go offline", but that isn't a realistic scenario IMO, because no operator in their right mind would drop prefixes with the state "Unknown". You could only realistically do that if all 550,000 Announcements in the DFZ are covered by a ROA. Not soon, if ever. -Alex
On Dec 6, 2014, at 3:27 AM, Alex Band <alexb@ripe.net> wrote:
If ARIN (or another other RIR) went offline or signed broken data, all signed prefixes that previously has the RPKI status "Valid", would fall back to the state "Unknown", as if they were never signed in the first place. The state would NOT be "Invalid".
Alex - Depends on the nature of the error... In cases of overclaiming, the current validation algorithm could result in "Invalid". This could happen, for example, if major ISP were to initiate transfer of some number resources to their business unit in another region, and then fail locally to swing to certs with the reduced resource list in a timely manner... All of the remaining prefixes in the existing cert would be deemed "invalid" and that could easily result in some very significant disruption for those validating w/RPKI. (i.e. as noted in <draft-ietf-sidr-rpki-validation-reconsidered-00>) FYI, /John John Curran President and CEO ARIN
On Dec 5, 2014, at 6:38 AM, Randy Bush <randy@psg.com> wrote:
i run rtconfig to take irr data and auto-install the fiter in my router
i run rpki-rtr to take rpki date and auto-install the fiter in my router
and the difference is?
Not much - that's very likely why RIPE's IRR terms and conditions require the user to hold harmless, indemnify and defend the RIPE NCC; why registering for RADb requires agreeing to indemnify Merit, etc. Thanks, /John John Curran President and CEO ARIN
zombie-thread! On Thu, Dec 4, 2014 at 12:39 PM, John Curran <jcurran@arin.net> wrote:
t (i.e. exactly the opposite of your “my routing decisions are affected and breakage happens” statement in your prior email.)
the discussion in the thread was interesting, sometimes a bit more personal than was required and at times devoid of useful data... but I did want to point out one thing, I didn't say the quoted section, at least not in this thread... thanks john for hanging in for the discussion... -chris
On Dec 16, 2014, at 2:19 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
zombie-thread!
On Thu, Dec 4, 2014 at 12:39 PM, John Curran <jcurran@arin.net> wrote: t (i.e. exactly the opposite of your “my routing decisions are affected and breakage happens” statement in your prior email.)
the discussion in the thread was interesting, sometimes a bit more personal than was required and at times devoid of useful data... but I did want to point out one thing, I didn't say the quoted section, at least not in this thread...
Ah, yes... "breakage happens" was another gentleman over on PPML <http://lists.arin.net/pipermail/arin-ppml/2014-December/029383.html> (and apologies for any confusion!)
thanks john for hanging in for the discussion...
Thanks to everyone for the important feedback (even if somewhat pointed at times... :-) /John John Curran President and CEO ARIN
Bill Woodcock <woody@pch.net> writes:
On Dec 4, 2014, at 7:35 AM, Andrew Gallo <akg1330@gmail.com> wrote:
In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it,
All the specific legal feedback Ive heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that?
The way the RPA is worded, ARIN seems to be attempting to offload all the risk to its member organizations. Anything that ARIN does has some degree of risk associated with it. Twice a year we host parties where alcohol is served. That's a risky endeavor on all sorts of ways - at least we're typically taking buses to and from the event so we aren't driving. I have heard it asserted the board is unwilling for the organization to shoulder even that level of risk as part of providing RPKI. As a board member, can you speak to this? Whether this extreme level of risk aversity is a matter of mistaken priorities (putting the organization itself ahead of accomplishing the organization's mission) or a way of making sure that we stop wasting money on RPKI due to demonstrable non-uptake is left as an exercise to the reader. You can infer from the last statement that I would applaud cutting our losses on RPKI. The quote on slide 23 of Wes' deck about replacing complex stuff like email templates with simple, easy to understand public key crypto was mine. If you can't get people to play ball nicely with client filtering, IRR components, etc. where the bar to entry is low, who can _possibly_ say with a straight face that we can get people to embrace RPKI? To the usual suspects: sorry to call your kid ugly. Don't hate the messenger. -r
On Thu, Dec 4, 2014 at 7:35 AM, Andrew Gallo <akg1330@gmail.com> wrote:
Honestly, that's what I'm trying to figure out as well. In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it, otherwise, the agreement will stand.
On 12/4/2014 10:04 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said:
In the past few months, I've spoken with, or heard second hand, from a
number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement.
Do we have a handle on *why* organizations are having issues with the agreement?
They want a pony.
On 12/4/14, 10:35 AM, "Andrew Gallo" <akg1330@gmail.com> wrote:
Honestly, that's what I'm trying to figure out as well. In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it, otherwise, the agreement will stand.
For my part, I have had discussions with ARIN's internal legal council and other staff about our specific concerns and how to address them, and intend to continue doing so, as I agree that this won't get solved if we just say "unacceptable" and drop the subject. That said, this is harder to manage because it doesn't fall into the existing ARIN policy development process, so the community doesn't have as direct of a voice on changes to the policies. I can't just submit a policy proposal to change how ARIN words its RPA, who is bound by it, and how ARIN provides RPKI services. Those are operational matters, implemented by the staff, governed by the board, who is informed by their legal council and staff. That is part of the reason why I brought some of the issues to the NANOG community, since interaction with ARIN board members and staff is what's necessary to make sure the concerns are addressed, and thus it benefits from wider discussion. I'll try to go through your survey as well. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On Dec 4, 2014, at 12:32 PM, George, Wes <wesley.george@twcable.com> wrote:
Those are operational matters, implemented by the staff, governed by the board, who is informed by their legal council and staff. That is part of the reason why I brought some of the issues to the NANOG community, since interaction with ARIN board members and staff is what's necessary to make sure the concerns are addressed, and thus it benefits from wider discussion.
Wes - I am happy to champion the change that you seek (i.e. will get it reviewed by legal and brought before the ARIN Board) but still need clarity on what change you wish to occur - A) Implicit binding to the indemnification/warrant disclaimer clauses (as done by the other RIRs) B) Removal of the indemnification & warranty disclaimer clause I asked this directly during your NANOG presentation, but you did not respond either way. I also noted that your own business customer agreements have the same indemnification & non-warranty clauses (as they are common in nearly all telecommunication and ISP service agreements) - are these now being dropped by TWC in agreements? Thanks! /John John Curran President and CEO ARIN
On Dec 4, 2014, at 12:53 PM, John Curran <jcurran@arin.net> wrote:
On Dec 4, 2014, at 12:32 PM, George, Wes <wesley.george@twcable.com> wrote:
Those are operational matters, implemented by the staff, governed by the board, who is informed by their legal council and staff. That is part of the reason why I brought some of the issues to the NANOG community, since interaction with ARIN board members and staff is what's necessary to make sure the concerns are addressed, and thus it benefits from wider discussion.
Wes -
I am happy to champion the change that you seek (i.e. will get it reviewed by legal and brought before the ARIN Board) but still need clarity on what change you wish to occur -
A) Implicit binding to the indemnification/warrant disclaimer clauses (as done by the other RIRs)
B) Removal of the indemnification & warranty disclaimer clause
I asked this directly during your NANOG presentation, but you did not respond either way. I also noted that your own business customer agreements have the same indemnification & non-warranty clauses (as they are common in nearly all telecommunication and ISP service agreements) - are these now being dropped by TWC in agreements?
I recall a lengthly discussion about this at the NANOG meeting that occurred after the session. I think there is a very strong emotional thing here where we said to you (which you seem to have forgotten) that option B above would be helpful as it’s already covered by the general registration agreement (which was your assertion). Comparing what you do with Time Warner cable seems like pure hyperbole and an attempt as CEO to inflame community discussion at minimum. - Jared
On Dec 4, 2014, at 1:01 PM, Jared Mauch <jared@puck.nether.net> wrote:
I am happy to champion the change that you seek (i.e. will get it reviewed by legal and brought before the ARIN Board) but still need clarity on what change you wish to occur -
A) Implicit binding to the indemnification/warrant disclaimer clauses (as done by the other RIRs)
B) Removal of the indemnification & warranty disclaimer clause
I asked this directly during your NANOG presentation, but you did not respond either way. I also noted that your own business customer agreements have the same indemnification & non-warranty clauses (as they are common in nearly all telecommunication and ISP service agreements) - are these now being dropped by TWC in agreements?
I recall a lengthly discussion about this at the NANOG meeting that occurred after the session. I think there is a very strong emotional thing here where we said to you (which you seem to have forgotten) that option B above would be helpful as it’s already covered by the general registration agreement (which was your assertion).
Several folks suggested making the RPKI indemnification tie back to the language in the existing RSA (it is not presently but instead done via separate language). However, when I asked Wes about that approach he did not know at the time if that would address TWC's particular concern (hence my reason for following up now via email)
Comparing what you do with Time Warner cable seems like pure hyperbole and an attempt as CEO to inflame community discussion at minimum.
Actually, it is to remind folks that such indemnification language is sought by most ISPs, despite their services being used in a mission critical mode by many customers and despite the ISPs efforts to make their services be highly reliable. (One can easily argue that best practices require multiple connections or service providers, but that is the same with best practices for RPKI use requiring proper preferences to issues with certification data...) /John John Curran President and CEO ARIN
Comparing what you do with Time Warner cable seems like pure hyperbole and an attempt as CEO to inflame community discussion at minimum.
Actually, it is to remind folks that such indemnification language is sought by most ISPs, despite their services being used in a mission critical mode by many customers and despite the ISPs efforts to make their services be highly reliable.
(One can easily argue that best practices require multiple connections or service providers, but that is the same with best practices for RPKI use requiring proper preferences to issues with certification data...)
/John
John Curran President and CEO ARIN
I think your question is fair if you are talking to the TWC CEO, but in this case you are not and it’s disingenuous to pretend otherwise (which you are attempting through your weak straw-man). If ARIN isn’t capable of running RPKI or performing its function, which perhaps we should infer from your talking points, perhaps we should all transfer our resources out of region and dissolve ARIN? I don’t think that would suit the community needs though. I (similar to Rob) have my own concerns about RPKI but do feel that this is an ARIN specific construct/wall that has been raised without action yet from ARIN. The fact that the meeting was 2 months ago and you have not acted/discussed with your counsel says everything I need to know about the situation, your personal motives and your personal desires for the outcomes. I hope it doesn’t represent your employer and that the ARIN Board brings it up with you. - Jared
On Dec 4, 2014, at 1:19 PM, Jared Mauch <jared@puck.nether.net> wrote:
I (similar to Rob) have my own concerns about RPKI but do feel that this is an ARIN specific construct/wall that has been raised without action yet from ARIN.
Jared - Please be specific - are you referring to the indemnification clauses (which are existing in other RIRs as well), the method of agreement, or not having ready access to the TAL, i.e. the click-accept access?
The fact that the meeting was 2 months ago and you have not acted/discussed with your counsel says everything I need to know about the situation, your personal motives and your personal desires for the outcomes. I hope it doesn’t represent your employer and that the ARIN Board brings it up with you.
Incorrect. Despite the lack of clarity, we started work on 27 October with both inside and external counsel regarding drafting some updates to the RPKI legal framework. This effort should be ready to be brought to the ARIN Board in January for their consideration, but it would be helpful to have more clarity on the concerns (i.e. is it access to the TAL, or the requirement for explicit agreement to terms and conditions, or the presence of indemnification/warrant-disclaimer language regardless of method of binding) At present, I am working on addressing the TAL access and the explicit agreement concerns that were raised during Wes's NANOG session. These are relatively straightforward to work with counsel and propose to the ARIN Board for their consideration. The issue of indemnification is far more challenging, and hence my reason for asking about the underlying need for such and how folks are handling its presence in other RIR RPKI terms and conditions. Thanks! /John John Curran President and CEO ARIN
On Dec 4, 2014, at 2:19 PM, John Curran <jcurran@arin.net> wrote:
On Dec 4, 2014, at 1:19 PM, Jared Mauch <jared@puck.nether.net> wrote:
I (similar to Rob) have my own concerns about RPKI but do feel that this is an ARIN specific construct/wall that has been raised without action yet from ARIN.
Jared -
Please be specific - are you referring to the indemnification clauses (which are existing in other RIRs as well), the method of agreement, or not having ready access to the TAL, i.e. the click-accept access?
I have other technical and administrative concerns which I won’t go into great detail here about.
The fact that the meeting was 2 months ago and you have not acted/discussed with your counsel says everything I need to know about the situation, your personal motives and your personal desires for the outcomes. I hope it doesn’t represent your employer and that the ARIN Board brings it up with you.
Incorrect. Despite the lack of clarity, we started work on 27 October with both inside and external counsel regarding drafting some updates to the RPKI legal framework. This effort should be ready to be brought to the ARIN Board in January for their consideration, but it would be helpful to have more clarity on the concerns (i.e. is it access to the TAL, or the requirement for explicit agreement to terms and conditions, or the presence of indemnification/warrant-disclaimer language regardless of method of binding)
the fact it’s taken 3 months to reach the board is of concern to me for an issue that was raised (prior to the October meeting) by operators, and where you were an active part of the discussion afterwards in the back of the plenary room. While you asked Wes, I certainly felt I was clear in telling you Yes that letting the existing RSA where you claimed also covered this would protect ARIN. If you have not discussed this with counsel since then, that feels to me like something that should have already occurred. Perhaps you are waiting until January though, I don’t know your thought process but it seems that a few months is enough time for it to occur (IMHO).
At present, I am working on addressing the TAL access and the explicit agreement concerns that were raised during Wes's NANOG session. These are relatively straightforward to work with counsel and propose to the ARIN Board for their consideration. The issue of indemnification is far more challenging, and hence my reason for asking about the underlying need for such and how folks are handling its presence in other RIR RPKI terms and conditions.
The actions of ARIN here speak volumes to the contempt that we observe towards those desiring to do standards body work on RPKI. This concerns me in my role of obtaining ARIN resources. I also wonder what other ways that ARIN has displeasure in the members that it’s not publicly voicing or making apparent. I’m also willing to accept that I may be sleep deprived, grumpy and that everyone here has hit upon a nerve about the RPA which I see as unresolved. At the last IETF meeting I raised the issue that if this (RPKI) goes poorly in its deployment, here we would just be turning it off if there was some catastrophic protocol or operational issue. People depend upon the internet to work and anything to reduce the reliability of it won’t be widely used. I am hoping that ARIN will be a partner in these activities vs what feels like feet dragging along the way. RPKI/SIDR may not be successful in the long term, but until that outcome is reached, we need ARIN to be part of the community and your leadership here is welcome and necessary. - Jared
On Dec 4, 2014, at 11:33 AM, Jared Mauch <jared@puck.Nether.net> wrote:
the fact it’s taken 3 months to reach the board is of concern
Jared, ARIN is now nine years in to applying thrust to this pig. The board does in fact revisit it with some frequency, since it’s expensive and the primary thing blocking other software development efforts, like ARIN Online functionality and so forth. It has not been ignored for the past three months, and it has not been ignored for the past nine years. The question of what to do about it, however, is no more likely to be resolved right now than it has been at any point in its painful history. Please focus on what we can do about it, rather than on the timeframe. John is doing his job. -Bill
On Dec 4, 2014, at 2:41 PM, Bill Woodcock <woody@pch.net> wrote:
On Dec 4, 2014, at 11:33 AM, Jared Mauch <jared@puck.Nether.net> wrote:
the fact it’s taken 3 months to reach the board is of concern
Jared, ARIN is now nine years in to applying thrust to this pig. The board does in fact revisit it with some frequency, since it’s expensive and the primary thing blocking other software development efforts, like ARIN Online functionality and so forth. It has not been ignored for the past three months, and it has not been ignored for the past nine years. The question of what to do about it, however, is no more likely to be resolved right now than it has been at any point in its painful history.
Please focus on what we can do about it, rather than on the timeframe. John is doing his job.
Part of that is collecting the feedback, which it seemed was unheard as more than Wes was part of the discussion. If ARIN has given up on RPKI, it would be helpful if that message were communicated to the community. - Jared
On Dec 4, 2014, at 2:33 PM, Jared Mauch <jared@puck.nether.net> wrote:
the fact it’s taken 3 months to reach the board is of concern to me for an issue that was raised (prior to the October meeting) by operators, andwhere you were an active part of the discussion afterwards in the back of the plenary room.
Jared - We kicked off a project to address the concerns within two weeks of ARIN/NANOG, doing so despite not have any clear consensus that providing ready access to the TAL without a click-accept RPA and switching to an implicit service agreement would materially improve things. I guess we could have waited for consensus on indemnification (or no indemnification), but it's not clear whether any consensus will ever emerge on that issue.
While you asked Wes, I certainly felt I was clear in telling you Yes that letting the existing RSA where you claimed also covered this would protect ARIN. If you have not discussed this with counsel since then, that feels to me like something that should have already occurred. Perhaps you are waiting until January though, I don’t know your thought process but it seems that a few months is enough time for it to occur (IMHO).
Addressing these RPKI issues is important, but there is quite a bit of other activities going on at the same time. Furthermore, revisiting RPKI terms and conditions and the imputed risk definitely requires a face-to-face Board discussion, and January is the first one scheduled after the ARIM Baltimore meeting in October.
The actions of ARIN here speak volumes to the contempt that we observe towards those desiring to do standards body work on RPKI. This concerns me in my role of obtaining ARIN resources. I also wonder what other ways that ARIN has displeasure in the members that it’s not publicly voicing or making apparent.
Jared - Feel free to raise any concerns with the Board if you wish; many (like Bill Woodcock) are on the nanog list, but in any case they all have emails listed here - <https://www.arin.net/about_us/bot.html>
I’m also willing to accept that I may be sleep deprived, grumpy and that everyone here has hit upon a nerve about the RPA which I see as unresolved.
Agreed, and work is underway to address.
At the last IETF meeting I raised the issue that if this (RPKI) goes poorly in its deployment, here we would just be turning it off if there was some catastrophic protocol or operational issue. People depend upon the internet to work and anything to reduce the reliability of it won’t be widely used.
That's very true, but getting folks to invest time & effort in internal, non-customer facing capabilities is very hard (and doubly so for things still in flux like RPKI.) If it were easy, we'll already have a community all of whom used some form of route filtering, either registry or IRR derived, and payoff from adding RPKI would be nominal...
I am hoping that ARIN will be a partner in these activities vs what feels like feet dragging along the way. RPKI/SIDR may not be successful in the long term, but until that outcome is reached, we need ARIN to be part of the community and your leadership here is welcome and necessary.
ARIN is very much part of the RPKI community, including participating in the IETF sidr activities, deploying both hosted and delegated RPKI support, etc. We're actively involved, but also attentive to details, particular when it comes to risk analysis. /John John Curran President and CEO ARIN
On 12/4/14, 1:13 PM, "John Curran" <jcurran@arin.net> wrote:
I am happy to champion the change that you seek (i.e. will get it reviewed by legal and brought before the ARIN Board) but still need clarity on what change you wish to occur -
A) Implicit binding to the indemnification/warrant disclaimer clauses (as done by the other RIRs)
B) Removal of the indemnification & warranty disclaimer clause
I asked this directly during your NANOG presentation, but you did not respond either way.
WG] I deferred because I am not a lawyer and am not empowered to speak anything more than my opinion on the matter. I believe that the more useful response to your question came during the ARIN members' meeting post-NANOG, where Rob Seastrom suggested at the mic that rather than a bunch of engineers and policy wonks playing armchair lawyer and guessing at what will make the actual lawyers happy, that we should organize a separate meeting involving: - the ARIN board - ARIN legal counsel and other relevant ARIN staff - legal representatives from as many of the operators and others expressing concern over this as appropriate, - along with a few of the technical folks to help deal with the interaction between the technical and the legal and use it to discuss the issues in order to come up with something better.
(One can easily argue that best practices require multiple connections or service providers, but that is the same with best practices for RPKI use requiring proper preferences to issues with certification data...)
WG] So how would I as an ARIN member go about getting a redundant RPKI provider? I'm uncomfortable being single-homed to ARIN since that seems contrary to best practices. Also: Most SPs provide an SLA to their customers that serves as a balance to contractual liability weasel words. Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On 4 Dec 2014, at 18:53, John Curran <jcurran@arin.net> wrote:
On Dec 4, 2014, at 12:32 PM, George, Wes <wesley.george@twcable.com> wrote:
Those are operational matters, implemented by the staff, governed by the board, who is informed by their legal council and staff. That is part of the reason why I brought some of the issues to the NANOG community, since interaction with ARIN board members and staff is what's necessary to make sure the concerns are addressed, and thus it benefits from wider discussion.
Wes -
I am happy to champion the change that you seek (i.e. will get it reviewed by legal and brought before the ARIN Board) but still need clarity on what change you wish to occur -
A) Implicit binding to the indemnification/warrant disclaimer clauses (as done by the other RIRs)
Some details on this: The RIPE NCC offers an RPKI Validator toolset which includes the Trust Anchors for all the RIR repositories except the one for ARIN. On the download page, there is this statement: "By setting up the RIPE NCC RPKI Validator, you confirm that you have read, understood and agree to the <RIPE NCC Certification Repository Terms and Conditions>." Download page: https://www.ripe.net/certification/tools-and-resources T&C: http://www.ripe.net/lir-services/resource-management/certification/legal/rip... There are instructions to get the ARIN TAL in the readme and UI of the RPKI Validator: - http://localcert.ripe.net:8088 - https://github.com/RIPE-NCC/rpki-validator/blob/master/rpki-validator-app/RE... Cheers, Alex
participants (18)
-
Alex Band -
Andrew Gallo -
Bill Woodcock -
Ca By -
Carlos M. Martinez -
Christopher Morrow -
George, Wes -
Jared Mauch -
Jay Ashworth -
John Curran -
Matthias Waehlisch -
Nick Hilliard -
Randy Bush -
Rob Seastrom -
Robert Seastrom
-
Sandra Murphy -
Valdis.Kletnieks＠vt.edu -
William Herrin