You want to authenticate your BGP peer relationships to help prevent tampering with your routing tables.
The BGP protocol includes an MD5-based authentication system for authenticating peers:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#router bgp 65500 Router1(config-router)#neighbor 192.168.55.5 remote-as 65501 Router1(config-router)#neighbor 192.168.55.5 password password-1234 Router1(config-router)#end Router1#
The same password must be configured on both routers:
Router2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router2(config)#router bgp 65501 Router2(config-router)#neighbor 192.168.55.6 remote-as 65500 Router2(config-router)#neighbor 192.168.55.6 password password-1234 Router2(config-router)#end Router2#
MD5 authentication is a standard part of BGP Version 4 that was introduced in RFC 2385. The IETF went further in RFC 3013 (which is also called BCP 46) to recommend that "BGP authentication should be used with routing peers" in the public Internet. This language, "should be used," indicates a strong recommendation, but not a requirement.
BGP is different from the routing protocols that we discussed in Chapter 6, Chapter 7, and Chapter 8 because you must explicitly configure the peer relationships between routers. These peers then use point-to-point TCP connections to exchange information, which makes it much more difficult for a malicious user to surreptitiously establish a peer relationship with one of your routers and corrupt your routing tables. But it is still possible to hijack an existing TCP connection between two BGP peers and inject bad routes. And, if the attacker is on the same network segment as one of the peers, they can potentially hijack the IP address of the legitimate peer and set up a new BGP session.
With authentication, this type of attack is considerably more difficult. This is because the attacker must not only get the TCP sequence numbers right, but he must also insert the correct encrypted authentication key.
Some sources have claimed that this MD5 authentication scheme is not sufficient for BGP because there are effective attacks that can break it. The Internet Draft document, "Security Requirements for Keys Used with the TCP MD5 Signature Option" (http://www.ietf.org/internet-drafts/draft-ietf-idr-md5-keys-00.txt) comments on this threat and makes the following recommendations:
Make your keys between 12 and 24 bytes long.
In situations with multiple BGP peers, avoid using the same keys with all peers.
Change your keys at least every 90 days.
It is also important to note that introducing authentication can cause delays in BGP message passing, although it shouldn't seriously affect normal IP packet processing. It can also cause increased CPU overhead on the BGP peer routers.
Despite all of this, in a hostile network, authentication can be useful because it makes it significantly harder for somebody to disrupt your routing tables. If your ISP supports this service, it is probably a good idea to use it.
It is also worth mentioning that, in your router's configuration file, the password will be stored in plain-text unless you have enabled the service password-encryption global configuration command. When you turn on password encryption, the router will store the command using the Cisco proprietary type 7 encryption:
! router bgp 65500 neighbor 192.168.55.5 remote-as 65501 neighbor 192.168.55.5 password 7 15020A1F173D24362C7E64704053 !
As we mentioned in Chapter 3, it is quite easy to break this encryption algorithm. But as long as you maintain good control over your router's configuration files, this will at least prevent somebody from learning the encryption key by looking over your shoulder.
When there is an authentication mismatch between two BGP peers, they will not be able to establish a connection. You will also see the following error message on one or both routers:
Jan 7 10:01:48 EST: %TCP-6-BADAUTH: No MD5 digest from 192.168.55.6:13662 to 192. 168.55.5:179
Chapter 3; RFC 3013; "Security Requirements for Keys Used with the TCP MD5 Signature Option", http://www.ietf.org/internet-drafts/draft-ietf-idr-md5-keys-00.txt, February 2002
 |
|
|
| Top |