Shane,
when I first joined the list, my sole intent was on working with some
people on coming up with ideas as to how security should be the basis for
certain areas of certain routing protocols. I remember sending out an
email and receiving no reply for ~1yr.
If anyone has been working on this, I'd be greatly interested in assisting
in some way.
Andrew
On Sat, 16 Dec 2000, Shane Amante wrote:
> Perhaps I missed it, but I haven't seen anyone mention security with
> respect to granular authentication of path/prefix/flow/policy
> information. And, I'm not talking about security as a "add-on"
> feature (e.g.: BGP/OSPF/IS-IS MD5 neighbor authentication) that merely
> authenticates two sides of a link, but not the substrate information
> contained in the messages carried between them. I mean real
> authentication of routing information, for whatever next-gen IDR
> approach is taken, should be innate and (preferably) unavoidable by
> operators who deploy it.
>
> There will clearly be performance and memory implications with any
> security mechanism(s). However, there feasibility should at least be
> considered for the following reason. The Internet may have already
> reached a point of critical mass where it is only being used, or going
> to be used, for those applications (web, mail, etc.) that can
> "tolerate" bad routing information. However, authentication of
> routing will be crucial to future real-time applications that may use
> the Internet, (e.g.: tele-medicine, VoIP, real-time Video,
> circuit-emulation, etc.) In those cases, application security is just
> not good enough.
>
> Also, before we rush to solve the problem, we might want to take a
> step back and state the problem(s) we are trying to solve. To quote
> one of my colleagues: "You need to have a target in order to know what
> you're aiming at." Along those lines, it would be good to formally
> elucidate all of the requirements for a next-gen IDR protocol. So
> far, (besides faster convergence and better scalability), I have only
> seen a few "here's what I want for Christmas" wish lists. ;-)
>
> If work on a requirements/features doc hasn't already begun I would be
> glad to work with others to put together a framework.
>
> -shane
>
>
>
>
> On Fri, Dec 15, 2000 at 04:42:44PM -0800, Fred Baker wrote:
> > varied.
> >
> > We're looking at the growth in routes, which is now roughly at the same
> > rate it was in 1993 prior to the deployment of CIDR. We believe that this
> > is primarily related to multihoming, and may be amenable to adjustment
> > using policies. Geoff Huston has suggested that we put a TTL on routes
> > advertised - when transit contracts are in place, maybe I want my immediate
> > neighbor to get a certain /28 route, but there is no need to send it beyond
> > him although other routes will go beyond him. Attacking the same problem, I
> > suggested another approach - if my route to you and my route to your left
> > nostril have the same next hop, I don't need to store the fact in my FIB,
> > nor advertise it beyond me. There is probably another way to solve it, and
> > it may be better.
> >
> > We are also looking at convergence times. Vendors are in the process of
> > deploying a different understanding of a certain paragraph in BGP-4, which
> > would bring global convergence on a withdraw or a new route to roughly 30
> > seconds. But for many networks, 30 seconds and 30 years are still roughly
> > comparable; they would prefer convergence on the order of seconds. The
> > summary offered by Ran Atkinson was that "current convergence times leave a
> > lot of things in weird states for long periods of time." I have suggested
> > using some variation on the DUAL algorithm in a next generation BGP in
> > order to improve convergence; I have suggested a variation on EIGRP as a
> > starting point for thinking about the algorithms. I'll attach an email sent
> > earlier this week, following the IAB discussion of same. Again, there may
> > be a different or better approach.
> >
> > Once we solve data distribution, I do believe that a better organization of
> > the information itself, and the policies, would be useful. I characterize
> > the way we use BGP now as "building skyscrapers out of tinkertoys". I would
> > be very much in favor of improved approaches. NIMROD, I believe, has a lot
> > of the right pieces, although I can't describe MPLS as my favorite
> > implementation of it. That will take more exploration than I personally
> > have begun.
>
>
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT