Re: ROVER routing security - its not enumeration

[Christopher Morrow <morrowc.lists () gmail com>]

On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey <massey () cs colostate edu> wrote:

> 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.

which are?

I can see a use-case for something like:
  "Build me a prefix list from the RIR data"

which is essentially:
  1) pull IRR data for customer-X
  2) validate all entries with 'resource certification' data
  3) deploy new filter to edge-link-to-customer-X (only if changes occur)
(shane seems to point at this as the method in question...)

I think this means that the customer here has to keep updated their
DNS data and their IRR data, and in the case (today) of 'ROVER'
getting no-answer, the customer skates... (no validation is possible).

I'm not sure you can extend usage of 'ROVER' to things which are not
'offline processed' though, and it's not clear to me that the
fail-open answer is good for us, absent some signal that 'customer-x
will not be playing today'.

> > - 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.

caching implies that:
  1) the cache is filled
  2) the timeout on records is longer than the outage(s)
  3) the timeout is still short-enough to meet user change requirements

> > - 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

in somewhat real-time on the router (get update, lookup dns records,
decide)? or via offline compute and peer filter-updates?

> > - 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

1.23.45.10.in-addr.arpa.
<rover prefix entry-10.45/16>

that's 2 copies... what about:
1.23.45.10.in-addr-arpa.
<rover-covering-route entry>
<rover-customer-allocation-10.45.16/19>
<rover-customer-of-customer-allocation-10.45.23/24>

that's 4 copies.

> between a prefix and a DNS name.  The resolver simply finds the data and has no need to
> understand where zone cuts occur.

don't I have to walk up the tree a few times in the above example
though? "Is this the covering route? the customer route? the
customer-of-customer-route? the-hijack? Wait, no RLOCK, so this was a
giant waste of time..."

> 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.

'resolver' here is what? router? unix-y-box-thing doing
filter-generation? near-line-query/response-box for
router-real-time-lookup?

> The convention is also useful for storing data at prefixes; geolocations is one example.

not to nit-pick, but near as I can tell no one uses the geoloc entries
in dns... also they aren't very well kept up to date by those few who
actually do put them into dns :(

> > (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.

10.45.23.0/24
10.45.16.0/19
10.45.0.0/16
10.0.0.0/8

> 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

you referenced this a few times:
  <http://www.nanog.org/meetings/nanog55/agenda.php>

doesn't mention a talk from L3 on 6/4 ... got link?

-chris