Subject: DNS as a means to distribute the IRR

From: Curtis Villamizar <[email-masked]>
Date: Fri, 11 Sep 1998 13:30:24 -0400

Since the idea of using DNS as a means to distribute the IRR has been
brought up again, I'll review the reason the idea was soundly rejected
in the past (and a major reason why RIDE never became a WG).

The primary use of the IRR is configuring router policy, which
requires access to the whole database.  This would mean a walk of the
entire DNS tree which is enormously resource intensive, plus verifying
signatures as the walk proceded.  To insure an up to date copy, you
could either walk the database each time you needed to configure
routers, or set up as a DNS secondary for all known zones.  This would
mean a lot of zone transfers (with signature verifications) just to
confirm that nothing changed.  Similarly the DNS server would have
everyone that was configuring routers acting as a secondary and would
have to provide a lot of signed zone transfers.  So the bottom line
was it was extremely inefficient and had very obviously scaling
problems.

Once again, if someone still wants to pursue DNS as a means to
distribute the IRR they are welcome to try to do so on their own or as
part of some other WG if they can get any other people interested.

Curtis

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Sep 1998 10:57:25 -0700 (PDT)

> was it was extremely inefficient and had very obviously scaling

uh, you may want to review the presentations and i-d that discussed this.
then again, you may not.

randy

---

From: [email-masked]
Date: Fri, 11 Sep 1998 11:02:35 -0700 (PDT)

> part of some other WG if they can get any other people interested.

I am concerned that there then becomes an intractable linkage between
a language for routing policy expression and a specific publication
method for that language.  If these two remain linked, then perhaps
the good work that RPS is gets tossed because the publication method
changes and is no longer relevent.

You raise points on the tractability of data collection in a broadly
distributed model. The converse is the accuarcy of data that is entered
centralized databases once with no good tools for aging stale data (the 
reclaim token should be set by default and the auto-expire fields 
should be set for all historical objects so the database does not get 
cluttered.) will provide inaccurate results in the configuration of 
policy.  It might be more prudent to use local, fresh copies of authoritative
data between peers than trek up to some third-party database to look up
stale data. Again, the arguements here are on the format and structure 
of the storage and publication method, not the language itself.

However, since this linkage is called out in the RPS charter, I'll not
question this chairs choice of publication method. I will note that in
the arguments used above for why DNS is a poor choice, some are false,
some are red-herrings, some are no longer true w/ current code and some
are true but may not be relevent and some are true and relevent. But
since the chair has ruled this particular topic out of scope, further
discussion will have to occur elsewhere. If there is interest, I'd be
happy to discuss the topic elsewhere.

--bill

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 14 Sep 1998 12:35:38 -0400

> uh, you may want to review the presentations and i-d that discussed this.

Randy,

I was on the RIDE mailing list and I have read the presentations and
the discussions.  I'm not sure which I-D you would be referring to
unless you mean your I-D (Tony^2, Yakov, Randy).  If so, I was at the
NANOG, IDR, and RPS meetings where this was presented.

Do you disagree with the statement above that you were replying to?
If you think that some presentation or I-D is particularly worth
reading, please tell us which one and why.  If you are referring to
your I-D please explain how the serious scaling problems that were
pointed out at prior NANOG, IDR, and RPS meetings are addressed (some
repeated above).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 14 Sep 1998 12:49:31 -0400

> of the storage and publication method, not the language itself.

You've hit an important consideration right on the head.

We need to be very careful in the way that we grandfather data from
the older routing databases into the database after rps-auth is put in
place.  This is covered, but possibly too briefly in rps-auth in
Appendix A.3 "Dealing with non-conformant or questionable older data"
(p 24-25, text version).

   A.3  Dealing with non-conformant or questionable older data

     Some of the newer requirements include requiring that all objects
     reference a maintainer object responsible for the integrity of the
     object and requiring accountability for the creation of maintainers to
     be recorded in the maintainer objects so that accountability can be
     traced back from an unresponsive maintainer.  In the event that
     contact information is absent or incorrect from objects and there is
     any question regarding the validity of the objects, the maintainer can
     be contacted.  If the maintainer is unresponsive, the maintainer that
     authorized the addition of that maintainer can be contacted to either
     update the contact information on the maintainer or confirm that the
     entity no longer exists or is no longer actively using the Internet or the
     registry.

     Many route objects exist for which there are no maintainers and for
     which inetnum and AS objects do not exist.  Some contain the now
     obsoleted guardian attribute rather than a mnt-by.

     It is not practical to unconditionally purge old data that does not
     have maintainers or does not conform to the authorization hierarchy.
     New additions must be required to conform to the new requirements
     (otherwise the requirements are meaningless).  New requirements can be
     phased in by requiring modifications to conform to the new
     requirements.

     A great deal of questionable data exists in the current registry.  The
     requirement that all objects have maintainers and the requirements for
     improved accountability in the maintainers themselves may make it
     easier to determine contact information even where the objects are not
     updated to reflect contact information changes.

     It is not unreasonable to require valid contact information on
     existing data.  A great deal of data appears to be unused, such as
     route objects for which no announcement has been seen in many months
     or years.  An attempt should be made to contact the listed contacts in
     the object, in the maintainer if there is one, then up the maintainer
     referral-by chain if there is one, and using the number registry or
     origin AS contact information if there is no maintainer accountability
     trail to follow.  Experience so far indicates that the vast majority
     of deletions identified by comparing registered prefixes against route
     dumps will be positively confirmed (allowing the deletion) or there
     will be no response due to invalid contact information (in many cases the
     IRR contact information points to [email-masked]).

     By allowing the registry to modify (or delete) any objects which are
     disconnected from the maintainer accountability trail, cleanup can be
     made possible (though mail header forging could in many cases have the
     same effect it is preferable to record the fact that the registry
     itself made the cleanup).  Similarly, a mechanism may be needed in the
     future to allow the maintainer in the referral-by to override
     maintainer privileges in a referred maintainer if all contacts have
     become unresponsive for a maintainer.  The referral-by maintainer is
     allowed to add an ``auth-override'' attribute which becomes usable as
     an ``auth'' within 60 days from the time of addition.  The maintainer
     themselves would be notified of the change and could remove the ``auth-
     override'' attribute before it becomes effective and inquire as to why it
     was added and correct whatever problem existed.  This can be supported im-
     mediately or added later if needed.

This allows a temporary gransfathering of old data of uncertain origin
and removal after no one claims it and if there does not appear to be
any reason to keep it.

This does not allow the removal of bogus data that should never have
been added in the first place but for which some party is tenaciously
asserting their right to keep the data in place.  Do we also want to
only temporarily grandfather such data until authorization in the AS
and IP number hierarchy can be confirmed?  I'd be delighted in the
WG's answer to that question was "yes".

> happy to discuss the topic elsewhere.

If the summary I made was incorrect, could you please help me and this
WG sort out what is true/flase, relevent/irrelevent?

Thanks,

Curtis

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Sep 1998 10:04:42 -0700 (PDT)

> This would mean a walk of the entire DNS tree

false.  see i-d.

> To insure an up to date copy, you could either walk the database each time
> you needed to configure routers, or set up as a DNS secondary for all
> known zones.  This would mean a lot of zone transfers (with signature
> verifications) just to confirm that nothing changed.

false.  see presentations.

> Similarly the DNS server would have everyone that was configuring routers
> acting as a secondary

false.  see normal dns practice and presentations.

> the bottom line was it was extremely inefficient and had very obviously
> scaling problems.

in fact, it is the ONLY proposal which is KNOWN TO SCALE.

randy

---

From: [email-masked]
Date: Mon, 14 Sep 1998 10:25:45 -0700 (PDT)

> WG sort out what is true/flase, relevent/irrelevent?

Not on the RPS list. The discussions of DNS as a publication method
have been declaired out of scope by one of the chairs of this group.

-- 
--bill

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 15 Sep 1998 14:32:03 +0200

