CE-PE Routing Security Best Practices
This section focuses on PE-CE IGP and addressing best practice security recommendations. You need to use what you learned in the previous sections as building blocks for this section.
PE-CE Addressing
The physical facility between the PE and CE remains an exposure with respect to access to the networks, data flows, and attack points. This link should be secured to the extent feasible while supporting application requirements and maintenance efforts.
The use of unnumbered links for addressing is frequently seen as a means to enhance the security of the PE, and to some extent the CE, because there is no exposed Layer 3 address to attack. If such an approach is desired, consideration must be given to the implications on the routing protocol being used between the PE and CE.
For example, if eBGP is the protocol in use, peering will need to be linked to loopback (or other) addresses and multihop must be enabled for the eBGP session. This control allows eBGP sessions to maintain over a number of hops by setting the Time-To-Live (TTL) appropriately. Unfortunately, the use of this modifier allows for remote eBGP connection attempts from any number of hops not necessarily just as defined in the sourcing configuration.
One of the most used troubleshooting tools in the IP network space is the ICMP Echo (ping) test. The use of unnumbered links removes the ability of the network operator to ping the directly connected interface as a fault analysis methodology. This may be seen as sufficient cause to support numbered interfaces. Further protection may also be available by encrypting the traffic flowing over the link using either payload encryption mechanisms or full link encryptors.
If the data being passed over the network is considered an extreme risk then such protection may be appropriate as discussed earlier in this chapter. Note also that use of overlapping address space for different VPNs is permitted and implemented today and is fundamental to BGP-VPN mechanisms for MPLS VPN.
Static Routing
Clearly, static routing provides the most stable and controlled scenario for the PE-CE interconnect. With static route definitions, there are no opportunities for errant routes to be introduced other than by typing them directly into the configurations. Also, there is less CPU impact with static routes because there is no dynamic routing process to run (other than the SP iBGP). In addition, because the CE and PE are both using explicitly configured routes, the security of the interconnection is improved?monitoring the intervening path will not provide any information as to what routes are accessible beyond the router.
Dynamic Routing
Alternatively, using a dynamic routing protocol reduces the amount of configuration effort on both the PE and CE routers. Also, changes within the customer's network addressing are readily accommodated and alternate pathing is more easily deployed. If a dynamic protocol is to be used between the PE and CE routers, then eBGP is the recommended choice due to its inherent stability, scalability, and control features. In any case, the use of a dynamic protocol mandates the use of an authentication mechanism between the two routers for security purposes.
In order to provide a degree of security in a dynamically routed PE-CE environment with respect to the peer relationships across the PE-CE links, MD5 authentication (Message Digest 5 Hashed Message Authentication Code [HMAC]) should be enabled between the peers. This mechanism uses a highly resistant hash algorithm in the handshake between the peers to provide some assurance that the peer is in fact the intended neighbor. The use of a preshared secret on the PE and CE routers provides support for the one-way encrypted hash message used to authenticate the peers. As such, coordination is required between the PE and CE management entities if they are separately controlled.
MD5 should be used as opposed to the other, less resilient hashing mechanisms available.
This mechanism is available for all the PE-CE routing protocols currently supported, including the following examples.
Key Chaining
Cipher block chaining (CBC) is a mode of operation for a block cipher (one in which a sequence of bits are encrypted as a simple unit or a block with a cipher key applied to the entire block). CBC uses what is known as an initialization vector (IV) of a certain length. One of its key characteristics is that it uses a chaining mechanism that causes the decryption of a block of cipher text to depend on all the preceding cipher blocks.
eBGP PE-CE Routing
With BGP between PE and CE, authentication is defined on a per-neighbor basis. Also, BGP does not currently support the use of key chains. Key-chaining of MD5 hashes is not yet supported with BGP.
Example 5-17 illustrates BGP authentication.
Example 5-17. BGP AUTHENTICATION
router bgp 13 address-family ipv4 vrf Peabody1 neighbor 1.1.1.1 remote-as 14 neighbor 1.1.1.1 password 5 1Sherman2 # establishes use of MD5 password "1Sherman2" for this neighbor address-family ipv4 vrf Dudley1 neighbor 2.2.2.2 remote-as 15 neighbor 2.2.2.2 password 5 77doright2 # establishes use of MD5 password "77doright2" for this neighbor
NOTE
With BGP, ensure that MD5 authentication is enabled at both ends of the router pair. A router without MD5 authentication definitions will result in a keepalive timeout observed from the routers with MD5 configured as per the BGP authentication explained in RFC 1771.
EIGRP PE-CE Routing
EIGRP authentication is defined in an interface-specific manner and can be instantiated using either clear text or MD5 passwords. As previously stated, MD5 is the recommended usage. Authentication must be enabled for the autonomous system (AS) in question, as illustrated in Example 5-18.
Example 5-18. EIGRP Authentication
router eigrp 13 address-family ipv4 vrf Bullwinkle1 autonomous-system 14 network 1.0.0.0 # define the vpn known as "Bullwinkle1" as operating under the eigrp autonomous system 14 address-family ipv4 vrf Rocky1 autonomous?system 15 network 1.0.0.0 # define the vpn known as "Rocky1" as operating under the eigrp autonomous system 15 interface Ethernet0/0 ip vrf forwarding Bullwinkle1 ip address 1.1.1.1 255.0.0.0 no ip directed-broadcast ip authentication mode eigrp 14 md5 # defines authentication mode for eigrp AS 14 # to be MD5 ip authentication key-chain eigrp 14 eigrp14 # sets the key chain name for eigrp AS 14 to the # string "eigrp14" interface Ethernet0/1 ip vrf forwarding Rocky1 ip address 1.1.1.1 255.0.0.0 no ip directed-broadcast ip authentication mode eigrp 15 md5 # defines authentication mode for eigrp AS 15 # to be MD5 ip authentication key-chain eigrp 15 eigrp15 # sets the key chain name for eigrp AS 15 to the # string "eigrp15" key chain eigrp14 key 1 key-string 5 1natashafatale3 # creates a 'chain' known as "eigrp14" of 1 key, with the # MD5 password set to"1natashafatale3" key chain eigrp15 key 1 key-string 5 3Borisbadenov1 # creates a 'chain' known as "eigrp15" of 1 key, with the # MD5 password set to
The key-chain software feature allows the user to define a set of keys bound into a chain that can then be applied to an authentication operation. The ability to define a set of keys, rather than just one, allows for easier key migration on the basis of some predetermined interval. Note the key number in this command construct is just an index rather than the "key" variable used in an MD5 context.
OSPF PE-CE Routing
OSPF also establishes authentication requirements on a per-interface basis. Additionally, authentication must be enabled for the area within the AS where authentication will be performed.
As with BGP, OSPF does not currently use the key chain methodology. Example 5-19 illustrates an OSPF authentication configuration.
Example 5-19. OSPF Authentication
router ospf 52 vrf Donald network 1.0.0.0 0.255.255.255 area 52 area 52 authentication message-digest # enables use of authentication within this ospf area for # ospf process 52 interface Ethernet0/0 ip vrf forwarding Donald ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast ip ospf authentication message-digest # establishes authentication for the neighbor across this interface ip ospf message-digest-key 13 md5 5 1Daisy3 # defines "1Daisy3" as the MD5 password to be used on this link router ospf 42 vrf Mickey network 1.0.0.0 0.255.255.255 area 42 area 42 authentication message-digest # enables use of authentication within this ospf area for # ospf process 42 interface Ethernet0/1 ip vrf forwarding Mickey ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast ip ospf authentication message-digest # establishes authentication for the neighbor across this interface ip ospf message-digest-key 13 md5 5 2minn1e7 # defines "2minn1e7" as the MD5 password to be used on this link
RIPv2 PE-CE Routing
RIP version 2 supports neighbor authentication in a similar fashion to EIGRP. Example 5-20 shows a configuration for RIPv2 authentication.
Example 5-20. RIPv2 Authentication
interface Ethernet0/0
ip vrf forwarding Daffy1
ip address 1.1.1.1 255.0.0.0
no ip directed-broadcast
ip rip authentication mode md5
#enables MD5 authentication over this rip interface
ip rip authentication key-chain Daffy1
#sets "Daffy1" as the key chain to be used for this link
key chain Daffy1
key 1
key-string 5 13Sylvester1
#creates a 'chain' known as "Daffy1" of 1 key, with the # MD5 password set to
"13Sylvester1"
PE-CE Routing Summary
The following summarizes PE-CE routing security, in order of security preference:
Static? If no dynamic routing is required (no security implications)
BGP? For redundancy and dynamic updates and inherent security features for BGP
IGPs? If BGP is not supported (limited security features such as MD-5)
Prevention of Routes from Being Accepted by Nonrecognized Neighbors
In the PE-CE dynamic routing space, the interconnections may be across multi-access media or may be misconnected in such a way that erroneous peers may be introduced. In order to prevent routes being accepted from nonrecognized neighbors, it is recommended that MD5 authentication be used between PEs and CEs that utilize dynamic protocols. If, however, this is not acceptable in a given environment, there is still a need to control the peering associations. Within BGP, this is inherently accomplished through the "neighbor" construct.
When EIGRP or RIP implemented, this functionality is not yet available for PE-CE interfaces. Without MD5, the only protection against unwanted routes would be the autonomous system numbers, which is a very weak mechanism from a protection perspective. In this environment, the distance command may be used to control acceptable route sources, as shown in Example 5-21.
Example 5-21. Distance Command
router eigrp 666 address-family ipv4 vrf VPN_20399 redistribute bgp 65000 metric 1000 100 100 1 500 network 140.0.0.0 distance 90 140.0.200.2 0.0.0.0 #defines an administrative distance of 90 (default) for eigrp routes #received from address 140.0.200.2 distance 255 0.0.0.0 255.255.255.255 #sets all other sources of routing to a value of unknown/untrusted autonomous-system 1 exit-address-family #NOTE: EIGRP requires that acceptable sources must precede the "255" source as #shown above router rip version 2 address-family ipv4 vrf VPN_20399 version 2 redistribute bgp 65000 network 140.0.0.0 distance 255 #sets all sources of routing info to a value of 255 unknown/untrusted distance 120 140.0.200.2 0.0.0.0 #sets an administrative distance of 120 (default) for rip routes received from #140.0.200.2 no auto-summary exit-address-family
BGP Maximum-Prefix Mechanism
Within an MPLS VPN environment, it is conceivable that through deliberate action or accidental misconfiguration, an excessive number of routes may be propagated from one routing peer to another. This behavior could readily impact the recipient router CPU, and if great enough, could lead to memory consumption sufficient to cause the router to disable CEF (and thereby all MPLS forwarding) or reload. This exposure exists for both the CE router and the PE router and, as such, should be controlled on both to the extent possible.
At this time, only BGP supports the concept of a maximum number of permitted prefixes. Within BGP, the maximum-prefix construct allows a user to define a maximum number of routes to be accepted from this peer. Once this maximum has been reached, the router can be configured to either issue a warning message or to restart the offending peer, with the interval to restart being configurable. In addition, a threshold may be defined where warning messages are issued prior to reaching the maximum.
Example 5-22 shows the configuration of BGP prefix limits.
Example 5-22. BGP Prefix Limit Configuration
router bgp 13 no synchronization bgp log-neighbor-changes no auto-summary address-family ipv4 vrf VPN_20499 neighbor 140.0.250.2 remote-as 500 neighbor 140.0.250.2 activate neighbor 140.0.250.2 maximum-prefix 45 80 restart 2 defines a 45 prefix maximum for routes delivered from this neighbor, with a warning
The following code reflects the console logging that occurs as the number of routes from a BGP peer reaches the threshold set for warning messages, and the subsequent peer restart once the actual maximum has been reached:
6d22h: %BGP-4-MAXPFX: No. of prefix received from 140.0.250.2 (afi 2) reaches 37, max 45 6d22h: %BGP-3-MAXPFXEXCEED: No. of prefix received from 140.0.250.2 (afi 2): 46 exceed
Once the maximum number of routes on the connection has been exceeded, the status of the BGP peer will indicate that it has been idled due to the prefix count limit having been overrun:
ESR3#sh ip bgp v a s | i 140.0.250.2 140.0.250.2 4 500 149 130 0 0 0 00:01:01 Idle (PfxCt)
For PE best practice considerations, implementing routing neighbor update authentication (MD5) and maximum-prefix for BGP updates are recommended for service provider implementations.
