[153377] in North American Network Operators' Group
ROVER routing security - its not enumeration
daemon@ATHENA.MIT.EDU (Daniel Massey)
Tue Jun 5 14:43:36 2012
From: Daniel Massey <massey@cs.colostate.edu>
Date: Tue, 5 Jun 2012 12:42:45 -0600
To: nanog@nanog.org
Cc: Daniel Massey <massey@cs.colostate.edu>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi,
Just wanted to clarify a few things about the ROVER approach. One key =
misunderstanding seems to=20
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=20
=20
A good summary of misunderstandings are listed below and addressed =
below:
> Summarizing a few other things other people have mentioned:
>=20
> - 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=20
an enumeration method. RPKI does provide enumeration, but ROVER is =
not trying to=20
duplicate RPKI.
I think the first step is to step back and ask whether every operational =
model needs=20
enumeration. For example, the talk yesterday by Level3 used the DNS =
and IRR=20
did not need such an enumeration. Enumeration is not a goal in =
itself. =20
There are number of operational models that provide the needed routing =
protection=20
without enumeration. =20
> - 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. =20
More broadly, whether one calls its a cache or RPKI validator or =
whatever, you=20
can build it with redundancy. One can certainly make either system =
work across=20
network outages. =20
> - 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=20
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.
>=20
This is a misunderstanding of the ROVER approach. =20
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. =20
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. =20
To determine this, you issue a second query. Is an RLOCK present =
along with the DNSKEY=20
used to sign the data? The existence of an RLOCK proves =
participation.
=20
> - 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=20
I strongly disagree with this. ROVER does use a naming convention. =20=
This is simply a convention, not a protocol change. The best analogy =
here is=20
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. =20
Clearly it is enormously better if there is a consistent way to name =
prefixes so=20
we have a common convention for naming the data. Everyone putting =
data in=20
is using the convention and we are working to get the convention =
standardized. =20
The convention is also useful for storing data at prefixes; geolocations =
is one example. =20
> (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=20
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=20
attempt to build a form of enumeration into ROVER. See the Level3 =
NANOG talk=20
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
=20=
