subject:"\[arin\-announce\] ARIN Resource Certification Update"

I see also that many concerns expressed here are extensions of the
perceived failures of the whole CA business. I agree that the whole
model of CAs has largely failed. Not only there are too many of them,
but the fact that they try to operate as for-profits makes them
vulnerable to all the pressures that come with the need to sell and
generate revenue.

The spectacular failures they have suffered in the past (certificates
with Microsoft's name on them, I guess everyone remembers) have
certainly not helped.

Basically the only thing you now get from using SSL certs is
end-to-end encryption, and for that, a self-signed certificate does
just as well as a thousand dollar one from your preferred friendly CA.

However, as I said on an earlier post, I still believe that the hosted
solution for RPKI is a good one at this point in time for a certain
group of users of a certain application. It is *very* vertical, or
niche if you want. We should not try to extend it to other
applications or other groups of users.

Randy sums up my whole feelings on the issue. I also think we need
top-down soon, and I wouldn't mind in the future seeing a nice Paretto
distribution where 80% of members use the hosted solution, but account
for 20% of routed space, where 20% customers use top-down accounting
for 80% of routed space.

Perfection is the enemy of good. Before hosted RPKI the only way of
checking origin-as information was to use one of the public routing
registries. A routing registry which is fed from RPKI data is a lot
more trustworthy than plain email auth IRRs are. Is it pefect? Of
course not. Can it be improved? Of course it can.

cheers!

Carlos

Re: [arin-announce] ARIN Resource Certification Update

> >There's a big difference. If a bank screws up and loses $5,000 of my
money, I
> > can (at least potentially) sue them and recover $5,000 which is  pretty much
> > identical to the $5,000 I lost.  If a key escrow company loses my private 
> > key,
> > getting back an identical private key is exactly the *wrong* solution.
> >
> > Crypto keys are not interchangable like dollar bills.
I never suggested that they were. I tried to point out a set of
institutions on which we place similar, if not higher, levels of trust
to those required to store a crypto key.

If your crypto bank loses your key, you can always revoke and resign.
And you'll be back on the air much faster than you can recover $5k from
a failed bank. And please do not get me out of context, I never said the
hosted solution was perfect, nor that the analogy applicable to every
aspect.

And I am not trying to extend the success of RIPE's hosted solution to
"everybody's digital identity". It is a vertical solution that is doing
well (and will hopefully continue to do so) on a vertical application.
For sure, it is probably not an example you can extend to other
applications.

Going back to money, I would *never* trust a hosted solution to hold a
key I use to access my online banking. This would clearly be a case
where a hosted solution is not applicable.

regards

Carlos

-- Carlos M. Martinez LACNIC I+D PGP KeyID 0xD51507A2 Phone:
+598-2604- ext. 4419


Carlos Martinez Cagnazzo

Re: [arin-announce] ARIN Resource Certification Update

2011-01-30 Thread Randy Bush

hi alex,

just to be clear

i think your web-based system is a good thing.  97.3% of your members do
not want to go through the effort of installing certifying software and
doing up/down with you.  i am not fond of you holding folk's private
keys, but that's what they get for laziness.  of course you might think
about john's concerns of liability, but you have less lawyers than he
does, so wtf.

but, as i have said, the lack of the up/down protocol is pretty serious.
that remaining 2.7% of your members have 90% of the address space, they
are the big providers, and they will not be happy with using your web
interface no matter how posh.

bottom line: i like your moving ahead.  i just wish you were moving more
quickly.

randy

Re: [arin-announce] ARIN Resource Certification Update

2011-01-30 Thread Valdis . Kletnieks

On Sun, 30 Jan 2011 11:57:57 -0200, Carlos Martinez-Cagnazzo said:
> What I just don't get if, we as a society, have created institutions
> we trust with our *money* (AKA banks), why there can't be institutions
> we trust with our crypto keys. I know that banks sometimes fail, and
> yes, probably "crypto banks" will sometimes fail as well, but on the
> whole, the failure rate of trusted institutions can be quite low,
> acceptably low.

There's a big difference.  If a bank screws up and loses $5,000 of my money, I
can (at least potentially) sue them and recover $5,000 which is  pretty much
identical to the $5,000 I lost.  If a key escrow company loses my private key,
getting back an identical private key is exactly the *wrong* solution.

Crypto keys are not interchangable like dollar bills.


pgpRwTKsD1T9V.pgp
Description: PGP signature

Re: [arin-announce] ARIN Resource Certification Update

2011-01-30 Thread Owen DeLong

#x27;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 mailto:jcur...@arin.net>>
>>>>> Date: January 24, 2011 2:58:52 PM EST
>>>>> To: "arin-annou...@arin.net<mailto:arin-annou...@arin.net>" 
>>>>> mailto:arin-annou...@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-annou...@arin.net<mailto:arin-annou...@arin.net>).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>>>> Please contact i...@arin.net if you experience any issues.
>>>>> 
>>>>> 
>>>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> --
> =
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =

Re: [arin-announce] ARIN Resource Certification Update

2011-01-30 Thread Leen Besselink

Hello Carlos,

On 01/30/2011 02:57 PM, Carlos Martinez-Cagnazzo wrote:
> What I just don´t get if, we as a society, have created institutions
> we trust with our *money* (AKA banks), why there can´t be institutions
> we trust with our crypto keys. I know that banks sometimes fail, and
> yes, probably "crypto banks" will sometimes fail as well, but on the
> whole, the failure rate of trusted institutions can be quite low,
> acceptably low.
>

Well, we tried to trust the Certificate Authorities for SSL/TLS but that
has failed too.

And they don't even hold private keys.

Your browser now indirectly trusts 1000+ (sub) certificate authorities.

Do I actually trust them all ? No, I don't but they could all sign a
certificate for paypal.com* which my browser would trust just fine.

A simple example is CNNIC which is a Chinese government agency, the people
in China don't trust them, so why should I ?

Should the browser really trust a German university to sign paypal.com* ?

How about an agency in the United Emirates ? How about my own government ?

Or Time Warner/AOL or Ford Motor company or Google ?

And so on.

https://www.eff.org/files/colour_map_of_CAs.pdf
https://www.eff.org/observatory
http://www.youtube.com/watch?v=VUKCDm04AqI
http://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html
http://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-a-safe-place.pdf

