rpki vs. secure dns?

Wed May 30 05:06:50 UTC 2012

"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