Mailing List Archive

"ah, the force is strong in this one."

On 2012-05-30 3:52 AM, Shane Amante wrote:
> On May 29, 2012, at 9:23 AM, Alex Band wrote:
>> ...
>>
>> As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)
> Actually, I believe it does. Specifically, there are two types of DNS RR's:
> a) RLOCK: Route Lock
> b) SRO: Secure Route Origin
> Please refer to the following URL for definitions of each: <http://tools.ietf.org/html/draft-gersch-grow-revdns-bgp-00#section-3>.

as dns is an unreliable protocol, and is not atomic across multiple
questions, what is the effect of seeing one of those rrsets but not the
other? (here again we see the disadvantage of starting from incomplete
information.)

On 2012-05-30 4:24 AM, Shane Amante wrote:
> On May 29, 2012, at 8:44 PM, Paul Vixie wrote:
>> ...
>>
>> the problem is in time domain bounding of data validity and data
>> reachability. ROVER expects you to be able to query for the information
>> about a route at the time you receive that route. that's point-in-time
>> validity and reachability, which you might not have depending on where
>> the DNS servers are and what order you're receiving routes in. RPKI+ROA
>> expects you to have periodic but complete access to a catalogue, and
>> then your future use of the data you fetched has only the risk of
>> staleness or invalidity, but never reachability.
>>
>> as others have stated, there is no reference collection of bad ideas.
>> otherwise we would have written this one up in 1996 when a couple of dns
>> people looked at the routing system and said 'hey what about something
>> like [ROVER]?' and the routing people explained in detail why it
>> wouldn't work.
> Just one correction to the above. As pointed out in Section 4 of draft-gersch-grow-revdns-bgp-00 "near-real-time route origin verification" is merely one instantiation of the "ROVER concept". Please refer to that section for other potential uses of such published data.

my comment on that draft was (on the dnsop mailing list, march 10, 2012):

> your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the
> draft and the design are of admirable quality. as a co-author of RFC
> 2317 i agree that it does not suit the needs of bgp security since it
> seeks only to provide a method of fully naming hosts, not networks.
>
> importantly, i see no reference to RFC 1101 in your draft. RFC 1101
> describes a way to name networks, and while at first it did not seem to
> be compatible with CIDR, implementation (in "netstat -r" back in BSD/OS
> 3.1) showed that RFC 1101 was in fact not as classful as it appeared.
...
> you may find that some of your work has already been done for you, or,
> you may find that this is related work that should be referenced in your
> draft along with the reasons why your proposed method is necessary.

joe and dan (authors of this draft) responded:

> thanks for your comments and support. We will definitely reference RFC draft 1101 in our next version.

and indeed this was done, but weakly:

> Changes from version 01 to 02
...
> Expanded the related work discussion to include RFC 1101.

looking at draft -02 we see:

> 4.1. Naming via RFC 1101
>
> The problem of associating records with network names dates back to
> at least [RFC1101]. This work coincides with some of the early
> development of DNS and discusses issues regarding hosts.txt files.
> The RFC observation makes a key observation that one should provide
> "mappings for subnets, even when nested".
>
> The approach taken here clearly states how to map an IPv4 prefix that
> is on an octet boundary. The RFC maps "10.IN-ADDR.ARPA for class A
> net 10, 2.128.IN-ADDR.ARPA for class B net 128.2, etc." This is
> essentially the same as the approach proposed here, although we
> append an "m" label (discussed later in this document).
>
> [RFC1101] also mentions more specific subnets, but the details are
> limited. We believe the approach proposed here builds on the best
> ideas from this RFC and expands on the details of how the naming
> convention would work.

in other words no explaination for why the existing RFC 1101 encoding
will not serve, even though RFC 1101 encoding been used for network
naming in the CIDR era, without limitation.

this reader is left wondering, what's the real impetus here?

> I would also ask people to expand their minds beyond the "it must have a (near-)real-time mechanism" directly coupled to the Control Plane" for a variety of reasons. Such a tight coupling of /any/ two systems inevitably, and unfortunately, will only fail at scale in ways that likely would never have been predicted a priori[1] --

i think you're paying insufficient attention to this discussion, if you
think that failure predictions have not already been well made with
respect to the rover approach to routing security.

> ...
>
> [1] FWIW, Dave Meyer has been doing some thinking about "complexity" for a while now, drawing analogies from outside of networking/computing, and has some fascinating insight. I'm sure if there's enough interest, he'd be willing to discuss it. Who knows, we may even learn something. :-)

see also <http://queue.acm.org/detail.cfm?id=1242499>.

paul

>> I would also ask people to expand their minds beyond the "it must
>> have a (near-)real-time mechanism" directly coupled to the Control
>> Plane" for a variety of reasons. Such a tight coupling of /any/ two
>> systems inevitably, and unfortunately, will only fail at scale in
>> ways that likely would never have been predicted a priori[1] --
> i think you're paying insufficient attention to this discussion, if
> you think that failure predictions have not already been well made
> with respect to the rover approach to routing security.

rfc 3439, the most complex document about simplicity you can imagine

randy

Another difference between RPKI and ROVER which hasn't come up much:

RPKI incorporates a lot of pre-existing machinery from X.509 et al.
This drags in some tedious detail which makes people's eyes cross, but
it gives us some tools which simply aren't available in DNS at
present. In particular, X.509's CRL mechanism combined with the way
that RPKI uses CMS messages with single-use EE certificates means that
in RPKI we have a way to revoke individual objects (eg, ROAs) at will.
DNSSEC only just barely has revocation at all, and that only for
DNSKEYs. The nearest equivalent to per-object revocation one could do
in DNSSEC would be either:

- generate a new ZSK, re-sign everything in the zone with the new
ZSK except for the RRsets you want to get rid of, and revoke the
old ZSK, or

- keep as many distinct ZSKs in the zone as you intend to have
distinctly revocable groups of objects in the zone, and make sure
you sign the right objects with the right ZSKs.

Neither of these solutions is very good: the first may involve
re-signing a lot of data every time you change anything, while the
latter is complex and tends to bloat the zone's apex DNSKEY RRset.

I suppose a third option would be to make every DNS owner name in the
reverse tree be a separate zone. Doesn't seem like an improvement.

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.

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

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

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

- 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 (conflicting data for same prefix can appear
in multiple zones, relying party has to sort this out, yum).

As far as I can tell, ROVER doesn't solve any of the hard problems in
RPKI. It's a different encoding of a partial subset of the data, with
some of the features removed.

On Mon, 28 May 2012, David Conrad wrote:

> As far as I can tell, ROVER is simply Yet Another RPKI Access Method
> like rsync and bittorrent with its own positives and negatives.

Not quite. ROVER's SRO & RLOCK statements have different semantics
than RPKI ROAs, and there are semantics that may not be (practically)
expressible in ROVER.

ROVER's semantics depend on DNS zone structure. The protection
offered by the RLOCK statement stops when a zone cut is reached --
longer routes are allowed unless there's an RLOCK in every descendant
zone. Having DNS users care about zone structure is, to quote Rob
Austein, "not normal".

-- Sam Weiler