RE: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-15 Thread Michel Py
Hi John,

> John Curran wrote :
> Even so, we at ARIN are in the midst of a Board-directed review of the RPKI 
> legal framework to see if any improvements can be made
> 
>   – I will provide further updates once it is completed.

Thanks, we appreciate the effort.

That being said, something has to be done. I feel that the RPKI validation by 
ARIN is somehow useless. Why : because few download the TAL (at least in part 
because of the indemnisation clause).
Therefore, many networks that do RPKI validation do validate prefixes from the 
other 4 RIRs but not mine.
In simple words : why bother validating, if all of most of the networks that 
could block invalid prefixes don't, because the TAL agreement is not palatable.

I understand that ARIN has to deal with a legal system that makes things 
difficult, but OTOH I would like ARIN's RPKI validation to provide the same 
protection than the other RIRs, which it currently does not.

I created my ROAs, but I am not protected as well as an Org belonging to 
another RIR.

Michel


TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread Ronald F. Guilmette
In message , 
John Curran  wrote:

>Alas, it’s not those who fail to properly configure RPKI that are likely to be
>litigating, but rather their impacted customers and those customers' business
>partners who all were unable to communicate due to no fault of their own. 
>
>Such a matter will not be thrown out of court, but will be the start of a long
>and very expensive process involving claims, discovery, experts, etc...

Perhaps.  There are certainly some big players (AWS) that if routing were
interrupted for even, say, 12 hours, a lot of folks would get really mad
about.

Correct me if I'm wrong, but one of your presentation slides seemed to
suggest that a separate arms-length legal entity could be established
to do the RPKI stuff, thus offloading most or all of the potential
liability onto and into this separate entity, which could conveniently
have minimal assets of the kind that might inspire members of the
plaintiff's bar who are looking for deep pockets.

Is that an actual possibility, or did you just throw that in there for the
sake of completness?

Personally, I don't much care how the problem gets solved, as long as it
gets solved.  The fundamental BGP problem has been known and discussed
now for 20+ years and it is only getting more dire and ominous, day by day.


Regards,
rfg


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread Anne P. Mitchell, Esq.


> There's obviously a disconnect where people aren't worried about indemnifying
> Spamhaus for using their block list, but are worried about indemnifying ARIN 
> for
> using the TAL.

That would be because there is a rather substantial difference between 
publishing an IP address for which you have spam in hand, and are saying (and 
only saying) "I received spam from this IP address" (not to mention something 
which people use to only affect inbound email), and hosting something on which 
others rely for making their acceptance decision of all legitimate Internet 
traffic, as well as for the ability to not move malicious (or even accidentally 
misconfigured) Internet traffic.

Anne

Anne P. Mitchell, Attorney at Law
Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose
CEO/President, Institute for Social Internet Public Policy
SuretyMail Email Reputation Certification
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Board of Directors, Denver Internet Exchange
Board of Directors, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
Former Counsel: Mail Abuse Prevention System (MAPS)
Member: California Bar Association



Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread Valdis Klētnieks
On Wed, 14 Aug 2019 16:07:49 -, John Curran said:

> > But I suspect a lot of companies are reading it as: "If a spammer sues you 
> > for using
> > a block list that prevents them from spamming your customers, you can't end 
> > up
> > owing money to the block list maintainers.  But if you rely on the ARIN 
> > TAL, and get
> > sued by an address hijacker, you could end up owing money to ARIN".

> It's is not "you owe money to ARIN", but it could be "you need to defend both
> yourself and ARIN from your customers litigation should you get it wrong."

Is there any workable way to remove or diminish the perception of liability in
the case of using it *correctly*?   I admit that (a) I'm not a lawyer and (b)
when I actually tried to read it I couldn't actually tell if it was "you
promise to defend us if you screw it up and customer traffic gets accidentally
dropped on the floor" or "you promise to defend us if you use it correctly and
miscreant traffic is intentionally dropped on the floor"...

There's obviously a disconnect where people aren't worried about indemnifying
Spamhaus for using their block list, but are worried about indemnifying ARIN for
using the TAL.



pgpPfQJhUFewN.pgp
Description: PGP signature


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread Rubens Kuhl
On Wed, Aug 14, 2019 at 1:09 PM John Curran  wrote:

> On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks 
> wrote:
> >
> > On Wed, 14 Aug 2019 02:42:09 -, John Curran said:
> >
> >> You might want want to ask them why they are now a problem when they
> weren’t
> >> before (Also worth noting that many of these ISP's own contracts with
> their
> >> customers have rather similar indemnification clauses.)
> >
> > Actually, it's probably ARIN that should be doing the asking, and seeing
> if
> > they can change the wording and/or rephrase the issue to allay concerns.
> >
> > It sounds to me like ARIN's *intent* was "if you get sued by your
> customers because
> > you screw the pooch on deployment, it's your screw-up to clean up and
> not our
> > problem". Or at least I *hope* that was the intent (see next paragraph)
>
> That is indeed the intent - please deploy routing validation using best
> practices, so that you & your customers don’t suffer any adverse impact
> when ARIN's repository is not available.
>
>
Or, move all your number resources to a subsidiary in the AP region, pay
membership fees to APNIC instead of ARIN, and use their trust anchor
instead of ARIN's.
BTW, since all 5 RIRs have certificates signing the whole IP address space,
it really makes no difference.


