RIP Justification

Thu Sep 30 04:29:41 UTC 2010

On Wed, 29 Sep 2010 19:31:26 -0500
Christopher Gatlin <chris at travelingtech.net> wrote:

> My point here is untrusted networks, such as business partners exchanging
> routes with each other.  Not many hops and less than a 100 prefixes.
> 
> Using BGP to exchange routes between these types of untrusted networks is
> like using a sledgehammer to crack a nut.  BGP was designed for unique AS's
> to peer in large scale networks such as the internet.  A far cry from
> business partners exchanging dynamic routes for fault tolerance.
> 

I've used BGP quite a fair bit, for both Internet scale and small
scale routing scenarios such as the one I recommended.

How do you prevent those business partners spoofing specific
route announcements within the RIP update, intentionally or otherwise,
such as a default route, causing either outages or attracting traffic
towards their networks that shouldn't be? A shared RIP MD5 key between
the routers doesn't validate the route information within the RIP
update. All the routers within your business partner domain will
blindly accept and trust the routing information in any and all of the
RIP updates they receive.

Do the businesses attached have a multilateral or bi-lateral routing
relationship? If routing relationship is multilateral, which is likely
because you're using RIP, are the business partners using IPsec to
ensure that if the routing is subverted, their traffic isn't disclosed
to partners it shouldn't be?

The scenario you're describing sounds pretty much exactly like a
internet/peering exchange is between ISPs. The routing security
issues are similar if not the same. In either multilateral or
bi-lateral routing scenarios, BGP will provide you with the
mechanisms needed to provide more trustworthy routing in these peer
exchange type scenarios.

> I've seen RIPv2 very successfully deployed in modern networks in this
> fashion.

Popular doesn't always equal good. Britney Spear's music
is a testament to that.

The threshold of success isn't if something works. It's whether it
continues to work in the face of adversity. I'd think your business
partner customers would expect a highly available service that is
resilient to predictable and preventable adverse events, with a
fairly likely one to be accidental route injection.

>  I advocate using an appropriate tool for the job.
> 

As do I, and therefore I don't worry to much about the specific
scenarios the tool was designed for - if the chosen tool provides the
most appropriate and relevant benefits for an acceptable cost,
the original design scenario doesn't matter.

Regards,
Mark.