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.
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.
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?
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.
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.
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)?
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?"
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.
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.
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.
...
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.
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.
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?
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.
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...)