Rubens


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread John Curran
On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks  wrote:
> 
> On Wed, 14 Aug 2019 02:42:09 -, John Curran said:
> 
>> You might want want to ask them why they are now a problem when they weren’t
>> before (Also worth noting that many of these ISP's own contracts with their
>> customers have rather similar indemnification clauses.)
> 
> Actually, it's probably ARIN that should be doing the asking, and seeing if
> they can change the wording and/or rephrase the issue to allay concerns.
> 
> It sounds to me like ARIN's *intent* was "if you get sued by your customers 
> because
> you screw the pooch on deployment, it's your screw-up to clean up and not our
> problem". Or at least I *hope* that was the intent (see next paragraph)

That is indeed the intent - please deploy routing validation using best 
practices, so that you & your customers don’t suffer any adverse impact when 
ARIN's repository is not available.

> But I suspect a lot of companies are reading it as: "If a spammer sues you 
> for using
> a block list that prevents them from spamming your customers, you can't end up
> owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
> and get
> sued by an address hijacker, you could end up owing money to ARIN”.

It’s is not “you owe money to ARIN’, but it could be “you need to defend both 
yourself and ARIN from your customers’ litigation should you get it wrong."

> (Having said that, John, it takes a special sort of CEO to stand out and be 
> seen
> in situations like this, and the world could probably use more CEO's like 
> that…)

 fairly easy to do if one has a thick skin… ;-)

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers




signature.asc
Description: Message signed with OpenPGP


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread Valdis Klētnieks
On Wed, 14 Aug 2019 02:42:09 -, John Curran said:

> You might want want to ask them why they are now a problem when they weren’t
> before (Also worth noting that many of these ISP's own contracts with their
> customers have rather similar indemnification clauses.)

Actually, it's probably ARIN that should be doing the asking, and seeing if
they can change the wording and/or rephrase the issue to allay concerns.

It sounds to me like ARIN's *intent* was "if you get sued by your customers 
because
you screw the pooch on deployment, it's your screw-up to clean up and not our
problem". Or at least I *hope* that was the intent (see next paragraph)

But I suspect a lot of companies are reading it as: "If a spammer sues you for 
using
a block list that prevents them from spamming your customers, you can't end up
owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
and get
sued by an address hijacker, you could end up owing money to ARIN".

(Having said that, John, it takes a special sort of CEO to stand out and be seen
in situations like this, and the world could probably use more CEO's like 
that...)





pgpqCVyRjaf5u.pgp
Description: PGP signature


Re: RPKI adoption

2019-08-14 Thread Job Snijders
Dear all,

On Wed, Aug 14, 2019 at 10:36:44AM +, John Curran wrote:
> On 14 Aug 2019, at 2:26 AM, Matthew Petach  wrote:
> > ...
> > Now, at the risk of bringing down the ire of the community on my
> > head...ARIN could consider tying the elements together, at least for
> > ARIN members.  Add the RPKI terms into the RSA document.  You need
> > IP number resources, congratulations, once you sign the RSA, you're
> > covered for RPKI purposes as well.
> 
> Matthew - 
> 
>   Yes indeed - this is one of several potential improvements that we’re 
> also investigating. 

I've attempted to produce a humorous world map chart to help clarify
there is a degree of asymmetry our community may need to consider:


http://instituut.net/~job/screenshots/e079d90a-3047-4034-8e7c-9caf6e387f1a.png

The ARIN members (mostly located in the red area) would like all
not-ARIN-members (located in the blue area, the rest of the world) to
use and honor their ROAs published through ARIN's RPKI service.

If not for the purpose of facilitating BGP Origin Validation on as many
as possible of Internet's routers to protect one's IP resources, why
else would anyone publish RPKI ROAs through their RIR?

In other words: ARIN members want something (something very reasonable!)
from "the rest of the world", but in order to accomplish that
'something', unfortunately "the rest" needs to agree to the ARIN RPA.
This has proven to be somewhat of an adoption barrier.

It would be fantastic when "the rest" are not required to do any such
thing and the ARIN RPKI TAL can be distributed without restrictions or
limitations.

I would love to see any solution that removes all potential friction for
"the rest of the world", even if that shifts some additional burden to
ARIN members themselves; because it's ARIN members that want something
from the world, less so the other way around.

On Wed, Aug 14, 2019 at 4:42 AM John Curran  wrote:
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but
> apparently they were not an issue at all when requesting IP address
> space or receiving a transfer.

Your observation (if correct) indeed is very interesting, and perhaps
demonstrates that RPKI business is something between ARIN and ARIN's
members, and less so between ARIN and all other potential relaying
parties on this planet. Or phrased differently: perhaps only ARIN
members should be the ones incurring the cost and burden of reviewing
and accepting ARIN's agreements.

I'd like to express my appreciation to ARIN's staff & ARIN's Board of
Trustees for dedicating their time and resources to research how to
improve in this context.

Kind regards,

Job

ps. Ofcourse this map is an oversimplification of the situation,
apologies for any inaccuracies.


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread John Curran
On 14 Aug 2019, at 1:21 AM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:

In message 
<06570278-e1ad-4bb0-a9fc-11a77bed7...@arin.net>,
John Curran mailto:jcur...@arin.net>> wrote:

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
legal framework to see if any improvements can be made   – I will
provide further updates once it is completed.

This is an excellent presentation John, and I'm real glad to see that you
have done such a nice job on it and touched on all of the important points.

In particular, I'm glad that you clarified that if everyone is just doing
what they ought to be doing, i.e. following best practices, then even if
RPKI central and all of its sister satellites should all be simultaneously
hit by metorites, then in theory at least, nobody should be any worse off
than they already are today.

And yes, I can't argue and won't argue that some folks aren't going to be
bozos and screw up their RPKI deployment, and then some of them -may-
possibly want to blame ARIN for -their- screw ups, but I continue to have
trouble envisioning how this would ever traslate into a lawsuit that
wouldn't simply be laughed out of court in about five seconds if handled
properly.

Alas, it’s not those who fail to properly configure RPKI that are likely to be 
litigating, but rather their impacted customers and those customers' business 
partners who all were unable to communicate due to no fault of their own.

Such a matter will not be thrown out of court, but will be the start of a long 
and very expensive process involving claims, discovery, experts, etc.  (a 
recent legal matter that was promptly resolved in ARIN’s favor pre-litigation 
still resulted in more than 1/3 million USD in costs...)   Absent a specific 
reason for dismissal, it is only in actual trial that the preponderance of 
evidence gets considered – and note that in such a dispute, we’d end up with a 
jury of regular folks hearing fairly technical arguments about certificate 
validation, covering ROA’s, caching, etc.In other words, even if handled 
perfectly, your five second estimate is likely off by a year or more (and hence 
the reason for indemnification - it provides a clear basis for ARIN’s exit from 
the matter, as it makes plain that the liability resulting from use of the RPKI 
repository lies with the ISP.)

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers





Re: RPKI adoption

2019-08-14 Thread John Curran
On 14 Aug 2019, at 12:51 AM, Hank Nussbacher  wrote:
> …
> Just like to add kudos to John for being open and responsive on this list and 
> other lists to numerous issues and questions in regards to ARIN.  Not many 
> CEOs are willing or able to respond as you do.  

Hank - 

Thanks! – as I work for you (i.e. this collective community), I see it 
as a reasonable obligation to be reachable/answerable regarding how your 
registry is being run.

/John

John Curran
President and CEO
American Registry for Internet Numbers

p.s.  As a reminder, those interested in more prominent/direct role in 
oversight of ARIN should consider running for the Board of Trustees…  






Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread John Curran
On 14 Aug 2019, at 2:26 AM, Matthew Petach  wrote:
> ...
> Now, at the risk of bringing down the ire 
> of the community on my head...ARIN could
> consider tying the elements together, at 
> least for ARIN members.  Add the RPKI terms 
> into the RSA document.  You need IP number
> resources, congratulations, once you sign the
> RSA, you're covered for RPKI purposes as well.

Matthew - 

Yes indeed - this is one of several potential improvements that we’re 
also investigating. 

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers



Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread John Curran
On 14 Aug 2019, at 1:01 AM, William Herrin  wrote: 
> ...
> >  I would observe that continued use at that point has been held
> > to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 
> > 356 F.3d 393 (2d Cir. 2004)]
> 
> In which Verio admitted to the court that they knew they were abusing 
> Register's computers but figured Register's contract with ICANN gave them the 
> right. The court would have reached the same decision regardless of 
> Register's notice: You're abusing computers that aren't yours. Stop it.

BIll - 

The particular finding from Register v. Verio that is relevant was that a user 
made aware of applicable terms with each query (even at the end) is sufficient 
for contractual binding after continued use.  

> Specht v. Netscape Communications Corp, on the other hand, found that, 
> "plaintiffs neither received reasonable notice of the existence of the 
> license terms nor manifested unambiguous assent" to the contract Netscape 
> offered for the use of their software at download-time, including assent to 
> settle disputes through arbitration.

Register v. Verio was after Specht v Netscape, and distinguished the situation 
where the user received terms at the end of each response from those cases 
where a user couldn’t reasonably determine that there were any applicable terms 
and conditions. 

> I'll take any bet you care to offer that the latter precedent applies to 
> casual consumer use of ARIN's whois.

That bet is available to you at any time by violating the terms the ARIN’s 
Whois service, so the question to ask yourself is: "do you feel lucky?”

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers




Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-14 Thread Matthew Petach
On Tue, Aug 13, 2019 at 5:44 PM John Curran  wrote:

> On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
> wrote:
>
> ...
> The last time I looked, RPKI adoption was sitting at around a grand total
> of 15% worldwide.  Ah yes, here it is...
>
>   https://rpki-monitor.antd.nist.gov/
>
> I've asked many people and many companies why adoption remains so low, and
> why their own companies aren't doing RPKI.  I've gotten the usual
> assortment
> of utterly lame excuses, but the one that I have had the hardest time
> trying to counter is the one where a network engineer says to me "Well,
> ya know, we were GOING to do that, but then ARIN... unlike the other four
> regional authorities... demanded that we sign some silly thing indemnifying
> them in case of something.
>
>
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but apparently
> they were not an issue at all when requesting IP address space or receiving
> a transfer.
> You might want want to ask them why they are now a problem when they
> weren’t before (Also worth noting that many of these ISP's own contracts
> with their customers have rather similar indemnification clauses.)
>

Hi John,

There are things companies will sign
when their backs are up against the wall
that they will balk at signing when it is
for an optional geek-ish extra.

