Fwd: [arin-announce] ARIN Resource Certification Update
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@arin.net<mailto:jcurran@arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce@arin.net<mailto:arin-announce@arin.net>" <arin-announce@arin.net<mailto:arin-announce@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@arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
thanks john. your consideration to the ops community is appreciated.
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.
way cool. and there are open source tool-sets the isps can run to handle their resources, generate roas, ...
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.
i understand fearing holding others' private keys and critical data. no blame there. <separate subject> 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? randy
On Jan 24, 2011, at 7:16 PM, Randy Bush wrote:
i understand fearing holding others' private keys and critical data. no blame there.
<separate subject> 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. <separate subject> 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
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
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
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
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
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> 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
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 <rdobbins@arbor.net> 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 <rdobbins@arbor.net> // <http://www.arbornetworks.com>
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
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
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
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?
<channeling steve kent> 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
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> 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
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
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> 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
On 2011-01-24, at 20:24, Danny McPherson wrote:
<separate subject> 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
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
On Mon, Jan 24, 2011 at 9:16 PM, Danny McPherson <danny@tcb.net> 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
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
On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-01-24, at 20:24, Danny McPherson wrote:
<separate subject> 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.
<snip>
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
On Jan 24, 2011, at 10:31 30PM, Christopher Morrow wrote:
On Mon, Jan 24, 2011 at 9:02 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-01-24, at 20:24, Danny McPherson wrote:
<separate subject> 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.
<snip>
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
On Mon, Jan 24, 2011 at 11:27 PM, Steven Bellovin <smb@cs.columbia.edu> 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)
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> 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
On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins <rdobbins@arbor.net> 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
On 2011-01-25, at 01:25, Christopher Morrow wrote:
On Mon, Jan 24, 2011 at 11:52 PM, Roland Dobbins <rdobbins@arbor.net> 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
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> 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
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.
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@arin.net<mailto:jcurran@arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce@arin.net<mailto:arin-announce@arin.net>" <arin-announce@arin.net<mailto:arin-announce@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@arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
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
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@arin.net<mailto:jcurran@arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce@arin.net<mailto:arin-announce@arin.net>" <arin-announce@arin.net<mailto:arin-announce@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@arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
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):
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@arin.net<mailto:jcurran@arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce@arin.net<mailto:arin-announce@arin.net>" <arin-announce@arin.net<mailto:arin-announce@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@arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
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. 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. - 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 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. 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. Have a great day! Carlos On Sat, Jan 29, 2011 at 11:52 PM, Owen DeLong <owen@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):
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@arin.net<mailto:jcurran@arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce@arin.net<mailto:arin-announce@arin.net>" <arin-announce@arin.net<mailto:arin-announce@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@arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
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@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):
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@arin.net<mailto:jcurran@arin.net>> Date: January 24, 2011 2:58:52 PM EST To: "arin-announce@arin.net<mailto:arin-announce@arin.net>" <arin-announce@arin.net<mailto:arin-announce@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@arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
- 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 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.
I am already trusting RIPE with my data - specifically, RIPE publishes route objects for my prefixes, and my transit providers generate their prefix lists based on these route objects. I fail to see how a hosted RPKI solution would make this situation worse. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Jan 30, 2011, at 8:28 AM, sthaug@nethelp.no wrote:
- 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 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.
I am already trusting RIPE with my data - specifically, RIPE publishes route objects for my prefixes, and my transit providers generate their prefix lists based on these route objects. I fail to see how a hosted RPKI solution would make this situation worse.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Because they publish data you have signed. They don't have the ability to modify the data and then sign that modification as if they were you if they aren't holding the private key. If they are holding the private key, then, you have, in essence, given them power of attorney to administer your network. If you're OK with that, more power to you. It's not the trust model I would prefer. Owen
Hey!
Steinar Haug, Nethelp consulting, sthaug@nethelp.no Because they publish data you have signed. They don't have the ability to modify the data and then sign that modification as if they were you if they aren't holding the private key. If they are holding the private key, then, you have, in essence, given them power of attorney to administer your network.
If you're OK with that, more power to you. It's not the trust model I would prefer.
I think that is the whole point. Hosted is fine with some, top-down will be preferred by others. Will top-down be intrinsically more secure than hosted? I am tempted to say yes, but I have some doubts on that too. What top-down certainly does is getting you out of the lawyers' sights. Mostly anyways.
Owen Carlos
On Sun, Jan 30, 2011 at 12:40 PM, Owen DeLong <owen@delong.com> wrote:
Because they publish data you have signed. They don't have the ability to modify the data and then sign that modification as if they were you if they aren't holding the private key. If they are holding the private key, then, you have, in essence, given them power of attorney to administer your network.
If you're OK with that, more power to you. It's not the trust model I would prefer.
I suspect that many users would prefer to trust ARIN with their private keys, if offered that choice. The reasons are simple; adoption will be more wide-spread if RPKI is easier to do; and as we all know, there are an awful lot of BGP networks which are: * on auto-pilot, with no clued in-house staff and no stable relationships with outside clue * driven by people who are somewhere between totally clueless and capable of understanding public-key encryption * driven by over-worked people who simply don't have time for another to-do of any complexity Many users would benefit from the kind of hosted service that is made available by, for example, RIPE. In fact, if they felt they could trust ARIN (or any alternative service which may exist), most of my clients would be perfectly fine with such a service, and I would not advise them to do otherwise without a valid business reason and a belief that equal or superior security would be provided by not using such a hosted service. Since ARIN holds ultimate authority over the ISP's address space anyway, if ARIN's private keys become compromised, whether or not you held onto your own keys will not matter to the rest of the world. If I understand correctly, John has expressed that ARIN's concern is they may be sued if their hosted service fails to perform, and that ordinary contractual language may be unable to limit damages if the reality is that the service-customer has no other choice but to use the ARIN service. This is clearly not a legitimate concern if there is an alternative to such an ARIN hosted service, such as using no hosted service at all, or the possibility of using another one. I don't see how the lack of ARIN providing a hosted service immediately in any way prevents them from doing so in the future. If widespread RPKI adoption doesn't happen and a few more accidental or intentional YouTube black-holes do happen, it seems likely that stakeholders will encourage ARIN to do more, and a hosted service would be an obvious step to increase adoption. As you know, my comfort level with ARIN handling tasks of an operational nature is not high; but if they are going to participate in RPKI in any way, I think they should be capable of performing similarly to RIPE. If not, we should be asking ourselves either 1) why would anyone trust RIPE with their keys; or 2) why is RIPE more trustworthy than ARIN? If the answer to that is RIPE is significantly more competent than ARIN (most folks I know are of this belief) then this discussion should not be about one technical effort. Instead, it should be about how to make ARIN better. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
From: Alex Band <alexb@ripe.net> 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
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 <alexb@ripe.net> 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
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 <alexb@ripe.net> 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 <alexb@ripe.net> 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
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
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
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-SSLivers... 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.
In message <4D457F0E.7070805@consolejunkie.net>, Leen Besselink writes:
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-SSLivers... -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.
Every validating recursive nameserver on the planet can be configured to do exactly that. Just install the root's keys and don't install any others. You won't be able to validate as secure data from security islands but that is what you want and is becoming less necessary as TLD start to get signed and accept DS records.
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.
A user can turn on DNSSEC any time they want to. Some ISPs have already turned on DNSSEC in their customer facing resolvers.
* 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.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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.
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-2222 ext. 4419 Carlos Martinez Cagnazzo <carlos@lacnic.net>
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
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
From: Alex Band <alexb@ripe.net> Date: Sun, 30 Jan 2011 11:39:36 +0100
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?
i think we may be talking past each other. the number of production validators will be unrelated to any difference between "prefixes signed because signing is easy" and "prefixes signed because operators are willing to do something hard." the operators who will sign even if it's hard (for example, deploying up/down) and also the operators who will only do it if it's easy (for example, hosted at an RIR) will each not care how many production validators there are at that moment -- their decision will be made on some other basis.
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."
the reasoning you're describing is what we had in mind when we built DLV as an early deployment aid for DNSSEC. we had to "break stiction" where if there were no validators there would be incentive to sign, and if there were no signatures there would be no incentive to validate. are you likewise proposing the hosted solution only as an early deployment aid? i'm really quite curious as to whether you'll continue operating an RPKI hosting capability even if it becomes unnec'y (as proved some day if many operators of all sizes demonstrate capability for up/down). if so, can you share the reasoning behind that business decision? i know it sounds like i'm arguing against a hosted solution, but i'm not. i'm just saying that network operators are going to make business decisions (comparing cost and risk to benefit) as to whether to sign and whether to validate, and RIR's are going to make business decisions (comparing cost and risk to benefit) as to what provisioning mode to offer, and i don't plan to try to tell any network operators to sign or validate based on my own criteria, nor do i plan to try to tell any RIR that they should host or do up/down based on my own criteria. it's their own criteria that matters. let's just get the best starting conditions we can get, and then expect that everybody will make the best decision they can make based on those conditions. at ISC i have been extremely interested in participating in RPKI development and i think that sra and randy (and the whole RPKI team inside IETF and among the RIRs) have done great work improving the starting conditions for anyone who has to make a business decision of whether to deploy and if so what mode to deploy in. on the ARIN BoT i have likewise been very interested in and supportive of RPKI and i'm happy to repeat john curran's words which were, ARIN is looking at the risks and benefits of various RPKI deployment scenarios, and we expect to do more public and member outreach and consultation at our upcoming meeting in san juan PR. Paul Vixie Chairman and Chief Scientist, ISC Member, ARIN BoT re:
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. ...
On 31 Jan 2011, at 04:25, Paul Vixie wrote:
the reasoning you're describing is what we had in mind when we built DLV as an early deployment aid for DNSSEC. we had to "break stiction" where if there were no validators there would be incentive to sign, and if there were no signatures there would be no incentive to validate. are you likewise proposing the hosted solution only as an early deployment aid?
We primarily offer hosting it is something our community want. You can now see in the adoption numbers that is true. It makes the entry barrier into the system as low as possible, which – apart from being a good thing in itself – aids deployment.
i'm really quite curious as to whether you'll continue operating an RPKI hosting capability even if it becomes unnec'y (as proved some day if many operators of all sizes demonstrate capability for up/down). if so, can you share the reasoning behind that business decision?
We're building and maintaining this with membership fees. Why would we keep something operational our members no longer want and need using their money? I sincerely doubt we'll ever get to that point soon, but we'll see. -Alex Band
participants (21)
-
Alex Band -
Arturo Servin -
Carlos M. Martinez -
Carlos Martinez-Cagnazzo -
Carlos Martinez-Cagnazzo
-
Charles N Wyble -
Christopher Morrow -
Danny McPherson -
Jeff Wheeler -
Joe Abley -
John Curran -
Leen Besselink -
Mark Andrews -
Owen DeLong -
Paul Vixie -
Randy Bush -
Richard Barnes -
Roland Dobbins -
Steven Bellovin -
sthaug＠nethelp.no -
Valdis.Kletnieks＠vt.edu