rpki vs. secure dns?
Rob Austein
sra+nanog at hactrn.net
Fri Jun 1 19:18:09 UTC 2012
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.
More information about the NANOG
mailing list