Re: [RPSEC] Interior vs exterior?

[bmanning@karoshi.com]

> 
> On Wed, 16 Oct 2002 bmanning@karoshi.com wrote:
> 
> > > One interesting question is: where is the authorative information about
> > > what is correct? I don't even think there is any kind of formal
> > > requirement to register routing information in a routing registry, and
> > > many people don't. The people that do, often make mistakes or register
> > > incomplete information.
> 
> > 	the centralized nature of the IRR system is problematic.
> > 	an approach that was attempted to push the responsibility
> > 	out to the folks that hold the delegations.
> > 	see:  http://www.isi.edu/~bmanning/inet98.html
> > 	for a method that preserves the semantics of RPSL,
> > 	while ensuring that the end sites are responsible for
> > 	the accuracy of the information published.
> > 	This only works if we can secure the DNS tho... :)
> 
> I did a quick read, so I may have missed some things...
> 
> A few problems/questions:
> 
> - Currently, the RR does syntax checking. This has saved me a number of
>   times, and I'm sure there are many people that have an even harder time
>   getting this right than I do.

	typos will eat your lunch every time.  thats why many folks
	are using GUIs for data entry and backend tools to generate
	the data.

> - Supposedly, the information would reside inside the network advertising
>   a routing policy itself. What happens if this network is unreachable?

	RFC 1219.  DNS servers should be on different pwoer grids, e.g.
	physically diverse.  So when your master dies or your network
	is degraded by backhoe fade, you have slaved the data to (at least)
	one other remote server. 

	(e.g. what happens when the network "fades" to the centralized
	site? :)

> - What about delays and inconsistencies that arise when new delegations
>   must be created and/or information is changed but still cached in
>   certain places?

	What about them? 

> I love the DNS to death, but I think we should be very careful about
> overloading it. (If only to keep the DNS guys off our back...) It might be
> good to create a new distributed database for routing information (and
> potentially other stuff), that can address some of the DNS weaknesses.

	Not nearly as big an overload as (NAPTR, ENUM, IDN, DNSSEC...)
	Its a bunch of TXT RRs for crying out loud.  No change in
	the DNS at all.  Its a simple matter of implementation.
	
	Its not goofy, like the proposal to validate all routes received
	by checking them in the DNS -BEFORE- using them.  This is an
	OOB check that the route received is being announced as intended
	by the proper delegee.



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec