[153386] in North American Network Operators' Group
Re: ROVER routing security - its not enumeration
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Tue Jun 5 15:29:00 2012
In-Reply-To: <B394E03B-B833-4824-9ED5-C84D2B35F8F7@cs.colostate.edu>
Date: Tue, 5 Jun 2012 15:28:18 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Daniel Massey <massey@cs.colostate.edu>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey <massey@cs.colostate.edu> wro=
te:
> did not need such an enumeration. =A0 =A0 Enumeration is not a goal in it=
self.
> There are number of operational models that provide the needed routing pr=
otection
> 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. =A0Helical dependencies can be
>> =A0 made to work, but this says that one probably should not be
>> =A0 depending on routing to make a point query to make decisions about
>> =A0 routing. =A0If you look at the architecture of the existing RPKI
>> =A0 validators (well, mine and BBN's, anyway, not sure about RIPE's but
>> =A0 suspect they took the same approach), we've gone to some trouble to
>> =A0 make sure that the validator will continue to work across network
>> =A0 outages as long as the collected data haven't expired or been
>> =A0 revoked. =A0In theory one could do the same thing with bulk transfer=
s
>> =A0 of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it
>> =A0 would not work well with point queries.
>
> Or a simpler approach that does not require bulk zone transfers or zone w=
alking 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
>> =A0 to origin validation. =A0RPKI can certify both prefixes and ASNs,
>> =A0 which gives it the basics needed to support path validation as well
>> =A0 as origin validation. =A0ASNs have no hierarchical structure, thus
>> =A0 would be a very poor match for encoding as DNS names.
>
> The focus is on origin and sub prefix hijacks. =A0 =A0 There are certainl=
y 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. =A0In
>> =A0 particular, as currently specified ROVER requires the relying party
>> =A0 to pay attention to DNS zone cuts, which is not normal in DNS (the
>> =A0 basic DNS model since RFC 883 has been that zones are something for
>> =A0 the zone administrator to worry about, resolvers mostly just see a
>> =A0 tree of RRsets). =A0ROVER requires the relying party to check for th=
e
>> =A0 same data in multiple zones and pay close attention to zone cuts.
>> =A0 While it is certainly possible to do all this, it is not a matter of
>> =A0 issuing a simple DNS query and you're done. =A0DNS caching effects c=
an
>> =A0 also complicate matters here if the zone structure is changing:
>> =A0 think about what happens if you have cached responses to some (but
>> =A0 not all) of the queries you need to make to figure out whether to
>> =A0 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. =A0There 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. =A0The resolver simply finds the data an=
d 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. =A0 =A0This 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
>> =A0 in multiple zones, relying party has to sort this out, yum).
>
> Again, =A0this is simply a naming convention. =A0 =A0There is a unique na=
me for a prefix.
> To DNS, =A0this is a name like any other name. =A0 A DNS name belongs to =
a zone. =A0 =A0It
> cannot appear in multiple zones. =A0 =A0 The prefix has a unique name. =
=A0 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. =A0Much of this see=
ms to be an
> attempt to build a form of enumeration into ROVER. =A0 =A0See the Level3 =
NANOG talk
> from Monday (6/4/12) for a concrete example of a different model. =A0 =A0=
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