IP addresses are the lifeblood of the
tech industry.  If you don't have an
IP address, you don't exist on the
Internet.  (Apologies to those of us
who still have modems configured
to call and retrieve mail addressed
with UUCP bang paths).

So, companies will grudgingly and with
much hand-wringing sign the RSA
necessary to get IP space.  Without,
they die.  Rather like oxygen; if we
had to sign a license agreement in
order to receive air to breathe, you'd
find most people would sign pretty
horrific terms of service agreements.

Slip those same terms in front of someone
as a requirement for them to buy beer,
and you'll likely discover a whole lot of
people are just fine drinking something
else instead.

So too with the RSA terms versus the
RPKI terms.

As companies, we can't survive without
IP addresses.  We'll sign just about anything
to stay alive.

RPKI is a geek toy.  It's not at all required
for a business to stay alive on the Internet,
so companies feel much safer in saying
"no way will we sign that!".

Now, at the risk of bringing down the ire
of the community on my head...ARIN could
consider tying the elements together, at
least for ARIN members.  Add the RPKI terms
into the RSA document.  You need IP number
resources, congratulations, once you sign the
RSA, you're covered for RPKI purposes as well.

That doesn't solve the issue for out-of-region
folks who don't have an RSA with ARIN; but
that's no worse than you are today; and by
bundling the RPKI terms in with the rest of the
RSA, you at  least get everyone in the ARIN
region that wants^Wneeds to maintain their
IP number resources in order to stay in business
on the Internet covered in terms of being able to
use the RPKI data.

If you've got them by the short and curlies
already, might as well bundle everything in
while they've got the pen in their hand.  ^_^;

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
> legal framework to see if any improvements can be made <
> https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>
>  – I will provide further updates once it is completed.
>

Best of luck!  I know we'll all be watching carefully to
see how it goes.:)

Matt


> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-13 Thread Ronald F. Guilmette
In message <06570278-e1ad-4bb0-a9fc-11a77bed7...@arin.net>, 
John Curran  wrote:

>Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
>legal framework to see if any improvements can be made vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>  – I will
>provide further updates once it is completed. 

This is an excellent presentation John, and I'm real glad to see that you
have done such a nice job on it and touched on all of the important points.

In particular, I'm glad that you clarified that if everyone is just doing
what they ought to be doing, i.e. following best practices, then even if
RPKI central and all of its sister satellites should all be simultaneously
hit by metorites, then in theory at least, nobody should be any worse off
than they already are today.

And yes, I can't argue and won't argue that some folks aren't going to be
bozos and screw up their RPKI deployment, and then some of them -may-
possibly want to blame ARIN for -their- screw ups, but I continue to have
trouble envisioning how this would ever traslate into a lawsuit that
wouldn't simply be laughed out of court in about five seconds if handled
properly.

Some arguably proximate historical analogs might be relevant here.

In the past, there have occasionally been problems when one or more of
the root name servers have been DDoSd or have otherwise had issues.
I don't recall anybody lining up to sue ICANN in those instances.

Spamhaus and other public anti-spam services publish their stuff to all
comers, without demanding indemnification.  Yes, they have been sued
from time to time, but none of that has ever resulted in any meaningful
damages, and if the company itself had just been more consistant in
obtaining sound legal advice, none of those events would even have been
all that bothersome.

So, what makes ARIN so special that it can't do what these others are doing
and just simply publish some information?  ARIN is in the State of Virginia
the last time I checked, and I do believe that the First Amendment still
applies in the State of Virginia, and indeed in all 50 states.  I mean it
isn't as if ARIN is going to go around yelling "Fire!" in a crowded theater
for God's sake!

So, you just slap a label on the whole bloody RPKI thing that says "Use at
your own risk" and that ought to do it, I think.  I understand that Steve
Ryan may not see it that way, but it's his job not to see it that way.
In practice, there is no need for -both- belt -and- suspenders.


Regards,
rfg


