Protecting BGP Neighbor Relationships

Authenticating using Passwords

This is the simplest solution for both eBGP & iBGP neighbors..
Following is an example for eBGP neighbors.

R1(config-router)#router bgp 1
R1(config-router)#neighbor 10.0.0.2 remote-as 2
R1(config-router)#neighbor 10.0.0.2 password cisco

R2(config-router)#router bgp 2
R2(config-router)#neighbor 10.0.0.2 remote-as 1
R2(config-router)#neighbor 10.0.0.1 password cisco

You can give encryption levels from 1-7 or MD5 hash as per the corporate security policy..
But still the routers are vulnerable to CPU DoS attacks as they check each and every malformed packet attacker sends..

Protecting eBGP Neighbors by Changing TTL

Routers send BGP packets to eBGP neighbors with a TTL of 1 by default which implies they should be connected directly. This is the security mechanism of eBGP. But an attacker can spoof this TTL value easily by fixing the TTL value to be 1 when the packets reach the destination router from a remote location.

In the above example, if the attacker set the TTL to 3, it will appear at R1 as TTL of 1 which means R1 will think the attacker is directly connected..

Additional TTL security command is like the following..

R1(config-router)#neighbor 10.0.0.2 ttl-security hops 1
R2(config-router)#neighbor 10.0.0.1 ttl-security hops 1

This will change the TTL of eBGP packets to 255. Both the neighbors will only accept the packets if the TTL is 255 only. Which means only directly connected routers will be able to try a peering..

Note:- 

ebgp-multihop is not a security command, it will only change the TTL to the given number which will only allow eBGP peers to accept packets which are lower or equal to that given value.
You can learn more about this command here. Still vulnerable to the above attack. ttl-security hops command is actually the reverse logic of ebgp-multihop command hence you cannot use both commands together..