At this point, I would really like to see someone implement a
DNS-recursive nameserver which
can be configured to only trust the root to DNSSEC-sign the root zone
and nothing else. And allow
the owners/operators/whatever of .com only allow to sign .com. Nothing more.

But that isn't really what DNSSEC was designed to do. I am however glad
people are working on adding
DNSSEC to the browser and some hash in DNS which tells the browser which
certificate or CA's are
trusted for a domain.

Even though it seems to be going slow, because there are many reasons
why DNSSEC won't be deployed
to users any time soon.

* Yes, I know Paypal.com uses an EV-certificate (green bar) and there
are a lot less CA's for that, but
it is just an example of a website.

How about the Chinese government reading what you do on gmail while you
are in China ? That is
just an example of something that does not use an EV-cert.

I'm not satisfied with the banks in my country either. It seems in both
cases to be a race to the bottom.
Cuttings costs any place they can, like reducing staff. Making it harder
and harder to use cash.

The CA's seem to be a race to the bottom too. They are not spending
money trying to improve their
systems, even though the environment around them is changing. Just
trying to make money from their
existing business.

Because it already is a race to the bottom, might as well offer free
certificates so everyone can use them
to secure any site. One CA already does this: https://www.startssl.com/
They atleast to me seem to be
very proactive.

The problem with banks is, I've not found a good alternative yet.

Fully support StartSSL and RIPE for trying to lower the bar for more
security.

Have a nice weekend,
Leen.

Re: [arin-announce] ARIN Resource Certification Update

2011-01-30 Thread Owen DeLong

On Jan 30, 2011, at 5:57 AM, Carlos Martinez-Cagnazzo wrote:

> What I just don´t get if, we as a society, have created institutions
> we trust with our *money* (AKA banks), why there can´t be institutions
> we trust with our crypto keys. I know that banks sometimes fail, and
> yes, probably "crypto banks" will sometimes fail as well, but on the
> whole, the failure rate of trusted institutions can be quite low,
> acceptably low.
> 
Banks are not an all or nothing proposition. Only a fool trusts a single
bank with all of his money.

On the other hand, your private key, short of a complicated key escrow
environment like the one employed by ICANN for the root key for DNSSEC
is an all-or-nothing proposition. EIther you completely trust the other
organization, or you don't.

Further, when we trust banks with our money, we trust them to hold it,
but, we have separate verifiable documentation of how much they are
holding for us and they are accountable to return the money to us upon
demand.

In the case of a private key, it's not money you hand over, it is your very
identity in the digital universe. It would be akin to handing your passport
to your banker and giving him the ability to replace your picture with his
own and then use that passport in whatever manner he sees fit.

> IMO the whole thing seems to boil down to the complex interaction of
> psychological, emotional and other aspects of how we perceive a
> certain situation. And it clearly depends on the region, just look at
> RIPE´s column and how it grows relentlessly (i included only a few
> lines, full stats can be found in the URL posted by Arturo in an
> earlier post)
> 
Yes, it is cultural and regional. Yes, it is partially a matter of psychology.

> R2a. IPv4 Space Covered by ROAs (in units of /24s)
> 
> 
> date   |lacnic| apnic|   afrinic|  arin|  ripe|
> 2011-01-11 |17|   189| 1| 0| 28902|
> 2011-01-12 |17|   189| 1|   1867.03| 32439|
> 2011-01-13 |17|  None| 1|   1867.03| 32810|
> 2011-01-14 |17|   181| 1|   1867.03| 32819|
> 2011-01-15 |17|   181| 1|   1867.03| 32875|
> 2011-01-16 |17|   181| 1|   1867.03| 32875|
> 2011-01-17 |17|   181| 1|20| 32903|
> 2011-01-18 |17|   181| 2|  None| 33783|
> 2011-01-19 |17|   177| 2|  None| 35271|
> 
> Hats off to RIPE People!
> 
We'll see. I have no doubt that if ARIN implemented RPKI the way
RIPE has, we'd see similar numbers. However, that doesn't tell
the whole story and there are differences in the legal framework
under which RIPE operates vs. ARIN that also present unique
challenges for ARIN doing things that way.

I'm not convinced that what RIPE is doing is completely in the
community interest. I think holding that many organization's
private keys in trust in a single central repository is somewhat
irresponsible and short sighted. Yes, it creates a near-term
benefit and accelerates deployment of RPKI. However, it
also has risks which don't show up in your table.

Owen

Re: [arin-announce] ARIN Resource Certification Update

t; 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 mailto:jcur...@arin.net>>
>>>> Date: January 24, 2011 2:58:52 PM EST
>>>> To: "arin-annou...@arin.net<mailto:arin-annou...@arin.net>" 
>>>> mailto:arin-annou...@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-annou...@arin.net<mailto:arin-annou...@arin.net>).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>>> Please contact i...@arin.net if you experience any issues.
>>>>
>>>>
>>>
>
>
>



-- 
--
=
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=

Re: [arin-announce] ARIN Resource Certification Update

What I just don´t get if, we as a society, have created institutions
we trust with our *money* (AKA banks), why there can´t be institutions
we trust with our crypto keys. I know that banks sometimes fail, and
yes, probably "crypto banks" will sometimes fail as well, but on the
whole, the failure rate of trusted institutions can be quite low,
acceptably low.

IMO the whole thing seems to boil down to the complex interaction of
psychological, emotional and other aspects of how we perceive a
certain situation. And it clearly depends on the region, just look at
RIPE´s column and how it grows relentlessly (i included only a few
lines, full stats can be found in the URL posted by Arturo in an
earlier post)

R2a. IPv4 Space Covered by ROAs (in units of /24s)


date   |lacnic| apnic|   afrinic|  arin|  ripe|
2011-01-11 |17|   189| 1| 0| 28902|
2011-01-12 |17|   189| 1|   1867.03| 32439|
2011-01-13 |17|  None| 1|   1867.03| 32810|
2011-01-14 |17|   181| 1|   1867.03| 32819|
2011-01-15 |17|   181| 1|   1867.03| 32875|
2011-01-16 |17|   181| 1|   1867.03| 32875|
2011-01-17 |17|   181| 1|20| 32903|
2011-01-18 |17|   181| 2|  None| 33783|
2011-01-19 |17|   177| 2|  None| 35271|