P.S.  Proactive failure testing (slide #15) is an excellent idea.  You could
and probably should fail the whole thing deliberately for 24 hours once a
year, just as a way of shaking the trees to see what idiots fall out.  It
would be like DNS Flag Day, on steroids.



Re: RPKI adoption

2019-08-13 Thread William Herrin
On Tue, Aug 13, 2019 at 9:51 PM Hank Nussbacher 
wrote:

> Just like to add kudos to John for being open and responsive on this list
> and other lists to numerous issues and questions in regards to ARIN.  Not
> many CEOs are willing or able to respond as you do.
>
> Thanks for your time and effort,
>

I'll second that despite my criticism.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-13 Thread William Herrin
On Tue, Aug 13, 2019 at 8:25 PM John Curran  wrote:
> On 13 Aug 2019, at 11:03 PM, William Herrin  wrote:
> I signed no legal agreement either to register my legacy addresses or to
do a whois lookup to check someone else's addresses. Just sayin’.
>
> If you instead used a command line interface (e.g. "whois -h
whois.arin.net …”),
> then you received output from ARIN’s Whois server along with notice of
the applicable terms of service…

Hi John,

As I no longer live within or act from within one of the 2 states to have
passed UCITA, you'll find that notice difficult to enforce.


>  I would observe that continued use at that point has been held
> to indicate agreement on your part [ref: Register.com, Inc. v. Verio,
Inc., 356 F.3d 393 (2d Cir. 2004)]

In which Verio admitted to the court that they knew they were abusing
Register's computers but figured Register's contract with ICANN gave them
the right. The court would have reached the same decision regardless of
Register's notice: You're abusing computers that aren't yours. Stop it.

Specht v. Netscape Communications Corp, on the other hand, found that,
"plaintiffs neither received reasonable notice of the existence of the
license terms nor manifested unambiguous assent" to the contract Netscape
offered for the use of their software at download-time, including assent to
settle disputes through arbitration.

I'll take any bet you care to offer that the latter precedent applies to
casual consumer use of ARIN's whois. I won't take any such bet when it
comes to the legal safety of redistributing ARIN's RPKI Trust Anchor
Locator in my software. And neither, apparently, do many of the folks who
would have to redistribute that TAL for ARIN's RPKI to be useful, as was
discussed here last September:
https://mailman.nanog.org/pipermail/nanog/2018-September/097161.html

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: RPKI adoption

2019-08-13 Thread Hank Nussbacher

On 14/08/2019 06:24, John Curran wrote:


When you did that Whois look up at the ARIN website, you did agree to 
terms of use for the Whois service which contains indemnification 
provisions and are legally enforceable. 



If you instead used a command line interface (e.g. "whois -h 
whois.arin.net  …”), then you received output 
from ARIN’s Whois server along with notice of the applicable terms of 
service…  I would observe that continued use at that point has been 
held to indicate agreement on your part [ref: Register.com 
, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)]


Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Just like to add kudos to John for being open and responsive on this 
list and other lists to numerous issues and questions in regards to 
ARIN.  Not many CEOs are willing or able to respond as you do.


Thanks for your time and effort,

-Hank



Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-13 Thread John Curran
On 13 Aug 2019, at 11:03 PM, William Herrin 
mailto:b...@herrin.us>> wrote:

On Tue, Aug 13, 2019 at 7:42 PM John Curran 
mailto:jcur...@arin.net>> wrote:
On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:
The last time I looked, RPKI adoption was sitting at around a grand total
of 15% worldwide.  Ah yes, here it is...

  https://rpki-monitor.antd.nist.gov/

I've asked many people and many companies why adoption remains so low, and
why their own companies aren't doing RPKI.  I've gotten the usual assortment
of utterly lame excuses, but the one that I have had the hardest time
trying to counter is the one where a network engineer says to me "Well,
ya know, we were GOING to do that, but then ARIN... unlike the other four
regional authorities... demanded that we sign some silly thing indemnifying
them in case of something.

Interestingly enough, those same indemnification clauses are in the 
registration services agreement that they already signed but apparently they 
were not an issue at all when requesting IP address space or receiving a 
transfer.

I signed no legal agreement either to register my legacy addresses or to do a 
whois lookup to check someone else's addresses. Just sayin’.

Bill -

When you did that Whois look up at the ARIN website, you did agree to terms of 
use for the Whois service which contains indemnification provisions and are 
legally enforceable. <https://www.arin.net/resources/registry/whois/tou/>