>> This would mean a walk of the entire DNS tree

I think some disagreements here stem from different usage scenarios.
The RPS/configuration scenario assumes that *all* decisions on validity
of prefixes must be encoded into a router *before* such a prefix is seen.
This means that the gathering process needs all the domains in the tree,
which at least means a check of every expired SOA record every configuration
run.

The DNS draft seems to assume an "if I need it, I look for it"
scenario, where a router issues a DNS query once a new AS number/prefix
combination is seen in its table.

The first scales with (the number of SOA records in the bgp.in-addr.arpa
tree + the number of zone modifications) * frequency of reconfig operations,
the second scales with the number of new/changed (origin prefix/AS)
combinations seen by a router. (anyone got stats on that?)
Both, of course, have to be scaled by the number of BGP routers
in the Internet using this system.
(Anyone know the number of BGP speaking routers in the Internet?)

(At the IAB routing workshop, people were trying to teach me not to say
"scales", but to say "scales to.." or "scales with...".....)

Anyway, it's only a walk of the bgp.in-addr.arpa tree, not the
DNS tree or the whole in-addr.arpa tree; one reason for the special prefix
(which I don't find very pretty architecture-wise....but that's me).

This is based on a cursory reading of draft-bates-bgp4-nlri-orig-verif-00.txt.
Feel free to slap me down if I missed the mark.

                      Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Sep 1998 05:59:22 -0700 (PDT)

> of prefixes must be encoded into a router *before* such a prefix is seen.

and assumes the static routing model, i.e. i know all the routes i will ever
accept when i configure my router.  this is popular at only one provider of
note. 

and, in the draft-bates-bgp4-nlri-orig-verif-00.txt, caching is pretty much
assumed.  in really demanding situations, the accompanying presentations
suggest that an already dnssec-verified cache be used.  while, in the static
case, it is not as needed as it is assumed that one configures routers
rarely.

randy

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 15 Sep 1998 11:03:14 -0400

In message <[email-masked]>, Harald Tveit Al
> (Anyone know the number of BGP speaking routers in the Internet?)

The DNS approach scales on the router with the (number of SOA record *
frequency of route change or SOA expiration) for the on-demand
approach or (number of SOA record * frequency of reconfig operations)
for the reconfig approach.  It scales on the DNS server by (number of
SOA record * BGP speaking routers in the Internet * frequency of route
change or SOA expiration).  Scaling here is a function of size of
routing table (number of SOA records should follow), number of BGP
speaking routers in the Internet, and frequency of route change
(limited by SOA expiration).  The scalability of this approach doesn't
look very promising.

The RPS redistribution scales only by the rate of changes in the
registry and number of adjacencies.  The flooding itself scales with
the number of adjacencies which need not exceed 3-4 for mirrors, the
number of routers in a given ISP for a specialized mirror serving
routers directly (though load could easily be subdivided if this were
ever an issue) and 1-2 for a router.

An estimate of the number of changes per day can be obtained by
rearranging from the output of the following command (where "*"
expands to ans, canet, mci, radb, ripe).

    grep '\*ch:' /production/dbase/data/*.save \
      | awk '{print $3;}' | sed 's,^199,9,' | sort -n | uniq -c | less

       7 980801     63 980816    363 980901
       9 980802    281 980817    159 980902
     139 980803    153 980818    102 980903
     316 980804    118 980819    122 980904
     210 980805    128 980820     29 980905
     141 980806    155 980821    118 980906
      95 980807      1 980822     84 980907
      38 980808     12 980823    124 980908
      15 980809    278 980824    116 980909
     122 980810    279 980825    276 980910
     167 980811    145 980826    215 980911
     180 980812    197 980827      9 980912
      97 980813    123 980828     29 980913
     170 980814     62 980829     39 980914
      15 980815      6 980830             
                   114 980831             

I've been saying a few 100 per day on average, which seems to be about
right.  If aggregation works, the rate of change is well bounded.  The
number of adjacencies should remain about constant.  Can't scale much
better than that.

Curtis