Hats off to RIPE People!

cheers,

Carlos

On Sun, Jan 30, 2011 at 8:39 AM, Alex Band  wrote:
> Paul,
>
> I think my question is very pertinent. Of course the number of signed 
> prefixes directly influences the number of validators. Do you think the RIPE 
> NCC Validator tool would have been downloaded over 100 times in the last 
> month if there were only 5 certified prefixes?
>
> In my opinion, the widespread availability of signed prefixes and mature 
> validation methods is key to the global success of resource certification. I 
> agree that small differences in the size of the set of signed routes don't 
> matter on a (relatively) short term, but the reality is that the difference 
> would be *enormous* if we wouldn't offer a hosted solution.
>
> Practically, in the real world, why would anyone invest time and effort in 
> altering their current BGP decision making process to accommodate for 
> resource certification if the technology is on nobody's radar, it's hard to 
> get your feet wet and there are just a handful of certified prefixes out 
> there. Wouldn't it be good if network operators think: "Because it helps 
> increase global routing security, it's easy to get started and lots of people 
> are already involved, perhaps I should have a look at (both sides of) 
> resource certification too."
>
> This is why I believe – and our adoption numbers prove – that the entry 
> barrier to the system should be as low as possible, both on the signing side 
> and the validation side. Once some of the people that are using the hosted 
> platform now decide they would rather run their own non-hosted solution at a 
> later stage, that would be even better. That immediately solves the private 
> key situation. But there will always be a group happy to rely on the hosted 
> model, and we cater to that.
>
> Because of the path we chose there is already a lot of operational experience 
> being gained, resulting in a large amount of feedback from a wide range of 
> users. This helps us shape the certification system and the validator tool, 
> which aids quality and usability. To me, that makes a lot of business sense. 
> This is why I think there should be as much certified address space available 
> as possible. Otherwise this will stay a niche technology until perhaps a 
> major event causes people to wake up (and hopefully take action). If 
> certification has reached the necessary level of maturity at that point 
> remains to be seen. Furthermore, preventing (future) malicious hijacking is 
> not the *only* reason the Internet community needs better routing security, 
> the accidental route leaking that happens every day is reason enough.
>
> -Alex
>
> On 29 Jan 2011, at 23:00, Paul Vixie wrote:
>
>>> From: Alex Band 
>>> Date: Sat, 29 Jan 2011 16:26:55 +0100
>>>
>>> ... 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?
>>
>> i don't agree that that question is pertinent.  in deployment scenario
>> planning i've come up with three alternatives and this question is not
>> relevant to any of them.  perhaps you know a fourth alternative.  here
>> are mine.
>>
>> 1. people who receive routes will prefer signed vs. unsigned, and other
>> people who can sign routes will sign them if it's easy (for example,
>> hosted) but not if it's too hard (for example, up/down).
>>
>> 2. same as #1 except people who really care about their routes

Re: [arin-announce] ARIN Resource Certification Update

2011-01-30 Thread Alex Band

Paul,

I think my question is very pertinent. Of course the number of signed prefixes 
directly influences the number of validators. Do you think the RIPE NCC 
Validator tool would have been downloaded over 100 times in the last month if 
there were only 5 certified prefixes?

In my opinion, the widespread availability of signed prefixes and mature 
validation methods is key to the global success of resource certification. I 
agree that small differences in the size of the set of signed routes don't 
matter on a (relatively) short term, but the reality is that the difference 
would be *enormous* if we wouldn't offer a hosted solution.

Practically, in the real world, why would anyone invest time and effort in 
altering their current BGP decision making process to accommodate for resource 
certification if the technology is on nobody's radar, it's hard to get your 
feet wet and there are just a handful of certified prefixes out there. Wouldn't 
it be good if network operators think: "Because it helps increase global 
routing security, it's easy to get started and lots of people are already 
involved, perhaps I should have a look at (both sides of) resource 
certification too." 

This is why I believe – and our adoption numbers prove – that the entry barrier 
to the system should be as low as possible, both on the signing side and the 
validation side. Once some of the people that are using the hosted platform now 
decide they would rather run their own non-hosted solution at a later stage, 
that would be even better. That immediately solves the private key situation. 
But there will always be a group happy to rely on the hosted model, and we 
cater to that.

Because of the path we chose there is already a lot of operational experience 
being gained, resulting in a large amount of feedback from a wide range of 
users. This helps us shape the certification system and the validator tool, 
which aids quality and usability. To me, that makes a lot of business sense. 
This is why I think there should be as much certified address space available 
as possible. Otherwise this will stay a niche technology until perhaps a major 
event causes people to wake up (and hopefully take action). If certification 
has reached the necessary level of maturity at that point remains to be seen. 
Furthermore, preventing (future) malicious hijacking is not the *only* reason 
the Internet community needs better routing security, the accidental route 
leaking that happens every day is reason enough.

-Alex

On 29 Jan 2011, at 23:00, Paul Vixie wrote:

>> From: Alex Band 
>> Date: Sat, 29 Jan 2011 16:26:55 +0100
>> 
>> ... 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?
> 
> i don't agree that that question is pertinent.  in deployment scenario
> planning i've come up with three alternatives and this question is not
> relevant to any of them.  perhaps you know a fourth alternative.  here
> are mine.
> 
> 1. people who receive routes will prefer signed vs. unsigned, and other
> people who can sign routes will sign them if it's easy (for example,
> hosted) but not if it's too hard (for example, up/down).
> 
> 2. same as #1 except people who really care about their routes (like
> banks or asp's) will sign them even if it is hard (for example, up/down).
> 
> 3. people who receive routes will ignore any unsigned routes they hear,
> and everyone who can sign routes will sign them no matter how hard it is.
> 
> i do not expect to live long enough to see #3.  the difference between #1
> and #2 depends on the number of validators not the number of signed routes
> (since it's an incentive question).  therefore small differences in the
> size of the set of signed routes does not matter very much in 2011, and
> the risk:benefit profile of hosted vs. up/down still matters far more.
> 
>> 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?
> 
> while i am expecting a rise in address piracy following depletion, i am
> not expecting #3 (see above) and i think most of the piracy will be of
> fallow or idle address space that will therefore have no competing route
> (signed or otherwise).  this will become more pronounced as address
> space holders who care about this and worry about this sign their routes
> -- the pirates will go after easier prey.  so again we see no material
> difference between hosted and up/down on the deployment side or if there
> is a difference it is much smaller than the risk:benefit profile
> difference on the provisioning side.
> 
> in summary, i am excited about RPKI and i've been pus

Re: [arin-announce] ARIN Resource Certification Update

2011-01-29 Thread Owen DeLong

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 mailto:jcur...@arin.net>>
>>> Date: January 24, 2011 2:58:52 PM EST
>>> To: "arin-annou...@arin.net<mailto:arin-annou...@arin.net>" 
>>> mailto:arin-annou...@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 
>>> infra

Re: [arin-announce] ARIN Resource Certification Update

2011-01-29 Thread Paul Vixie

> From: Alex Band 
> Date: Sat, 29 Jan 2011 16:26:55 +0100
> 
> ... 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?

i don't agree that that question is pertinent.  in deployment scenario
planning i've come up with three alternatives and this question is not
relevant to any of them.  perhaps you know a fourth alternative.  here
are mine.

1. people who receive routes will prefer signed vs. unsigned, and other
people who can sign routes will sign them if it's easy (for example,
hosted) but not if it's too hard (for example, up/down).