If you instead used a command line interface (e.g. "whois -h 
whois.arin.net<http://whois.arin.net> …”), then you received output from ARIN’s 
Whois server along with notice of the applicable terms of service…  I would 
observe that continued use at that point has been held to indicate agreement on 
your part [ref: Register.com<http://Register.com>, Inc. v. Verio, Inc., 356 
F.3d 393 (2d Cir. 2004)]

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers





Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-13 Thread William Herrin
On Tue, Aug 13, 2019 at 7:42 PM John Curran  wrote:

> On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
> wrote:
>
> The last time I looked, RPKI adoption was sitting at around a grand total
> of 15% worldwide.  Ah yes, here it is...
>
>   https://rpki-monitor.antd.nist.gov/
>
> I've asked many people and many companies why adoption remains so low, and
> why their own companies aren't doing RPKI.  I've gotten the usual
> assortment
> of utterly lame excuses, but the one that I have had the hardest time
> trying to counter is the one where a network engineer says to me "Well,
> ya know, we were GOING to do that, but then ARIN... unlike the other four
> regional authorities... demanded that we sign some silly thing indemnifying
> them in case of something.
>
>
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but apparently
> they were not an issue at all when requesting IP address space or receiving
> a transfer.
>

I signed no legal agreement either to register my legacy addresses or to do
a whois lookup to check someone else's addresses. Just sayin'.

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

2019-08-13 Thread John Curran
On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:
...
The last time I looked, RPKI adoption was sitting at around a grand total
of 15% worldwide.  Ah yes, here it is...

  https://rpki-monitor.antd.nist.gov/

I've asked many people and many companies why adoption remains so low, and
why their own companies aren't doing RPKI.  I've gotten the usual assortment
of utterly lame excuses, but the one that I have had the hardest time
trying to counter is the one where a network engineer says to me "Well,
ya know, we were GOING to do that, but then ARIN... unlike the other four
regional authorities... demanded that we sign some silly thing indemnifying
them in case of something.

Interestingly enough, those same indemnification clauses are in the 
registration services agreement that they already signed but apparently they 
were not an issue at all when requesting IP address space or receiving a 
transfer.
You might want want to ask them why they are now a problem when they weren’t 
before (Also worth noting that many of these ISP's own contracts with their 
customers have rather similar indemnification clauses.)

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI 
legal framework to see if any improvements can be made 
<https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>
  – I will provide further updates once it is completed.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers



Re: Report on Legal Barriers to RPKI Adoption

2019-01-09 Thread Ben Maddison via NANOG
Hi all,

Thanks Christopher and co-authors for this document. The issues that you have 
highlighted are critical to ensuring that SOV and other future applications of 
the RPKI can be deployed in production without becoming serious latent risk to 
the Internet community and RIR system.

As a case in point with respect to your recommendations regarding the RPA, we, 
AS37271, have announced that we will implement strict SOV (i.e. dropping 
Invalids) as of 1 April 2019.

As things stand today, we will not be making use of the ARIN TAL.

We have arrived at this decision primarily because we are not willing to be 
bound by the indemnification clause (paragraph 7) of the RPA. In our 
assessment, the potential (and unbounded) liability that we could be exposed to 
under that clause presents a substantial business risk, and that it is 
inappropriate given the nature of the service and the role of an RIR in 
providing authoritative data on the allocation of number resources.

I believe problems also exist in other sections of the RPA, and my strong 
preference would be for ARIN to dispense with it altogether. However, if 
paragraph 7 were to be removed, we would likely be inclined towards accepting 
it.

Since the RPA imposes substantial obligations and risks on the relying party, I 
also believe that putting convenience methods (such as click-through acceptance 
during install of RP software packages) in place will simply encourage users to 
agree to accept those risks without fully understanding them, thus storing up 
unintended legal risks for Internet operators in the future.
I therefore welcome Job and Nathalie's assertions that there is little interest 
in the community of RP software developers to implement these "features".

This mail is already plenty long enough, but I am happy to discuss in more 
detail, either on- or off-list, if others are interested.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd


From: NANOG  on behalf of Nathalie Trenaman 

Sent: 08 January 2019 12:40:33
To: Job Snijders
Cc: David Wishnick; Christopher S. Yoo; nanog@nanog.org
Subject: Re: Report on Legal Barriers to RPKI Adoption

Dear all,

After reading the report, I agree with Job it was well written and a must-read 
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point 
2:

2.   Developers of RPKI validation software should consider integrating 
acceptance of ARIN's RPA into their software workflows. ARIN recently enabled 
this possibility, and developers should deliberate on whether to capitalize on 
the opportunity.


To put it bluntly: item 2 is not going to happen.

We've discussed this extensively in the OpenBSD community (who are working on a 
new RPKI Validation implementation [source: rpki-client]), and concluded that 
collecting explicit consent to the RPA on behalf of ARIN is undesirable and 
without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data 
- and we're not going to make an exception for ARIN and encumber each and every 
OpenBSD or rpki-client(1) installation.

I checked the temperature in the room of the other relevant RPKI Validation 
implementations, and it appears that *nobody* is planning to integrate 
acceptance of ARIN's RPA into their installation process.


I concur that for the RIPE NCC Validator this is something we don't want to 
implement.
Having said that, we do hear from our users that the current setup, where we 
point users to the ARIN TAL, is not optimal to say the least. Users simply 
don't understand why the other TALs automatically are installed and the ARIN 
TAL isn't, so we follow the discussions in the ARIN region closely.

Best regards,

Nathalie Trenaman
RIPE NCC





Op 6 jan. 2019, om 17:02 heeft Job Snijders mailto:j...@ntt.net>> 
het volgende geschreven:

Dear Christopher, David, NANOG community,

Thank you for your research and report. I found the report quite readable (not 
having a legal background) and well structured. Definitely edifying and worth 
the read! In this mail I'll reply specifically to a few points from the 
executive summary (and snip the rest).

For those of you who don't want to create a SSRN account here is a copy of the 
report:
http://instituut.net/~job/SSRN-id3309813.pdf


On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo 
mailto:cs...@law.upenn.edu>> wrote:
Here is a summary of our recommendations:
On the ROV side of the equation, the principal legal hindrances have to do with 
the terms and conditions governing access to the RPKI repository offered by 
ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed 
to ensure the agreement is binding. Regarding ROV:
1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
current approach to repository distribution, embodied in the RPA. W

Re: Report on Legal Barriers to RPKI Adoption

2019-01-08 Thread Nathalie Trenaman
Dear all,

After reading the report, I agree with Job it was well written and a must-read 
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point 
2:

> 2.   Developers of RPKI validation software should consider integrating 
> acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled 
> this possibility, and developers should deliberate on whether to capitalize 
> on the opportunity.
> 
> 
> 
> To put it bluntly: item 2 is not going to happen.
> 
> We’ve discussed this extensively in the OpenBSD community (who are working on 
> a new RPKI Validation implementation [source: rpki-client]), and concluded 
> that collecting explicit consent to the RPA on behalf of ARIN is undesirable 
> and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or 
> IRR data - and we’re not going to make an exception for ARIN and encumber 
> each and every OpenBSD or rpki-client(1) installation.
> 
> I checked the temperature in the room of the other relevant RPKI Validation 
> implementations, and it appears that *nobody* is planning to integrate 
> acceptance of ARIN’s RPA into their installation process.


I concur that for the RIPE NCC Validator this is something we don’t want to 
implement. 
Having said that, we do hear from our users that the current setup, where we 
point users to the ARIN TAL, is not optimal to say the least. Users simply 
don’t understand why the other TALs automatically are installed and the ARIN 
TAL isn’t, so we follow the discussions in the ARIN region closely.

