Hi,
Just wanted to clarify a few things about the ROVER approach. One key misunderstanding seems to
be that ROVER is an approach for enumerating all potentially valid routes. This is not the case. Slides
on ROVER are posted for the NANOG 55 talk and there was an additional Lightning talk Monday in NANOG
A good summary of misunderstandings are listed below and addressed below:
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.
ROVER's operational model is ask a question and get an answer. ROVER is not
an enumeration method. RPKI does provide enumeration, but ROVER is not trying to
duplicate RPKI.
I think the first step is to step back and ask whether every operational model needs
enumeration. For example, the talk yesterday by Level3 used the DNS and IRR
did not need such an enumeration. Enumeration is not a goal in itself.
There are number of operational models that provide the needed routing protection
without enumeration.
- 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.
Or a simpler approach that does not require bulk zone transfers or zone walking is
simply DNS caching, which already exists and is well understood.
More broadly, whether one calls its a cache or RPKI validator or whatever, you
can build it with redundancy. One can certainly make either system work across
network outages.
- 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.
The focus is on origin and sub prefix hijacks. There are certainly discussions and
early experiments with future additions, but the work is focused on origin/subprefix
events.
- 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.
This is a misunderstanding of the ROVER approach.
Multiple copies of the data do not exist in multiple zones. There is a one-to-one mapping
between a prefix and a DNS name. The resolver simply finds the data and has no need to
understand where zone cuts occur.
On the other hand, DNS administrators do care about how they make zone cuts and delegate to
their customers. They can take a /16 and delegate two /17's, or they can manage the whole thing
in a single zone. Their choice.
A resolver simply issues a query for the unique DNS name associated with a prefix. This could be
done with anything from a complex tool set to a simply command line tool like dig.
The confusion here may arise from what happens if you get an *authenticated* response
saying there is no routing data at this name. This could mean 1) the prefix should not be announced
or 2) the reverse DNS happens to be signed with DNSSEC but the site is not participating in
routing security via DNS.
To determine this, you issue a second query. Is an RLOCK present along with the DNSKEY
used to sign the data? The existence of an RLOCK proves participation.
- 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
I strongly disagree with this. ROVER does use a naming convention.
This is simply a convention, not a protocol change. The best analogy here is
that one may have an internal naming convention for naming routers or particular
servers or so forth. You should follow this convention and build this into your
provisioning scripts where appropriate.
Clearly it is enormously better if there is a consistent way to name prefixes so
we have a common convention for naming the data. Everyone putting data in
is using the convention and we are working to get the convention standardized.
The convention is also useful for storing data at prefixes; geolocations is one example.
(conflicting data for same prefix can appear
in multiple zones, relying party has to sort this out, yum).
Again, this is simply a naming convention. There is a unique name for a prefix.
To DNS, this is a name like any other name. A DNS name belongs to a zone. It
cannot appear in multiple zones. The prefix has a unique name. The name
cannot appear in multiple zones.
ROVER is not trying to do exactly what RPKI is doing. Much of this seems to be an
attempt to build a form of enumeration into ROVER. See the Level3 NANOG talk
from Monday (6/4/12) for a concrete example of a different model. There are many different
operational models. We seek a common convention for data publishing, but believe
strongly there can and should be different operational models for how you do
validation in your network.
Thanks,
Dan and Joe