2. same as #1 except people who really care about their routes (like
banks or asp's) will sign them even if it is hard (for example, up/down).

3. people who receive routes will ignore any unsigned routes they hear,
and everyone who can sign routes will sign them no matter how hard it is.

i do not expect to live long enough to see #3.  the difference between #1
and #2 depends on the number of validators not the number of signed routes
(since it's an incentive question).  therefore small differences in the
size of the set of signed routes does not matter very much in 2011, and
the risk:benefit profile of hosted vs. up/down still matters far more.

> 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?

while i am expecting a rise in address piracy following depletion, i am
not expecting #3 (see above) and i think most of the piracy will be of
fallow or idle address space that will therefore have no competing route
(signed or otherwise).  this will become more pronounced as address
space holders who care about this and worry about this sign their routes
-- the pirates will go after easier prey.  so again we see no material
difference between hosted and up/down on the deployment side or if there
is a difference it is much smaller than the risk:benefit profile
difference on the provisioning side.

in summary, i am excited about RPKI and i've been pushing hard for in
both my day job and inside the ARIN BoT, but... let's not overstate the
case for it or kneejerk our way into provisioning models whose business
sense has not been closely evaluated.  as john curran said, ARIN will
look to the community for the guideance he needs on this question.  i
hope to see many of you at the upcoming ARIN public policy meeting in
san juan PR where this is sure to be discussed both at the podium and in
the hallways and bar rooms.

Paul Vixie
Chairman and Chief Scientist, ISC
Member, ARIN BoT

Re: [arin-announce] ARIN Resource Certification Update

2011-01-29 Thread Arturo Servin


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 mailto:jcur...@arin.net>>
>> Date: January 24, 2011 2:58:52 PM EST
>> To: "arin-annou...@arin.net<mailto:arin-annou...@arin.net>" 
>> mailto:arin-annou...@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-annou...@arin.net<mailto:arin-annou...@arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-announce
>> Please contact i...@arin.net if you experience any issues.
>> 
>> 
>

Re: [arin-announce] ARIN Resource Certification Update

2011-01-29 Thread John Curran

On Jan 29, 2011, at 10:26 AM, 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.

Alex - Yes, congrats on rolling out that offering!  Also, I wish the folks at 
the very best on the up/down protocol work, since (as you're likely aware) ARIN 
is planning to leverage that effort in our up/down service development.  :-)

> 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?

For many organizations, a hosted service offers the convenience that would make 
deployment likely.  The challenge that ARIN faces isn't with respect to whether 
our community trusts us to run a properly secured and audited service, but the 
potential implied liability to ARIN if a party alleges that the hosted service 
performs incorrectly.  It is rather challenging to show that a "relying party" 
is legally bound to the terms of service in certificate practices statement, 
and this means that there are significant risks in the offering the service 
(even with it performing perfectly), since much of the normal contractual 
protections are not available.

Imagine an organization that incorrectly enters its AS number during a ROA 
generation, and succeeds in taking itself off their air for a prolonged period. 
 Depending on the damages the organization suffered as a result, it may want to 
claim that ARIN's Hosted RPKI system performed "incorrectly", as may those 
folks who were impacted by not being able to reach the organization.  While 
ARIN's hosted system would be performing perfectly, the risk and costs to the 
organization in trying to defend against such (spurious) claims could be very 
serious.  Ultimately, the ARIN Board needs to weigh such matters of benefit and 
risk in full against the mission and determine the appropriate direction.

> 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?

The RPKI information regarding valid address holder is effectively same as that 
contained in the WHOIS, so readily available evidence of resource holder is 
available today.  Parties already use information from the RIRs from WHOIS and 
routing registries to do various forms of resource & route validation; resource 
certification simply provides a clearer, more secure & more consistent model 
for this information.  I'm not saying that resource certification isn't 
important, but do not think that characterizing its need as crucial 
specifically due to IPv4 depletion is the complete picture.  

ARIN recognizes the importance of resource certification and hence its 
commitment to supporting resource certification for resources in the region via 
Up/Down protocol. There is not a decision on a hosted RPKI offer at this time, 
but that is because we want to be able to discuss the benefits and risks with 
the community at our upcoming April meeting to make sure there is significant 
demand for service as well as appropriate mechanisms for safely managing the 
risks involved.  I hope this clarifies the update message that I sent out 
earlier, and provides some insight into the considerations that have led ARIN's 
position on resource certification.

Thanks!
/John

John Curran
President and CEO
ARIN

Re: [arin-announce] ARIN Resource Certification Update

2011-01-29 Thread Alex Band

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 mailto:jcur...@arin.net>>
> Date: January 24, 2011 2:58:52 PM EST
> To: "arin-annou...@arin.net<mailto:arin-annou...@arin.net>" 
> mailto:arin-annou...@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-annou...@arin.net<mailto:arin-annou...@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-announce
> Please contact i...@arin.net if you experience any issues.
> 
> 

smime.p7s
Description: S/MIME cryptographic signature

Re: [arin-announce] ARIN Resource Certification Update

2011-01-28 Thread Samuel Weiler


[moderation seems slow; resending from subscribed address instead]

On Mon, 24 Jan 2011, Danny McPherson wrote:


I suspect I've sufficiently chummed the waters, I'll kick back and absorb
all the reasons this is a whack idea :)


