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