Best regards,

Nathalie Trenaman
RIPE NCC





> Op 6 jan. 2019, om 17:02 heeft Job Snijders  het volgende 
> geschreven:
> 
> Dear Christopher, David, NANOG community,
> 
> Thank you for your research and report. I found the report quite readable 
> (not having a legal background) and well structured. Definitely edifying and 
> worth the read! In this mail I’ll reply specifically to a few points from the 
> executive summary (and snip the rest). 
> 
> For those of you who don’t want to create a SSRN account here is a copy of 
> the report: 
> http://instituut.net/~job/SSRN-id3309813.pdf 
> 
> 
> 
> On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo  > wrote:
> Here is a summary of our recommendations:
> 
> On the ROV side of the equation, the principal legal hindrances have to do 
> with the terms and conditions governing access to the RPKI repository offered 
> by ARIN in its Relying Party Agreement (“RPA”), and in the manner it has 
> employed to  ensure the agreement is binding. Regarding ROV:
> 
> 1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
> current approach to repository distribution, embodied in the RPA. We conclude 
> that two paths would be reasonable. First, ARIN should consider dropping the 
> RPA altogether. This would remove the most significant legal barriers to 
> widespread utilization of the ARIN RPKI repository.
> 
> 
> 
> I’m happy to see suggestions that dropping the RPA is a viable path.
> 
> In December 2018 we’ve measured that around TWENTY percent of the networks 
> deploying RPKI based Origin Validation are missing the ARIN TAL [source: 
> benjojo]. This is an extremely worrying number, as it means that ARIN ROAs 
> are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the 
> root cause for ARIN being an outliner is absence of the ARIN TAL in the 
> common RPKI Validation softwares. The absence of the ARIN TAL in software 
> distributions can be directly attributed to the existence of the RPA and 
> applicable contract doctrines.
> 
> If no changes are made to the current situation, I expect the 20% number to 
> remain the same or even grow, effectively making ARIN’s RPKI services 
> unsuitable for the purpose of securing routing.
> 
> 
> 2.   Developers of RPKI validation software should consider integrating 
> acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled 
> this possibility, and developers should deliberate on whether to capitalize 
> on the opportunity.
> 
> 
> 
> To put it bluntly: item 2 is not going to happen.
> 
> We’ve discussed this extensively in the OpenBSD community (who are working on 
> a new RPKI Validation implementation [source: rpki-client]), and concluded 
> that collecting explicit consent to the RPA on behalf of ARIN is undesirable 
> and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or 
> IRR data - and we’re not going to make an exception for ARIN and encumber 
> each and every OpenBSD or rpki-client(1) installation.
> 
> I checked the temperature in the room of the other relevant RPKI Validation 
> implementations, and it appears that *nobody* is planning to integrate 
> acceptance of ARIN’s RPA into their installation process.
> 
> 
> 4.   In addition to the 

Re: Report on Legal Barriers to RPKI Adoption

2019-01-06 Thread Job Snijders
Dear Christopher, David, NANOG community,

Thank you for your research and report. I found the report quite readable
(not having a legal background) and well structured. Definitely edifying
and worth the read! In this mail I’ll reply specifically to a few points
from the executive summary (and snip the rest).

For those of you who don’t want to create a SSRN account here is a copy of
the report:
http://instituut.net/~job/SSRN-id3309813.pdf


On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo  wrote:

> Here is a summary of our recommendations:
>
On the ROV side of the equation, the principal legal hindrances have to do
> with the terms and conditions governing access to the RPKI repository
> offered by ARIN in its Relying Party Agreement (“RPA”), and in the manner
> it has employed to ensure the agreement is binding. Regarding ROV:
>
> 1.   The goal of widespread ROV counsels in favor of ARIN reviewing
> its current approach to repository distribution, embodied in the RPA. We
> conclude that two paths would be reasonable. First, ARIN should consider
> dropping the RPA altogether. This would remove the most significant legal
> barriers to widespread utilization of the ARIN RPKI repository.
>


I’m happy to see suggestions that dropping the RPA is a viable path.

In December 2018 we’ve measured that around TWENTY percent of the networks
deploying RPKI based Origin Validation are missing the ARIN TAL [source:
benjojo]. This is an extremely worrying number, as it means that ARIN ROAs
are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the
root cause for ARIN being an outliner is absence of the ARIN TAL in the
common RPKI Validation softwares. The absence of the ARIN TAL in software
distributions can be directly attributed to the existence of the RPA and
applicable contract doctrines.

If no changes are made to the current situation, I expect the 20% number to
remain the same or even grow, effectively making ARIN’s RPKI services
unsuitable for the purpose of securing routing.


2.   Developers of RPKI validation software should consider integrating
> acceptance of ARIN’s RPA into their software workflows. ARIN recently
> enabled this possibility, and developers should deliberate on whether to
> capitalize on the opportunity.
>


To put it bluntly: item 2 is not going to happen.

We’ve discussed this extensively in the OpenBSD community (who are working
on a new RPKI Validation implementation [source: rpki-client]), and
concluded that collecting explicit consent to the RPA on behalf of ARIN is
undesirable and without precedent. This doesn’t exist for DNSSEC, TLS
certificates, or IRR data - and we’re not going to make an exception for
ARIN and encumber each and every OpenBSD or rpki-client(1) installation.

