cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
455
Views
0
Helpful
6
Replies

EIGRP authentication...........any opinions

matthewmphc
Level 1
Level 1

Our network is looking at having to employ MD5 authentication for our EIGRP network to ensure no rogue routers can join our AS. However, we've never done it before, and we can't find anyone else around us who is doing it either. We don't know a lot about it, so we have some concerns about it as far as how easily can it break, how time dependent it is, etc. Before we pursue this, we were wondering if there is another method of controlling what routers are participating in our network. If anyone has any ideas or thoughts on MD5 authentication, we'd appreciate hearing it. Thanks

6 Replies 6

MD5 authentication is quite secure though not completely hack-proof. It should protect routing exchanges from being falsified. By using hard to guess passwords and changing passwords periodically for MD5 authentication you get a certain amount of security for the routing protocol. If you are looking for more stronger security then you may have to enable IPSEC to protect routing updates but that would require lot of configuration changes and mayn't be an option if you have a really large network.

Have a look at the RFC1321 link below for more information MD5 signature algorithm.

http://www.faqs.org/rfcs/rfc1321.html

HTH

Sundar

Joseph W. Doherty
Hall of Fame
Hall of Fame

Have implemented MD5 in a sizable network for OSPF. The fun part was the cut over. No issues after the cut over.

Other possible security measures, ACLs to block unknown routers from peering. Setting edge networks where there are no peers to passive. (Once in place, MD5 seems easier to maintain then either of these.)

ruwhite
Level 7
Level 7

I always suggest folks look at three things before implementing MD5 for any routing protocol:

1. The hardness of the router in question. The easiest thing to do here is to set up the routers in the lab, capture a single packet with MD5 in a sniffer, mess with the packet guts in some way so the MD5 hash is no longer valid, and then throw that single packet at a router with MD5 configured at varying bit rates. See what the proc util, etc, does when you do this. Your results will vary per router, and they might give you some idea about various issues you might have when implementing MD5 on publicly accessible interfaces.

2. I would always turn all public facing interfaces to passive, which prevents neighbor formation through those interfaces. This is a very effective and cheap means to protect the edge interfaces on the network, and also to reduce mistakes in routers peering along non-transit links they shouldn't be peering along.

3. I would seriously consider building a set of filters which cover all your infrastructure links, and using those on all edges as inbound packet filters. It would be nice if there were some dynamic way to distribute these sorts of things (and there are projects underway to do so)....

HTH--feel free to email me privately if you need some help with these three.

:-)

Russ

"2. I would always turn all public facing interfaces to passive, which prevents neighbor formation through those interfaces. This is a very effective and cheap means to protect the edge interfaces on the network, and also to reduce mistakes in routers peering along non-transit links they shouldn't be peering along. "

Just for consideration, sometimes non-transit links could be desired to become transit links, if you don't have a dedicated transit(s).

e.g.

Two gateway routers (not L3 switches) are on two edge subnets. One of the router's uplink fails. Without gateway link tracking or a dedicated different transit path, it will black hole if the active gateway.

e.g.

Gateway routers are advertising a summary address for both locally connected subnets. Then connection to one of the local subnets fail. Unless the summary is withdrawn or another transit available, external inbound traffic to that router will black hole such traffic.

Other issues can arise with multiple failures. So, consider carefully the usage of passive when supporting redundancy.

"Just for consideration, sometimes non-transit links could be desired to become transit links, if you don't have a dedicated transit(s). "

OTOH, most of the network design geeks I work with strongly recommend not using edge facing links for transit, ever. IE, the network should be designed around never using edge facing links for transit. There are several reasons:

1. This complicates security, as above. If you have clearly defined transit and nontransit links, then you have a lot of tools at your disposal which don't require large scale cryptographic rollouts, etc, to defend your network infrastructure.

2. This can often lead to second order side effects that aren't immediately apparent. For instance, what if one of the hosts on the links you're using for redundancy is running a huge file transfer on the link when you fail over to it? What would happen to your voip, etc, over that link? These sorts of problems are often difficult to predict, and can actually cause more problems than you solve with the failover.

3. This can create uncontrolled transit paths in your network, which can actually slow down convergence.

While I understand that in the real world, you cannot always afford the additional links, it's normally a really good idea not to mix transit and non-transit links, even when you're considering failover situations.

:-)

Russ

"While I understand that in the real world, you cannot always afford the additional links, it's normally a really good idea not to mix transit and non-transit links, even when you're considering failover situations. "

It's really not a question of mixing them, it's usage of passive or not, if you don't have dedicated transits. Even if you do have dedicated transits, is one enough or should you avoid single points of failure there too.

#1 You're correct about using non-dedicated transits can complicate security! Mostly since it now has to take into account failover transit traffic.

#2 Some issues are going to arise when there's a failover. For instance, depending on what happened, and supporting topology and hardware, live VoIP calls might be interrupted or even dropped. However, there's a major difference between millisecond or multi-second interruptions and waiting for hardware replacement. With regard to huge file transfer already on alternate path, this can be addressed with QoS.

#3 Indeed! If fact, where there aren't dedicated transits, and more than one non-dedicated transit path exists, often it's a good idea to limit intentional peering to only two paths.

Again, don't disagree about the benefit of having dedicated transits, and if you do, not to mix them, but if you don't have them, there are valid reasons to not use passive.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: