[arin-announce] ARIN Resource Certification Update

Owen DeLong owen at delong.com
Sun Jan 30 09:03:55 CST 2011


On Jan 30, 2011, at 6:11 AM, Carlos Martinez-Cagnazzo wrote:

> Do you really think that a set of keys stored in a random PC in a
> random office is safer than on a periodically backed-up, encrypted
> database? In this future I only see lost keys, keys appearing listed
> in something.ru domains, tons of support calls to hostmasters, and
> ROAs repeatedly becoming invalid, all things that will seriously harm
> RPKI adoption.
> 
I think that organizational key security needs to be the responsibility
of the organization. I rarely use Valet parking because I don't like
having my car keys left on a peg board full of easy-to-steal car keys
along with many other attractive theft targets.

I think that centralizing a bunch of RPKI keys on a single server
makes a very attractive target.

> In the end, I see two things:
> 
> - Hosted solutions aren´t supposed to fit everyone, that´s why
> top-down is being developed. This is not news.
> 
Yep.

> - Hosted solutions offer a low barrier entry to smaller organizations
> who simply cannot develop their own PKI infrastructure. This is the
> case where they also lack the organizational skills to properly manage
> the keys themselves, so, in most cases at least, they are *better off*
> with a hosted solution
> 
They also offer an attractive target for miscreants with a huge payoff
if they are ever compromised.

> For RPKI to succeed we have to succeed not only on the technical side
> but on the *human* side of things. Adoption of RPKI will only move
> forward if network admins have *confidence* in the stability,
> dependability and overall quality of the whole system. ROAs repeatedly
> becoming invalid for the wrong reasons will represent a death blow to
> RPKI adoption.
> 
Succeeding on the human side includes doing things in a way that
makes people comfortable with the solution.

The internet has succeeded largely because we have avoided putting
all of our eggs (or even major subsets of our eggs) in single baskets.
Hosted RPKI private keys are an example of putting an awful lot of
very important eggs into a very small basket.

> For RIPE, their hosted solution is clearly meeting expectations within
> their region. Other region´s mileage may vary. I hope we (LACNIC) can
> do just as well.
> 
We'll see how people feel after the first time it gets pwn3d.

> Have a great day!
> 
> Carlos
> 
You too.

Owen

> On Sat, Jan 29, 2011 at 11:52 PM, Owen DeLong <owen at delong.com> wrote:
>> I don't understand why you can't have a hosted solution where the private keys
>> are not held by the host.
>> 
>> Seems to me you should be able to use a Java Applet to do the private key
>> generation and store the private key on the end-user's machine, passing
>> objects that need to be signed by the end user down to the applet for
>> signing.
>> 
>> This could be just as low-entry for the user, but, without the host holding
>> the private keys.
>> 
>> What am I missing?
>> 
>> Owen
>> 
>> On Jan 29, 2011, at 1:06 PM, Arturo Servin wrote:
>> 
>>> 
>>>       I agree with Alex that without a hosted solution RIPE NCC wouldn't have so many ROAs today, for us, even with it, it has been more difficult to roll out RPKI among our ISPs. As many, I do not think that a hosted suits to everybody and it has some disadvantages but at leas it could help to lower the entry barrier for some.
>>> 
>>> 
>>>       Speaking about RPKI stats, here some ROA evolution in various TAs (the data from ARIN is from their beta test, the rest are production systems):
>>> 
>>> http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt
>>> 
>>>       And visually:
>>> 
>>> http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png
>>> 
>>>       and
>>> 
>>> http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/
>>> 
>>>       To see each region.
>>> 
>>> http://www.labs.lacnic.net/~rpki/rpki-heatmaps
>>> 
>>>       Also, bgpmon has a nice whois interface for humans to see ROAs (not sure if this link was share here or in twitter, sorry if I am duplicating):
>>> 
>>> http://bgpmon.net/blog/?p=414
>>> 
>>> 
>>> Best regards,
>>> -as
>>> 
>>> 
>>> 
>>> On 29 Jan 2011, at 13:26, Alex Band wrote:
>>> 
>>>> John,
>>>> 
>>>> Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this.
>>>> 
>>>> To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them.
>>>> 
>>>> I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now?
>>>> 
>>>> Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that?
>>>> 
>>>> Alex Band
>>>> Product Manager, RIPE NCC
>>>> 
>>>> P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format:
>>>> http://lunimon.com/valid-roas-20110129.csv
>>>> 
>>>> 
>>>> 
>>>> On 24 Jan 2011, at 21:33, John Curran wrote:
>>>> 
>>>>> Copy to NANOG for those who aren't on ARIN lists but may be interested in this info.
>>>>> FYI.
>>>>> /John
>>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
>>>>> Date: January 24, 2011 2:58:52 PM EST
>>>>> To: "arin-announce at arin.net<mailto:arin-announce at arin.net>" <arin-announce at arin.net<mailto:arin-announce at arin.net>>
>>>>> Subject: [arin-announce] ARIN Resource Certification Update
>>>>> 
>>>>> ARIN continues its preparations for offering production-grade resource certification
>>>>> services for Internet number resources in the region.  ARIN recognizes the importance
>>>>> of Internet number resource certification in the region as a key element of further
>>>>> securing Internet routing, and plans to rollout Resource Public Key Infrastructure (RPKI)
>>>>> at the end of the second quarter of 2011 with support for the Up/Down protocol for those
>>>>> ISPs who wish to certify their subdelegations via their own RPKI infrastructure.
>>>>> 
>>>>> ARIN continues to evaluate offering a Hosting Resource Certification service for this
>>>>> purpose (as an alternative to organizations having to run their own RPKI infrastructure),
>>>>> but at this time it remains under active consideration and is not committed.   We look
>>>>> forward to discussing the need for this type of service and the organization implications
>>>>> atour upcoming ARIN Members Meeting in April in San Juan, PR.
>>>>> 
>>>>> FYI,
>>>>> /John
>>>>> 
>>>>> John Curran
>>>>> President and CEO
>>>>> ARIN
>>>>> 
>>>>> _______________________________________________
>>>>> ARIN-Announce
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto:ARIN-announce at arin.net>).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>>>> Please contact info at arin.net if you experience any issues.
>>>>> 
>>>>> 
>>>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> --
> =========================
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =========================




More information about the NANOG mailing list