Chapter 9. Service Provider Network Case Studies
In this chapter, you will learn about the following:
• How to apply IP traffic plane security techniques within an Internet transit SP network design
• How to apply IP traffic plane security techniques within an MPLS VPN SP network design
• How the combination of IP traffic plane techniques provides an effective defense in depth and breadth security architecture
The purpose of this chapter is to demonstrate the use of the security concepts and techniques described in Chapters 4 through 7 by applying them to a conceptual service provider (SP) network as case studies. The intent is to clarify your understanding of how all of these individual security techniques are brought together to form an effective defense in depth and breadth strategy that secures the SP network and each of its IP traffic planes. The same IPsec VPN and MPLS VPN case studies presented in Chapter 8 “Enterprise Network Case Studies,” are reviewed in this chapter, but now from the perspective of the SP. This chapter complements Chapter 8, which reviewed these two case studies from the perspective of enterprise networks.
Two different SP edge router configurations are studied in this chapter, including a dedicated Internet edge router and a dedicated MPLS VPN edge router. Although Internet and MPLS VPN services can be integrated onto a shared edge router with routing and address separation assured, for the purposes of this chapter, we review the security techniques applicable to Internet and MPLS VPN services separately using distinct edge router configurations. The common topology for both of these case studies is illustrated in the high-level, conceptual diagram shown in Figure 9-1. As shown in Figure 9-1, an SP IP/MPLS core network provides transport for both case studies. Customer A has three sites, two that connect directly to the SP network that is the focus of the case studies (Corporate HQ and Remote 1) and one that obtains Internet access through some other provider (Remote 2). These three Customer A sites will be used to illustrate a very common Internet access topology. Customer B also has three sites, all of which connect directly to the same SP IP/MPLS network (AS 65001). These three Customer B sites will be used to illustrate a very common MPLS VPN topology.
Figure 9-1. Conceptual View of Enterprise and Service Provider Networks for Chapters 8 and 9 Case Studies
As previously stated, the case studies in this chapter focus on the SP side of the network. That is, in each case, the focus is on the SP edge routers and their respective security requirements. In Chapter 8, the focus is on the enterprise side of the network (CPE routers) for these same case studies. Thus, Chapters 8 and 9 complement one another by sharing a common network topology whereby physical network links interconnect the enterprise and SP networks in both case studies.
The following information is presented for each of the two SP case studies in this chapter:
• The network topology, including IP addressing, and the functional requirements for each of the case study routers of focus, as appropriate
• The derived router configurations, along with detailed comments describing the relationship between specific configuration command entries and the respective contribution of each entry to IP traffic plane security
No single example case study can cover all of the many aspects of IP traffic plane security from the perspective of an SP. SP networks vary widely due to product mix, topology, services, protocols, traffic behavior, and organizational mission. Nevertheless, what should be evident from these case studies is the defense in depth and breadth methodology used to identify and protect each IP traffic plane component within the SP network presented. With this understanding, you will be able to apply similar methods and procedures to mitigate the risk of security attacks against your specific network.
Case Study 1: IPsec VPN and Internet Access
Case Study 1 focuses on a typical scenario where an SP provides Internet access to different enterprise sites. An IPsec VPN is used to connect the headquarters and remote sites of the enterprise into a private IP VPN. In this scenario, the SP simply provides Internet access to the enterprise. IPsec VPN services are provided by the CPE routers, which are managed by the enterprise itself. Hence, the SP has no awareness of IPsec VPN services used within the enterprise and, therefore, handles all traffic received from or destined to the enterprise as native IP data plane traffic. Conversely, the enterprise handles all IPsec VPN traffic within the IP services plane as described in Chapter 8. A description of the SP network topology, functional requirements, and translated security requirements follows.
Network Topology and Requirements
The SP network topology and assigned IP addressing schemes used within this case study are illustrated in Figure 9-2. Customer A has three sites with Internet access. Two sites, Corporate HQ (on the right side of the figure) and Remote 1 (on the lower-left side of the figure), obtain their Internet connectivity by direct connections to the same SP IP/MPLS network (AS 65001). The third site, Remote 2 (on the upper-left side of the figure), obtains its Internet access through a different provider.
Figure 9-2. Conceptual SP Network Architecture for Internet-Based IPsec VPN Case Study 1
The functional requirements assumed in this case study are as follows:
• Customer access to Internet: The SP network simply provides Internet transit services to the enterprise and, therefore, has no awareness of IPsec VPN services, which are fully contained within the enterprise network. Nevertheless, given that the IPsec VPN service tunnels terminate on the Customer A CPE routers, the SP network must provide remote IP reachability to the CPE routers from the wider Internet. Remote IP reachability to the CPE routers is provided exclusively through the data plane within the SP network.
• Internet access to Customer A web services: In addition to remote IP reachability to the Customer A CPE routers, Customer A requires that its public web server (172.16.0.16/32), located within the DMZ network of the HQ site, be accessible from the wider Internet. In this case study, assume that the SP installs a static route for the DMZ network address of 172.16.0.0/24 with a next hop pointing toward the Customer A router CPE-A0, and that this prefix is also advertised via eBGP to the SP’s Internet peers and, therefore, carried within the global Internet routing table.
Note
In reality, this address range is private and would never be advertised or routable within the wider Internet. This is used solely as an example for the purposes of this case study.
• Static IP default routing between SP and customer sites: Static IP default routing is used between the SP and Customer A CPE routers. Although the customer uses OSPF as its Internal Gateway Protocol (IGP), including between remote sites per Chapter 8, this is transparent to the SP because it runs above the IPsec VPN services layer. All remote traffic received from or destined to a Customer A site is handled by the SP as native IP data plane traffic per above. Note, because static routing is used, not all of the BGP security techniques outlined in Chapter 4, “Data Plane Security,” are reviewed here—specifically, those applicable to eBGP sessions, including prefix filters, prefix limits, and BGP graceful restart.
• Global Internet routing: Through a combination of Internet peering and Internet transit agreements with upstream SPs, the SP in this case study (AS 65001) carries the full Internet routing table within its global IP routing table. This enables the SP to offer Internet transit services itself to downstream customers. BGP is used to exchange prefix information with Internet peers and multi-homed customer sites. IP reachability between edge networks within the SP network is provided through OSPF, which serves as the IGP.
• Unmanaged CPE router: The SP manages its own routers in this case study via in-band methods, including the Internet edge routers and shared core (P) routers. The SP has no specific requirements for CPE router access because those routers are unmanaged (in other words, managed by the enterprise, not the SP). In this case study, it is assumed that the SP has a dedicated NOC that performs provisioning, management, and monitoring functions, and that the NOC is contained within the 192.168.252.0/22 address block. Therefore, all management plane traffic associated with the SP edge and core routers must be either sourced from or destined to a host within the 192.168.252.0/22 address block. Management applications assumed in this case study include SSH, Syslog, SNMP, NTP, TFTP, and TACACS+ only.
Figure 9-3 highlights the types and relationships of the interfaces associated with the SP Internet edge router in this case study.
Figure 9-3. IP Traffic Plane Relationships to Router Interfaces for Internet-Based IPsec VPN Case Study 1
You were first introduced to these interface types in Chapter 3, “IP Network Traffic Plane Security Concepts.” The following interfaces are included in this case study:
• External: External interfaces connect networks belonging to two different administrative domains. Hence, by definition, an edge router includes at least one external interface. In this case study, two Customer A customer edge (CE) routers, CPE-A0 and CPE-A1, connect directly to the SP network (AS 65001) via PE-00 and PE-02, respectively. CPE-A2 connects to a different SP but has IP reachability to the other Customer A sites via the Internet. For both connections of CPE-A0 and CPE-A1, the associated edge router (PE) interfaces are assumed to be Serial0/0/0. The IP addresses assigned to these PE-CE links are shown in Figure 9-2. For all external PE-CE links, /30 subnet masking is assigned.
• Internal: Internal interfaces connect network infrastructure wholly within one administrative domain. All SP edge and core routers shown in Figure 9-2 include at least two internal interfaces. Interfaces Serial1/0/0 and Serial2/0/0 of PE-00 are considered internal to the SP network. All internal interfaces within this case study are assigned from the 172.30.0.0/15 address block. The IP subnets associated with these internal interfaces are carried within the SP IGP (OSPF in this case study).
• Loopback: All SP edge and core routers shown in Figure 9-2 implement a single loopback interface that is used for control and management plane traffic. All loopback interfaces within this case study are assigned from the 192.168.1.0/24 address block, as shown in Figure 9-2. The /32 IP subnets associated with these internal interfaces are also carried within the SP IGP (OSPF in this case study).
• Receive: All routers include by default a receive interface that “logically” represents the slow path to the IOS process level on the RP. The receive path applies to any ingress packets that must be punted from the CEF fast path to be processed locally by the router’s CPU whether transit or receive adjacency packets. Because the receive path represents an exception packet processing path between the CEF fast path and IOS process level, it is not assigned or associated with a specific IP subnet. However, as you will see, control plane security features are applied to these logical interfaces.
Figure 9-3 highlights in particular the router of focus for this case study, PE-00, and illustrates the relationship among its interfaces. This router is also the focus for the sample IOS configuration that follows.
Router Configuration
Security configurations may be derived based upon the preceding topology and functional requirements. Router PE-00 is used as the focal point for the remaining discussions; however, the other Internet edge routers shown within the topology of Figure 9-2 have similar but locally specific configurations.
Example 9-1 provides the derived Cisco IOS configuration that satisfies the preceding requirements and defense in depth and breadth security principles. This configuration assumes that PE-00 is a Cisco 12000 series router (12416), and that it is running IOS Software Release 12.0(32)S with the SSH feature set. Line numbers precede each configuration command shown in Example 9-1 and serve as reference points for the remainder of the discussion that directly follows, which is organized by IP traffic plane.
Example 9-1. Case Study 1 SP Internet Edge Router PE-00 Configuration
1 : version 12.0
2 : service nagle
3 : no service pad
4 : service tcp-keepalives-in
5 : service tcp-keepalives-out
6 : service timestamps debug datetime msec localtime show-timezone
7 : service timestamps log datetime msec localtime show-timezone
8 : service password-encryption
9 : no service dhcp
10 : !
11 : hostname PE-00
12 : !
13 : boot-start-marker
14 : boot system disk0:gsr-k3p-mz.120-32.S3.bin
15 : boot-end-marker
16 : !
17 : logging buffered 4096 debugging
18 : no logging console
19 : logging monitor errors
20 : !
21 : aaa new-model
22 : aaa authentication login default tacacs+ local
23 : aaa authentication enable default tacacs+ enable
24 : aaa authorization exec default tacacs+ none
25 : aaa accounting commands 1 default start-stop tacacs+
26 : aaa accounting commands 15 default start-stop tacacs+
27 : enable secret 5 $1$rdYk$45iBa5oBI.QGmjoFDS9j00
28 : !
29 : username noc-admin secret 5 $1$z.rf$jFH3rwXPQdsXP8FxUeCV5.
30 : memory free low-watermark processor 100000
31 : ip subnet-zero
32 : no ip source-route
33 : no ip gratuitous-arps
34 : ip icmp rate-limit unreachable 100
35 : ip options drop
36 : ip cef
37 : no ip finger
38 : ip tcp window-size 32768
39 : ip tcp synwait-time 5
40 : ip tcp path-mtu-discovery
41 : no ip bootp server
42 : ip ssh time-out 20
43 : ip ssh source-interface Loopback0
44 : ip ssh version 1
45 : no ip domain-lookup
46 : ip domain-name sp-as65001.com
47 : !
48 : ip receive access-list 101
49 : !
50 : class-map match-all gold
51 : match ip precedence 4 5
52 : class-map match-all bronze
53 : match ip precedence 0 1
54 : class-map match-all control
55 : match ip precedence 6 7
56 : class-map match-all silver
57 : match ip precedence 2 3
58 : class-map match-all CoPP-management
59 : match access-group 121
60 : class-map match-all CoPP-normal
61 : match access-group 122
62 : class-map match-all CoPP-remaining-IP
63 : match access-group 124
64 : class-map match-all CoPP-undesirable
65 : match access-group 123
66 : class-map match-all CoPP-routing
67 : match access-group 120
68 : !
69 : !
70 : policy-map edge-recolor
71 : class class-default
72 : set precedence 0
73 : policy-map CoPP
74 : class CoPP-undesirable
75 : police 8000 conform-action drop exceed-action drop
76 : class CoPP-routing
77 : police 8000 conform-action transmit exceed-action transmit
78 : class CoPP-management
79 : police 50000 conform-action transmit exceed-action drop
80 : class CoPP-normal
81 : police 15000 conform-action transmit exceed-action drop
82 : class CoPP-remaining-IP
83 : police 8000 conform-action transmit exceed-action drop
84 : class class-default
85 : police 8000 conform-action transmit exceed-action transmit
86 : policy-map diffserv-qos
87 : class control
88 : bandwidth percent 20
89 : class gold
90 : bandwidth percent 40
91 : class silver
92 : bandwidth percent 30
93 : class bronze
94 : bandwidth percent 10
95 : !
96 : !
97 : !
98 : !
99 : interface Loopback0
100 : ip address 192.168.1.5 255.255.255.255
101 : no ip unreachables
102 : no ip directed-broadcast
103 : !
104 : interface Null0
105 : no ip unreachables
106 : !
107 : interface Serial0/0/0
108 : description - Link to Customer A CPE-A0 router
109 : ip address 209.165.200.225 255.255.255.252
110 : ip access-group 100 in
111 : ip verify unicast source reachable-via rx
112 : no ip redirects
113 : no ip unreachables
114 : no ip directed-broadcast
115 : encapsulation ppp
116 : ntp disable
117 : no peer neighbor-route
118 : no cdp enable
119 : service-policy input edge-recolor
120 : !
121 : interface Serial1/0/0
122 : description - Link to P-00 router
123 : mtu 4072
124 : ip address 172.31.4.1 255.255.255.252
125 : no ip directed-broadcast
126 : encapsulation ppp
127 : ip ospf message-digest-key 1 md5 7 095F4B0A0B0003
128 : service-policy output diffserv-qos
129 : !
130 : interface Serial2/0/0
131 : description - Link to P-03 router
132 : mtu 4072
133 : ip address 172.30.4.1 255.255.255.252
134 : no ip directed-broadcast
135 : encapsulation ppp
136 : ip ospf message-digest-key 1 md5 7 095F4B0A0B0003
137 : service-policy output diffserv-qos
138 : !
139 : router ospf 1
140 : router-id 192.168.1.5
141 : log-adjacency-changes
142 : area 0.0.0.0 authentication message-digest
143 : passive-interface Loopback0
144 : network 172.31.0.0 0.0.255.255 area 0.0.0.0
145 : network 172.30.0.0 0.0.255.255 area 0.0.0.0
146 : network 192.168.1.0 0.0.0.255 area 0.0.0.0
147 : !
148 : router bgp 65001
149 : bgp router-id 192.168.1.5
150 : bgp maxas-limit 100
151 : bgp log-neighbor-changes
152 : neighbor 192.168.1.2 remote-as 65001
153 : neighbor 192.168.1.2 password 7 02050D480809
154 : neighbor 192.168.1.2 update-source Loopback0
155 : !
156 : address-family ipv4
157 : redistribute static
158 : neighbor 192.168.1.2 activate
159 : neighbor 192.168.1.2 next-hop-self
160 : no auto-summary
161 : no synchronization
162 : network 172.16.0.0 mask 255.255.255.0
163 : exit-address-family
164 : !
165 : ip classless
166 : ip route 172.16.0.0 255.255.255.0 Serial0/0
167 : ip route 192.0.2.1 255.255.255.255 Null0
168 : ip route 209.165.200.0 255.255.252.0 Null0
169 : ip route 209.165.200.226 255.255.255.255 Serial0/0
170 : no ip http server
171 : !
172 : !
173 : logging trap notifications
174 : logging source-interface Loopback0
175 : logging 192.168.255.50
176 : access-list 10 permit 192.168.252.0 0.0.3.255
177 : access-list 100 deny ip any 172.30.0.0 0.1.255.255
178 : access-list 100 deny ip any 192.168.1.0 0.0.0.255
179 : access-list 100 deny ip any 192.168.252.0 0.0.3.255
180 : access-list 100 deny ip 0.0.0.0 0.255.255.255 any
181 : access-list 100 deny ip 10.0.0.0 0.255.255.255 any
182 : access-list 100 deny ip 127.0.0.0 0.255.255.255 any
183 : access-list 100 deny ip 169.254.0.0 0.255.255.255 any
184 : access-list 100 deny ip 172.16.0.0 0.0.15.255 any
185 : access-list 100 deny ip 192.0.2.0 0.0.0.255 any
186 : access-list 100 deny ip 192.168.0.0 0.0.255.255 any
187 : access-list 100 deny ip 198.18.0.0 0.1.255.255 any
188 : access-list 100 deny ip 224.0.0.0 63.255.255.255 any
189 : access-list 100 permit ip any any
190 : access-list 101 permit ospf 192.168.1.0 0.0.0.255 any precedence internet
191 : access-list 101 permit tcp host 192.168.1.2 host 192.168.1.5 eq 179
precedence internet
192 : access-list 101 permit tcp host 192.168.1.2 eq 179 host 192.168.1.5
precedence internet
193 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 22
194 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 eq 22 host 192.168.1.5
195 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 123
196 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 eq tacacs host
192.168.1.5 established
197 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 69
198 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 161
199 : access-list 101 permit icmp any any echo
200 : access-list 101 permit icmp any any echo-reply
201 : access-list 101 permit icmp any any ttl-exceeded
202 : access-list 101 permit icmp any any unreachable
203 : access-list 101 permit icmp any any port-unreachable
204 : access-list 101 permit icmp any any packet-too-big
205 : access-list 101 deny ip any any
206 : access-list 120 permit ospf 192.168.1.0 0.0.0.255 any precedence internet
207 : access-list 120 permit tcp host 192.168.1.2 host 192.168.1.5 eq 179
precedence internet
208 : access-list 120 permit tcp host 192.168.1.2 eq 179 host 192.168.1.5
precedence internet
209 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 22
210 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 123
211 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 eq tacacs host
192.168.1.5 established
212 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 69
213 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 161
214 : access-list 121 permit ip 192.168.252.0 0.0.3.255 any
215 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any echo
216 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any echo
217 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any echo
218 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any echo-reply
219 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any echo-reply
220 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any echo-reply
221 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any packet-too-big
222 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any packet-too-big
223 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any packet-too-big
224 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any ttl-exceeded
225 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any ttl-exceeded
226 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any ttl-exceeded
227 : access-list 123 permit icmp any any fragments
228 : access-list 123 permit udp any any fragments
229 : access-list 123 permit tcp any any fragments
230 : access-list 124 permit ip any any
231 : !
232 : !
233 : tacacs-server host 192.168.255.30
234 : tacacs-server timeout 2
235 : no tacacs-server directed-request
236 : tacacs-server key 7 s3cr3t
237 : snmp-server community s3cr3t RO 10
238 : snmp-server trap-source Loopback0
239 : snmp-server enable traps tty
240 : snmp-server host 192.168.255.1 version 2c s3cr3t
241 : !
242 : control-plane slot 0
243 : service-policy input CoPP
244 : control-plane slot 1
245 : service-policy input CoPP
246 : control-plane slot 2
247 : service-policy input CoPP
248 : control-plane slot 3
249 : service-policy input CoPP
250 : control-plane slot 4
251 : service-policy input CoPP
252 : control-plane slot 5
253 : service-policy input CoPP
254 : control-plane slot 6
255 : service-policy input CoPP
256 : control-plane slot 9
257 : service-policy input CoPP
258 : control-plane slot 10
259 : service-policy input CoPP
260 : control-plane slot 11
261 : service-policy input CoPP
262 : control-plane slot 12
263 : service-policy input CoPP
264 : control-plane slot 13
265 : service-policy input CoPP
266 : control-plane slot 14
267 : service-policy input CoPP
268 : control-plane slot 15
269 : service-policy input CoPP
270 : !
271 : banner motd ^C
272 : **** AUTHORIZED ACCESS ONLY *****
273 : **** This system is the property of SP AS65001.
274 : **** Disconnect IMMEDIATELY if you are not an authorized user!
275 : **** ********************** *****
276 : ^C
277 : !
278 : line con 0
279 : exec-timeout 5 0
280 : login authentication default
281 : line aux 0
282 : no exec
283 : line vty 0 4
284 : access-class 10 in
285 : access-class 10 out
286 : exec-timeout 5 0
287 : transport input ssh
288 : !
289 : process cpu threshold type total rising 80 interval 5 falling 20 interval 5
290 : ntp authentication-key 1 md5 0017400516081F 7
291 : ntp authenticate
292 : ntp trusted-key 1
293 : ntp source Loopback0
294 : ntp access-group serve-only 10
295 : ntp server 192.168.255.40 key 1
296 : no cns aaa enable
297 : !
298 : end
Data Plane
In this case study, and from the perspective of router PE-00, data plane traffic includes the following:
• Internal to internal traffic: Data plane traffic in this category includes traffic that is sourced by and destined to devices wholly within the administrative domain of the SP (AS 65001). In the case of PE-00, this includes all packets routed between the redundant uplinks (that is, only those packets routed between Serial1/0/0 and Serial2/0/0). Many SP network designs are architected such that internal to internal data plane traffic is routed exclusively through core routers and not through edge routers except during multiple core failure conditions. In this way, the PE-00 uplink interface capacity is used exclusively for traffic routed between internal and external interfaces and, of course, control and management plane protocols. Hence, in this case study and from the perspective of PE-00, no data plane traffic is included in this category.
• Internal to external traffic: Data plane traffic in this category includes traffic that is sourced within the SP internal infrastructure but destined to external networks outside the SP’s administrative domain. Support for such internal to external traffic forwarding is required by some external applications such as IP traceroute and Path MTU Discovery (PMTUD). For the purposes of this case study and from the perspective of PE-00, this type of internal to external data plane traffic is limited to certain ICMP types—for example, Fragmentation Needed but Do Not Fragment Bit Set (Message Type 3, Code 4) and Time Exceeded (Message Type 11)—and comes from internal interfaces within the SP internal infrastructure prefix range 172.30.0.0/15.
• External to internal traffic: Data plane traffic in this category includes traffic that is sourced externally and destined for internal SP infrastructure, such as in the case of SPs with hosted content. However, in this case study and from the perspective of PE-00, no legitimate data plane traffic is included in this category. Therefore, such traffic is filtered at the network edge to mitigate the risk of an attack against the internal SP infrastructure.
• External to external traffic: Data plane traffic in this category includes traffic that is sourced externally and destined to an external network. Such traffic requires transit from the SP and possibly the wider Internet for remote connectivity. For SPs, this often represents the vast majority of the data plane traffic seen within the network. In this case study and from the perspective of PE-00, this includes any traffic that ingresses an external interface, such as Serial0/0/0, and that is destined to a prefix only reachable through another external interface. The egress external interface can exist on either PE-00 or a different edge router within the SP network (AS 65001). Either way, external to external traffic simply transits the SP network.
Data Plane Security
From the perspective of PE-00, the techniques used for data plane security include the following:
• Interface ACL: A combined infrastructure and antispoofing ACL is applied to the Serial0/0/0 interface to filter any ingress traffic destined to SP internal infrastructure, including the SP NOC, and any special-use and reserved IP addresses (per RFC 3330). This policy is defined through the extended ACL 100 (lines 177 through 189), which is attached to the Serial0/0/0 interface in the input direction on line 110. Note that this input ACL applies to all ingress traffic. Because PE-00 exchanges only data plane packets with CPE-A0, no permit ACL entries are included for control, management, and services plane traffic. The only traffic that is filtered is traffic destined to internal SP infrastructure addresses and spoofed traffic that is using special-use and reserved IP addresses. All other traffic is allowed. Although it is possible for the SP to also configure an egress ACL on Serial0/0/0 as well, rarely would it do so for unmanaged Internet access customers. In this case, Customer A has taken the responsibilities for managing its Internet access (CPE) router itself, as was described in Chapter 8. The interface ACL policy mitigates the risk of both direct attacks against the SP internal infrastructure and spoofing attacks using special-use and reserved IP addresses.
• uRPF: Unicast RPF strict mode is deployed on the PE-00 external interface to Customer A for antispoofing protection. The use of uRPF strict mode will filter (drop) any ingress traffic sourced from outside the Customer A HQ network public address blocks, including 172.16.0.0/24 and 209.165.200.226/32. Only ingress traffic having an IP source address within these two address blocks is permitted by uRPF strict mode. Configuration line 111 enables uRPF for antispoofing protection on the Serial0/0/0 interface. The uRPF policy mitigates the risk of spoofing attacks.
• QoS: QoS is deployed within the SP network in support of differentiated services and to isolate important control plane traffic from the other IP traffic planes. The associated policy map (lines 86 through 94) and class maps (lines 50 through 57) are defined using MQC. The policy is then attached to the PE-00 uplink interfaces, including Serial1/0/0 and Serial2/0/0 per lines 128 and 137. If the PE-00 uplinks become congested, QoS will reserve 20 percent of uplink bandwidth for control plane traffic. To ensure that low-priority external traffic does not inadvertently or maliciously enter the high-priority traffic classes (in other words, gold, silver, control), a QoS recoloring policy is applied to Internet access ports, including the PE-00 serial interface (Serial0/0/0) to CPE-A0 (line 119). The associated policy (lines 70 through 72) simply recolors all traffic with IP precedence 0. This prevents any transit Internet traffic from being classified into the SP’s high-priority traffic classes. Hence, the queuing and recoloring policies mitigate the risk of resource (bandwidth) exhaustion attacks against high-priority traffic classes including control plane protocols.
• IP options: IP packets with option headers are filtered by the ip options drop global configuration command (line 35). The IOS default behavior of IP source routing is also disabled with the no ip source-route global configuration command (line 32). Disabling IP options in this way mitigates the risk of IP options–based attacks.
• ICMP techniques: On a per-interface basis, several ICMP best common practices (BCP) are also applied. ICMP Destination Unreachable and Redirect message generation is disabled using the no ip unreachables (line 113) and no ip redirects (line 112) interface configuration commands, respectively. Global rate limiting of ICMP Destination Unreachable message generation is also enabled via line 34. ICMP Information Request and Address Mask Request processing is disabled by default within IOS; hence, the no ip information-reply and no ip mask-reply interface commands are applied by default. Disabling ICMP processing in this way mitigates the risk of transit IP data plane attacks and ICMP-based control plane attacks.
• IP directed broadcasts: The dropping of IP directed broadcast packets is the default behavior in IOS 12.0(32)S and, hence, the no ip directed-broadcast interface command is applied by default (line 114). Earlier versions of IOS forwarded IP directed broadcast packets by default. You should confirm the default behavior for your IOS release in order to properly mitigate the risk of directed broadcast based attacks.
• Edge router external link protection: Whereas IP reachability from the wider Internet to the CPE-A0 Serial0/0 interface is required for IPsec VPN services as outlined previously, it is not required to the PE-00 Serial0/0/0 interface. To mitigate the risk of remote attacks against PE routers that leverage IP reachable external interface addresses, an aggregate static route to Null0 is configured on every edge and core router within the SP network (line 168). As a result, remote external traffic destined to an external PE-CE (Internet access) interface is now discarded as described in detail in Chapter 4. Because this configuration has the additional impact of making local eBGP next hops no longer reachable, BGP next-hop-self (line 159) must be set for iBGP sessions. Further, to maintain IP reachability to CPE-A0 in support of IPsec VPN and NAT services, a static route for the host prefix 209.165.200.226/32 is also configured (line 169) and redistributed into iBGP (line 157). The no peer neighbor-route command (line 117) is also configured on the Serial0/0 interface to ensure that the 209.165.200.226/32 connected prefix does not appear in the router RIB, which would prevent the 209.165.200.226/32 static route from being redistributed into iBGP. Redistributing 209.165.200.226/32 into iBGP enables remote IP reachability to CPE-A0 in support of IPsec VPN services. Note that the generation of ICMP Destination Unreachable messages is also disabled on the Null0 interface via line 105. This is important, because without this configuration, ICMP Destination Unreachable messages would be generated by the Null0 interface, possibly causing high CPU utilization. (Note that the Null0 interfaces will not appear in the router configuration unless default interface configuration parameters are modified, such as no ip unreachables.) The PE-CE link protection policy using an aggregate static route to Null0 mitigates the risk of remote attacks against PE external interfaces.
• Remotely triggered black hole (RTBH) filtering: As detailed in Chapter 4, RTBH mechanisms must be predeployed before they can be used for security incident response. The configuration necessary on PE-00 is simply a static route to the Null0 interface (line 167). This prepares the router for destination-based RTBH filtering, which would be invoked by a remote trigger router. Because uRPF is also enabled on PE-00, as described previously in this list, source-based RTBH filtering can also be invoked by a remote trigger router.
Control Plane
In this case study, and from the perspective of router PE-00, control plane traffic includes the following:
• IGP traffic: The SP uses OSPF as its IGP, which is enabled on all internal and loopback interfaces throughout the SP infrastructure. Because static IP default routing is used by the Customer A CPE routers, neither OSPF nor BGP is enabled on the PE-00 external interface to CPE-A0. Although Customer A uses OSPF as its IGP between remote sites, it runs within the IPsec VPN services layer, and hence appears as native data plane traffic to the PE-00. Further, these two instances of OSPF are completely unique because they support completely unrelated administrative domains. Therefore, no OSPF adjacencies are formed between PE-00 and CPE-A0. In the case of PE-00, OSPF is enabled on the uplinks, which represent the 172.30.4.1/30 and 72.31.4.1/30 networks, and on the 192.168.1.5/32 prefix associated with Loopback0.
• BGP: Although eBGP is not used between PE-00 and CPE-A0, iBGP is enabled on all edge and core routers within the SP network in support of interdomain (Internet) routing.
• Layer 2 keepalives: L2 keepalives will be used on all of the Serial interfaces of PE-00. L2 keepalives are not used for Ethernet nor are they applicable to virtual interfaces such as Loopback0.
Control Plane Security
From the perspective of PE-00, the techniques used for control plane security include the following:
• Selective Packet Discard (SPD): SPD is turned on by default, and on 12000 series routers, aggressive mode is the only mode available. Hence, no additional configuration is required. The hold-queue, headroom, and extended headroom default settings are adequate as well.
• IP Receive ACLs: An IP rACL is applied to filter unauthorized traffic destined to the IOS process level on PE-00. Configuration lines 190 through 205 define the IP rACL policy using the extended ACL 101, which is then applied to the receive interface in the inbound direction on line 48. All traffic flows are denied by the IP rACL except for the following:
— OSPF traffic sourced from 192.168.1.0/24 and with IP precedence 6 (line 190).
— BGP traffic sourced from an internal BGP route reflector (192.168.1.2/24) and with IP precedence 6 (lines 191 and 192).
— Management traffic sourced from the SP NOC 192.168.252.0/22 (lines 193 through 198).
— Several types of ICMP packets (management plane traffic) must be permitted by the rACL for operational needs (Echo Reply, Time Exceeded, and certain IP destination unreachables). These ACE rules are configured on lines 199 through 204.
Per Chapter 5, “Control Plane Security,” all CEF receive adjacency traffic has to be accounted for within the IP rACL policy, including both control and management plane traffic. IP rACLs mitigate the risk of unauthorized (attack) traffic from reaching the IOS process level.
• Control Plane Policing (CoPP): CoPP is enabled to protect IOS process level functions, including control and management plane services. Only distributed CoPP is enabled by applying MQC service policies to the control plane, as shown on lines 242 through 269. The associated MQC policies that permit, deny, or rate limit control and management plane traffic flows are defined via lines 73 through 85. The MQC class maps and extended ACLs used for CoPP packet classification are configured via lines 58 through 67, and 206 through 230, respectively. Because the catch-all CoPP-remaining-IP traffic class (line 82) directly precedes it, the class-default portion of the CoPP policy map (lines 84 and 85) accounts for all Layer 2 keepalive traffic only. Note, the routing and class-default traffic classes are unpoliced. The management, normal (ICMP), and remaining IP traffic classes are rate limited. Traffic classified into the undesirable class is dropped. Per Chapter 5, all IOS process level traffic has to be accounted for within the CoPP policy, including control and management plane traffic as well as exception data plane traffic. CoPP mitigates the risk of unauthorized traffic and exception IP transit traffic from reaching the IOS process level.
• OSPF MD5 authentication: OSPF is enabled on lines 139 through 146. Further, within the OSPF routing process itself, passive-interface is configured for the Loopback0 interface, as shown on line 143. MD5 authentication for configured OSPF areas is also enabled (line 142). MD5 authentication passwords are configured on each of the internal physical interfaces, including Serial1/0/0 (line 127) and Serial2/0/0 (line 136). Note that even though the prefix associated with Loopback0 is enabled for OSPF, this interface does not require the MD5 key to be applied because it is a virtual interface and no adjacency is formed. MD5 authentication helps to mitigate the risk of attacks against OSPF.
• BGP MD5 authentication: BGP is enabled on lines 148 through 163. BGP MD5 authentication (line 153) is enabled between PE-00 and the BGP route reflector (192.168.1.2/32) within the SP network. MD5 authentication helps to mitigate the risk of attacks against BGP.
Management Plane
In this case study, and from the perspective of router PE-00, in-band management plane traffic includes the following:
• Provisioning traffic: Management plane traffic in this category includes SSH and TFTP traffic and must be sourced internally from the SP NOC (192.168.252.0/22). Telnet and HTTP are not permitted. In the case of PE-00, ingress management traffic of this type will be destined to the 192.168.1.5/32 address of Loopback0. Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix of the SP NOC.
• Monitoring traffic: Management plane traffic in this category includes SNMP, NetFlow, and Syslog, and this traffic is only authorized to and from the internal network. In the case of PE-00, ingress SNMP traffic will be destined to the 192.168.1.5/32 address of Loopback0. Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix of the SP NOC. Local NetFlow collectors are not included in this case study, which would generally require export to an internal address outside of the SP NOC 192.168.252.0/22 address block.
• Other traffic: Several other protocols are configured within the management plane, including NTP, DNS, and TACACS+. In the case of PE-00, management traffic of this type will all be within the SP NOC 192.168.252.0/22 address block. In addition, several types of ICMP packets must be permitted by the IP rACL and CoPP policies (see the preceding “Control Plane” section) for operational needs, including ICMP Echo Request, Echo Reply, Time Exceeded, and specific IP Unreachable types. CDP is disabled on external interfaces but enabled on internal interfaces.
• Out-of-band traffic: The console interface is used for OOB management access. Management Plane Security From the perspective of PE-00, the techniques used for management plane security include the following:
Management Plane Security
From the perspective of PE-00, the techniques used for management plane security include the following:
• Out-of-band management: Password authentication is enabled for terminal access using the console port (line 280). Password authentication mitigates the risk of unauthorized access.
• SNMP: SNMP parameters are configured via lines 237 through 240, which includes sending SNMP traps in v2c format to the SP NOC (line 240). Only read-only SNMP access is allowed (line 237) given that no read-write community string is configured. Further, SNMP read access is restricted to sources permitted within the SNMP configured standard ACL 10 (line 176). SNMP packets greater than 1500 bytes are also discarded, given the IOS default behavior for snmp-server packetsize. These SNMP security techniques mitigate the risk of unauthorized access and network reconnaissance.
• Disable unused services:
— BOOTP: BOOTP services are disabled on line 41.
— CDP: CDP is disabled on external interfaces only (line 118).
— DHCP: DHCP server functions are disabled on line 9.
— DNS-based host name-to-address translation: DNS-based name resolution by the router is disabled on line 45.
— EXEC mode: Because the auxiliary port is not used for in-band or out-of-band management, EXEC mode is disabled (line 282) on the auxiliary port.
— Finger service: The finger service is disabled on line 37.
— HTTP server: The (unsecure) HTTP server is disabled on line 170.
— Minor servers: Both the minor TCP and UDP servers are disabled by default within IOS.
— NTP: NTP is disabled on external interfaces only (line 116). The NTP configuration associated with internal interfaces is described later in this list.
— PAD: The PAD service is disabled on line 3.
These management plane security techniques mitigate the risk of unauthorized access and network reconnaissance.
• AAA: AAA is fully enabled for authentication, authorization, and accounting. This begins with the aaa new-model configuration command (line 21). TACACS+ serves as the primary authentication mechanism (lines 22 and 23) for both user-level and privilege-level (enable) EXEC mode access. If PE-00 loses IP connectivity to the TACACS+ server for whatever reason, local username/password authentication will be used for user-level EXEC mode access (line 22) and enable password authentication will be used for privilege-level (enable) EXEC mode access (line 23). A local noc-admin username and password is configured (lines 29) in support of local username/ password authentication. The enable secret is configured (line 27) in support of enable password authentication. Command authorization is configured to use TACACS+ and then none (in other words, no authorization) if IP connectivity to the TACACS+ server is lost (line 24). Command accounting is also configured to use TACACS+ (lines 25 and 26). The TACACS+ server-related parameters are configured via lines 233 through 236. The configuration of the TACACS+ server itself is outside the scope of this book. The preceding AAA policies mitigate the risk of unauthorized access and provide user accounting.
• SSH services: Configuring SSH requires that an IP domain name be specified (for RSA key generation). This is done via line 46. The RSA encryption key is generated outside the configuration during router setup. SSH protocol parameters are configured on lines 42 through 44, and VTY lines are restricted to SSH transport (line 287). Remote terminal access is further restricted to sources matching ACL 10, per lines 284 and 285. SSH provides secure remote terminal access to IP routers. As such, it mitigates the risk of session eavesdropping, which may compromise router configurations, passwords, and so on and be leveraged for an attack.
• Disable idle user sessions: Idle EXEC sessions are disabled after 5 minutes (lines 279 and 286). Further, TCP keepalives are enabled via lines 5 and 6 and serve to terminate connections where the remote host disappears (provide no positive acknowledgement [ACK]). Disabling idle user sessions in this way reduces the risk of unauthorized access.
• NTP: NTP is enabled to facilitate correlation of network events (line 290 through 295). Ingress NTP protocol messages are restricted to sources permitted within the NTP configured standard ACL 10 (line 294). Further, MD5 authentication is enabled for NTP protocol message exchanged with the configured NTP server (lines 290 through 292 and line 295). MD5 authentication helps to mitigate the risk of attacks against NTP, which is valuable for network event correlation, including security incident response.
• Syslog: Syslog parameters are configured on lines 173 through 175, which includes directing Syslog messages to the SP NOC (line 175). Timestamps are also appended to each Syslog (and debug) message per lines 7 and 8. In addition, Syslog is configured to report OSPF adjacency changes (line 141) and BGP neighbor state changes (line 151). In order to generate Syslog messages when free memory resources are low, low-watermark levels are set for processor memory on line 30. Further, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 289. Syslog provides valuable network telemetry and is useful for security incident response.
• Other BCPs: Other BCP router security configurations related to the management plane are implemented. The router host name is configured on line 11. Global service settings are modified, including enabling timestamps for all debug and logging messages (lines 6 and 7) and enabling password encryption services (line 8). The router boot image is specified on line 14 (lines 13 and 15 are auto-generated). Buffered logging is enabled at debug level and the buffer size is set (line 17). The display of logging messages to the console is disabled (line 18). The enable secret is set on line 27. Several global settings for router self-generated TCP sessions are adjusted, including enabling Nagle services (line 2), enabling TCP keepalives per “Disable idle user sessions” above (lines 4 and 5), increasing the TCP window size (line 38), reducing the TCP SYN wait time (line 39), and enabling PMTUD (line 40). In order to generate Syslog messages when free memory resources are low, a low-watermark level is set for processor memory on line 30. A message of the day (MOTD) login banner is configured on lines 271 through 276. Finally, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 289.
Services Plane
In this case study, there are no services plane requirements from the perspective of router PE-00. All services plane requirements occur on the customer side of the network in the form of GRE + IPsec VPNs, and are instantiated on the CPE routers as was demonstrated in Chapter 8.
Case Study 2: MPLS VPN
Case Study 2 focuses on a typical scenario where an MPLS VPN service is used to connect customer headquarters and remote sites within a private IP VPN across the SP’s shared IP network infrastructure. A description of the case study network topology, functional requirements, and translated security requirements follows.
Network Topology and Requirements
The SP network topology and assigned IP addressing schemes used within this case study are illustrated in Figure 9-4. Customer B has three sites connected using a managed MPLS VPN service, and all three sites obtain their any-to-any VPN connectivity by direct connections to the same SP network. Hence, the Inter-AS VPN architectural options (a), (b), and (c) per RFC 4364 section 10 (see Chapter 2, “Threat Models for IP Networks,” and Chapter 7, “Services Plane Security”) do not apply to this case study. The configurations and security techniques for the managed CE routers are reviewed in the companion enterprise case study in Chapter 8.
Figure 9-4. Conceptual Enterprise Network Architecture for MPLS VPN Case Study 2
The functional requirements assumed in this case study are as follows:
• MPLS VPN: The SP (AS 65001) provides any-to-any IP VPN connectivity between all of the geographically disperse Customer B offices. The IP VPN is built within the SP network using RFC 4364 MPLS VPNs. BGP routing is used between the Customer B CE routers and the associated SP MPLS VPN PE routers to exchange Customer B prefix information. The SP in turn carries these customer-specific prefixes within Multiprotocol BGP (MBGP) to provide reachability between customer sites within a single customer IP VPN and to provide addressing and routing separation between different customer IP VPNs.
• Intranet Access: Access to Customer B’s MPLS VPN and associated network prefixes is restricted to Customer B offices only. There is no Internet access from the Customer B VPN, or vice versa. External IP reachability is only provided between the CE router loopback addresses and the SP NOC for management purposes given that the Customer B CE routers are managed (as described directly below).
• Managed CE router: All Customer B CE routers are managed by the SP. For operational reasons, then, the SP must have in-band access to each managed CE router. The SP also manages the MPLS VPN PE and core (P) routers. The PE and P routers are managed both in-band and out-of-band using the console ports. Management applications assumed in this case study include SSH, Syslog, SNMP, NTP, TFTP, and TACACS+.
Figure 9-5 highlights the types and relationships of the interfaces associated with the MPLS VPN PE router in this case study.
Figure 9-5. IP Traffic Plane Relationships to Router Interfaces for MPLS VPN Case Study 2
You were first introduced to these interface types in Chapter 3. The following interfaces are included in this case study:
• Internal: Internal interfaces connect network assets wholly within one administrative domain. All SP routers shown in Figure 9-4 include at least two internal interfaces. In this case study, interfaces Serial1/0/0 and Serial2/0/0 of PE-03 are considered internal to the SP network. For all internal interfaces, /30 subnet masking is used for the purposes of this case study. The prefixes associated with these internal interfaces are routable within the IGP (OSPF in this case study). External reachability to these internal prefixes is not allowed per the MPLS VPN architecture, as outlined in Chapter 7.
• External: External interfaces connect networks belonging to two different administrative domains. All SP MPLS VPN edge (PE) routers include at least one external interface. Hence, by definition, an edge router normally includes at least one external interface. In the MPLS VPN case, the PE-CE link is contained within a VRF. Although the VRF routing table is customer specific, it is associated with customer routing and not the SP IGP. Hence, from the SP perspective, the PE-CE link is considered external. Conversely, from the enterprise perspective, because the link is contained within the IP VPN, it may be treated as internal, per Chapter 8.
• Loopback: All SP edge and core routers shown in Figure 9-4 implement a single loopback interface that is used for control and management plane traffic. All loopback interfaces within this case study are assigned from the 192.168.1.0/24 address block, as shown in Figure 9-4. The /32 IP subnets associated with these internal interfaces are also carried within the SP IGP (OSPF in this case study).
• Receive: All routers include by default a receive interface that “logically” represents the slow path to the IOS process level. The receive path applies to any ingress packets that must be punted from the CEF fast path to be processed locally by the router’s CPU whether transit or receive adjacency packets. Because the receive path represents an exception packet processing path between the CEF fast path and IOS process level, it is not assigned or associated with a specific IP subnet.
Figure 9-5 highlights in particular the router of focus for this case study, PE-03, and illustrates the relationship among its interfaces. This router is also the focus for the sample IOS configuration that follows.
Router Configuration
Security configurations may be derived based upon the topology and functional requirements presented in the preceding section. Router PE-03 is used as the focal point for the remaining discussions; however, the other MPLS VPN PE routers shown in the topology in Figure 9-4 have similar but locally specific configurations. Note that PE-02 represents a shared edge router supporting both Internet and MPLS services.
Example 9-2 provides the derived IOS configuration that satisfies the preceding requirements and the defense in depth and breadth security principles. This configuration assumes that PE-03 is a Cisco 12000 series router (12416), and that it is running Cisco IOS Software Release 12.0(32)S with the SSH feature set. Similar to Example 9-1, line numbers precede each configuration command shown in Example 9-2 and serve as reference points for the remainder of the discussion that directly follows, which is organized by IP traffic plane.
Example 9-2. Case Study 2 SP MPLS VPN Provider Edge Router Configuration
1 : version 12.0
2 : service nagle
3 : no service pad
4 : service tcp-keepalives-in
5 : service tcp-keepalives-out
6 : service timestamps debug datetime msec localtime show-timezone
7 : service timestamps log datetime msec localtime show-timezone
8 : service password-encryption
9 : no service dhcp
10 : !
11 : hostname PE-03
12 : !
13 : boot-start-marker
14 : boot system disk0:gsr-k3p-mz.120-32.S3.bin
15 : boot-end-marker
16 : !
17 : logging buffered 4096 debugging
18 : no logging console
19 : logging monitor errors
20 : aaa new-model
21 : aaa authentication login default tacacs+ local
22 : aaa authentication enable default tacacs+ enable
23 : aaa authorization exec default tacacs+ none
24 : aaa accounting commands 1 default start-stop tacacs+
25 : aaa accounting commands 15 default start-stop tacacs+
26 : enable secret 5 $1$rdYk$45iBa5oBI.QGmjoFDS9j00
27 : !
28 : username noc-admin secret 5 $1$z.rf$jFH3rwXPQdsXP8FxUeCV5.
29 : memory free low-watermark processor 100000
30 : ip subnet-zero
31 : no ip source-route
32 : no ip gratuitous-arps
33 : ip icmp rate-limit unreachable 100
34 : ip options drop
35 : ip cef
36 : no ip finger
37 : ip tcp window-size 32768
38 : ip tcp synwait-time 5
39 : ip tcp path-mtu-discovery
40 : no ip bootp server
41 : ip ssh time-out 20
42 : ip ssh source-interface Loopback0
43 : ip ssh version 1
44 : no ip domain-lookup
45 : ip domain-name sp-as65001.com
46 : !
47 : ip vrf CustB-VPN
48 : rd 65001:10
49 : export map mgmtvpn-filter
50 : route import 65001:10
51 : route export 65001:10
52 : route import 65001:20
53 : maximum routes 1000 90
54 : !
55 : mpls label protocol ldp
56 : mpls ldp neighbor 192.168.1.2 password 7 04480E051D2458
57 : no mpls ip propagate-ttl forwarded
58 : tag-switching advertise-tags for 91
59 : !
60 : ip receive access-list 101
61 : !
62 : class-map match-any gold
63 : match ip precedence 4 5
64 : match mpls experimental 4 5
65 : class-map match-any bronze
66 : match ip precedence 0 1
67 : match mpls experimental 0 1
68 : class-map match-any silver
69 : match ip precedence 2 3
70 : match mpls experimental 2 3
71 : class-map match-any control
72 : match ip precedence 6 7
73 : match mpls experimental 6 7
74 : class-map match-all CoPP-management
75 : match access-group 121
76 : class-map match-all CoPP-normal
77 : match access-group 122
78 : class-map match-all CoPP-remaining-IP
79 : match access-group 124
80 : class-map match-all CoPP-undesirable
81 : match access-group 123
82 : class-map match-all CoPP-routing
83 : match access-group 120
84 : !
85 : policy-map edge-recolor
86 : class class-default
87 : set mpls experimental imposition 0
88 : policy-map CoPP
89 : class CoPP-undesirable
90 : police 8000 conform-action drop exceed-action drop
91 : class CoPP-routing
92 : police 8000 conform-action transmit exceed-action transmit
93 : class CoPP-management
94 : police 50000 conform-action transmit exceed-action drop
95 : class CoPP-normal
96 : police 15000 conform-action transmit exceed-action drop
97 : class CoPP-remaining-IP
98 : police 8000 conform-action transmit exceed-action drop
99 : class class-default
100 : police 8000 conform-action transmit exceed-action transmit
101 : policy-map diffserv-qos
102 : class control
103 : bandwidth percent 20
104 : class gold
105 : bandwidth percent 40
106 : class silver
107 : bandwidth percent 30
108 : class bronze
109 : bandwidth percent 10
110 : !
111 : !
112 : !
113 : !
114 : interface Loopback0
115 : ip address 192.168.1.1 255.255.255.255
116 : no ip unreachables
117 : no ip directed-broadcast
118 : !
119 : interface Null0
120 : no ip unreachables
121 : !
122 : interface Serial0/0/0
123 : description - Link to Customer B CE-B0 router
124 : ip vrf forwarding CustB-VPN
125 : ip address 209.165.200.241 255.255.255.252
126 : ip access-group 100 in
127 : no ip redirects
128 : no ip unreachables
129 : no ip directed-broadcast
130 : encapsulation ppp
131 : ntp disable
132 : no cdp enable
133 : service-policy input edge-recolor
134 : !
135 : interface Serial1/0/0
136 : description - Link to P-03 router
137 : mtu 4072
138 : ip address 172.31.5.1 255.255.255.252
139 : no ip directed-broadcast
140 : encapsulation ppp
141 : mpls label protocol ldp
142 : tag-switching ip
143 : ip ospf message-digest-key 1 md5 7 095F4B0A0B0003
144 : service-policy output diffserv-qos
145 : !
146 : interface Serial2/0/0
147 : description - Link to P-00 router
148 : mtu 4072
149 : ip address 172.30.5.1 255.255.255.252
150 : no ip directed-broadcast
151 : encapsulation ppp
152 : mpls label protocol ldp
153 : tag-switching ip
154 : ip ospf message-digest-key 1 md5 7 095F4B0A0B0003
155 : service-policy output diffserv-qos
156 : !
157 : router ospf 1
158 : router-id 192.168.1.1
159 : log-adjacency-changes
160 : area 0.0.0.0 authentication message-digest
161 : passive-interface Loopback0
162 : network 172.31.0.0 0.0.255.255 area 0.0.0.0
163 : network 172.30.0.0 0.0.255.255 area 0.0.0.0
164 : network 192.168.1.0 0.0.0.255 area 0.0.0.0
165 : !
166 : router bgp 65001
167 : bgp router-id 192.168.1.1
168 : bgp maxas-limit 100
169 : bgp log-neighbor-changes
170 : neighbor 192.168.1.2 remote-as 65001
171 : neighbor 192.168.1.2 password 7 02050D480809
172 : neighbor 192.168.1.2 update-source Loopback0
173 : neighbor 209.165.200.242 remote-as 65002
174 : neighbor 209.165.200.242 update-source Serial0/0
175 : !
176 : address-family ipv4
177 : no neighbor 192.168.1.2 activate
178 : no neighbor 209.165.200.242 activate
179 : no auto-summary
180 : no synchronization
181 : exit-address-family
182 : !
183 : address-family vpnv4
184 : neighbor 192.168.1.2 activate
185 : neighbor 192.168.1.2 send-community both
186 : no auto-summary
187 : no synchronization
188 : exit-address-family
189 : !
190 : address-family ipv4 vrf CustB-VPN
191 : redistribute connected
192 : neighbor 209.165.200.242 remote-as 65002
193 : neighbor 209.165.200.242 update-source Serial0/0
194 : neighbor 209.165.200.242 activate
195 : neighbor 209.165.200.242 maximum-prefix 250 restart 2
196 : neighbor 209.165.200.242 ttl-security hops 1
197 : no auto-summary
198 : no synchronization
199 : exit-address-family
200 : !
201 : ip classless
202 : !
203 : no ip http server
204 : !
205 : logging trap notifications
206 : logging source-interface Loopback0
207 : logging 192.168.255.50
208 : access-list 10 permit 192.168.252.0 0.0.3.255
209 : access-list 90 permit 209.165.200.240 0.0.0.3
210 : access-list 91 permit 192.168.1.0 0.0.0.255
211 : access-list 100 permit ip 209.165.200.242 0.0.0.0 192.168.252.0 0.0.3.255
212 : access-list 100 permit ip 209.165.200.242 0.0.0.0 209.165.200.241 0.0.0.0
213 : access-list 100 deny ip any 192.168.252.0 0.0.3.255
214 : access-list 100 deny ip any 209.165.200.241 0.0.0.0
215 : access-list 100 permit ip any any
216 : access-list 101 permit ospf 192.168.1.0 0.0.0.255 any precedence internet
217 : access-list 101 permit tcp host 192.168.1.2 host 192.168.1.5 eq 179
precedence internet
218 : access-list 101 permit tcp host 192.168.1.2 eq 179 host 192.168.1.5
precedence internet
219 : access-list 101 permit tcp host 209.165.200.242 host 209.165.200.241 eq 179
precedence internet
220 : access-list 101 permit tcp host 209.165.200.242 eq 179 host 209.165.200.241
precedence internet
221 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 22
222 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 123
223 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 eq tacacs host
192.168.1.5 established
224 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 69
225 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 161
226 : access-list 101 permit ip 192.168.252.0 0.0.3.255 any
227 : access-list 101 permit udp 192.168.1.0 0.0.0.255 any eq 646 precedence
internet
228 : access-list 101 permit udp 192.168.1.0 0.0.0.255 eq 646 any precedence
internet
229 : access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 646 precedence
internet
230 : access-list 101 permit tcp 192.168.1.0 0.0.0.255 eq 646 any precedence
internet
231 : access-list 101 permit icmp any any echo
232 : access-list 101 permit icmp any any echo-reply
233 : access-list 101 permit icmp any any ttl-exceeded
234 : access-list 101 permit icmp any any unreachable
235 : access-list 101 permit icmp any any port-unreachable
236 : access-list 101 permit icmp any any packet-too-big
237 : access-list 101 deny ip any any
238 : access-list 120 permit ospf 192.168.1.0 0.0.0.255 any precedence internet
239 : access-list 120 permit tcp host 192.168.1.2 host 192.168.1.1 eq 179
precedence internet
240 : access-list 120 permit tcp host 192.168.1.2 eq 179 host 192.168.1.5
precedence internet
241 : access-list 120 permit tcp host 209.165.200.242 host 209.165.200.241 eq 179
precedence internet
242 : access-list 120 permit tcp host 209.165.200.242 eq 179 host 209.165.200.241
precedence internet
243 : access-list 120 permit udp 192.168.1.0 0.0.0.255 any eq 646 precedence
internet
244 : access-list 120 permit udp 192.168.1.0 0.0.0.255 eq 646 any precedence
internet
245 : access-list 120 permit tcp 192.168.1.0 0.0.0.255 any eq 646 precedence
internet
246 : access-list 120 permit tcp 192.168.1.0 0.0.0.255 eq 646 any precedence
internet
247 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 22
248 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 123
249 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 eq tacacs host
192.168.1.5 established
250 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 69
251 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 161
252 : access-list 121 permit ip 192.168.252.0 0.0.3.255 any
253 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any echo
254 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any echo
255 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any echo
256 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any echo-reply
257 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any echo-reply
258 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any echo-reply
259 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any packet-too-big
260 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any packet-too-big
261 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any packet-too-big
262 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any ttl-exceeded
263 : access-list 122 permit icmp 192.168.1.0 0.0.0.255 any ttl-exceeded
264 : access-list 122 permit icmp 209.165.200.0 0.0.3.255 any ttl-exceeded
265 : access-list 123 permit icmp any any fragments
266 : access-list 123 permit udp any any fragments
267 : access-list 123 permit tcp any any fragments
268 : access-list 124 permit ip any any
269 : !
270 : tacacs-server host 192.168.255.30
271 : tacacs-server timeout 2
272 : no tacacs-server directed-request
273 : tacacs-server key 7 s3cr3t
274 : snmp-server community s3cr3t RO 10
275 : snmp-server trap-source Loopback0
276 : snmp-server enable traps tty
277 : snmp-server host 192.168.255.1 vrf CustB-VPN s3cr3t
278 : snmp-server host 192.168.255.1 version 2c s3cr3t
279 : !
280 : route-map mgmtvpn-filter permit 10
281 : match ip address 90
282 : set ext-community rt 65001:10 65001:30
283 : !
284 : tag-switching tdp router-id Loopback0
285 : control-plane slot 0
286 : service-policy input CoPP
287 : control-plane slot 1
288 : service-policy input CoPP
289 : control-plane slot 2
290 : service-policy input CoPP
291 : control-plane slot 3
292 : service-policy input CoPP
293 : control-plane slot 4
294 : service-policy input CoPP
295 : control-plane slot 5
296 : service-policy input CoPP
297 : control-plane slot 6
298 : service-policy input CoPP
299 : control-plane slot 9
300 : service-policy input CoPP
301 : control-plane slot 10
302 : service-policy input CoPP
303 : control-plane slot 11
304 : service-policy input CoPP
305 : control-plane slot 12
306 : service-policy input CoPP
307 : control-plane slot 13
308 : service-policy input CoPP
309 : control-plane slot 14
310 : service-policy input CoPP
311 : control-plane slot 15
312 : service-policy input CoPP
313 : !
314 : banner motd ^C
315 : **** AUTHORIZED ACCESS ONLY *****
316 : **** This system is the property of SP AS65001.
317 : **** Disconnect IMMEDIATELY if you are not an authorized user!
318 : **** ********************** *****
319 : ^C
320 : !
321 : line con 0
322 : exec-timeout 5 0
323 : login authentication default
324 : line aux 0
325 : no exec
326 : line vty 0 4
327 : access-class 10 in vrf-also
328 : access-class 10 out
329 : exec-timeout 5 0
330 : transport input ssh
331 : !
332 : process cpu threshold type total rising 80 interval 5 falling 20 interval 5
333 : ntp authentication-key 1 md5 0017400516081F 7
334 : ntp authenticate
335 : ntp trusted-key 1
336 : ntp source Loopback0
337 : ntp access-group serve-only 10
338 : ntp server 192.168.255.40 key 1
339 : ntp server vrf CustB-VPN 192.168.255.40 key 1
340 : no cns aaa enable
341 : !
342 : end
Data Plane
In this case study, and from the perspective of router PE-03, no data plane traffic is included in this category. Rather VPN customer transit traffic is handled within the IP services plane.
Data Plane Security
External traffic is not associated with the IP data plane in any way given that this is an MPLS VPN service. External traffic is associated with the control, management, and services planes only, as described in the respective sections that follow. Therefore, in this case study, there are no data plane security requirements from the perspective of router PE-00.
Control Plane
In this case study, and from the perspective of router PE-03, control plane traffic includes the following:
• BGP: Control plane traffic in this category includes eBGP traffic between the PE-03 Serial0/0/0 address and the Serial0/0 address on CE-B0. BGP routing is used to dynamically exchange VPN prefix information between Customer B offices and the SP network. This category also includes MBGP traffic, which operates between the PE-03 and its internal MBGP (M-iBGP) peers. M-iBGP routing is used to dynamically exchange VPN prefix information between SP MPLS VPN PE routers within the SP network. Deployed in combination, eBGP and M-iBGP provide reachability between customer sites within a single customer IP VPN as well as addressing and routing separation between different customer IP VPNs.
• IGP traffic: Control plane traffic in this category includes OSPF, which is used as the IGP within the SP network. OSPF is configured for all internal and loopback interfaces within the SP infrastructure and provides IP reachability between BGP next hops and, optionally, to the SP NOC. In the case of PE-03, OSPF is enabled on the uplinks, including the 172.31.5.1/24 and 172.30.5.1/24 networks, and on the 192.168.1.1/32 prefix for Loopback0.
• Label Distribution Protocol: Control plane traffic in this category includes LDP (RFC 3036), which is used as the label distribution protocol by the SP in this case study. LDP is configured for all internal interfaces within the SP infrastructure and distributes MPLS labels for all of the MPLS VPN PE /32 loopback prefixes carried within the IGP (OSPF in this case). Distributing labels only for /32 loopback addresses of PE routers results in MPLS label switched paths (LSP) being established between ingress and egress PE routers only. In this way, only services plane traffic is label switched across the SP network, and not internal SP data, control, and management plane traffic. Nevertheless, LDP serves as a control plane protocol for the establishment of MPLS LSPs across the SP network between ingress and egress MPLS VPN PE routers.
• Layer 2 keepalives: L2 keepalives will be used on all of the Serial interfaces of PE-03. L2 keepalives are not used for Ethernet nor are they applicable to virtual interfaces such as Loopback0.
Control Plane Security
From the perspective of PE-03, the security mechanisms that will be used for control plane traffic segmentation and control include the following:
• Selective Packet Discard (SPD): SPD is turned on by default, and on 12000 series routers, aggressive mode is the only mode available. Hence, no additional configuration is required. The hold-queue, headroom and extended headroom default settings are adequate as well.
• IP Receive ACLs: An IP rACL is applied to filter unauthorized traffic destined to the IOS process level on PE-03. Configuration lines 216 through 237 define the IP rACL policy using the extended ACL 101, which is then applied to the receive interface in the inbound direction on line 60. All traffic flows are denied by the IP rACL except for the following:
— OSPF traffic sourced from 192.168.1.0/24 and with IP precedence 6 (line 216).
— BGP traffic sourced from an internal BGP route reflector (192.168.1.2/24) and with IP precedence 6 (lines 217 and 218).
— BGP traffic sourced from CE-B0 external Serial0/0 interface (209.165.200.242/32) and with IP precedence 6 (lines 219 and 220).
— Management traffic sourced from the SP NOC 192.168.252.0/22 (lines 221 through 226).
— LDP traffic sourced from 192.168.1.0/24 and with IP precedence 6 (line 227 through 230).
— Several types of ICMP packets (management plane traffic) must be permitted by the rACL for operational needs (Echo Reply, Time Exceeded, and certain IP Destination Unreachables). These ACE rules are configured on lines 231 through 236.
Per Chapter 5, all CEF receive adjacency traffic has to be accounted for within the IP rACL policy, including both control and management plane traffic. IP rACLs mitigate the risk of unauthorized (attack) traffic from reaching the IOS process level.
• Control Plane Policing (CoPP): CoPP is enabled to protect IOS process level functions, including control and management plane services. Only distributed CoPP is enabled by applying MQC service policies to the control plane, as shown on lines 285 through 312. The associated MQC policies that permit, deny, or rate limit control and management plane traffic flows are defined via lines 88 through 100. The MQC class maps and extended ACLs used for CoPP packet classification are configured via lines 74 through 83, and 238 through 268, respectively. Because the catch-all CoPP-remaining-IP traffic class (line 97) directly precedes it, the class-default portion of the CoPP policy map (lines 99 and 100) accounts for all Layer 2 keepalive traffic only. Note, the routing and class-default traffic classes are unpoliced. The management, normal (ICMP), and remaining IP traffic classes are rate limited. Traffic classified into the undesirable class is dropped. Per Chapter 5, all IOS process level traffic has to be accounted for within the CoPP policy, including control and management plane traffic as well as exception data plane traffic. CoPP mitigates the risk of unauthorized traffic and exception IP transit traffic from reaching the IOS process level.
• OSPF MD5 authentication: OSPF is enabled on lines 157 through 164. Further, within the OSPF routing process itself, passive-interface is configured for the Loopback0 interface, as shown on line 161. MD5 authentication for configured OSPF areas is also enabled (line 160). MD5 authentication passwords are configured on each of the internal physical interfaces, including Serial1/0/0 (line 143) and Serial2/ 0/0 (line 154). Note that even though the prefix associated with Loopback0 is enabled for OSPF, this interface does not require the MD5 key to be applied because it is a virtual interface and no adjacency is formed. MD5 authentication helps to mitigate the risk of attacks against OSPF.
• BGP MD5 authentication: BGP MD5 authentication is applied to the internal M-iBGP session (line 171). MD5 authentication helps to mitigate the risk of attacks against BGP.
• BGP TTL Security Check: GTSM is only supported for eBGP sessions and is also configured on a per-neighbor basis. Because PE03 and CE-B0 are directly connected eBGP peers, a GTSM hop count of 1 is configured (line 196). The BGP TTL Security Check helps to mitigate the risk of attacks against eBGP.
• BGP prefix limits: Neighbor maximum prefix limits are configured on line 195. This prevents CPE-B0 from flooding PE-03 with a large number of VPN prefixes and, thereby, consuming the full Customer B VPN routing table, which is limited to 1000 prefixes (line 53).
• VPN prefix maximum: To control the maximum number of routes within the Customer B VPN routing table and the aggregate VPN routes maintained by PE-03, a maximum limit is imposed per customer VPN (line 53).
• LDP MD5 authentication: MD5 authentication is enabled for LDP (line 56). MD5 authentication helps to mitigate the risk of attacks against LDP.
Management Plane
In this case study, all CE routers are assumed to be managed in-band by the SP. Thus, the SP assigns a globally unique IP address to each CE Loopback0 interface for management plane purposes. These loopback interface addresses are reachable within the Management VPN defined within the SP infrastructure. Management plane traffic from the perspective of CE-B0 was reviewed in Chapter 8. From the perspective of router PE-03, management plane traffic includes the following:
• Provisioning traffic: Management plane traffic in this category includes SSH and TFTP traffic and must be sourced internally from the SP NOC (192.168.252.0/22). Telnet and HTTP are not permitted. In the case of PE-03, ingress management traffic of this type will be destined to the 192.168.1.1/32 address of Loopback0. Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix of the SP NOC.
• Monitoring traffic: Management plane traffic in this category includes SNMP, NetFlow, and Syslog, and this traffic is only authorized to and from the internal network. In the case of PE-03, ingress SNMP traffic will be destined to the 192.168.1.1/32 address of Loopback0. Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix of the SP NOC. Local NetFlow collectors are not included in this case study, which would generally require export to an internal address outside of the SP NOC 192.168.252.0/22 address block.
• Other traffic: Several other protocols are configured within the management plane, including NTP, DNS, and TACACS+ traffic. In the case of PE-03, management traffic of this type will all be within the SP NOC 192.168.252.0/22 address block. In addition, several types of ICMP packets must be permitted by the IP rACL and CoPP policies (see the preceding “Control Plane” section) for operational needs, including ICMP Echo Request, Echo Reply, Time Exceeded, and specific IP Unreachable types. CDP is disabled on external interfaces but enabled on internal interfaces.
• Out-of-band traffic: The console interface is used for out-of-band management access.
Management Plane Security
From the perspective of PE-03, the techniques used for management plane security include the following:
• OOB management: Password authentication is enabled for terminal access using the console port (line 323). Password authentication mitigates the risk of unauthorized access.
• SNMP: SNMP parameters are configured via lines 274 through 278, which includes sending SNMP traps in v2c format to the SP NOC (line 278). Only read-only SNMP access is allowed (line 274) given that no read-write community string is configured. Further, SNMP read access is restricted to sources permitted within the SNMP configured standard ACL 10 (line 274). SNMP packets greater than 1500 bytes are also discarded, given the default IOS behavior for snmp-server packetsize. These SNMP security techniques mitigate the risk of unauthorized access and network reconnaissance.
• Disable unused services:
— BOOTP: BOOTP services are disabled on line 40.
— CDP: CDP is disabled on external interfaces only (line 132).
— DHCP: DHCP server functions are disabled on line 9.
— DNS-based host name-to-address translation: DNS-based name resolution by the router is disabled on line 44.
— EXEC mode: Because the auxiliary port is not used for in-band or out-of-band management, EXEC mode is disabled (line 325) on the auxiliary port.
— Finger service: The finger service is disabled on line 36.
— HTTP server: The (unsecure) HTTP server is disabled on line 203.
— Minor servers: Both the minor TCP and UDP servers are disabled by default.
— NTP: NTP is disabled on external interfaces only (line 131). The NTP configuration associated with internal interfaces is described later in this list.
— PAD: The PAD service is disabled on line 3.
These management plane security techniques mitigate the risk of unauthorized access and network reconnaissance.
• AAA: AAA is fully enabled for authentication, authorization, and accounting. This begins with the aaa new-model configuration command (line 20). TACACS+ serves as the primary authentication mechanism (lines 21 and 22) for both user-level and privilege-level (enable) EXEC mode access. If PE-03 loses IP connectivity to the TACACS+ server for whatever reason, local username/password authentication will be used for user-level EXEC mode access (line 21) and enable password authentication will be used for privilege-level (enable) EXEC mode access (line 22). The local username noc-admin and password is configured (line 28) in support of local username/ password authentication. The enable secret is configured (line 26) in support of enable password authentication. Command authorization is configured to use TACACS+ and then none (that is, no authorization) if IP connectivity to the TACACS+ server is lost (line 23). Command accounting is also configured to use TACACS+ (lines 24 through 25). The TACACS+ server-related parameters are configured via lines 270 through 273. The configuration of the TACACS+ server itself is outside the scope of this book. The preceding AAA policies mitigate the risk of unauthorized access and provide user accounting.
• SSH services: Configuring SSH requires that an IP domain name be specified (for RSA key generation). This is done via line 45. The RSA encryption key is generated outside the configuration during router setup. SSH protocol parameters are configured on lines 41 through 43, and VTY lines are restricted to SSH transport (line 330). Remote terminal access is further restricted to sources matching ACL 10, per lines 327 and 328. SSH provides secure remote terminal access to IP routers. As such, it mitigates the risk of session eavesdropping, which may compromise router configurations, passwords, and so on and be leveraged for an attack.
• Disable idle user sessions: Idle EXEC sessions are disabled after 5 minutes (lines 322 and 329). Further, TCP keepalives are enabled via lines 4 and 5 and serve to terminate connections where the remote host disappears (provides no positive acknowledgement [ACK]). Disabling idle user sessions in this way reduces the risk of unauthorized access.
• NTP: NTP is enabled to facilitate correlation of network events (lines 333 through 339). Ingress NTP protocol messages are restricted to sources permitted within the NTP configured standard ACL 10 (line 337). Further, MD5 authentication is enabled for NTP protocol messages exchanged with the configured NTP server (lines 333 through 335 and line 338). MD5 authentication helps to mitigate the risk of attacks against NTP, which is valuable for network event correlation, including security incident response.
• Syslog: Syslog parameters are configured on lines 205 through 207, which includes directing Syslog messages to the SP NOC (line 207). Timestamps are also appended to each Syslog (and debug) message per lines 6 and 7. In addition, Syslog is configured to report OSPF adjacency changes (line 159) and BGP neighbor state changes (line 169). In order to generate Syslog messages when free memory resources are low, low-watermark levels are set for processor memory on line 29. Further, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 332. Syslog provides valuable network telemetry and is useful for security incident response.
• Management VPN: The Management VPN is primarily used for management of managed CE routers. Nevertheless, it provides an alternate in-band management path to PE routers in addition to the existing in-band access via the IGP (OSPF) and OOB access via the console port. A route map is configured (lines 280 through 282) such that only the MPLS VPN PE-CE links are distributed (line 49) into the Management VPN. Management plane functions—including but not limited to SNMP traps (line 277), NTP (line 339), and VTY access (line 327)—may also be configured to operate within the Management VPN. Further, PE-03 is configured as a spoke within the Management VPN (line 52), which prevents IP reachability between any two PEs (and CEs) within the Management VPN.
• Other BCPs: Other BCP router security configurations related to the management plane are implemented. The router host name is configured on line 11. Global service settings are modified, including enabling timestamps for all debug and logging messages (lines 6 and 7) and enabling password encryption services (line 8). The router boot image is specified on line 14 (lines 13 and 15 are auto-generated). Buffered logging is enabled at debug level and the buffer size is set (line 17). The display of logging messages to the console is disabled (line 18). The enable secret is set on line 26. Several global settings for router self-generated TCP sessions are adjusted, including enabling Nagle services (line 2), enabling TCP keepalives per “Disable idle user sessions” above (lines 4 and 5), increasing the TCP window size (line 37), reducing the TCP SYN wait time (line 5), and enabling PMTUD (line 39). In order to generate Syslog messages when free memory resources are low, a low-watermark level is set for processor memory on line 29. A message of the day (MOTD) login banner is configured on lines 314 through 319. Finally, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 332.
Services Plane
In this case study, and from the perspective of router PE-03, services plane traffic includes only MPLS VPN customer traffic, which includes all remote IP traffic transmitted between Customer B offices. All IP data plane packets that are exchanged between Customer B offices are MPLS encapsulated at the associated ingress PE router. The traffic is then MPLS label switched across the SP network through the IP services plane. The egress PE uses the imposed MPLS label to determine the next-hop CE router, and then de-encapsulates the IP packet from the MPLS label stack and forwards the IP packet downstream to the next-hop CE router.
Services Plane Security
From the perspective of PE-03, the techniques used for services plane security include the following:
• Virtual routing/forwarding (VRF) instance: Customer B is placed into an MPLS VPN by attaching the associated VRF to the Serial0/0/0 interface (line 124). The MPLS VPN architecture (RFC 4364) ensures addressing and routing separation, as described in Chapters 2 and 7.
• Interface ACL: An infrastructure ACL is applied to the Serial0/0/0 interface (line 126) to filter any unauthorized traffic destined to SP internal infrastructure, including PE loopbacks, PE external interfaces, and the SP NOC. Note, because this is an MPLS VPN service, external reachability to the SP core network is natively denied because the external interface is assigned to a VRF (line 124). The ACL policy is defined through the extended ACL 100 (lines 211 through 215), which is attached to the Serial0/0/0 interface in the input direction on line 126. This ACL mitigates the risk of attacks that are sourced from within a customer VPN and that target PEs within the customer VPN. This is necessary to protect other customers attached to the same PE. Namely, a successful attack against the PE can cause collateral damage that affects other connected customers.
• QoS: QoS is deployed within the SP network in support of differentiated services and to isolate important control plane traffic from the other IP traffic planes. The associated policies (lines 101 through 109) and class maps (lines 62 through 73) are defined using MQC. The policy is then attached to the PE-03 uplink interfaces, including Serial1/0/0 and Serial2/0/0 per lines 144 and 155. If the PE-03 uplinks become congested, QoS will reserve 20 percent of uplink capacity for control plane traffic. To ensure that low-priority external traffic does not inadvertently or maliciously enter the high-priority traffic classes (in other words, gold, silver, control), a QoS recoloring policy is applied to MPLS VPN access ports, including the PE-03 serial interface to CE-B0 (line 133). The associated policy (lines 85 through 87) simply marks all traffic with MPLS experimental bits 0. This prevents any transit MPLS VPN traffic from being classified into the SP’s high-priority traffic classes. Note, IP differentiated services are widely available for MPLS VPN networks. Such QoS policies applied to the MPLS VPN PE-CE link are outside the scope of this book. Note, however, that with MPLS VPN services, encapsulated IP packets need not be modified in any way while transiting the SP network. Notice that in Case Study 1 in this chapter, the edge recoloring policy sets the IP precedence to 0 for all ingress packets. Conversely, in this case study, the edge recoloring policy sets the MPLS experimental bits to 0 (line 87) for all ingress packets. Given that MPLS VPN services tunnel IP traffic across the SP network through the use of an MPLS label stack, QoS transparency is available whereby the SP does not re-mark Customer B’s IP precedence markings in any way. The queuing and recoloring policies outlined directly above mitigate the risk of resource (bandwidth) exhaustion attacks against high-priority traffic classes including control plane protocols.
• IP options: IP packets with option headers are filtered by the ip options drop global configuration command (line 34). The IOS default behavior of IP source routing is also disabled with the no ip source-route global configuration command (line 31). Disabling IP options in this way mitigates the risk of IP options–based attacks.
• ICMP techniques: On a per-interface basis, several ICMP BCPs are also applied. ICMP Destination Unreachable and Redirect message generation is also disabled using the no ip unreachables (line 128) and no ip redirects(line 127) interface configuration commands, respectively. Global rate limiting of ICMP Destination Unreachable message generation is also enabled via line 33. ICMP Information Request and Address Mask Request processing is disabled by default within IOS; hence, the no ip information-reply and no ip mask-reply interface commands are applied by default. Disabling ICMP processing in this way mitigates the risk of transit IP data plane attacks and ICMP-based control plane attacks.
• IP directed broadcasts: The dropping of IP directed broadcast packets is the default behavior in IOS 12.0(32)S and, hence, the no ip directed-broadcast interface command is applied by default (line 129). Earlier versions of IOS forwarded IP directed broadcast packets by default. You should confirm the default behavior for your IOS release in order to properly mitigate the risk of directed broadcast based attacks.
• Disable TTL propagation: IP to MPLS TTL propagation is disabled (line 57), which mitigates the risk of TTL expiry attacks against core (P) routers within the SP network.
• Interface MTU: The SP core network is configured with an MTU (lines 137 and 148) greater than that of the PE-CE links, which have a default interface MTU of 1500. This mitigates the risk of IP fragmentation of MPLS VPN services plane traffic, given the MPLS shim header (see Appendix B, “IP Protocol Headers”) imposed by ingress MPLS VPN PE routers in support of MPLS VPN services.
Summary
This chapter demonstrated the use of the concepts and techniques described in Chapters 4 through 7 by applying them to conceptual SP network case studies. Two edge router case studies were presented: a typical enterprise IPsec VPN and Internet access case, and an MPLS VPN case. Full configurations were provided for both case studies, and included annotations for all security components to provide the appropriate context for each mechanism.
These case studies focused on the SP side of the network. In Chapter 8, the focus is on the enterprise side of the network for these same cases.
Further Reading
Behringer, M., and M. Morrow. MPLS VPN Security. Cisco Press, 2005. ISBN 1-58705-183-4.
Greene, B. R., and P. Smith. ISP Essentials. Cisco Press, 2002. ISBN: 1-58705-041-2.