Routing Security

This section identifies how to secure routing protocols and includes the use of Message Digect-5 (MD-5) for MPLS control plane protocols such as Label Distribution Protocol (LDP). We specifically illustrate PE-CE routing protocol examples from a security perspective and introduce a Time-To-Live (TTL) security mechanism for BGP (Generalized TTL Security Mechanism [RFC 3682]). We also discuss mechanisms such as setting prefix limitations in order to monitor further for traffic anomalies.

Neighbor Router Authentication

How does a provider really know that the routing updates are from one of the provider's internal backbone routers and that the route really came from a neighboring router on the provider's backbone? It is difficult to validate this situation unless route authentication is used. Theoretically, routing information can be spoofed and injected into a service provider's backbone. The horror of experiencing a normal 50 K route object's jump to 200 K or 500 K and then observing these routes propagate all over the SP backbone has been a subject of numerous security meetings. Service providers are strongly encouraged to prevent their routers from receiving fraudulent route updates by configuring neighbor router authentication.

Neighbor router authentication occurs whenever routing updates are exchanged between neighbor routers that are in the control of the service provider. This authentication ensures that a router receives reliable routing information from a trusted source. Without neighbor authentication, unauthorized or deliberately malicious routing updates could compromise the security of your network traffic. A security compromise could occur if an unfriendly party diverts or analyses your network traffic. For example, an unauthorized router could send a fictitious routing update to convince your router to send traffic to an incorrect destination. This diverted traffic could be analyzed to learn confidential information about your organization or merely used to disrupt your organization's ability to effectively communicate using the network. Neighbor router authentication prevents any such fraudulent route updates from being received by your router. You should configure any router for neighbor authentication if that router meets all of these conditions:

The router uses any of the routing protocols previously mentioned.
It is conceivable that the router might receive a false route update.
If the router were to receive a false route update, the service provider network might be compromised.

Configure a router for neighbor authentication and configure the neighbor router for neighbor authentication.

When neighbor authentication has been configured on a router, the router authenticates the source of each routing update packet it receives. This is accomplished by the exchange of an authenticating key (sometimes referred to as password) that is known to both the sending and receiving router. There are two types of neighbor authentication used: plain text authentication and Message Digest Algorithm Version 5 (MD5) authentication. Both forms work in the same way, with the exception that MD5 sends a "message digest" instead of the authenticating key itself. The message digest is created using the key and a message, but the key itself is not sent, preventing it from being read while it is being transmitted. Plain text authentication sends the authentication key itself over the wire.

Using MD5 authentication, however, is a recommended security best practice.

CAUTION

As with all keys, password, and other security secrets, it is imperative that the SP closely guard authenticating keys in neighbor authentication. The security benefits of this feature are reliant on the SP maintaining all authenticating keys confident. Also, when performing router management tasks via SNMP, do not ignore the risk associated with sending keys using nonencrypted SNMP.

Note also that with SNMP access for customers there is a risk of overloading the CPU with SNMP walks. The service provider recommendation is to use an SNMP proxy for customer access. MD5 authentication works similarly to plain text authentication, except that the key is never sent over the wire. Instead, the router uses the MD5 algorithm to produce a "message digest" of the key (also called a hash). The message digest is then sent instead of the key itself.

Hash provides an additional layer of security in addition to encryption. The hash system does not provide absolute security. MD5, is the most common hashing system for today's cryptography. MD5 processes the input text in 512-bit blocks, divided into 16 32-bit sub-blocks. The output of MD5 is a set of 4 32-bit blocks, which are concatenated to form a single string of 128-bit hash value.

MD5 for Label Distribution Protocol

The Label Distribution Protocol (LDP) for the P components use Message-Digest 5 (MD5) authentication in order to protect against label spoofing. Enable all LDP sessions for MD5 authentication. This recommendation also applies for CsC environments where a PE router is providing CE routers with labels for IGP routes in the VPN MD5 for LDP:


mpls ldp neighbor 194.22.15.2 password 7 ****** (scrambled)

NOTE

MD5 can only be supported for LDP, not TDP.

The best practice recommendation is to use LDP and not Tag Distribution Protocol (TDP), which is Cisco proprietary.

In environments using the Cisco proprietary Tag Distribution Protocol (TDP) globally, LDP can be enabled on a per-circuit basis if authentication is required.

In case of LDP sessions for CsC, the vrf keyword is added to the mpls ldp neighbor command of the PE router.

From PE for CsC:


mpls ldp neighbor vrf Reading 192.168.2.25 password 7 **** (scrambled)

From CE for CsC:


mpls ldp neighbor 192.168.2.26 password 7 **** (scrambled)

For PE-PE authentication, enable MD5 authentication on the multiprotocol BGP sessions between PE routers. This requires only the neighbor password command:


router bgp 10

no synchronization

bgp log-neighbor-changes

neighbor 194,22,15.2 remote-as 10

neighbor password 7 ********************* (scrambled)



Same for route reflectors (vpnv4 route exchange)

TTL Security Mechanism for BGP

The BGP Support for TTL Security Check feature introduces a lightweight security mechanism to protect Exterior Border Gateway Protocol (eBGP) peering sessions from CPU utilization-based attacks using forged IP packets. Enabling this feature prevents attempts to hijack the eBGP peering session by a host on a network segment that is not part of either BGP network or by a host on a network segment that is not between the eBGP peers.

You enable this feature by configuring a minimum Time-To-Live (TTL) value for incoming IP packets received from a specific eBGP peer. When this feature is enabled, BGP will establish and maintain the session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. If the value is less than the configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. Note that the value corresponds to the "hop" count, where the minimum TTL calculated value is 255.

BGP must be configured in your network, and eBGP peering sessions must be established.

This feature needs to be configured on each participating router. It protects the eBGP peering session in the incoming direction only and has no effect on outgoing IP packets or the remote router.

Restrictions for BGP Support for TTL Security Check

This feature is designed to protect only eBGP peering sessions and is not supported for iBGP peers and iBGP peer groups.

When configuring the BGP Support for TTL Security Check feature to support an existing multihop peering session, you must first disable the neighbor ebgp-multihop router configuration command by entering the no neighbor ebgp-multihop command before configuring this feature with the neighbor ttl-security router configuration command. These commands are mutually exclusive, and only one command is required to establish a multihop peering session. If you attempt to configure both commands for the same peering session, an error message will be displayed in the console.

The effectiveness of this feature is reduced in large-diameter multihop peerings. In the event of a CPU utilization-based attack against a BGP router that is configured for large-diameter peering, you may still need to shut down the affected peering sessions to handle the attack.

This feature is not effective against attacks from a peer that has been compromised inside your network. This restriction also includes BGP peers that are not part of the local or external BGP network but are connected to the network segment between the BGP peers (for example, a switch or hub that is used to connect the local and external BGP networks).

This feature does not protect the integrity of data sent between eBGP peers and does not validate eBGP peers through any authentication method. This feature validates only the locally configured TTL count against the TTL field in the IP packet header.

The BGP Support for TTL Security Check feature introduces a lightweight security mechanism to protect eBGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force denial of service (DoS) attacks that attempt to disable the network by flooding the network with IP packets that contain forged source and destination IP addresses.

This feature protects the eBGP peering session by comparing the value in the TTL field of received IP packets against a hop count that is configured locally for each eBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, the IP packet is accepted and processed normally. If the TTL value in the IP packet is less than the locally configured value, the packet is silently discarded and no ICMP message is generated. This is designed behavior; a response to a forged packet is unnecessary.

Accurately forging the TTL count in an IP packet is generally considered to be impossible. It is possible to forge the TTL field in an IP packet header. However, accurately forging a packet to match the TTL count from a trusted peer is not possible unless the network to which the trusted peer belongs has been compromised.

This feature supports both directly connected peering sessions and multihop eBGP peering sessions. The BGP peering session is not affected by incoming packets that contain invalid TTL values. The BGP peering session will remain open, and the router will silently discard the invalid packet. The BGP session, however, can still expire if keepalive packets are not received before the session timer expires.

Configuring the TTL Security Check for BGP Peering Sessions

The BGP Support for TTL Security Check feature is configured with the neighbor ttl-security command in router configuration mode or address family configuration mode. When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. Enabling this feature secures the eBGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router. The hop-count argument is used to configure the maximum number of hops that separate the two peers. The TTL value is determined by the router from the configured hop count. The value for this argument is a number from 1 to 254.

Configuring the TTL Security Check for Multihop BGP Peering Sessions

The BGP Support for TTL Security Check feature supports both directly connected peering sessions and multihop peering sessions. When this feature is configured for a multihop peering session, the neighbor ebgp-multihop router configuration command cannot be configured and is not needed to establish the peering session. These commands are mutually exclusive, and only one command is required to establish a multihop peering session. If you attempt to configure both commands for the same peering session, an error message will be displayed in the console.

To configure this feature for an existing multihop session, you must first disable the existing peering session with the no neighbor ebgp-multihop command. The multihop peering session will be restored when you enable this feature with the neighbor ttl-security command.

This feature should be configured on each participating router. To maximize the effectiveness of this feature, the hop-count argument should be strictly configured to match the number of hops between the local and external network. However, you should also consider path variation when configuring this feature for a multihop peering session.

Benefits of the BGP Support for TTL Security Check Feature

The BGP Support for TTL Security Check feature provides an effective and easy-to-deploy solution to protect eBGP peering sessions from CPU utilization-based attacks. When this feature is enabled, a host cannot attack a BGP session if the host is not a member of the local or remote BGP network or if the host is not directly connected to a network segment between the local and remote BGP networks. This solution greatly reduces the effectiveness of DoS attacks against a BGP autonomous system.

How to Secure BGP Sessions with the BGP Support for TTL Security Check Feature

This section contains the following procedures:

Configuring the TTL-Security Check (required)
Verifying the TTL-Security Check Configuration (optional)

Configuring the TTL-Security Check

To configure the BGP Support for TTL Security Check Feature, perform the steps in this section.

To maximize the effectiveness of this feature, we recommend that you configure it on each participating router. Enabling this feature secures the eBGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router.

Restrictions

The neighbor ebgp-multihop command is not required when this feature is configured for a multihop peering session and should be disabled before configuring this feature.

The benefit of this feature is reduced in large-diameter multihop peerings. In the event of a CPU utilization-based attack against a BGP router that is configured for large-diameter peering, you may still need to shut down the affected peering sessions to handle the attack.

This feature is not effective against attacks from a peer that has been compromised inside of the local and remote network. This restriction also includes peers that are on the network segment between the local and remote network.