[arin-ppml] Revisit RPKI TAL Relying Party Agreement?

[LOOS Eric (BCS/CBU)]

IANAL, but I have worked enough with our legal department to see some red flags in the RPA:

-          Possibility for on-sided modifications of the T&C with automatic acceptance thereof

-          Complete indemnification of ARIN et al.

So I definitely sympathize with the point that the RPA as worded there is probably unacceptable for many carriers (us included)
I also agree that it is a moot point whether this is a click through before a download is possible or fine print of the website which is presumable accepted once the service is accessed; it is in fact indeed commendable that ARIN does not try to let companies agree to such far reaching legal language without at least raising the flag. Therefore the points made by Wes during his nanog talk regarding the modification of the RPA are pertinent here.

I wonder why the trustees have chosen to take such a defensive approach on information contained in the RKPI, after all we have had RBL lists in the past for blocking mail, we pretty much all uses RIR routing registries for building our filters, many people rely on PeeringDB for keeping their peering records up to date and I have not encountered such defensive position before.

Especially RPKI requires a wide acceptance to be able to do anything useful.
What would be the process for the trustees to review this matter and share their insights on this matter?

Eric Loos
Senior Product Manager - Capacity & IP
Tel. +32 2 547 51 21 • Mob. +32 475 40 94 44
eric.loos at bics.com<mailto:eric.loos at bics.com>

BICS SA/NV
Rue Lebeau 4, 1000 Brussels, Belgium
www.bics.com<http://www.bics.com/>



From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
Sent: Wednesday 1 February 2017 15:54
To: Job Snijders <job at ntt.net>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?

On 1 Feb 2017, at 4:01 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:
I am certain that an appropriate (and equally short) wget command
could suffice technically for installing ARIN’s TAL, but including
such in a script (or including the TAL directly in the source code
repository) would deprive parties of the ability to fully consider and
accept the responsibilities involved.

Correct. Thank you for this summary. Your summary narrows it down to
exactly the point of friction.

Questions that come to mind: are the responsibilities as outlined by the
RPA proportional to the goals the RPA is intended to achieve? Should any
responsibilities be associated with the distribution of cryptographic
public keys? To me DNSSEC seems an apt comparison.

Job -

The typical relying parties “usage” of certificates in DNSSEC is heavily proscribed by
both protocol and implementation, and occurs with only nominal configuration choices on
behalf of the relying party.  Both the maturity of DNSSEC and deployment model greatly
minimize the potential for misconfiguration on behalf of a relying party, with the result being
that misconfiguration by zone administrators is a much more common occurrence and one
whose impact is limited to but their own domain (reference RFC 7646 for more detail on
same and thus the desire for locally administered negative trust anchors to address
such circumstances...)  Even when a DNSSEC validation error occurs, there remains the
potential for self-help on behalf of end users (via the option to switch to a non-validating
resolver.)

Contrast this to RPKI, wherein the introduction of origin validation into an ISP’s routing
architecture has many operational considerations, and inherently includes the potential to
readily impact the ISP's primary business under anything less than carefully planned and
executed BGP origin validation deployment efforts.   While I’m am certain that everyone
deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable
workarounds by the impacted customers) inherently means the potential for business impact
is greater than exists with deployment of DNSEC validation by ISPs – i.e. while I do believe
that your comparison to DNSSEC is directionally correct, it fails overall due to the very real
and significant difference in the magnitude of potential business impact to the relying party.

/John

John Curran
President and CEO
ARIN






________________________________

**** DISCLAIMER****
http://www.bics.com/maildisclaimer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170203/366b37af/attachment.htm>