I checked the temperature in the room of the other relevant RPKI Validation
implementations, and it appears that *nobody* is planning to integrate
acceptance of ARIN’s RPA into their installation process.


4.   In addition to the important step ARIN has already taken to enable
> third-party software developers to integrate RPA acceptance into their
> software workflows, ARIN should consider reducing the barriers to
> third-party service development imposed by the RPA’s prohibited conduct
> clause. Specifically, ARIN should consider methods for allowing approved
> developers to make use of RPKI information as an input into more
> sophisticated services.
>
5.   Separately, ARIN should consider revising the prohibited conduct
> clause to allow broader distribution of information created with RPKI as an
> input for research and analysis purposes.
>


To provide context for the above two paragraphs, at this point in time it’s
unclear whether BGPMon’s WHOIS, NLNOG’s IRRExplorer, and the various “RPKI
to IRR” services are violating the RPA. I believe it to be highly
undesirable for this uncertainty to persist, nor would it be acceptable to
require each and every (potential) innovator or researcher to sign
contracts with ARIN. ARIN members would be significantly worse off if these
services stop using the ARIN TAL.

Finally, ARIN members should realize that the majority of ASNs on the
Internet are *outside* North America and are not ARIN members. We want
*all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and
misconfigurations don’t know borders. It’s not reasonable to require Dutch,
Indian, Russian and Chinese networks to enter into a contractual agreement
with ARIN in order to protect the ARIN members. This is why we need things
to work properly out of the box, just like was done with DNSSEC. Reform is
needed.

Kind regards,

Job

[benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018
[rpki-client]:
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65


Report on Legal Barriers to RPKI Adoption

2019-01-03 Thread Christopher S. Yoo
As many of you know, the prospects for widespread RPKI adoption grew more 
promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to 
cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT 
began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced 
its intention to begin filtering routes in early 2019. The Mutually Agreed 
Norms for Routing Security now has over 100 network operators signed on.

Still, as 2019 begins, many worry that legal issues are hindering RPKI 
adoption. This is especially true for North American networks, which have a 
comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are 
comparatively underutilized by parties using RPKI-based route origin validation 
("ROV") to inform their routing decisions.

My coauthor (David Wishnick) and I have spent the past year delving into the 
legal issues surrounding RPKI. Today, we are publicizing our report on how the 
network operator community should address these issues. It is available 
here<https://ssrn.com/abstract=3308619>. If you are interested in the future of 
routing security, we encourage you to read it (or its Executive Summary). We've 
tried to keep the legalese to a minimum.

RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. 
Going forward, we expect to continue a fruitful dialogue about how the network 
operator community can reduce the legal barriers to RPKI adoption.

Here is a summary of our recommendations:

On the ROV side of the equation, the principal legal hindrances have to do with 
the terms and conditions governing access to the RPKI repository offered by 
ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed 
to ensure the agreement is binding. Regarding ROV:

1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
current approach to repository distribution, embodied in the RPA. We conclude 
that two paths would be reasonable. First, ARIN should consider dropping the 
RPA altogether. This would remove the most significant legal barriers to 
widespread utilization of the ARIN RPKI repository. Second, because the legal 
risks faced by ARIN in an RPA-free world are ultimately uncertain, it would 
also be reasonable for ARIN to maintain the RPA for the purposes of 
contractually allocating risks to the parties best positioned to reduce and 
mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's 
indemnification clause, instead relying solely on the RPA's disclaimers of 
warranties and limitations of liability, or at least reducing the 
indemnification clause's scope to eliminate the problem of moral hazard.

2.   Developers of RPKI validation software should consider integrating 
acceptance of ARIN's RPA into their software workflows. ARIN recently enabled 
this possibility, and developers should deliberate on whether to capitalize on 
the opportunity.

3.   The network operator community and ARIN should broadly publicize 
ARIN's policy of revising various RPA clauses for government entities that are 
prohibited from agreeing to them.

4.   In addition to the important step ARIN has already taken to enable 
third-party software developers to integrate RPA acceptance into their software 
workflows, ARIN should consider reducing the barriers to third-party service 
development imposed by the RPA's prohibited conduct clause. Specifically, ARIN 
should consider methods for allowing approved developers to make use of RPKI 
information as an input into more sophisticated services.

5.   Separately, ARIN should consider revising the prohibited conduct 
clause to allow broader distribution of information created with RPKI as an 
input for research and analysis purposes.

6.   As a general alternative, the Internet community should consider 
whether to develop a separate corporate entity that would be responsible for 
operational aspects of RPKI repository provision. That corporation could 
conduct such activities for the North American region, or on a worldwide basis.

Regarding the ROA-issuance side of the equation, the principal legal obstacles 
stem from the terms and conditions found in ARIN's Registration Services 
Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI 
Terms of Service. Regarding these, the report recommends the following:

1.   ARIN should consider adopting a pathway to provide RPKI services that 
would explicitly refrain from altering the existing balance of property and 
transferability rights associated with IP address allocations.

2.   The network operator community and ARIN should broadly publicize 
ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses 
for government entities that are prohibited from agreeing to them. ARIN should 
also begin presenting the RPKI Terms of Service to newly-onboarded