rpki vs. secure dns?

Alex Band alexb at ripe.net
Sat Apr 28 08:19:39 CDT 2012


On 28 Apr 2012, at 14:57, Stephane Bortzmeyer wrote:

> On Sat, Apr 28, 2012 at 12:34:52PM +0200,
> Alex Band <alexb at ripe.net> wrote 
> a message of 41 lines which said:
> 
>> In reality, since the RIRs launched an RPKI production service on 1
>> Jan 2011, adoption has been incredibly good (for example compared to
>> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
>> world-wide have opted-in to the system and requested a resource
>> certificate using the hosted service, or running an open source
>> package with their own CA. 
> 
> I have an experience with the deployment of DNSSEC and the problem
> with DNSSEC was not to have signed zones (many are, now) but to have
> people *using* these signatures to check the data (i.e. validating in
> a resolver).
> 
> RPKI has many ROA (signed objects) but how many operators validate
> routes on their production routers? Zero?

First you need a robust system and reliable data. Native router support is coming along. We could be getting to a stage where people will use the data in production. Time will tell...

>> But it's not just that, these ISPs didn't just blindly get
>> certificate and walk away.
> 
> Most of the ROAs are very recent. Again, the experience with DNSSEC
> shows that starting is easy ("DNSSEC in siw minutes"). It's long term
> management which is *the* problem. Wait until people start to change
> the routing data and watch the ROAs becoming less and less correct...
> 
>> Data quality is really good. 
> 
> It's not what you said:
> 
> "It is safe to say that overall data quality is pretty bad"
> <https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-real-world> 
> (good paper, by the way, thanks)

A lot has changed since I wrote that. :)

-Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2355 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120428/ea595021/attachment.bin>


More information about the NANOG mailing list