Subject: Re: the problem that needs solving vs the problem as seen by

From: [email-masked]
Date: Mon, 7 Sep 1998 04:49:23 -0700 (PDT)

> >We would expect the zones to be DELEGATED by the IANA to the registries to
> >which the relevant address space is allocated, and for them to populate the
> >data.  I could probably write an I-D if you are really interested in this
> >approach.

(Randy)
	Almost. You only take this one level.  I'd expect -anyone-
	who delegates addresses to be responsible for keeping their
	bits of the world accurate and that there would be a verifiable
	chain of custody back to the IANA.  And there are already 
	a number of I-Ds so I'm not sure that another would be that
	much help. 

> Sounds as though it is time for the authors to dust off the
> bgp4-nlri-orig-verif-00 draft?

(Paul)
	I've always thought that this is a bit farther than I'd be 
	willing to go, at least for now.  Longer term this might 
	be a good tactic.  

> >I would find embedding RPS in the DNS as particularly sick and broken,
> >combining the worst aspects of two approaches.
> 
> Me too. And it solves the wrong problem anyhow.

	So... it might solve a problem? :)  My example was done as
	a proof-of-concept.  I don't expect people to run right out and
	stuff the DNS with all the RPSL syntax.  It could be done
	and might be simpler than the currently discussed distribution
	methods.  Its not pretty.

> I'd really like to see a solution to the origin auth problem. The DNS
> exists and works well as a distributed database. If the address registries
> could populate a new "BGP TLD" with info about the ASes they assign, and
> the networks assigned within those ASes, don't we get close to solving the
> real problem in one swoop? (Detail omitted, but that is a job for a
> draft... ;-)

	Except the delegation registries don't have access to prefix/as
	mapping. Only the delegates know what they choose to announce 
	and how.

> (We don't need to use DNS, but anyone want to deploy yet another global
> distributed database system and encourage everyone to use it?)
> 
> philip

For your viewing pleasure I've taken the 7-Sep-98 ASN delegation file
from the ARIN ftp site and stuffed it into the RDI.INT zone.  Won't 
give you the prefixes associated with the ASN, but it does get you 
another way to look up the contact for a given ASN.  

If the contact for any given ASN would like to re-map that entry to
their own servers so they can indicate which prefixes they are willing
to announce (sort of like the 4555.rdi.int example) they can.  The
only way to check authoritative announcements is if the prefix delegates
add an entry into the in-addr.arpa zones that they maintain to indicate
which ASN is expected to be the authoritative announcer for said prefix.

--bill

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Sep 1998 01:02:30 +1200

> which ASN is expected to be the authoritative announcer for said prefix.

Wouldn't this stretch the in-addr.arpa schema in these days of variable
length prefixes?

We have been delegated 203.97.0.0/17. We would presumably need a marker
for our AS to be kept in every n.97.203.in-addr.arpa zone (0 <= n < 128).
Other interested parties would presumably need to check all these zones
for markers in order to validate the assertion that we will source
203.97.0.0/17 that we would make in our 4768.rdi.int records (yuck,
incidentally!)

Most of the n.97.203.in-addr.arpa zones have SOA on our nameservers, but
in the case where we have delegated a /24 (or shorter prefix) block to a
customer, the corresponding in-addr.arpa zones are delegated directly to
their nameservers. Most of these customers are singly-attached to us, and
do not source advertisements from their own ASN.

Do we now make it a requirement that those customers include some kind
of marker for our AS in their in-addr.arpa zones? Some of them have enough
trouble with PTR records... I can only imagine the commercial implications
of ceasing advertisements for a customer because they've missed a "."
in their zone file!

I'm not convinced of the fact, but I imagine that the desirable goal of
a fully authenticated, secure and rigorously applied public routing policy
for all ASes will never occur in the real network. Far more likely is
"we will peer with you/sell you service, but we build our routing filters
from the RADB/rdi.int/whatever. If you want it to work, you must populate
the appropriate records."

If everybody has sufficient confidence in the advertisements of their
directly connected peer networks, isn't that enough? Regardless of what
"sufficient" means in any particular case?

Incidentally I find the whole idea of using the DNS to maintain distributed
databases of information _other_ than address-to-name translations quite
nice -- the DNS is already a Great Big Distributed Thing, and it seems to
work pretty well most of the time.

Someone else mentioned that using a high-level protocol like the DNS to
carry (low-level) routing policy was an inherently scary idea -- however,
I don't really see the distinction between a high-level protocol like
DNS and a high-level protocol like whois...

If it makes us more comfortable to keep local copies of the vital
information from neighboring ASes local, then we can arrange zone
transfers, just as we might choose to mirror the RADB.

If we want to keep separate (more complete, more secretive) information
about our policy internally and publish a subset, we can do that too. We
already do that with the existing DNS to hide names which are only used
internally.

Joe

-- 
Joe Abley <[email-masked]>      Tel +64 9 912-4065, Fax +64 9 912-5008
Network Architect, CLEAR Net                      http://www.clear.net.nz/

---

From: [email-masked]
Date: Mon, 7 Sep 1998 06:10:00 -0700 (PDT)

> Wouldn't this stretch the in-addr.arpa schema in these days of variable

	Yup. It will get better(worse?) with binary labels.

> 203.97.0.0/17 that we would make in our 4768.rdi.int records (yuck,

	Only if they wanted to check authoritative vs proxy announcements.

> the appropriate records."

	A highly desirable goal.  And yes, if the client screws up they
	lose connectivity. Gives them an incentive to keep stuff current. :)

> "sufficient" means in any particular case?

	Well, perhaps.  Trust but verify is a good motto.

> transfers, just as we might choose to mirror the RADB.

	Yup. with the exception that there is a distinction of
	where/who maintains the authoritative data.  There is the
	centralized model and the distributed model.

> already do that with the existing DNS to hide names which are only used

	Well known technique.

-- 
--bill

---

From: "Mike O'Dell" <[email-masked]>
Date: Mon, 07 Sep 1998 09:58:25 -0400

no need to work too hard

just FTPing a list from the address assignment authority 
would be OK with me....

someting very, very simple like this:

for the AS-major listing:  (AS -> Prefix mapping)

as num starts in column one with prefixes following
separated by whitespace (tab or blanks), end lines with a
newline, leading whitespace indicates a continuation of
the previous line

701	a.b.c.d/10 e.f.g.h/14 .....
	p.q.r.s/18 t.u.v.w/14 ....

for a prefix-major listing (Prefix -> AS mapping), just reverse the 
field order (again, just whitespace (tabs and/or spaces):

a.b.c.d/10	701 801 901 1001 1101 ...
		2101 2201 2301 ...

this isn't all that hard, is it??

	-mo