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