Short summary: it's not entirely whack, but no one has yet put forward a 
working data model.  The scheme in Bill Manning's INET'98 paper might have 
worked for classFUL addresses, but not CIDR.  I think there may have been 
similar problems with Lutz Donnerhacke and Wouter Wijngaards' scheme(s) from 
2008.


Joe Abley's problem statement on this list gets to one of the issues. Your 
answer to him of "New prefix-based RRs?  And perhaps even a new .arpa or 
in-addr.arpa subdomain" is a bit short on details.  I challenge you to work out 
the details.  Once we have something concrete, then we can pick apart why it 
won't work, tweak, and repeat.


-- Sam

Re: [arin-announce] ARIN Resource Certification Update

2011-01-27 Thread Randy Bush

> Why does this stop the whole thing short?

the devil is in the details and the trust.  i am desperately open to
other approaches.  but work it out at the detailed level, not just a
troll on nanog.  i anxiously await your and danny's draft.

randy

Re: [arin-announce] ARIN Resource Certification Update

2011-01-27 Thread Jack Bates


On 1/27/2011 7:51 PM, Osterweil, Eric wrote:

I think the bottom line is that this infrastructure will allow a security
solution to reach deployment_much_  sooner than a green-field design.


Errr, yeah. See IPv6 deployment.


Jack

Re: [arin-announce] ARIN Resource Certification Update

2011-01-27 Thread Osterweil, Eric

On 1/25/11 7:04 AM, "Roland Dobbins"  wrote:

> 
> 
> On Jan 25, 2011, at 9:52 PM, Joe Abley wrote:
> 
>> If the DNS was as unreliable as those words suggested, nobody would use it.
> 
> I see evidence of this unreliability every day, so I must respectfully
> disagree.
> 
> ;>
> 
>> The reality is that everybody uses it.
> 
> The reality is that they don't really have a choice, now, do they?
> 
> ;>

I think it's actually correct, and backs up Danny's point: it is very useful
to be able to use a system that is: deployed, understood, operationally
viable, etc.  The risk of designing from scratch is best described by the
lead time many other architectural changes have/are facing in being
deployed.

I think the bottom line is that this infrastructure will allow a security
solution to reach deployment _much_ sooner than a green-field design.

Eric

Re: [arin-announce] ARIN Resource Certification Update

2011-01-27 Thread Osterweil, Eric

Sorry to be Johnny-come-lately to this...

On 1/24/11 6:31 PM, "Randy Bush"  wrote:

>> Right, I've heard the circular dependency arguments.  So, are you
>> suggesting the RPKI isn't going to rely on DNS at all?
> 
> correct.  it need not.

Maybe I am misunderstand something here...  Are (for example) the rsync
processes going to use hard coded IPs?  Are the SIAs and AIAs referenced by
IP?

> 
>> I'm of the belief RPKI should NOT be on the critical path, but instead
>> focus on Internet number resource certification - are you suggesting
>> otherwise?
> 
> 
> see the word 'certification'?  guess where that leads.  pki.  add
> resources and stir.

Sounds like a loose definition of pki.  Does DNSSEC count as such a loosely
defined pki? :-P

> 
>>> if the latter, then you have the problem that the dns trust model is
>>> not congruent with the routing and address trust model.
>> That could be easily fixed with trivial tweaks and transitive trust/
>> delegation graphs that are, I suspect.
> 
> not bloody likely.  the folk who sign dns zones are not even in the same
> building as the folk who deal with address space.  in large isps, not
> even in the same town.

Why does this stop the whole thing short?  I think the people who run any
as-yet-to-be-developed-and-deployed system don't sit in any building at
all... Yet, right? :)

Tbqh, I think I might be missing something important (so, please forgive my
ignorance), but I don't see how (for example) admins of the SMTP
infrastructure have trouble getting their MX records right in DNS zones...
How are getting certs in there so much worse?

Eric

Re: [arin-announce] ARIN Resource Certification Update

2011-01-25 Thread Charles N Wyble


On 1/24/2011 8:52 PM, Roland Dobbins wrote:

On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote:


thinking of using DNS is tempting


The main arguments I see against it are:


2.  The generally creaky, fragile, brittle, non-scalable state of the 
overall DNS infrastructure in general.


Can you expand on this a bit?


Routing and DNS, which are the two essential elements of the Internet control 
plane, are e also its Achilles' heels.  It can be argued that making routing 
validation dependent upon the DNS would make this situation worse.

The main reasons for it are those Danny stated:

1.  DNS exists.

2.  DNSSEC is in the initial stages of deployment.

3.  There's additional relevant work going on which would make DNS more 
suitable for this application.

4.  Deployment inertia.



I kind of like the DNS idea. Though some challenges have been raised in 
this thread that warrant further discussion.  In particular the in.addr 
delegation scenarios between RIRs.

Re: [arin-announce] ARIN Resource Certification Update

2011-01-25 Thread Roland Dobbins

On Jan 25, 2011, at 9:52 PM, Joe Abley wrote:

> If the DNS was as unreliable as those words suggested, nobody would use it.

I see evidence of this unreliability every day, so I must respectfully disagree.

;>

> The reality is that everybody uses it.

The reality is that they don't really have a choice, now, do they?

;>

Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: [arin-announce] ARIN Resource Certification Update

2011-01-25 Thread Joe Abley

On 2011-01-25, at 01:25, Christopher Morrow wrote:

> On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins  wrote:
> 
>> 2.  The generally creaky, fragile, brittle, non-scalable state of the 
>> overall DNS infrastructure in general.
> 
> this is getting better, no? I mean for the in-addr and larger folks,
> anycast + lots of other things are making DNS much more reliable than
> it was 10 years ago... or am I living in a fantasy world?

I think "generally creaky" is right on. The DNS is a seething, living tangle of 
misconfigurations and protocol violations, which I think is to be expected 
given that it's so very distributed.

("I think we should deploy a database that is co-admined by many millions of 
people who don't know each other, all using different varieties of software. 
We'll make everything end-users do on the Internet depend on it. It'll be 
great.")

But I think "fragile", "brittle" and "non-scaleable" are demonstrably wrong. If 
the DNS was as unreliable as those words suggested, nobody would use it. The 
reality is that everybody uses it.

Joe

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Christopher Morrow

On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins  wrote:
>
> On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote:
>
>> thinking of using DNS is tempting
>
>
> The main arguments I see against it are:
>
> 1.      Circular dependencies.

in the end though... if you depend upon something off-box to get you
going, you're screwed.

What makes that slightly better, in the case of the planned work so
far (sidr work), is that the router feeds from an operator-decided
location (direct-link, pop-local, region-local, network-local,
neighbor-network). At initial boot time (for a long time probably)
having 'valid' routes is less important than 'some routes'. Failing to
'get routing up' before 'secureify things', I think is the goal.

With the ability to ratchet down the validation knob at operator
demand when they feel 'validated only'  is a good choice.

> 2.      The generally creaky, fragile, brittle, non-scalable state of the 
> overall DNS infrastructure in general.
>

this is getting better, no? I mean for the in-addr and larger folks,
anycast + lots of other things are making DNS much more reliable than
it was 10 years ago... or am I living in a fantasy world?

NOTE: I leave out unprepared (or under-prepared) end-sites wrt
dos/ddos ... though I suppose in last month's example: Mastercard.com
probably would have had (has?) their PTR records served from servers
on the same end-site as their attacked asset :( so that's a failure
mode to keep in mind (and extra things for operators at sites to keep
in mind as well).

> Routing and DNS, which are the two essential elements of the Internet control 
> plane, are e also its Achilles' heels.  It can be argued that making routing 
> validation dependent upon the DNS would make this situation worse.
>

to some extent it will be, folks won't revert to /etc/hosts for
getting to publication points, cache servers, etc ... BUT there are
timescales measured here not in 'milliseconds' but in hours.
Small-scale outages aren't as damaging, and if your cache infra is
planned such that once you get external data internally you can feed
all your regional/pop/etc caches from there, hopefully things are
simpler.

> The main reasons for it are those Danny stated:
>
> 1.      DNS exists.
>
> 2.      DNSSEC is in the initial stages of deployment.
>
> 3.      There's additional relevant work going on which would make DNS more 
> suitable for this application.
>
> 4.      Deployment inertia.
>

yea, but I see forking this into DNS as having to hack about in
something where it doesn't really fit well, and may end up with more
hackery after the initial thoughts of: "Ah! just toss some new RR foo
in there, sign with dnssec, win!"

now we have:
  o oh, and don't keep all of your DNS servers on your network, in
case of an outage.
  o don't forget about TTLs on records, how do you expire something?
(this is a perennial problem in dns...)
  o delegating of subnets around to customers, on gear they operate (or don't??)

There are likely more things to keep in mind as well.

-Chris

Re: [arin-announce] ARIN Resource Certification Update


On Jan 25, 2011, at 11:35 AM, Christopher Morrow wrote:

> thinking of using DNS is tempting


The main arguments I see against it are:

1.  Circular dependencies.

2.  The generally creaky, fragile, brittle, non-scalable state of the 
overall DNS infrastructure in general.

Routing and DNS, which are the two essential elements of the Internet control 
plane, are e also its Achilles' heels.  It can be argued that making routing 
validation dependent upon the DNS would make this situation worse.

The main reasons for it are those Danny stated:

1.  DNS exists.

2.  DNSSEC is in the initial stages of deployment.

3.  There's additional relevant work going on which would make DNS more 
suitable for this application.

4.  Deployment inertia.


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Christopher Morrow

On Mon, Jan 24, 2011 at 11:27 PM, Steven Bellovin  wrote:
>
> On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote:

>> it's not the best example, but I know that at UUNET there were plenty
>> of examples of the in-addr tree not really following the BGP path.
>>
> The other essential point is that routers don't do RPKI queries in
> real-time; rather, they have a copy of the entire RPKI database, which
> they update as needed.  In other words, the operational model doesn't
> fit the way the DNS works.

sure, I was just adding fuel to jabley's in-addr graphing. thinking of
using DNS is tempting, but there seem to be some corner cases that
would cause hackery, so why not try to do it 'right' originally
instead of using that shoe-horn?

-chris
(eh.. for the record, I do participate in the SIDR-wg which is trying
to do this with the rPKI, so I am a little biased I suppose)

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Steven Bellovin


On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote:

> On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley  wrote:
>> 
>> On 2011-01-24, at 20:24, Danny McPherson wrote:
>> 
>>> 
>>> Beginning to wonder why, with work like DANE and certificates in DNS
>>> in the IETF, we need an RPKI  and new hierarchical shared dependency
>>> system at all and can't just place ROAs in in-addr.arpa zone files that are
>>> DNSSEC-enabled.
> 
>> But what about this case?
>> 
>>  RIR allocates 10.0.0.0/8 to A
>>  A allocates 10.0.0.0/16 to B
>>  B allocates 10.0.0.0/24 to C
>> 
>> In this case the DNS delegations go directly from RIR to C; there's no 
>> opportunity for A or B to sign intermediate zones, and
>> hence no opportunity for them to indicate the legitimacy of the allocation.
> 
> it's not the best example, but I know that at UUNET there were plenty
> of examples of the in-addr tree not really following the BGP path.
> 
The other essential point is that routers don't do RPKI queries in
real-time; rather, they have a copy of the entire RPKI database, which
they update as needed.  In other words, the operational model doesn't
fit the way the DNS works.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Christopher Morrow

On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley  wrote:
>
> On 2011-01-24, at 20:24, Danny McPherson wrote:
>
>> 
>> Beginning to wonder why, with work like DANE and certificates in DNS
>> in the IETF, we need an RPKI  and new hierarchical shared dependency
>> system at all and can't just place ROAs in in-addr.arpa zone files that are
>> DNSSEC-enabled.

> But what about this case?
>
>  RIR allocates 10.0.0.0/8 to A
>  A allocates 10.0.0.0/16 to B
>  B allocates 10.0.0.0/24 to C
>
> In this case the DNS delegations go directly from RIR to C; there's no 
> opportunity for A or B to sign intermediate zones, and
> hence no opportunity for them to indicate the legitimacy of the allocation.

it's not the best example, but I know that at UUNET there were plenty
of examples of the in-addr tree not really following the BGP path.

-chris

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 9:21 PM, Richard Barnes wrote:
> The more you have to invent, though, the more this sounds like a
> bike-shed discussion.
> s/DNSSEC/X.509/g
> s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g

The difference is that we don't have an operational RPKI system, we 
do have an operational DNS one.  

It's most certainly NOT a bike shed discussion - at least with respect 
to how I'd configure my routers.

I suspect I've sufficiently chummed the waters, I'll kick back and absorb 
all the reasons this is a whack idea :)

-danny

Re: [arin-announce] ARIN Resource Certification Update

>> the folk who sign dns zones are not even in the same building as the
>> folk who deal with address space.
> I think the idea is to effectuate de-siloing in this space to the
> point that the DNS folks would make the appropriate delegations to the
> addressing folks, who would then proceed to create/administer their
> RRs/certs without further day-to-day reference to the DNS folks.

read more carefully.  i was responding to danny taking my bait of using
dns keying for resource keys.

randy

Re: [arin-announce] ARIN Resource Certification Update

On Jan 25, 2011, at 9:31 AM, Randy Bush wrote:

> the folk who sign dns zones are not even in the same building as the folk who 
> deal with address space.

I think the idea is to effectuate de-siloing in this space to the point that 
the DNS folks would make the appropriate delegations to the addressing folks, 
who would then proceed to create/administer their RRs/certs without further 
day-to-day reference to the DNS folks.

Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: [arin-announce] ARIN Resource Certification Update


On Jan 25, 2011, at 9:24 AM, Danny McPherson wrote:

>  So, are you suggesting the RPKI isn't going to rely on DNS at all?


In terms of organic, real-time route validation performed by routers - which it 
is assumed is an ultimate goal of rPKI, at some point in the future - one 
should hope this wouldn't be the case, yes?


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: [arin-announce] ARIN Resource Certification Update

> Right, I've heard the circular dependency arguments.  So, are you
> suggesting the RPKI isn't going to rely on DNS at all?

correct.  it need not.

> I'm of the belief RPKI should NOT be on the critical path, but instead
> focus on Internet number resource certification - are you suggesting
> otherwise?


see the word 'certification'?  guess where that leads.  pki.  add
resources and stir.

>> if the latter, then you have the problem that the dns trust model is
>> not congruent with the routing and address trust model.
> That could be easily fixed with trivial tweaks and transitive trust/
> delegation graphs that are, I suspect.

not bloody likely.  the folk who sign dns zones are not even in the same
building as the folk who deal with address space.  in large isps, not
even in the same town.

randy

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 9:14 PM, Randy Bush wrote:
> 
> you want certificates etc?  or did you plan to reuse dns keys?

I suspect the former, reusing much of the SIDR machinery 
perhaps, although

> if the former, than all you are discussing is changing the transport to
> make routing security rely on dns and dns security.  not a really great
> plan.

Right, I've heard the circular dependency arguments.  So, are
you suggesting the RPKI isn't going to rely on DNS at all?

I'm of the belief RPKI should NOT be on the critical path, but instead 
focus on Internet number resource certification - are you suggesting 
otherwise?

> if the latter, then you have the problem that the dns trust model is not
> congruent with the routing and address trust model.

That could be easily fixed with trivial tweaks and transitive trust/
delegation graphs that are, I suspect.

-danny

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Richard Barnes

On Mon, Jan 24, 2011 at 9:16 PM, Danny McPherson  wrote:
>
> On Jan 24, 2011, at 9:02 PM, Joe Abley wrote:
>>
>> In this case the DNS delegations go directly from RIR to C; there's no 
>> opportunity for A or B to sign intermediate zones, and hence no opportunity 
>> for them to indicate the legitimacy of the allocation.
>>
>> As a thought experiment, how would you see this working?
>
> New prefix-based RRs?  And perhaps even a new .arpa or
> in-addr.arpa subdomain, the draft Randy referenced even
> discussed the latter, IIRC.
>
> -danny

The more you have to invent, though, the more this sounds like a
bike-shed discussion.
s/DNSSEC/X.509/g
s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Richard Barnes

It's in-band only in the sense of delivery.  The worst that a
corruption of the underlying network can do to you is deny you
updates; it can't convince you that a route validates when it
shouldn't.  And even denying updates to your RPKI cache isn't that
bad, since the update process doesn't really need to be real-time.
Things will stay the same until you start hitting expiration times.
The ultimate worst case is that everything expires and there are no
RPKI-validated routes ... just like today.

--Richard



On Mon, Jan 24, 2011 at 9:11 PM, Roland Dobbins  wrote:
>
> On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote:
>
>> I just don't like the notion of deploying a brand new system with data that 
>> at the end of the day is going to look an awful lot like the existing 
>> in-addr.arpa delegation system that's deployed, and introduce new 
>> hierarchical shared dependencies that don't exist today.
>
>
> Right - so, the macro point here is that in order to make use of rPKI so as 
> to ensure the integrity of the global routing system, the presupposition is 
> that there's already sufficient integrity in said routing global system for 
> the rPKI tree to be successfully walked in the first place, given that it's 
> all in-band, right?
>
> And since it's all in-band, anyways, with the recursive dependencies that 
> implies, why not make use of another, pre-existing inband hierarchical system 
> which is explicitly designed to ensure the integrity of its answers, and 
> which is already in the initial stages of its deployment - i.e., DNSSEC?
>
> Note I'm not advocating this position, per se, just being sure I understand 
> the argument for purposes of discussion.
>
> 
> Roland Dobbins  // 
>
> Most software today is very much like an Egyptian pyramid, with millions
> of bricks piled on top of each other, with no structural integrity, but
> just done by brute force and thousands of slaves.
>
>                          -- Alan Kay
>
>
>

Re: [arin-announce] ARIN Resource Certification Update


On Jan 24, 2011, at 9:02 PM, Joe Abley wrote:
> 
> In this case the DNS delegations go directly from RIR to C; there's no 
> opportunity for A or B to sign intermediate zones, and hence no opportunity 
> for them to indicate the legitimacy of the allocation.
> 
> As a thought experiment, how would you see this working?

New prefix-based RRs?  And perhaps even a new .arpa or 
in-addr.arpa subdomain, the draft Randy referenced even 
discussed the latter, IIRC.

-danny

Re: [arin-announce] ARIN Resource Certification Update

> I just don't like the notion of deploying a brand new system 

you want certificates etc?  or did you plan to reuse dns keys?

if the former, than all you are discussing is changing the transport to
make routing security rely on dns and dns security.  not a really great
plan.

if the latter, then you have the problem that the dns trust model is not
congruent with the routing and address trust model.

randy

Re: [arin-announce] ARIN Resource Certification Update

On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote:

> I just don't like the notion of deploying a brand new system with data that 
> at the end of the day is going to look an awful lot like the existing 
> in-addr.arpa delegation system that's deployed, and introduce new 
> hierarchical shared dependencies that don't exist today. 

Right - so, the macro point here is that in order to make use of rPKI so as to 
ensure the integrity of the global routing system, the presupposition is that 
there's already sufficient integrity in said routing global system for the rPKI 
tree to be successfully walked in the first place, given that it's all in-band, 
right?

And since it's all in-band, anyways, with the recursive dependencies that 
implies, why not make use of another, pre-existing inband hierarchical system 
which is explicitly designed to ensure the integrity of its answers, and which 
is already in the initial stages of its deployment - i.e., DNSSEC?

Note I'm not advocating this position, per se, just being sure I understand the 
argument for purposes of discussion.

Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Joe Abley

On 2011-01-24, at 20:59, Danny McPherson wrote:

> On Jan 24, 2011, at 8:48 PM, Randy Bush wrote:
> 
>>> And now that DNSSEC is deployed
>> 
>> and you are not sharing what you are smoking
> 
> root and .arpa are signed, well on the way, particularly relative 
> to RPKI.
> 
> Incremental cost of signing in-addr.arpa using a deployed DNS 
> system as opposed to continuing development, deployment and 
> operationalizing and dealing with all the political issues with 
> deploying a new RPKI system -- hrmm.

IN-ADDR.ARPA will be signed relatively soon, as part of the work described here:

  http://in-addr-transition.icann.org/

Timeline to follow, here and other similar lists, some time relatively soon. 
But I'm curious about your thoughts on the case I mentioned in my last message. 
I don't think the existence of a secure delegation chain from the root down to 
operator of the last sub-allocated address block is all that is required, here.

Joe

Re: [arin-announce] ARIN Resource Certification Update

2011-01-24 Thread Joe Abley


On 2011-01-24, at 20:24, Danny McPherson wrote:

>  
> Beginning to wonder why, with work like DANE and certificates in DNS
> in the IETF, we need an RPKI  and new hierarchical shared dependency 
> system at all and can't just place ROAs in in-addr.arpa zone files that are 
> DNSSEC-enabled. 

In the case where (say)

 RIR allocates 10.0.0.0/8 to A
 A allocates 10.1.0.0/16 to B
 B allocates 10.1.1.0/24 to C

there's a clear path of delegations in the DNS under IN-ADDR.ARPA from RIR -> A 
-> B -> C and this matches the chain of address assignments. If you adopt the 
convention that a secure delegation (a signed DS RRSet) is analogous to an RPKI 
signature over a customer certificate, then this seems vaguely usable. 

But what about this case?

 RIR allocates 10.0.0.0/8 to A
 A allocates 10.0.0.0/16 to B
 B allocates 10.0.0.0/24 to C

In this case the DNS delegations go directly from RIR to C; there's no 
opportunity for A or B to sign intermediate zones, and hence no opportunity for 
them to indicate the legitimacy of the allocation.

As a thought experiment, how would you see this working?


Joe

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 8:48 PM, Randy Bush wrote:

>> And now that DNSSEC is deployed
> 
> and you are not sharing what you are smoking

root and .arpa are signed, well on the way, particularly relative 
to RPKI.

Incremental cost of signing in-addr.arpa using a deployed DNS 
system as opposed to continuing development, deployment and 
operationalizing and dealing with all the political issues with 
deploying a new RPKI system -- hrmm.

And again, I'm not opposed to RPKI and know we REQUIRE 
number resource certification before we can secure the routing 
system.  I just don't like the notion of deploying a brand new 
system with data that at the end of the day is going to look an 
awful lot like the existing in-addr.arpa delegation system that's 
deployed, and introduce new hierarchical shared dependencies 
that don't exist today.  Keep it simple?

-danny

Re: [arin-announce] ARIN Resource Certification Update

> And now that DNSSEC is deployed

and you are not sharing what you are smoking

> and DANE is happening

see above

randy

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 8:32 PM, Randy Bush wrote:

> let's wind the wayback machine to 1998
> 
>http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00

Yep, read that way back when it was posted initially, and again 
a short while back, makes good sense, methinks. 

And now that DNSSEC is deployed and DANE is happening, 
you could even include certificates there in the event that relying 
parties want to employ them for dynamic secure routing in the 
future and we wouldn't have to build (or deal with the operational 
and political hurdles that are sure to arise) with RPKI at all.

-danny

Re: [arin-announce] ARIN Resource Certification Update

> Beginning to wonder why, with work like DANE and certificates in DNS
> in the IETF, we need an RPKI and new hierarchical shared dependency
> system at all and can't just place ROAs in in-addr.arpa zone files
> that are DNSSEC-enabled.

let's wind the wayback machine to 1998

http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00

randy

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 7:16 PM, Randy Bush wrote:
> 
> i understand fearing holding others' private keys and critical data.  no
> blame there.
> 
> 
> but out of curiousity, how reality based are arin's general liability
> fears?  in the last few years, how many times has arin been a named
> defendant in a law suit?  how many times a [principal] plaintiff?

How many times has the operational integrity of ARIN's infrastructure 
influenced actual routing on the Internet in the past?  Seems like
well-placed concern on behalf of the ARIN BoT, IMO.

Beginning to wonder why, with work like DANE and certificates in DNS
in the IETF, we need an RPKI  and new hierarchical shared dependency 
system at all and can't just place ROAs in in-addr.arpa zone files that are 
DNSSEC-enabled. 

--but very happy we have some progress for Internet number resource 
certification.

-danny

Re: Fwd: [arin-announce] ARIN Resource Certification Update