ROVER routing security - its not enumeration

[Daniel Massey <massey () cs colostate edu>]

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