Another difference between RPKI and ROVER which hasn't come up much: RPKI incorporates a lot of pre-existing machinery from X.509 et al. This drags in some tedious detail which makes people's eyes cross, but it gives us some tools which simply aren't available in DNS at present. In particular, X.509's CRL mechanism combined with the way that RPKI uses CMS messages with single-use EE certificates means that in RPKI we have a way to revoke individual objects (eg, ROAs) at will. DNSSEC only just barely has revocation at all, and that only for DNSKEYs. The nearest equivalent to per-object revocation one could do in DNSSEC would be either: - generate a new ZSK, re-sign everything in the zone with the new ZSK except for the RRsets you want to get rid of, and revoke the old ZSK, or - keep as many distinct ZSKs in the zone as you intend to have distinctly revocable groups of objects in the zone, and make sure you sign the right objects with the right ZSKs. Neither of these solutions is very good: the first may involve re-signing a lot of data every time you change anything, while the latter is complex and tends to bloat the zone's apex DNSKEY RRset. I suppose a third option would be to make every DNS owner name in the reverse tree be a separate zone. Doesn't seem like an improvement. Summarizing a few other things other people have mentioned: - The normal operating mode with RPKI is to fetch everything rather than do a point query. We've spent the last decade or so making that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead of NSEC, etc). This makes it fairly difficult to know in advance what queries one should be asking ROVER (as Paul Vixie puts it, ROVER isn't a catalogue). When I pressed the ROVER folks about this at the Paris IETF meeting, they mumbled something about maybe walking the IRR or other external databases as a way of knowing what DNS queries to issue. - Circular dependencies are a problem. Helical dependencies can be made to work, but this says that one probably should not be depending on routing to make a point query to make decisions about routing. If you look at the architecture of the existing RPKI validators (well, mine and BBN's, anyway, not sure about RIPE's but suspect they took the same approach), we've gone to some trouble to make sure that the validator will continue to work across network outages as long as the collected data haven't expired or been revoked. In theory one could do the same thing with bulk transfers of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it would not work well with point queries. - ROVER gives us no traction on path validation (BGPSEC), it's limited to origin validation. RPKI can certify both prefixes and ASNs, which gives it the basics needed to support path validation as well as origin validation. ASNs have no hierarchical structure, thus would be a very poor match for encoding as DNS names. - Some of the DNS aspects of ROVER are a little strange. In particular, as currently specified ROVER requires the relying party to pay attention to DNS zone cuts, which is not normal in DNS (the basic DNS model since RFC 883 has been that zones are something for the zone administrator to worry about, resolvers mostly just see a tree of RRsets). ROVER requires the relying party to check for the same data in multiple zones and pay close attention to zone cuts. While it is certainly possible to do all this, it is not a matter of issuing a simple DNS query and you're done. DNS caching effects can also complicate matters here if the zone structure is changing: think about what happens if you have cached responses to some (but not all) of the queries you need to make to figure out whether to allow a more specific route punched out of a larger prefix block. - The reuse of existing infrastructure argument for ROVER is somewhat disingenuous -- it's only partial reuse of existing infrastructure. ROVER's new encoding of prefixes as DNS names means that a lot of new stuff would need to be deployed, and attempting to be backwards compatible with the existing DNS reverse tree adds some complexity to ROVER's architecture (conflicting data for same prefix can appear in multiple zones, relying party has to sort this out, yum). As far as I can tell, ROVER doesn't solve any of the hard problems in RPKI. It's a different encoding of a partial subset of the data, with some of the features removed.