Chapter 8. Enterprise Network Case Studies
In this chapter, you will learn about the following:
• How to apply IP traffic plane security techniques to a typical Internet-based, IPsec VPN enterprise network design
• How to apply IP traffic plane security techniques to a typical MPLS VPN enterprise 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 concepts and techniques described in Chapters 4 through 7 by applying them to conceptual enterprise networks as case studies. The intent is to clarify your understanding of how all of these security techniques are brought together to form an effective defense in depth and breadth security strategy that secures the enterprise network and each of its IP traffic planes.
Two case studies are presented, one being a site-to-site Internet-based IPsec VPN, and the other being a site-to-site MPLS VPN. Defense in depth and breadth principles are applied to protect IP traffic planes within each architecture. The common topology for both of these case studies is illustrated in the high-level, conceptual diagram shown in Figure 8-1. As shown in Figure 8-1, a service provider (SP) IP/MPLS core network provides access for both case studies. Customer A has three sites, two that connect directly to the SP (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 IPsec VPN and Internet access topology. Customer B also has three sites, but in this case all of them connect directly to the SP IP/MPLS network. These three Customer B sites will be used to illustrate a very common MPLS VPN case.
Figure 8-1. Conceptual View of Enterprise and Service Provider Networks for Chapters 8 and 9 Case Studies
The case studies in this chapter focus on the enterprise (customer) side of the network. That is, in each case study, the focus is on the customer edge routers and their respective security requirements. In Chapter 9, “Service Provider Network Case Studies,” the focus will be turned on the SP side of the network for these same case studies. Thus, Chapters 8 and 9 are companions to each other and share a common topology whereby external interfaces interconnect the enterprise and SP networks in both case studies.
The following information is presented for both case studies in this chapter:
• The network topology, including IP addressing plans, and the requirements for network data plane, control plane, management plane, and services plane traffic, as appropriate
• The derived router configurations, along with detailed comments describing the relationship between specific entries and each entry’s respective contribution to IP traffic plane security
Obviously, no single enterprise network design case study can cover all aspects of IP traffic plane security, and these case studies will not be able to cover every possible topology, variation, nuance, or condition. What should be evident from these case studies, however, is the defense in depth and breadth methodology used to identify and protect each IP traffic plane component within the enterprise network designs presented. With this understanding, you will be able to apply similar methods and procedures to your particular network topology, product mix, and organizational mission, with the goal of developing appropriate IP traffic plane security policies.
Case Study 1: IPsec VPN and Internet Access
Case Study 1 focuses on a typical enterprise scenario where IPsec is used within an Internet access environment to connect headquarters and remote sites into a private IP VPN. A description of the case study network topology, functional requirements for the network, and translated security requirements follows.
Network Topology and Requirements
The network topology and assigned IP addressing schemes used within this case study are illustrated in Figure 8-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. The third site, Remote 2 (on the upper-left side of the figure), obtains its Internet access through a different provider.
Figure 8-2. Conceptual Enterprise Network Architecture for Internet-Based IPsec VPN Case Study 1
The functional requirements assumed in this case study are as follows:
• IPsec VPN hub-and-spoke topology: To provide the necessary functionality of privacy between headquarters and remote sites, Customer A deploys GRE + IPsec to create its VPN topology. GRE is used in conjunction with IPsec so that Customer A can also run OSPF within the VPN to provide dynamic routing-based reachability information for internal networks. In this way, each IPsec VPN tunnel appears as a single-hop forwarding path between remote sites and the HQ site. Remote CPE routers appear as if they are one IP hop away from the HQ CPE router. Because GRE is used, IPsec is run in transport mode.
• User (internal) access to Internet: Customer A uses NAT to provide Internet reachability from the private address space within its enterprise networks. In this case study, assume that all 10/8 addresses are private and that NAT is used for external traffic destined to the Internet. Outbound traffic is limited to web-based resources (HTTP port 80 and HTTPS port 443).
• Static IP default routing between SP and customer sites: Customer A uses OSPF as its Interior Gateway Protocol (IGP), including between remote sites. All external sites, including the Internet, are found via a static default route directed toward each PE interface IP address.
• Internet (external) access to Customer A web services: Customer A requires that web services within its DMZ network located at the HQ site shall be reachable from the Internet. In this case study, assume that the 172.16.0.0/24 DMZ network is Internet routable, and that a single web server (or proxy) located at 172.16.0.16/32 must be reachable from the Internet.
• Management: Customer A manages its own routers in this case study. Management plane traffic is only permitted on internal interfaces and from internal (private) addresses. For operational reasons, certain ICMP packets for example, Echo Reply, Time Exceeded (for traceroute), and a few other selected types, must be permitted from the Internet. Management applications assumed in this case study include SSH, HTTPS, Syslog, SNMP, NTP, SCP, TACACS+, and DNS.
Figure 8-3 highlights the types and relationships of the interfaces found on the customer edge (CE) routers in this case study. These interface types were first introduced in Chapter 3, “IP Network Traffic Plane Security Concepts.” The following interfaces are included in this case study:
• Internal: Internal interfaces connect network assets wholly within the administrative domain of Customer A. All three Customer A routers include at least one internal interface. In this case study, FastEthernet0/1 for CPE-A1 and FastEthernet0/1 for CPE-A2 are internal for the remote sites. The headquarters router, CPE-A0, includes two internal interfaces represented by FastEthernet0/1 for the user network and FastEthernet1/0 for the DMZ network. (Of course, the trust levels are very different for these two internal interfaces.) The assigned IP addresses for this case study are shown in Figure 8-2 for each internal interface. In all cases, /24 subnet masking is assigned. The prefixes associated with these internal interfaces are routed within the IGP (OSPF in this case study) to form the Customer A private network.
• External: External interfaces connect networks belonging to two different administrative domains. All three Customer A routers include one external interface, Serial0/0 in all cases, that connects each CE router to its upstream Internet provider. CPE-A0 and CPE-A1 connect to the SP IP/MPLS network that is the focus of the Chapter 9 SP case study. CPE-A2 connects to a different provider. (This is solely to show that for IPsec VPNs, CPEs only require Internet access and not connectivity to one specific SP.) The assigned IP addresses for this case study are shown in Figure 8-2 for each of these serial connections. In all cases, /30 address masking is assigned. The prefixes associated with these external interfaces are not routed within the IGP in this case study because they are provided by the upstream SP and serve as transit links only with no attached IP hosts.
• Loopback: All three Customer A CPE routers implement a single loopback interface that is primarily used for management plane traffic. In this case study, Loopback0 is used. The assigned IP addresses for this case study are shown in Figure 8-2 for each loopback interface. In all cases, /32 address masking is assigned. These loopback interfaces are routed within the IGP and are reachable via the Customer A VPN for management plane purposes.
• Tunnel: All three Customer A routers implement a tunnel interface that is used to deliver services plane traffic. That is, the tunnel interface provides GRE encapsulation for Customer A traffic that is to be encrypted with the IPsec VPN. In this case study, CPE-A1 and CPE-A2 each require a single tunnel interface, Tunnel0, to connect to the HQ router. The HQ router, CPE-A0, requires two tunnel interfaces, Tunnel0 and Tunnel1, in this case study, one for each remote site. Several options exist for tunnel interface addressing. In this case study, each tunnel interface takes on the IP address of the loopback interface on the same router.
• Receive: All routers include by default a receive interface that “logically” represents the slow path to the IOS process level. This applies to any ingress packets that must be punted from the CEF fast path to the router’s CPU for local processing.
Figure 8-3. IP Traffic Plane Relationships to Router Interfaces for Internet-Based IPsec VPN Case Study 1
Figure 8-3 highlights in particular the router of focus for this case study, CPE-A0, and illustrates the relationship among its interfaces. This router is also the focus for the sample IOS configuration in the “Router Configuration” section that follows.
Router Configuration
Security configurations may be derived based upon the preceding topology and functional requirements. Router CPE-A0 is used as the focal point for the remaining discussions. The other Customer A CPE routers shown in the topology in Figure 8-2 have similar but locally specific configurations.
Example 8-1 provides the derived Cisco IOS configuration that implements the preceding requirements and defense in depth and breadth security principles. This configuration assumes that CPE-A0 is a Cisco ISR class router (1800, 2800, or 3800 series), and that it is running Cisco IOS version 12.4 software with IPsec AES/3DES feature support and advanced IP services support. Line numbers precede each configuration command shown in Example 8-1 and serve as reference points for the remainder of the discussion that directly follows, which is organized by IP traffic plane.
Example 8-1. Case Study 1 Enterprise Customer Premises Edge Router Configuration
1 : !
2 : version 12.4
3 : service nagle
4 : no service pad
5 : service tcp-keepalives-in
6 : service tcp-keepalives-out
7 : service timestamps debug datetime msec localtime show-timezone
8 : service timestamps log datetime msec localtime show-timezone
9 : service password-encryption
10 : no service dhcp
11 : !
12 : hostname CPE-A0
13 : !
14 : boot-start-marker
15 : boot system flash c3845-advipservicesk9-mz.124-10.bin
16 : boot-end-marker
17 : !
18 : logging buffered 4096 debugging
19 : no logging console
20 : logging monitor errors
21 : enable secret 5 $1$Vmt.$SYiN8ZjKPe7DuTvNHm/vS.
22 : !
23 : aaa new-model
24 : !
25 : aaa authentication banner ^C
26 : **** AUTHORIZED ACCESS ONLY *****
27 : **** This system is the property of Customer A
28 : **** Disconnect IMMEDIATELY if you are not an authorized user!
29 : **** ********************** *****^C
30 : aaa authentication password-prompt Customer_A-Password:
31 : aaa authentication username-prompt Customer_A-Username:
32 : !
33 : aaa authentication login CustA group tacacs+ local
34 : aaa authentication enable default group tacacs+ enable
35 : aaa authorization exec default group tacacs+ none
36 : aaa accounting commands 1 default start-stop group tacacs+
37 : aaa accounting commands 10 default start-stop group tacacs+
38 : aaa accounting commands 15 default start-stop group tacacs+
39 : !
40 : aaa session-id common
41 : !
42 : memory-size iomem 15
43 : ip subnet-zero
44 : no ip source-route
45 : no ip gratuitous-arps
46 : ip icmp rate-limit unreachable 100
47 : ip spd mode aggressive
48 : ip options drop
49 : ip tcp window-size 32768
50 : ip tcp synwait-time 5
51 : ip tcp path-mtu-discovery
52 :!
53 :!
54 : ip cef
55 : ip domain name customer-a.com
56 : no ip domain lookup
57 : !
58 : !
59 : no ip bootp server
60 : ip ssh time-out 20
61 : ip ssh source-interface Loopback0
62 : ip ssh version 2
63 : ip scp server enable
64 : !
65 : !
66 : memory free low-watermark processor 100000
67 : memory free low-watermark IO 1000000
68 : username gregg privilege 15 secret 5 $1$c/vj$kAzIb.llu.OBhGH1hRVS2/
69 : username dave privilege 10 secret 5 $1$gCTJ$wjUiXxisNBZfxQeJr67a91
70 : !
71 : !
72 : class-map match-all CoPP-management
73 : match access-group 121
74 : class-map match-all CoPP-normal
75 : match access-group 122
76 : class-map match-all CoPP-remaining-IP
77 : match access-group 124
78 : class-map match-all CoPP-routing
79 : match access-group 120
80 : class-map match-any CoPP-undesirable
81 : match access-group 123
82 : !
83 : !
84 : policy-map CoPP
85 : class CoPP-undesirable
86 : police 8000 1500 1500 conform-action drop exceed-action drop
87 : class CoPP-routing
88 : police 125000 1500 1500 conform-action transmit exceed-action transmit
89 : class CoPP-management
90 : police 50000 1500 1500 conform-action transmit exceed-action drop
91 : class CoPP-normal
92 : police 15000 1500 1500 conform-action transmit exceed-action drop
93 : class CoPP-remaining-IP
94 : police 8000 1500 1500 conform-action transmit exceed-action drop
95 : class class-default
96 : police 8000 1500 1500 conform-action transmit exceed-action transmit
97 : !
98 : !
99 : crypto isakmp policy 10
100 : encr 3des
101 : authentication pre-share
102 : crypto isakmp key s3cr3t address 209.165.201.2
103 : crypto isakmp key s3cr3t address 209.165.202.130
104 : !
105 : crypto ipsec transform-set CRYPTO esp-3des esp-sha-hmac
106 : mode transport
107 : !
108 : crypto call admission limit ike sa 2
109 : !
110 : crypto map GREIPSEC local-address Serial0/0
111 : crypto map GREIPSEC 10 ipsec-isakmp
112 : set peer 209.165.201.2
113 : set transform-set CRYPTO
114 : match address GRE1
115 : crypto map GREIPSEC 20 ipsec-isakmp
116 : set peer 209.165.202.130
117 : set transform-set CRYPTO
118 : match address GRE2
119 : !
120 : !
121 : interface Tunnel0
122 : description - To Customer A Remote 1
123 : ip unnumbered Loopback0
124 : ip verify unicast source reachable-via rx
125 : ip mtu 1400
126 : tunnel source Serial0/0
127 : tunnel destination 209.165.201.2
128 : !
129 : interface Tunnel1
130 : description - To Customer A Remote 2
131 : ip unnumbered Loopback0
132 : ip verify unicast source reachable-via rx
133 : ip mtu 1400
134 : tunnel source Serial0/0
135 : tunnel destination 209.165.202.130
136 : !
137 : interface Null0
138 : no ip unreachables
139 : !
140 : interface Loopback0
141 : description - Loopback for Management access
142 : ip address 10.255.255.50 255.255.255.255
143 : no ip unreachables
144 : !
145 : interface Serial0/0
146 : description - To SP PE-00
147 : ip address 209.165.200.226 255.255.255.252
148 : ip access-group iACL-external in
149 : ip verify unicast source reachable-via rx allow-default
150 : no ip redirects
151 : no ip unreachables
152 : no ip proxy-arp
153 : ip nat outside
154 : ip virtual-reassembly
155 : no fair-queue
156 : crypto map GREIPSEC
157 : !
158 : interface FastEthernet0/0
159 : no ip address
160 : shutdown
161 : !
162 : interface FastEthernet0/1
163 : description - Customer A HQ Internal
164 : ip address 10.0.0.1 255.255.255.0
165 : ip access-group iACL-internal out
166 : ip verify unicast source reachable-via rx
167 : no ip redirects
168 : no ip unreachables
169 : no ip proxy-arp
170 : ip nat inside
171 : ip virtual-reassembly
172 : ip route-cache flow
173 : ip ospf message-digest-key 1 md5 7 044858051D7258
174 : no mop enabled
175 : !
176 : interface FastEthernet1/0
177 : description - Customer A HQ DMZ
178 : ip address 172.16.0.1 255.255.255.0
179 : ip access-group iACL-DMZ in
180 : ip verify unicast source reachable-via rx
181 : no ip redirects
182 : no ip unreachables
183 : no ip proxy-arp
184 : ip ospf message-digest-key 1 md5 7 0017400516081F
185 : no mop enabled
186 : !
187 : interface FastEthernet1/1
188 : no ip address
189 : shutdown
190 : !
191 : router ospf 10
192 : log-adjacency-changes
193 : area 0 authentication message-digest
194 : passive-interface FastEthernet0/1
195 : passive-interface FastEthernet1/0
196 : passive-interface Loopback0
197 : network 10.0.0.0 0.0.0.255 area 0
198 : network 10.255.255.50 0.0.0.0 area 0
199 : network 172.16.0.0 0.0.0.255 area 0
200 : !
201 : no ip http server
202 : ip http access-class 10
203 : ip http authentication local
204 : ip http secure-server
205 : ip classless
206 : ip route 0.0.0.0 0.0.0.0 209.165.200.225
207 : ip route 10.0.0.0 255.0.0.0 Null0
208 : ip route 14.0.0.0 255.0.0.0 Null0
209 : ip route 24.0.0.0 255.0.0.0 Null0
210 : ip route 39.0.0.0 255.0.0.0 Null0
211 : ip route 127.0.0.0 255.0.0.0 Null0
212 : ip route 128.0.0.0 255.255.0.0 Null0
213 : ip route 169.254.0.0 255.255.0.0 Null0
214 : ip route 172.16.0.0 255.240.0.0 Null0
215 : ip route 192.0.2.0 255.255.255.0 Null0
216 : ip route 192.168.0.0 255.255.0.0 Null0
217 : !
218 : ip nat inside source list NATADD interface Serial0/0 overload
219 : !
220 : ip access-list extended GRE1
221 : permit gre host 209.165.200.226 host 209.165.201.2
222 : ip access-list extended GRE2
223 : permit gre host 209.165.200.226 host 209.165.202.130
224 : ip access-list extended NATADD
225 : deny ip 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255
226 : permit ip 10.0.0.0 0.0.0.255 any
227 : ip access-list extended iACL-DMZ
228 : permit tcp host 172.16.0.16 eq www any established
229 : ip access-list extended iACL-external
230 : permit udp host 209.165.201.2 host 209.165.200.226 eq isakmp
231 : permit udp host 209.165.202.130 host 209.165.200.226 eq isakmp
232 : permit esp host 209.165.201.2 host 209.165.200.226
233 : permit esp host 209.165.202.130 host 209.165.200.226
234 : deny ip 0.0.0.0 0.255.255.255 any
235 : deny ip 10.0.0.0 0.255.255.255 any
236 : deny ip 14.0.0.0 0.255.255.255 any
237 : deny ip 24.0.0.0 0.255.255.255 any
238 : deny ip 39.0.0.0 0.255.255.255 any
239 : deny ip 127.0.0.0 0.255.255.255 any
240 : deny ip 128.0.0.0 0.0.255.255 any
241 : deny ip 169.254.0.0 0.0.255.255 any
242 : deny ip 172.16.0.0 0.31.255.255 any
243 : deny ip 192.0.2.0 0.0.0.255 any
244 : deny ip 192.168.0.0 0.0.255.255 any
245 : deny ip any 224.0.0.0 0.0.0.255
246 : deny ip 224.0.0.0 0.0.0.255 any
247 : permit tcp any host 172.16.0.16 eq www
248 : permit tcp any host 209.165.200.226 established
249 : permit icmp any 209.165.200.226 echo-reply
250 : permit icmp any 209.165.200.226 ttl-exceeded
251 : permit icmp any 209.165.200.226 port-unreachable
252 : permit icmp any 209.165.200.226 protocol-unreachable
253 : permit icmp any 209.165.200.226 packet-too-big
254 : ip access-list extended iACL-internal
255 : permit tcp host 172.16.0.16 eq www 10.0.0.0 0.0.0.255 established
256 : deny ip 172.16.0.0 0.0.0.255 any
257 : permit tcp any 10.0.0.0 0.0.0.255 established
258 : permit tcp host 10.0.0.1 host 10.0.0.10 eq 22
259 : permit udp host 10.255.255.50 eq snmp host 10.0.0.11
260 : permit udp host 10.255.255.50 eq snmptrap host 10.0.0.11
261 : permit udp host 10.255.255.50 host 10.0.0.11 eq syslog
262 : permit udp host 10.255.255.50 host 10.0.0.10 eq ntp
263 : permit icmp any 10.0.0.0 0.0.0.255 echo-reply
264 : permit icmp any 10.0.0.0 0.0.0.255 packet-too-big
265 : permit icmp any 10.0.0.0 0.0.0.255 time-exceeded
266 : permit icmp any 10.0.0.0 0.0.0.255 port-unreachable
267 : permit icmp any 10.0.0.0 0.0.0.255 protocol-unreachable
268 : logging trap notifications
269 : logging source-interface Loopback0
270 : logging 10.0.0.11
271 : access-list 10 permit 10.0.0.0 0.255.255.255
272 : access-list 120 remark -- Routing Protocol ACL for CoPP
273 : access-list 120 remark -- -- permit ospf
274 : access-list 120 permit ospf 10.0.0.0 0.255.255.255 any precedence internet
275 : access-list 121 remark -- Management Protocol ACL for CoPP
276 : access-list 121 remark -- -- permit ssh (and also scp)
277 : access-list 121 permit tcp 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 eq 22
278 : access-list 121 remark -- -- permit snmp
279 : access-list 121 permit udp 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
eq snmp
280 : access-list 121 remark -- -- permit tacacs+
281 : access-list 121 permit tcp 10.0.0.0 0.255.255.255 eq tacacs 10.0.0.0
0.255.255.255 established
282 : access-list 121 remark -- -- permit DNS
283 : access-list 121 permit udp 10.0.0.0 0.255.255.255 eq domain 10.0.0.0
0.255.255.255
284 : access-list 121 remark -- -- permit ntp
285 : access-list 121 permit udp 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
eq ntp
286 : access-list 121 remark -- -- permit https
287 : access-list 121 permit tcp 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
eq 443
288 : access-list 121 remark -- -- permit traceroute
289 : access-list 121 permit udp any gt 10000 any gt 10000
290 : access-list 121 remark -- -- permit IKE (udp 500)
291 : access-list 121 permit udp any any eq isakmp
292 : access-list 122 remark -- Normal Traffic ACL for CoPP
293 : access-list 122 remark -- -- permit ICMP types
294 : access-list 122 permit icmp any any echo
295 : access-list 122 permit icmp any any echo-reply
296 : access-list 122 permit icmp any any ttl-exceeded
297 : access-list 122 permit icmp any any unreachable
298 : access-list 122 permit icmp any any port-unreachable
299 : access-list 122 permit icmp any any packet-too-big
300 : access-list 123 remark -- Undesirable Traffic ACL for CoPP
301 : access-list 123 remark -- -- Block Fragments
302 : access-list 123 permit tcp any any fragments
303 : access-list 123 permit udp any any fragments
304 : access-list 123 permit icmp any any fragments
305 : access-list 123 permit ip any any fragments
306 : access-list 123 remark -- -- Block Slammer
307 : access-list 123 permit udp any any eq 1434
308 : access-list 124 remark -- Catch-All IP ACL for CoPP
309 : access-list 124 remark -- -- permit all IP
310 : access-list 124 permit ip any any
311 : snmp-server community s3cr3t RO 10
312 : snmp-server packetsize 1400
313 : snmp-server enable traps tty
314 : snmp-server trap-source Loopback0
315 : snmp-server host 10.0.0.11 version 2c s3cr3t
316 : no cdp run
317 : !
318 : tacacs-server host 10.0.0.12
319 : tacacs-server timeout 2
320 : no tacacs-server directed-request
321 : tacacs-server key 7 0017400516081F
322 : !
323 : control-plane
324 : service-policy input CoPP
325 : !
326 : !
327 : banner motd ^C
328 : **** AUTHORIZED ACCESS ONLY *****
329 : **** This system is the property of Customer A
330 : **** Disconnect IMMEDIATELY if you are not an authorized user!
331 : **** ********************** *****^C
332 : privilege exec level 10 show ip ospf
333 : privilege exec level 10 show ip route
334 : privilege exec level 10 show ip interface
345 : privilege exec level 10 show ip
336 : privilege exec level 10 show logging
337 : !
338 : line con 0
339 : exec-timeout 60 0
340 : login authentication CustA
341 : line aux 0
342 : transport input none
343 : transport output none
344 : line vty 0 4
345 : access-class 10 in
346 : exec-timeout 60 0
347 : login authentication CustA
348 : transport input ssh
349 : !
350 : scheduler allocate 6000 1000
351 : process cpu threshold type total rising 80 interval 5 falling 20 interval 5
352 : ntp authentication-key 1 md5 0505121F6C471D10 7
353 : ntp authenticate
354 : ntp trust-key 1
355 : ntp source Loopback0
356 : ntp access-group serve-only 10
357 : ntp server 10.0.0.10 key 1
358 : !
359 : end
Data Plane
In this case study, and from the perspective of router CPE-A0, data plane traffic includes the following:
• Internal to internal traffic: Data plane traffic in this category includes traffic that is sourced from and destined to devices wholly within the administrative domain of the enterprise. In the case of CPE-A0, this includes all packets routed between local LANs (that is, only those packets routed between FastEthernet0/1 and FastEthernet1/0). Packets traversing the IPsec VPN are converted from the data plane to the services plane as described in the “Services Plane” section later in the chapter. Even though this traffic remains within a single administrative domain, this traffic is considered to be in the services plane due to the extra processing and specialized handling performed by the router.
• Internal to external traffic: Data plane traffic in this category includes traffic that is sourced internally but destined to external networks (Internet traffic, for example) outside the administrative domain of this enterprise. In the case of CPE-A0, this type of internal to external traffic is sourced from internal users on the 10.0.0.0/24 private network and destined to networks outside of the 10.0.0.0/24 private network. User traffic sourced from the private 10.0.0.0/24 network is converted from the data plane to the services plane through the NAT process (as discussed below in the “Services Plane” section later in this chapter). For the purposes of this case study, there should not be any traffic sourced from the 172.16.0.0/24 DMZ network except for the replies from the web server located at 172.16.0.16/32. This traffic remains in the data plane.
• External to internal traffic: Data plane traffic in this category includes traffic that is externally sourced and destined to internal resources. In the case of CPE-A0, the web server at 172.16.0.16/32 on the DMZ network is the only authorized internal host granted reachability from external networks. (IPsec traffic from remote sites is included in the “Services Plane” section.)
Data Plane Security
From the perspective of router CPE-A0, the security mechanisms used for data plane traffic segmentation and control include the following:
• Interface ACL: An interface ACL is applied to the Serial0/0 interface in the ingress (in) direction to limit the traffic permitted to enter CPE-A0. Example 8-1 configuration lines 229 through 253 implement this functionality via the named extended ACL iACL-external, which is then applied to the Serial0/0 interface in the inbound direction on line 148. Note that this ACL accounts for all ingress traffic, so entries are included for data, management, and services plane traffic. (No IP layer control plane traffic traverses this interface.) An interface ACL is also applied to FastEthernet0/1 in the egress (out) direction to limit the traffic permitted to reach the user LAN. Configuration lines 254 through 267 implement this functionality via the named extended ACL iACL-internal, which is applied to the FastEthernet0/1 interface in the outbound direction on line 165. Note that this ACL only permits return HTTP traffic from the DMZ LAN, and return TCP traffic, management plane traffic, and certain ICMP traffic from the Internet. Finally, an interface ACL is applied to the FastEthernet1/0 interface in the ingress direction to limit the permitted traffic sent from the DMZ LAN. Configuration lines 227 through 228 implement this functionality via the named extended ACL iACL-DMZ, which is applied to the FastEthernet1/0 interface in the inbound direction on line 179. This ACL only permits established HTTP traffic from the DMZ LAN to be transmitted. Although these ACLs have some duplication of coverage, together they provide defense in depth and breadth protection and increase the overall security posture of router CEP-A0.
Note
The use of the stateful IOS Firewall feature is also feasible and can provide additional security when compared to stateless ACLs. IOS Firewall is capable of tracking outbound requests and dynamically tracking these requests to permit return traffic in a stateful manner. Refer to the “Further Reading” section for more details.
• Antispoofing ACL: Assuming RFC 3330 special-use IPv4 addresses should not be routed within the Internet, all IP packets with RFC 3330 addresses as sources must be dropped because they are obviously spoofed packets. Thus, these prefixes are included in the iACL-external interface ACL applied to Serial0/0 in the ingress direction. (Note that the CPE-A0 DMZ prefix 172.16.0.0/32 is assumed to be routable for the purposes of this case study but is otherwise part of the RFC 3330 reserved address space. Regardless, packets should not enter Serial0/0 with source addresses of internal infrastructure prefixes.) Antispoofing functionality is implemented as part of the named extended ACL iACL-external via lines 234 through 246.
• uRPF: Unicast RPF strict mode is deployed on all interfaces. For the Serial0/0 interface, the allow-default keyword must be used for this implementation, as shown on line 149, given that a default route is used for forwarding to external prefixes reachable via the Internet. For the internal interfaces, FastEthernet0/1 and FastEthernet1/0, uRPF strict mode can be applied without the allow-default keyword, as shown on lines 166 and 180. In addition, uRPF strict mode is applied to the Tunnel0 and Tunnel1 interfaces, as shown on lines 124 and 132. Note that the static routes to Null0 improve the effectiveness of uRPF (as described in the upcoming “Control Plane” section). uRPF provides antispoofing protection in conjunction with the interface ACL described above in support of defense in depth and breadth principles.
• IP options: The ability for the router to process IP packets with option headers is disabled with the global ip options drop configuration (line 48). The default IOS behavior of processing IP packets with the Source Route option header is also disabled with the no ip source-route configuration (line 44). While overlap exists between these two commands for IP packets with source route header options, but this supports in depth and breadth principles.
• IP directed broadcasts: The dropping of IP directed broadcast packets is the default behavior in this IOS image, so the best common practice (BCP) for earlier IOS images to include the no ip directed-broadcast command is not required.
• ICMP techniques: On a per-interface basis, several ICMP BCPs are also enabled. Disabling IP redirects is configured using the no ip redirects interface command (lines 150, 167, and 181), and disabling the generation of ICMP Destination Unreachable messages is configured using the no ip unreachables interface command (lines 151, 168, and 182). The global rate limiting of ICMP Destination Unreachable messages is also enabled via line 46. The generation of ICMP Address Mask Reply messages and ICMP Information Reply messages is disabled by default in this IOS image, so the BCP for earlier IOS images to include the no ip information-reply and no ip mask-reply interface commands is not required.
Control Plane
In this case study, and from the perspective of router CPE-A0, control plane traffic includes the following:
• IGP traffic: IP layer control plane traffic in this category includes OSPF, which is used as the IGP in the case study. OSPF is configured for all private prefixes. In the case of CPE-A0, this includes the 10.0.0.0/24 and 172.16.0.0/24 networks, and the 10.255.255.50/32 prefix for Loopback0. In this case study, OSPF adjacencies will only be formed between CPE routers across the IPsec-protected GRE tunnels. Thus, OSPF control plane traffic does not need to be sent out internal interfaces. OSPF traffic from other sites will appear as services plane traffic to the external (Serial) and tunnel interfaces.
• Layer 2 keepalives: Layer 2 keepalives will exist on the Serial interfaces of CPE-A0. Layer 2 keepalives are not defined within the IEEE Ethernet specifications, nor are they applicable to virtual interfaces such as Loopback0.
Control Plane Security
From the perspective of CPE-A0, the security mechanisms that will be used for control plane traffic segmentation and control include the following:
• Control Plane Policing (CoPP): CoPP is one of the primary mechanisms for protecting the route processor CPU. When configured, all punted packets reach the route processor CPU through the CoPP mechanism, including all control plane and management plane packets, most services plane packets, and exceptions IP data plane packets. In the case of CPE-A0, CoPP is implemented via MQC mechanisms. In total, the CoPP configuration includes the ACLs 120, 121, 122, 123, and 124 shown on lines 272 through 310, the class-map statements shown on lines 72 through 81, and the policy-map statements shown on lines 84 through 96. CoPP is enabled by applying the service policy to the control plane, as shown on lines 323 through 324. Note that the class-default portion of the CoPP policy-map (lines 95 and 96) should be left unpoliced here because it only sees Layer 2 keepalive traffic, due to the existence of the catch-all CoPP-remaining-IP traffic class (lines 93 and 94) directly preceding it in the policy map.
• Default route: A default route to the Internet is configured on line 206. Because a default route matches any destination prefix, other security measures are implemented to prevent the router from forwarding spoofed traffic (for example, in the case where malware infects a user network device). These include the ACLs and uRPF configurations that prevent spoofed traffic from reaching the Internet (described earlier in the “Data Plane” section), the static routes to Null0 (described in this section), and portions of the NAT configuration that help protect NAT and IPsec encryption resources (described in the “Services Plane” section later in the chapter).
• OSPF MD5 authentication: OSPF is enabled on lines 191 through 199. The passive-interface commands on lines 194 through 196 prevent OSPF from sending its control plane traffic out these interfaces. (The network prefixes associated with these interfaces will still be carried within and advertised by OSPF.) The MD5 hash-based authentication feature is turned on for OSPF with the area 0 authentication message-digest configuration (line 193) to prevent OSPF message spoofing. The interfaces FastEthernet0/1 and FastEthernet1/0 apply the MD5 key for OSPF router authentication, as shown on lines 173 and 184, respectively. Note that even though the prefix associated with Loopback0 is carried in OSPF, this interface does not require the MD5 key to be applied because it is a virtual interface.
• Selective Packet Discard (SPD): SPD is turned on by default, and the hold-queue, headroom, and extended headroom default settings are adequate. However, SPD aggressive mode is not enabled by default and should be turned on. SPD aggressive mode is enabled via the hidden global EXEC command ip spd mode aggressive (line 47). (This command will then appear in the configuration.)
• Static routes to Null0: A static route to Null0 is installed for the 10.0.0.0/8 prefix. Only certain prefixes within the 10.0.0.0/8 IP address block are actually used by Customer A sites. However, because a default route points toward the Internet, any traffic generated toward unknown destinations will flow toward the Internet and consume NAT resources. This static route to Null0 prevents packets destined to unknown addresses within the 10.0.0.0/8 block from reaching the Internet by way of the NAT process (which helps protect NAT resources). Similar rationale applies for the other prefixes assigned static routes to Null0. These static routes also aid uRPF strict mode, especially with the allow-default keyword, in distinguishing spoofed source addresses. (Legitimate sources will match the uRPF check based on the more-specific 10.0.x.0/24 prefixes installed via OSPF. Spoofed packets outside these more-specific prefixes will fail the uRPF check due to the Null0 match.) Static routes to Null0 are applied via lines 207 through 216. The Null0 interface is configured on line 137, and the generation of ICMP Destination Unreachable messages is disabled on the Null0 interface on line 138.
• Disable unused services: BCP router security configurations related to the control plane include disabling the proxy ARP feature on a per-interface basis via the no ip proxy-arp command (lines 152, 169, and 183) and, for the FastEthernet interfaces, disabling the MOP protocol via the no mop enabled command (lines 174 and 185).
Management Plane
In this case study, and from the perspective of router CPE-A0, management plane traffic includes the following:
• Provisioning traffic: Management plane traffic in this category includes SSH, HTTPS, and SCP traffic. This traffic must be sourced internally per the case study requirements. Telnet, FTP, and TFTP are not permitted because they are inherently insecure protocols. In the case of CPE-A0, ingress management traffic of this type will be destined to the 10.255.255.50/32 address of Loopback0. Management traffic of this type will be destined to the 10.0.0.0/24 prefix range (all provisioning occurs from within the HQ site).
• Monitoring traffic: Management plane traffic in this category includes SNMP and Syslog, and this traffic exists only within the internal network. In the case of CPE-A0, ingress SNMP traffic will be destined to the 10.255.255.50/32 address of Loopback0. For this case study, Customer A is assumed to have collocated the SNMP and Syslog services on the server at 10.0.0.11.
• Other traffic: Several other protocols are configured within the management plane, including NTP and TACACS+ traffic. In the case of CPE-A0, management traffic of this type will all be within the 10.0.0.0/24 prefix range. For this case study, the TACACS+ server is at 10.0.0.12 and the NTP device is at 10.0.0.10. In addition, several types of ICMP packets (management plane traffic) must be permitted for operational needs (Echo Reply, Time Exceeded, and certain IP Unreachable messages). CDP is globally disabled.
• OOB traffic: The console interface is configured for OOB management plane access.
Management Plane Security
From the perspective of CPE-A0, the security mechanisms that will be used for management plane traffic segmentation and control include the following:
• Loopback0 interface: The interface Loopback0 is configured on lines 140 through 143 to support management plane traffic.
• AAA: AAA is fully configured for authentication, authorization, and accounting. This begins with the aaa new-model configuration (line 23). An authentication banner is configured (lines 25 through 29), and customized authentication username and password prompts are configured (lines 30 and 31). Login authentication is configured to use TACACS+ and then local information with the list name CustA (line 33). Enable-mode authentication is configured to use TACACS+ and then the enable secret (line 34). (The TACACS+ server implementation is not shown.) Command authorization is configured to use TACACS+ and then none (line 35). Command accounting is configured to use TACACS+ (lines 36 through 38). Finally, two local usernames are configured with different privilege levels (lines 68 and 69). Several commands have been added at privilege level 10 for users granted this level of enable access, as shown on lines 332 through 336.
• SSH services: Configuring SSH requires that a domain name be specified (for RSA encryption key generation), as shown on line 55. (The RSA encryption key is generated outside the configuration during router setup.) SSH protocol parameters are configured on lines 60 through 62.
• In-band VTY access: In-band VTY management plane access is configured on lines 344 through 348. VTY access is restricted to sources matching ACL 10 via line 345, and in-band VTY access is restricted to using the SSH protocol only, on line 348.
• HTTPS and SCP services: HTTPS access is enabled via lines 202 through 204. Line 202 restricts HTTPS access to sources matching ACL 10. ACL 10 is defined on line 271. HTTP is disabled on line 201. Secure Copy (SCP) server functionality is enabled on line 63.
• SNMP and Syslog: SNMP configuration parameters are implemented via lines 311 through 315. SNMP access is restricted to read-only by the community string s3cr3t and is limited to sources matching ACL 10 via line 311. (SNMP is restricted to only monitoring in this case study. Write access is not permitted.) Syslog configurations are included on lines 268 through 270. In addition, to generate Syslog messages when OSPF adjacency changes occur, logging of these changes is enabled on line 192.
• TACACS+, NTP, and DNS: The TACACS+ server parameters are configured via lines 318 through 321. The DNS name resolution by the router is disabled on line 56. NTP is configured via lines 352 and 357. Ingress NTP messages are restricted to sources permitted by ACL 10 (line 356). Further, MD5 authentication is enabled for NTP message exchanges with the configured NTP server (lines 352 through 354 and line 357).
• Out-of-band console access: OOB (console port) access is configured on lines 338 through 340. Console login authentication is referred to the AAA list CustA on line 340. AUX port transport is disabled (effectively shutting down the port) on lines 341 through 343.
• Disable unused services: Several global service settings are disabled, including PAD service (line 4), DHCP services (line 10), and (globally) CDP (line 316). Note that CDP could be disabled on a per-interface basis if its use was desired within the Customer A network. In this case, it would be disabled only on external interfaces. The processing of gratuitous ARP messages is disabled on line 45, and the BOOTP service is disabled on line 59. Note that disabling IP finger services is the default in this IOS image, so the no ip finger or no service finger commands are not required.
• Other BCPs: Other BCP router security configurations related to the management plane are implemented. The router host name is configured on line 12. Global service settings are modified, including enabling timestamps for all debug and logging messages (lines 7 and 8) and enabling password encryption services (line 9). The router boot image is specified on line 15 (lines 14 and 16 are auto-generated). Buffered logging is enabled at debug level and the buffer size is set (line 18). The display of logging messages to the console is disabled (line 19), and logging to the monitor at the error level is enabled (line 20). The enable secret is set on line 21. Several global settings for router self-generated TCP sessions are adjusted, including enabling Nagle services (line 3), enabling TCP keepalives (lines 5 and 6), increasing the TCP window size (line 49), reducing the TCP SYN wait time (line 50), and enabling Path MTU Discovery (line 51). In order to generate Syslog messages when free memory resources are low, low-watermark levels are set for processor and I/O memory on lines 66 and 67. A message of the day (MOTD) login banner is configured on lines 327 through 331. To guarantee CPU time for processes, scheduler allocate is configured on line 350. Finally, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 351.
Services Plane
In this case study, and from the perspective of router CPE-A0, services plane traffic includes the following:
• GRE + IPsec VPN traffic: Services plane traffic in this category includes all traffic traversing the GRE + IPsec VPN tunnels between headquarters and remote sites. All packets (data plane, control plane, and management plane) that are exchanged between headquarters and remote sites are routed through the established GRE tunnels. All GRE packets have source and destination addresses corresponding to each Serial0/0 interface. The GRE tunnel interfaces themselves are unnumbered, but reference the Loopback0 interface. All GRE packets are then encrypted using the IPsec ESP protocol. All IPsec packets also have source and destination addresses corresponding to each Serial0/0 interface. IKE provides the control channel for IPsec and also has source and destination addresses corresponding to each Serial0/0 interface.
• NAT traffic: Services plane traffic in this category includes all traffic that is sourced internally but destined to external networks (for instance, Internet traffic) outside the administrative domain of this enterprise. In the case of CPE-A0, user traffic from the private 10.0.0.0/24 network is converted from the data plane to the services plane using NAT resources. (Return traffic to the NAT process is also permitted.)
Services Plane Security
From the perspective of CPE-A0, the security mechanisms that will be used for services plane traffic segmentation and control include the following:
• GRE: GRE is configured to provide unicast IPv4 encapsulation of all packets considered to be within the Customer A private network. From the perspective of CPE-A0, two tunnels are configured, one to Remote 1 and a second to Remote 2. The GRE tunnel interfaces are configured on lines 121 through 127 and lines 129 through 135. The tunnel IP MTU is set to 1400 bytes on lines 125 and 133 to cause GRE to prefragment IP packets that exceed 1400 bytes in length to account for GRE and IPsec encapsulation overhead. GRE would normally prefragment for packets exceeding 1476 bytes by default. (This prevents packets from potentially being fragmented by the router after IPsec encapsulation, which would result in significant performance degradation due to the need for reassembly prior to decryption on the receiving side. That is, if fragmentation is required, it is done prior to IPsec encryption.)
• IPsec: IPsec is configured to encrypt the GRE tunneled traffic between headquarters and remote sites. The IKE (IPsec Phase 1) configuration is listed on lines 99 through 101. This policy enables 3DES encryption (line 100) for IKE, and defines that the authentication mechanism should use a preshared key (line 101). The preshared key used for each IKE peer is configured on lines 102 and 103. Finally, IKE call admission protection is enabled on line 108, which limits the number of simultaneous IKE sessions to two in this case. The IPsec Phase 2 protection scheme is defined on lines 105 and 106. Note that the transport mode is enabled (line 106) because GRE tunneling is being used. The IPsec tunnel is configured to use the IP address of interface Serial0/0 (line 110), and the crypto map is configured for the two IPsec tunnels on lines 112 through 118. Note that encryption is applied to all packets matching the named extended ACLs GRE1 and GRE2 as configured on lines 114 and 118. These named extended ACLs are defined on lines 220 through 223. Because IPsec is securing GRE tunnels, the ACL classification used to match traffic requiring IPsec support is trivial. Finally, the crypto map is applied to the Serial0/0 interface on line 156.
• NAT: Outbound traffic from the internal private address space (in other words, the 10.0.0.0/8 network) and destined for the Internet uses NAT services. The NAT policy is defined on line 218, which indicates that inside packets with source IP addresses matching ACL NATADD shall be use the NAT service, and the Serial0/0 IP address shall be used as a port address translation (PAT) pool. The ACL NATADD is defined on lines 224 through 226. As shown, the first entry (line 225) denies packets that are sourced from the private network behind CPE-A0 and destined to any other Customer A VPN site. These packets will use the GRE + IPsec tunnel and thus do not require NAT services. The second entry (line 226) permits packets to use NAT services when destined to the Internet. (Note that the static routes to Null0, defined on lines 207 through 216, are extremely useful for protecting the NAT services. Packets sent toward bogus destinations (for example, in the case where an internal host is infected by a worm and is scanning random networks in search of vulnerable hosts) would be dropped rather than following the default route to the Internet and consuming valuable NAT resources. Finally, line 170 assigns the FastEthernet0/1 interface as NAT inside, and line 153 assigns the Serial0/0 interface as NAT outside to provide the appropriate inside and outside context to NAT services. (The DMZ interface does not require NAT services because this address space is assumed to be Internet routable in this case study.)
Case Study 2: MPLS VPN
Case Study 2 focuses on a typical enterprise 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 for the network, and translated security requirements follows.
Network Topology and Requirements
The network topology and assigned IP addressing schemes used within this case study are illustrated in Figure 8-4. Customer B has three sites connected using a managed MPLS VPN topology, and all three sites obtain their VPN connectivity by direct connections to the same SP IP/MPLS network. Hence, the RFC 4364 section 10 Inter-AS VPN architectural options (a), (b), and (c) do not apply to this case study. MPLS VPN configurations and security techniques for PE and core P routers are reviewed in the companion SP case study within Chapter 9.
Figure 8-4. Conceptual Enterprise Network Architecture for MPLS VPN Connectivity Case Study 2
The functional requirements assumed in this case study are as follows:
• MPLS VPN: Customer B obtains any-to-any IP VPN connectivity from its SP for access between all private sites. The IP VPN is built within the SP network using RFC 4364 MPLS VPNs, and thus Customer B has few requirements on its side of the network. In this case study, being a rather small network, each CE router is assumed to have only a single internal interface for user access at each site. Because each internal interface must be reachable by all other remote sites, these connected interfaces are redistributed into eBGP, and the SP in turn carries these customer-specific prefixes within Multiprotocol BGP (M-BGP) to provide reachability between sites within a single customer IP VPN. By using M-BGP, the SP is assured of addressing and routing separation between different customer IP VPNs. In this case study, the SP is assumed to be AS 65001, and Customer B is assumed to be AS 65002.
• Access: All users of the Customer B MPLS VPN are considered internal, and have access to all Customer B locations and network prefixes. There is no access from the Customer B MPLS VPN to the Internet. Conversely, external access to the Customer B MPLS VPN is not required other than the SP Management VPN, described next, because the customer CE routers are managed.
• Management: In this case study, it is assumed that all Customer B CE routers are managed by the SP. For operational reasons, then, the SP must have in-band access to each CE device. This is achieved using the Management VPN technique, which was described in Chapter 6, “Management Plane Security.”
Figure 8-5 highlights the types and relationships of the interfaces found on the customer edge (CE) router in this case study. These interface types were first introduced in Chapter 3. The following interfaces are included in this case study:
• Internal: Internal interfaces connect network assets wholly within one administrative domain. In this case study, Customer B CE routers only have internal interfaces. That is, even the CE-PE link is considered internal because the PE side of the link is installed in a VRF that binds the link to the private IP VPN of Customer B. Thus, all three Customer B routers include one internal CE-PE interface (in other words, the Serial0/0 interface of all CE routers) that connects each CE router to the SP IP/MPLS network. The assigned IP addresses for this case study are shown in Figure 8-4 for each of these serial connections. In all cases, /30 subnet masking is assigned, and the CE-PE address space is provided by the SP. Even though these interfaces are internal for Customer B, in the context of this case study, the SP restricts access to these prefixes (via ACLs) to prevent Customer B generated packets from reaching the PE and CE interfaces within the VRF (described in the upcoming “Data Plane” section). All three Customer B routers also include a single FastEthernet internal interface. In this case study, FastEthernet0/1 is the common internal interface for all three CE routers. The assigned IP addresses for this case study are also shown in Figure 8-4 for each FastEthernet internal interface. In all cases, /24 subnet masking is assigned. The prefixes associated with these connected interfaces are redistributed into eBGP, and the SP in turn carries these customer-specific prefixes within MBGP to provide reachability between sites within a single customer IP VPN and to provide addressing and routing separation between different customer IP VPNs.
• External: External interfaces connect networks belonging to two different administrative domains. Although the PE-CE links connect the customer and SP networks (and use eBGP), they are considered internal because the PE side of the link is installed in a VRF that binds the link to the private IP VPN of the customer. Thereby, reachability to CE and PE routers is only available from within the IP VPN or via the Management VPN. Therefore, in this case study, all CE router interfaces are considered internal.
• Loopback: All three Customer B routers implement a single loopback interface, Loopback0, which is used for SP management plane traffic (SP management access to the CE routers using the Management VPN). The assigned IP addresses for this case study are shown in Figure 8-4. In all cases, /32 subnet masking is assigned. Because the SP is assumed to be managing all CE routers, these loopback interface addresses are assigned by the SP, and they are reachable within the Management VPN.
• Receive: All routers include by default a receive interface that “logically” represents the slow path to the IOS process-level. This applies to any ingress packets that must be punted from the CEF fast path to the router’s CPU for local processing.
Figure 8-5. IP Traffic Plane Relationships to Router Interfaces for MPLS VPN Case Study 2
Figure 8-5 highlights in particular the router of focus for this case study, CE-B0, and illustrates the relationship among its interfaces. This router is also the focus for the sample IOS configuration in the “Router Configuration” section that follows.
Router Configuration
Security configurations may be derived based upon the topology shown in Figure 8-4 and the previously described functional requirements. Router CE-B0 is used as the focal point for the remaining discussions. The other Customer B CE routers shown in the topology in Figure 8-4 have similar but locally specific configurations.
Example 8-2 provides the derived Cisco IOS configuration that implements the preceding requirements and defense in depth and breadth security principles. This configuration assumes that CPE-B0 is a Cisco ISR class router (1800, 2800, or 3800 series), and that is running Cisco IOS version 12.4 software.
Note
Even though limited requirements are defined for the CE routers in this case study and thus only a basic IOS image is required, implementing more complex security features may be useful in some MPLS VPN network environments. For example, IOS Firewall and IOS IPS features may be useful for enforcing security policies within the MPLS VPN. In addition, IPsec encryption may be required on top of the MPLS VPN to provide confidentiality and integrity mechanisms. In these cases, an IOS image similar to the one used in Case Study 1 is appropriate.
As in Case Study 1, line numbers precede each configuration command shown in Example 8-2 and serve as reference points for the remainder of the discussion that directly follows, which is organized by IP traffic plane.
Example 8-2. Case Study 2 Enterprise Customer Edge Router Configuration
1 : !
2 : version 12.4
3 : service nagle
4 : no service pad
5 : service tcp-keepalives-in
Continues
6 : service tcp-keepalives-out
7 : service timestamps debug datetime msec localtime show-timezone
8 : service timestamps log datetime msec localtime show-timezone
9 : service password-encryption
...10 : no service dhcp
11 : !
12 : hostname CE-B0
13 : !
14 : boot-start-marker
15 : boot system flash c3845-advipservicesk9-mz.124-10.bin
16 : boot-end-marker
17 : !
18 : logging buffered 4096 debugging
19 : no logging console
20 : logging monitor errors
21 : enable secret 5 $1$Vmt.$SYiN8ZjKPe7DuTvNHm/vS.
22 : !
23 : aaa new-model
24 : !
25 : aaa authentication login SPnoc group tacacs+ local
26 : aaa authentication enable default group tacacs+ enable
27 : aaa authorization exec default group tacacs+ none
28 : aaa accounting commands 1 default start-stop group tacacs+
29 : aaa accounting commands 15 default start-stop group tacacs+
30 : !
31 : memory-size iomem 15
32 : ip subnet-zero
33 : no ip source-route
34 : no ip gratuitous-arps
35 : ip icmp rate-limit unreachable 100
36 : ip spd mode aggressive
37 : ip options drop
38 : ip tcp window-size 32768
39 : ip tcp synwait-time 5
40 : ip tcp path-mtu-discovery
41 : !
42 : !
43 : ip cef
44 : ip ip domain name spnet.com
45 : no ip domain-lookup
46 : !
47 : !
48 : no ip bootp server
49 : ip ssh time-out 20
50 : ip ssh source-interface Loopback0
51 : ip ssh version 2
52 : ip scp server enable
53 : !
54 : !
55 : memory free low-watermark processor 100000
56 : memory free low-watermark IO 1000000
57 : username sp-noc privilege 15 secret 5 $1$c/vj$kAzIb.llu.OBhGH1hRVS2/
58 : !
59 : !
60 : class-map match-all CoPP-management
61 : match access-group 121
62 : class-map match-all CoPP-normal
63 : match access-group 122
64 : class-map match-all CoPP-remaining-IP
65 : match access-group 124
66 : class-map match-all CoPP-routing
67 : match access-group 120
68 : class-map match-any CoPP-undesirable
69 : match access-group 123
70 : !
71 : !
72 : policy-map CoPP
73 : class CoPP-undesirable
74 : police 8000 1500 1500 conform-action drop exceed-action drop
75 : class CoPP-routing
76 : police 125000 1500 1500 conform-action transmit exceed-action transmit
77 : class CoPP-management
78 : police 50000 1500 1500 conform-action transmit exceed-action drop
79 : class CoPP-normal
80 : police 15000 1500 1500 conform-action transmit exceed-action drop
81 : class CoPP-remaining-IP
82 : police 8000 1500 1500 conform-action transmit exceed-action drop
83 : class class-default
84 : police 8000 1500 1500 conform-action transmit exceed-action transmit
85 : !
86 : !
87 : interface Null0
88 : no ip unreachables
89 : !
90 : interface Loopback0
91 : description - Loopback for SP Management access
92 : ip address 192.168.0.1 255.255.255.255
93 : no ip unreachables
94 : !
95 : interface Serial0/0
96 : description - To SP PE-03
97 : ip address 209.165.200.242 255.255.255.252
98 : ip access-group iACL-extin in
99 : ip access-group iACL-extout out
100 : ip verify unicast source reachable-via rx
101 : no ip redirects
102 : no ip unreachables
103 : no ip proxy-arp
104 : no fair-queue
105 : !
106 : interface FastEthernet0/0
107 : no ip address
108 : shutdown
Continues
109 : !
110 : interface FastEthernet0/1
111 : description - Customer B HQ Internal
112 : ip address 10.0.0.1 255.255.255.0
113 : ip access-group iACL-internal in
114 : ip verify unicast source reachable-via rx
115 : no ip redirects
116 : no ip unreachables
117 : no ip proxy-arp
118 : no mop enabled
119 : !
120 : interface FastEthernet1/0
121 : no ip address
122 : shutdown
123 : !
124 : interface FastEthernet1/1
125 : no ip address
126 : shutdown
127 : !
128 : !
129 : router bgp 65002
130 : no synchronization
131 : bgp log-neighbor-changes
132 : redistribute connected route-map CustB
133 : neighbor 209.165.200.241 remote-as 65001
134 : neighbor 209.165.200.241 ttl-security hops 1
135 : neighbor 209.165.200.241 update-source Serial0/0
136 : neighbor 209.165.200.241 send-community extended
137 : no auto-summary
138 :!
139 :!
140 : no ip http server
141 : ip http access-class 10
142 : ip http authentication local
143 : ip http secure-server
144 : ip classless
145 : !
146 : !
147 : !
148 : ip bgp-community new-format
149 : ip prefix-list Connected seq 5 permit 10.0.0.0/24
150 : !
151 : ip access-list extended iACL-extin
152 : deny ip 10.0.0.0 0.255.255.255 host 209.165.200.242
153 : deny ip 10.0.0.0 0.255.255.255 host 192.168.0.1
154 : permit tcp host 209.165.200.241 host 209.165.200.242 eq bgp
155 : permit tcp host 209.165.200.241 eq bgp host 209.165.200.242
156 : deny tcp any any eq bgp
157 : deny tcp any eq bgp any
158 : permit icmp 192.168.252.0 0.0.3.255 host 192.168.0.1 echo
159 : permit icmp 192.168.252.0 0.0.3.255 host 192.168.0.1 echo-reply
160 : permit icmp 192.168.252.0 0.0.3.255 host 209.165.200.242 echo
161 : permit icmp 192.168.252.0 0.0.3.255 host 209.165.200.242 echo-reply
162 : permit icmp 10.0.0.0 0.255.255.255 10.0.0.0 0.0.0.255 echo-reply
163 : permit icmp 10.0.0.0 0.255.255.255 10.0.0.0 0.0.0.255 packet-too-big
164 : permit icmp 10.0.0.0 0.255.255.255 10.0.0.0 0.0.0.255 time-exceeded
165 : permit icmp 10.0.0.0 0.255.255.255 10.0.0.0 0.0.0.255 port-unreachable
166 : permit icmp 10.0.0.0 0.255.255.255 10.0.0.0 0.0.0.255 protocol-unreachable
167 : deny icmp any any
168 : permit udp 192.168.252.0 0.0.3.255 host 192.168.0.1 eq snmp
169 : permit udp 192.168.252.0 0.0.3.255 host 192.168.0.1 eq ntp
170 : deny udp any any eq snmp
171 : permit ip any any
172 : ip access-list extended iACL-extout
173 : deny ip 10.0.0.0 0.0.0.255 209.165.200.240 0.0.0.3
174 : deny ip 10.0.0.0 0.0.0.255 209.165.201.4 0.0.0.3
175 : deny ip 10.0.0.0 0.0.0.255 209.165.202.144 0 0.0.0.3
176 : deny ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255
177 : deny ip 10.0.0.0 0.0.0.255 192.168.252.0 0.0.3.255
178 : permit ip host 192.168.0.1 192.168.252.0 0.0.3.255
179 : permit ip host 192.168.0.1 host 209.165.200.241
180 : permit tcp host 209.165.200.242 host 209.165.200.241 eq bgp
181 : permit tcp host 209.165.200.242 eq bgp host 209.165.200.241
182 : deny tcp any any eq bgp
183 : deny tcp any eq bgp any
184 : permit tcp host 192.168.0.1 192.168.252.0 0.0.3.255 eq 22
185 : permit icmp host 192.168.0.1 192.168.252.0 0.0.3.255 eq echo
186 : permit icmp host 192.168.0.1 192.168.252.0 0.0.3.255 eq echo-reply
187 : permit icmp host 209.165.200.242 192.168.252.0 0.0.3.255 eq echo
188 : permit icmp host 209.165.200.242 192.168.252.0 0.0.3.255 eq echo-reply
189 : permit icmp 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255 echo-reply
190 : permit icmp 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255 packet-too-big
191 : permit icmp 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255 time-exceeded
192 : permit icmp 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255 port-unreachable
193 : permit icmp 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255 protocol-unreachable
194 : deny icmp any any
195 : permit ip any any
196 : ip access-list extended iACL-internal
197 : permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255
198 : deny ip any any
199 : logging trap notifications
200 : logging source-interface Loopback0
201 : logging 192.168. 255.11
202 : access-list 10 permit 192.168.252.0 0.0.3.255
203 : access-list 120 remark -- Routing Protocol ACL for CoPP
204 : access-list 120 remark -- -- permit bgp
205 : access-list 120 permit tcp host 209.165.200.241 eq bgp host 209.165.200.242
206 : access-list 120 permit tcp host 209.165.200.241 host 209.165.200.242 eq bgp
207 : access-list 121 remark -- Management Protocol ACL for CoPP
208 : access-list 121 remark -- -- permit ssh (and also scp)
209 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 host 192.168.0.1 eq 22
210 : access-list 121 remark -- -- permit snmp
211 : access-list 121 permit udp 192.168.252.0 0.0.3.255 host 192.168.0.1 eq eq
snmp
Continues
212 : access-list 121 remark -- -- permit tacacs+
213 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 eq tacacs host
192.168.0.1established
214 : access-list 121 remark -- -- permit ntp
215 : access-list 121 permit udp 192.168.0.0 0.0.0.255 host 192.168.0.1 eq ntp
216 : access-list 121 remark -- -- permit https
217 : access-list 121 permit tcp 192.168.252.0 0.0.3.255 host 192.168.0.1 eq 443
218 : access-list 121 remark -- -- permit traceroute
219 : access-list 121 permit udp any gt 10000 any gt 10000
220 : access-list 122 remark -- Normal Traffic ACL for CoPP
221 : access-list 122 remark -- -- permit ICMP types
222 : access-list 122 permit icmp any any echo
223 : access-list 122 permit icmp any any echo-reply
224 : access-list 122 permit icmp any any ttl-exceeded
225 : access-list 122 permit icmp any any unreachable
226 : access-list 122 permit icmp any any port-unreachable
227 : access-list 122 permit icmp any any packet-too-big
228 : access-list 123 remark -- Undesirable Traffic ACL for CoPP
229 : access-list 123 remark -- -- Block Fragments
230 : access-list 123 permit tcp any any fragments
231 : access-list 123 permit udp any any fragments
232 : access-list 123 permit icmp any any fragments
233 : access-list 123 permit ip any any fragments
234 : access-list 123 remark -- -- Block Slammer
235 : access-list 123 permit udp any any eq 1434
236 : access-list 124 remark -- Catch-All IP ACL for CoPP
237 : access-list 124 remark -- -- permit all IP
238 : access-list 124 permit ip any any
239 :!
240 : route-map CustB permit 10
241 : match ip address prefix-list Connected
242 :!
243 : snmp-server community s3cr3t RO 10
244 : snmp-server packetsize 1400
245 : snmp-server enable traps tty
246 : snmp-server trap-source Loopback0
247 : snmp-server host 192.168. 255.11 version 2c s3cr3t
248 : no cdp run
249 : !
250 : tacacs-server host 192.168. 255.12
251 : tacacs-server timeout 2
252 : no tacacs-server directed-request
253 : tacacs-server key 7 0017400516081F
254 : !
255 : control-plane
256 : service-policy input CoPP
257 : !
258 : banner motd ^C
259 : **** AUTHORIZED ACCESS ONLY *****
260 : **** This system is the property of Customer B
261 : **** Disconnect IMMEDIATELY if you are not an authorized user!
262 : **** ********************** *****^C
263 : !
264 : line con 0
265 : exec-timeout 60 0
266 : login authentication SPnoc
267 : line aux 0
268 : transport input none
269 : transport output none
270 : line vty 0 4
271 : access-class 10 in
272 : exec-timeout 60 0
273 : login authentication SPnoc
274 : transport input ssh
275 : !
276 : scheduler allocate 6000 1000
277 : process cpu threshold type total rising 80 interval 5 falling 20 interval 5
278 : ntp authentication-key 1 md5 0505121F6C471D10 7
279 : ntp authenticate
280 : ntp trust-key 1
281 : ntp source Loopback0
282 : ntp access-group serve-only 10
283 : ntp server 192.168. 255.10 key 1
284 : !
285 : end
Data Plane
In this case study, and from the perspective of router CE-B0, 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 enterprise. In the case of CE-B0, this includes all packets routed between each LAN located at sites within the Customer B MPLS VPN. For CE-B0, this interface is represented by FastEthernet0/1. From the perspective of CE-B0, all user traffic is data plane traffic because the MPLS VPN services plane is only defined within the SP side of the network. The CE router has no MPLS VPN awareness.
Data Plane Security
From the perspective of CE-B0, the security mechanisms used for data plane traffic segmentation and control include the following:
• Interface ACLs: Interface ACLs are applied to interface Serial0/0 in both the ingress (in) and egress (out) directions to limit the traffic permitted to enter and exit CE-B0. Example 8-2 configuration lines 151 through 171 implement the ingress functionality via the named extended ACL iACL-extin, which is applied to Serial0/0 in the inbound direction on line 98. Note that this ACL accounts for all ingress traffic, so entries are included for data, management, and control plane traffic. This ACL denies user traffic destined to the Serial0/0 and Loopback0 interfaces because these are controlled exclusively by the SP for control plane and management plane purposes. Further, only the SP NOC address block (192.168.252.0/22) is permitted to reach the Loopback0 destination. The named extended ACL iACL-extout, shown on lines 172 through 195, is applied to Serial0/0 in the outbound direction on line 99 to limit the traffic permitted to enter SP network. This ACL denies user traffic destined to the PE interface address and to the SP NOC address block. Only traffic from the Loopback0 address is permitted to reach the PE interface or SP NOC address block. All other user traffic is permitted to transit the MPLS VPN. Finally, an interface ACL is applied to the FastEthernet0/1 interface in the ingress direction to limit the traffic permitted to reach CE-B0. Configuration lines 196 through 198 implement this functionality via the named extended ACL iACL-internal, which is applied to the FastEthernet0/1 interface in the inbound direction on line 113. This ACL only permits user traffic from the internal LAN that is destined for any address within the Customer B MPLS VPN address range (assumed 10.0.0.0/8). Although these ACLs have some duplication of coverage, together they provide defense in depth and breadth protection and increase the overall security posture of router CE-B0.
Note
The use of the stateful IOS Firewall feature is also feasible and can provide additional security when compared to stateless ACLs. IOS Firewall is capable of tracking outbound requests and dynamically tracking these requests to permit return traffic in a stateful manner. Refer to the “Further Reading” section for more details.
• uRPF: Unicast RPF strict mode is deployed on all interfaces to prevent packets with obviously spoofed IP source addresses from entering the network. For the interface Serial0/0, this implementation is shown on line 100. For interface FastEthernet0/1, uRPF strict mode is applied as shown on line 114.
• IP options drop: The ability for the router to process IP packets with option headers is disabled with the global ip options drop configuration (line 37). The default IOS behavior of processing IP packets with the Source Route option header is also disabled with the no ip source-route configuration (line 33). Again, overlap exists between these two commands for IP header source route options, but this supports in depth and breadth principles.
• IP directed broadcasts: The dropping of IP directed broadcast packets is the default behavior in this IOS image, so the BCP for earlier IOS images to include the no ip directed-broadcast command is not required.
• ICMP techniques: On a per-interface basis, several ICMP BCPs are also enabled. Disabling IP redirects is configured using the no ip redirects interface command (lines 101 and 115), and disabling the generation of ICMP Destination Unreachable messages is configured using the no ip unreachables interface command (lines 93, 102, and 116). Globally, rate limiting of ICMP Destination Unreachable messages is enabled via line 35. The generation of ICMP Address Mask Reply messages and ICMP Information Reply messages is disabled by default in this IOS image, so the BCP for earlier IOS images to include the no ip information-reply and no ip mask-reply interface commands is not required.
Control Plane
In this case study, and from the perspective of router CE-B0, control plane traffic includes the following:
• External BGP (eBGP): Control plane traffic in this category includes eBGP traffic between the interface addresses on CE-B0 and the PE link. In this case study, the prefix associated with the FastEthernet0/1 interface is redistributed into BGP, and then the SP carries this prefix within MBGP to create the Customer B MPLS IP VPN.
• Layer 2 keepalives: Layer 2 keepalives will exist on the Serial interfaces of CPE-B0. Layer 2 keepalives are not defined within the IEEE Ethernet specifications, nor are they applicable to virtual interfaces such as Loopback0.
Control Plane Security
From the perspective of CE-B0, the security mechanisms that will be used for control plane traffic segmentation and control include the following:
• Control Plane Policing (CoPP): CoPP is one of the primary mechanisms for protecting the route processor CPU. When configured, all punted packets reach the route processor CPU through the CoPP mechanism, including in this case all control plane and management plane packets, and some exceptions IP data plane packets. In the case of CE-B0, CoPP is implemented via MQC mechanisms. In total, the CoPP configuration includes the ACLs 120, 121, 122, 123, and 124 shown on lines 203 through 238, the class-map statements shown on lines 60 through 69, and the policy-map statements shown on lines 72 through 84. CoPP is enabled by applying the service policy to the control plane, as shown on lines 255 and 256. Note that the class-default portion of the CoPP policy-map (lines 83 and 84) should be left unpoliced here because it only sees Layer 2 keepalive traffic, because of the existence of the catch-all CoPP-remaining-IP traffic class (lines 81 and 82) directly preceding it in the policy map.
• BGP and BGP TTL security: BGP is configured on lines 129 through 137. Interface Serial0/0 is specified as the source of the CE-B0 BGP traffic on line 135. Connected interfaces are redistributed into BGP on line 132 using the route-map CustB as a filter. Route-map CustB is configured on lines 240 and 241. This route map refers to the ip prefix-list Connected (line 241), which is defined on line 149. Because BGP extended communities will be exchanged, bgp-communities new-format is enabled on line 148. The BGP implementation of the Generalized TTL Security Mechanism (GTSM) is enabled on line 134.
• Selective Packet Discard (SPD): SPD is turned on by default, and the hold-queue, headroom, and extended headroom default settings are adequate. However, SPD aggressive mode is not enabled by default and should be turned on. SPD aggressive mode is enabled via the hidden global configuration command ip spd mode aggressive (line 36).
• Null0 interface: The Null0 interface is configured on lines 87 and 88. The generation of ICMP Destination Unreachable messages for this interface is disabled on line 88.
• Disable unused services: BCP router security configurations related to the control plane include disabling the proxy ARP feature on a per-interface basis via the no ip proxy-arp command (lines 103 and 117). For the FastEthernet interface, the MOP protocol is also disabled via the no mop enabled command (line 118).
Management Plane
In this case study, all CE routers are assumed to be managed by the SP. Thus, the SP assigns a globally unique IP address to a loopback interface that is used for management plane purposes. These loopback interface IP addresses are reachable within the SP Management VPN defined within the SP infrastructure. (See Case Study 2 in Chapter 9 for details on this Management VPN configuration.) From the perspective of router CE-B0, management plane traffic includes the following:
• Provisioning traffic: Management plane traffic in this category includes SSH, HTTPS, and SCP traffic. This traffic must be sourced from within the SP Management VPN and must be destined to the 192.168.0.1/32 address of Loopback0. VTY traffic is restricted to SSH only (Telnet is not permitted). Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix range associated with the SP NOC management block.
• Monitoring traffic: Management plane traffic in this category includes SNMP and Syslog. In the case of CE-B0, ingress SNMP traffic will be destined to the 192.168.0.1/32 address of Loopback0. Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix range associated with the SP NOC management block.
• Other traffic: Several other protocols are used within the management plane and include NTP and TACACS+ traffic. In the case of CE-B0, management traffic of this type will be destined to the 192.168.0.1/32 address of Loopback0. Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix range associated with the SP NOC management block. In addition, several types of ICMP packets (management plane traffic) must be permitted by the iACL (as described under ICMP Techniques section of the “Data Plane” section above) as well for operational needs (Echo Reply, Time Exceeded, and certain IP Unreachable messages). CDP is globally disabled.
• OOB traffic: The console interface is configured for OOB management plane access.
Management Plane Security
From the perspective of CE-B0, the security mechanisms that will be used for management plane traffic segmentation and control include the following:
• Loopback0 interface: The interface Loopback0 is configured on lines 90 through 93. CoPP policies described in the “Control Plane” section above only allow management plane traffic destined to this IP address of the CPE-B0 router.
• AAA: AAA is fully configured for authentication, authorization, and accounting. This begins with the aaa new-model configuration (line 23). Login authentication is configured to use TACACS+ and then local information with the list name SPnoc (line 25). Enable-mode authentication is configured to use TACACS+ and then the enable secret (line 26). (The TACACS+ implementation is not shown.) Command authorization is configured to use TACACS+ and then none (line 27). Command accounting is configured to use TACACS+ (lines 28 and 29). Finally, a local username is configured on line 57.
• SSH services: Configuring SSH requires that a domain name be specified (for RSA encryption key generation). This is done via line 44. (The RSA encryption key is generated outside the configuration during router setup.) SSH protocol parameters are configured on lines 49 through 51.
• In-band VTY access: In-band VTY management plane access is configured on lines 270 through 274. VTY access is restricted to sources matching ACL 10 via line 271, and in-band VTY access is restricted to using the SSH protocol only, on line 274.
• HTTPS and SCP services: HTTPS access is enabled via lines 141 through 143. Line 141 restricts HTTPS access to sources matching ACL 10. ACL 10 is defined on line 202. The HTTP server is disabled on line 140. SCP server functionality is enabled on line 52.
• SNMP and Syslog: SNMP configuration parameters are implemented via lines 243 through 247. SNMP access is restricted to read-only by the community string s3cr3t and is limited to sources matching ACL 10 via line 243. (SNMP is restricted to only monitoring in this case study. Write access is not permitted.) Syslog configurations are included on lines 199 through 201. In addition, in order to generate Syslog messages when BGP changes occur, logging of these changes is enabled on line 131.
• TACACS+, NTP, and DNS: The TACACS+ server parameters are configured via lines 250 through 253. DNS name resolution is disabled for queries generated by the router on line 45. NTP is configured via lines 278 and 283. Ingress NTP messages are restricted to sources permitted by ACL 10 (line 282). Further, MD5 authentication is enabled for NTP message exchanges with the configured NTP server (lines 278 through 280 and line 283).
• Out-of-band console access: OOB (console port) access is configured on lines 264 through 266. Console and VTY login authentication refer to the AAA list SPnoc on lines 266 and 273, respectively. AUX port transport is disabled (effectively shutting down the port) on lines 267 through 269.
• Disable unused services: Several global service settings are disabled, including PAD service (line 4), DHCP services (line 10), and (globally) CDP (line 248). The processing of gratuitous ARP messages is disabled on line 34, and the BOOTP service is disabled on line 48. Note that disabling IP finger services is the default in this IOS image, so the no ip finger or no service finger commands are not required.
• Other BCPs: Other BCP router security configurations related to the management plane are implemented. The router host name is configured on line 12. Global service settings are modified, including enabling timestamps for all debug and logging messages (lines 7 and 8) and enabling password encryption services (line 9). The router boot image is specified on line 15 (lines 14 and 16 are auto-generated). Buffered logging is enabled at debug level and the buffer size is set (line 18). The display of logging messages to the console is disabled (line 19), and logging to the monitor at the error level is enabled (line 20). The enable secret is set on line 21. Several global settings for router self-generated TCP sessions are adjusted, including enabling Nagle services (line 3), enabling TCP keepalives (lines 5 and 6), increasing the TCP window size (line 38), reducing the TCP SYN wait time (line 39), and enabling Path MTU Discovery (line 40). In order to generate Syslog messages when free memory resources are low, low-watermark levels are set for processor and I/O memory on lines 55 and 56. A message of the day (MOTD) login banner is configured on lines 258 through 262. To guarantee CPU time for processes, scheduler allocate is configured on line 276. Finally, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 277.
Services Plane
There are no services plane requirements from the perspective of router CE-B0 in this case study. All services plane requirements occur on the SP side of the network and are instantiated on the PE routers. Chapter 9 provides these details.
Summary
This chapter demonstrated the use of various concepts and techniques described in Chapters 4 through 7 by applying them to conceptual enterprise networks as case studies. Two case studies were presented, one being an Internet-based site-to-site IPsec VPN, and the other being a site-to-site MPLS VPN. Defense in depth and breadth principles were applied to protect IP traffic as it travels across the Internet or a shared IP infrastructure. Full configurations were provided for both case studies, and annotations were included for all security components to provide the appropriate context for each mechanism.
These case studies focused on the enterprise (customer) side of the network. In Chapter 9, the focus will be turned on the SP side of the network for these same cases.
Further Reading
Cisco IOS Firewall Design Guide. Cisco Documentation. http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_implementation_design_guide09186a00800fd670.html.
“Cisco IOS Firewall Performance Guidelines for Cisco Integrated Services Routers.” http://www.cisco.com/en/US/partner/products/ps5855/products_white_paper0900aecd8061536b.shtml.