cisco press router security strategies phần 7 potx

IPsec VPN Services 381 Figure 7-4 Application of IPsec AH to IP Datagrams in Tunnel Mode and Transport Mode IPsec is designed per IETF standards for IP unicast-based traffic only. As such, when there are requirements to apply IPsec to multicast applications, non-IP traffic, or routing protocols that use multicast or broadcast addressing, then the additional use of a generic route encapsulation (GRE) tunneling is necessary. GRE provides the means for encapsulating many traffic types within unicast IP packets, hence meeting the requirement for IPsec encapsulation. With IPsec and GRE working together, support is available for multicast applications; routing protocols such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and Enhanced Interior Gateway Routing Protocol (EIGRP); or even the transport of non-IP traffic such as IPX or AppleTalk within an IPsec environment. A simple example configuration of an IPsec VPN using ESP encapsulation in tunnel mode is illustrated in Figure 7-5, with the corresponding configuration being given in Example 7-5. Figure 7-6 and corresponding configuration Example 7-6 show the same topology again for the comparable IPsec plus GRE architecture as a direct comparison. (a) IP Datagram – AH Transport Mode (b) IP Datagram – AH Tunnel Mode Original IP Datagram Integrity Checked Integrity Checked Original IP Header AH Header AH Header IP Payload IP Payload IP Payload Layer 2 Header Layer 2 Header New Tunnel IP Header Original IP Datagram Original IP Header IP Payload Original IP Header Original IP Header 382 Chapter 7: IP Services Plane Security Figure 7-5 IPsec VPN Deployment Using ESP Tunnel Mode Example 7-5 IPsec VPN Configuration Using ESP Tunnel Mode Router-A Configuration ! crypto isakmp policy 10 authentication pre-share crypto isakmp key cisco123 address 192.168.5.1 ! crypto ipsec transform-set VPN-trans esp-3des esp-md5-hmac ! crypto map vpnmap local-address Serial0//0 crypto map vpnmap 10 ipsec-isakmp set peer 192.168.5.1 set transform-set VPN-trans match address 101 ! interface Ethernet1 ip address 10.1.1.1 255.255.255.0 interface Serial1/0 ip address 192.168.1.1 255.255.255.252 crypto map vpnmap ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 ! ip route 0.0.0.0 0.0.0.0 192.168.1.2 Router-B Configuration ! crypto isakmp policy 10 authentication pre-share crypto isakmp key cisco123 address 192.168.1.1 ! crypto ipsectransform-set VPN-trans esp-3des esp-md5-hmac ! crypto map vpnmap local-address Serial0//0 crypto map vpnmap 10 ipsec-isakmp set peer 192.168.1.1 set transform-set VPN-trans 10.1.1.0/24 10.1.2.0/24 Serial0/0 192.168.1.1 Serial0/0 192.168.5.1 Router A Router B Internet IPsec Tunnel IPsec VPN Services 383 The example illustrated in Figure 7-5 and the corresponding configurations in Example 7-5 draw on many default conditions and represent a very basic IPsec VPN setup in Cisco IOS. For brevity, only the relevant configuration components are shown. This example is useful nonetheless for illustrating the details of IPsec VPNs. The components of relevance include the crypto isakmp configuration, which provisions the IKE Phase 1 process, and the crypto ipsec transform-set configuration, which provisions the IKE Phase 2 process. The crypto map elements tie the Phase 1 and Phase 2 components together, and the use of an access-list (101 in Example 7-5) specifies which traffic should be subjected to the IPsec VPN process. It should be noted that the Phase 1 and Phase 2 attributes match in both router configurations, and that the access list entries in ACL 101 are reciprocals (mirror images) of each other. These are requirements for Cisco IPsec VPN configurations. Note also the use of the default route (ip route) as well. In this case, all traffic is forwarded toward the same next hop. However, only the traffic matching the crypto ACL will be encrypted and sent across the IPsec VPN tunnel. The remaining traffic (that which does not match the crypto ACL) is forwarded unaltered. In one sense, you may think of this as being similar to a static routing decision, because the router encrypts and encapsulates packets matching this ACL and forwards them not based on the original destination IP address, but instead based on the IPsec header destination IP address (in other words, the set peer address). For Cisco IOS, it is important to note that each entry in the crypto ACL causes the creation of a unique pair of SAs because these ACL entries represent IPsec policy enforcement specifications. SA creation and maintenance consumes resources on the router, and thus a finite number can be allocated. Similar to the way in which managing static routes becomes overwhelming as your network size increase (and thus the benefit of the use of dynamic routing protocols), IPsec VPNs often enlist the aid of the GRE tunneling mechanisms to enable the use of dynamic routing protocols for similar efficiencies. Managing crypto ACL entries can become overwhelming and resource-consuming as IPsec VPN networks increase in size. One way to minimize the creation of SAs and at the same time obtain the benefits of dynamic routing is to use GRE tunneling within IPsec VPNs. IPsec (by IETF standards) is only capable of carrying match address 101 ! interface Ethernet1 ip address 10.1.2.1 255.255.255.0 interface Serial1/0 ip address 192.168.5.1 255.255.255.252 crypto map vpnmap ! access-list 101 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255 ! ip route 0.0.0.0 0.0.0.0 192.168.5.2 Example 7-5 IPsec VPN Configuration Using ESP Tunnel Mode (Continued) 384 Chapter 7: IP Services Plane Security unicast IP packets. Because GRE is itself a unicast IP packet, it is possible to apply the IPsec VPN policy to GRE-encapsulated traffic. This not only greatly simplifies the crypto ACL construction, as illustrated in Example 7-6, but also allows for the use of a dynamic routing protocol (across the GRE tunnel). The example illustrated in Figure 7-6 and the corresponding configurations in Example 7-6 show a very simplified IPsec plus GRE VPN deployment. Figure 7-6 IPsec + GRE VPN Deployment Using ESP Tunnel Mode Example 7-6 IPsec + GRE VPN Configuration Using ESP Tunnel Mode Router-A Configuration crypto isakmp policy 10 authentication pre-share crypto isakmp key cisco123 address 192.168.5.1 ! crypto ipsec transform-set VPN-trans esp-3des esp-md5-hmac ! crypto map vpnmap local-address Serial0//0 crypto map vpnmap 10 ipsec-isakmp set peer 192.168.5.1 set transform-set VPN-trans match address 102 ! interface Ethernet1 ip address 10.1.1.1 255.255.255.0 interface Serial1/0 ip address 192.168.1.1 255.255.255.252 interface Tunnel0 ip address 10.10.255.1 255.255.255.252 ip mtu 1400 tunnel source Serial0/0 tunnel destination 192.168.5.1 crypto map vpnmap ! router eigrp 100 network 10.0.0.0 0.0.0.255 no auto-summary ! ip route 0.0.0.0 0.0.0.0 192.168.1.2 10.1.1.0/24 10.1.2.0/24 Serial0/0 192.168.1.1 Serial0/0 192.168.5.1 Router A Router B Internet IPsec + GRE Tunnel IPsec VPN Services 385 Because the topologies in Figure 7-5 and Figure 7-6 include only two endpoints, the efficiency gains in using GRE are perhaps not obvious from the configurations in Example 7-5 and Example 7-6. It should be apparent, however, that as more networks are added behind the IPsec gateways (Routers A and B), additional entries in the crypto ACL would be required in Example 7-5 (and as a result, more SAs would be built). The crypto ACL in Example 7-6, on the other hand, would remain unchanged because it only refers to the GRE tunnel endpoints in the crypto ACLs, and dynamic routing takes care of the rest. The preceding examples are very basic and are intended solely to illustrate the service components required for IPsec VPNs for the purpose of providing a point of reference for the security recommendations described next. There are many excellent references that deal ! access-list 102 permit gre host 192.168.1.1 host 192.168.5.1 Router-B Configuration crypto isakmp policy 10 authentication pre-share crypto isakmp key cisco123 address 192.168.1.1 ! crypto ipsectransform-set VPN-trans esp-3des esp-md5-hmac ! crypto map vpnmap local-address Serial0//0 crypto map vpnmap 10 ipsec-isakmp set peer 192.168.1.1 set transform-set VPN-trans match address 102 ! interface Ethernet1 ip address 10.1.2.1 255.255.255.0 interface Serial1/0 ip address 192.168.5.1 255.255.255.252 interface Tunnel0 ip address 10.10.255.2 255.255.255.252 ip mtu 1400 tunnel source Serial0/0 tunnel destination 192.168.1.1 crypto map vpnmap ! router eigrp 100 network 10.0.0.0 0.0.0.255 no auto-summary ! ip route 0.0.0.0 0.0.0.0 192.168.5.2 ! access-list 102 permit gre host 192.168.5.1 host 192.168.1.1 Example 7-6 IPsec + GRE VPN Configuration Using ESP Tunnel Mode (Continued) 386 Chapter 7: IP Services Plane Security specifically with IPsec VPN architectures and their optimizations. Some of these are referenced in the Further Reading section at the end of this chapter. Securing IPsec VPN Services It may sound odd that a security protocol such as IPsec requires protection itself. However, when considering that implementing IPsec requires significant additional packet processing resources above and beyond normal data plane forwarding, not to mention the establishment and maintenance of a separate control plane, it is easy to see why the IPsec process itself must be protected. Additional CPU processing (mainly for IKE functions), memory consumption (for SA storage), and specialized hardware (for encryption) are used to implement IPsec VPNs. The two main reasons for protecting IPsec include the following: • IPsec is a complex service: IPsec involves extra packet handling, the maintenance of state, and additional interconnected complexities with routing, NAT, and other processing functions. Thus, IPsec can itself become a potential DoS target. Whether malicious or unintentional through misconfigurations and inadvertent resource consumption, it is possible to impact the IPsec service itself, or even the platform(s) upon which the service is hosted. • IPsec is a specialized service: IPsec is a specialized service that requires additional resources beyond normal forwarding. Although newer hardware options are available to increase the capacity and performance of IPsec VPNs, these still remain premium services. Because this hardware represents a finite resource, only selected packets should be capable of using the service. In addition, the encryption process itself can add delay in forwarding, so QoS mechanisms may also need to be applied to prioritize flows within the IPsec VPN. The main ideas here are essentially the same as with the other services previously described. The services plane applies additional packet handling requirements, implying that they can become DoS targets. In addition, services represent scarce resources (as compared with standard data plane forwarding), implying that the service should be reserved for selected packets. Thus, the following considerations should be made when deploying IPsec VPNs. IKE Security As described above in the IPsec VPN Overview section, the IKE establishes and maintains the control plane for IPsec VPNs. IKE uses UDP as transport, defaulting to port 500. IKE packets are receive packets and are normally processed by the router CPU itself. Because the IKE process must be publicly reachable, it is exposed to direct attack. In addition, the first version of IKE (IKEv1), the most generally deployed version today, requires that some fairly significant amount of processing be accomplished within the IKE Phase 1 negotiation process before it can determine whether the IKE request is legitimate or not. (IKEv2 IPsec VPN Services 387 provides some corrective measures to help alleviate this issue.) Thus, you should take steps to protect the IKE process. The following approaches can be taken, and may be layered with other mechanisms for additional protection: • Interface ACLs: Interface ACLs may be used to limit the sources permitted to reach the IKE process if specific source IP addresses are known. This mainly applies for site-to-site VPNs with fixed IP addresses, because remote-access VPNs generally are sourced from unknown addresses. In the case where this is acceptable, the access list entries should permit selected traffic to reach UDP port 500. (Infrastructure ACL construction and deployment for control plane protection is covered in Chapter 5.) • CoPP: Because IKE packets are receive packets that are processed by the router CPU, they are seen by CoPP mechanisms. CoPP can be used to rate limit IKE connection requests to the router. This has proven effective in cases where the source of the IKE requests is not previously known. Keep in mind that both legitimate and malicious requests will be rate limited. (Specific details on CoPP construction and deployment for control plane processes are covered in Chapter 5.) • Call Admission Control: In later versions of Cisco IOS, a feature named Call Admission Control (CAC) was introduced to protect processes such as IKE session establishment. CAC may be configured and applied to IKE in one of two ways: — To limit the number of IKE SAs that a router can establish, you may configure an absolute IKE SA limit by entering the crypto call admission limit ike sa command in IOS global configuration mode. In this case, the router drops new IKE SA requests when the configured value has been reached. — To limit the system resources that the router may dedicate to IKE, expressed as a percentage of maximum global system resources available, you may configure the call admission limit command, also in IOS global configuration mode. In this case, the router drops new IKE SA requests when the specified percentage of system resources being used exceeds the configured value. More information on CAC may be found in the Cisco.com “Call Admission Control for IKE” reference in the “Further Reading” section. Fragmentation Fragmentation occurs when the IP packet size exceeds the egress link MTU. In modern networks, this is normally not an issue for standard IP forwarding, but, just as in the case of MPLS section above, when services plane protocols such as IPsec encapsulate packets, the added overhead results in oversized IP packets that may require fragmentation before transmission. IP packet fragmentation is never desirable. As previously described in 388 Chapter 7: IP Services Plane Security Chapter 2, fragmentation requires slow path processing and results in performance impacts. This performance impact manifests itself in several ways, some of which are generic to fragmentation in general, and some of which are specific to IPsec in particular. The following discusses both types of issues and then describes options for avoiding or managing fragmentation: • General fragmentation issues: Generally, fragmentation requires the support of slow path processing on routers. Because of this, there is a performance impact simply due to slow path forwarding when fragmentation is required. In addition, fragmentation involves splitting one packet into two, and if the original packet is only slightly oversized, these two new packets will include one large packet and one small packet. Because there are now twice as many packets to forward, and when looking at the maximum forwarding rate of the platform on a PPS basis, you have now consumed twice the resources (headers, trailers, inter-packet delays, routing decisions, and so on) for the same amount of data. In addition, all intermediate routers must forward these additional packets as well. Finally, the receiver must reassemble the fragments, and if any fragments are lost along the way, the entire packet must be retransmitted. • IPsec specific fragmentation issues: More specifically for IPsec, fragmentation can have an even more significant impact on router performance. One thing that should be obvious from Figures 7-3 and 7-4 is that the original packet size increases by up to 84 bytes, depending on IPsec options and mode. By default, packets are fragmented after encryption. When that happens, it causes reassembly to be required by the IPsec VPN peer router prior to decryption. Routers are not designed for fragmentation reassembly, and reassembly is even more processor intensive than fragmentation. For IPsec VPNs, two interrupts are required: one to get packets to the reassembly process, and one to get packets to the decryption process. (Reassembly is not normally required to be performed by the router for normal data plane traffic because the destination address is the end host, not the router itself.) When fragmentation and reassembly must be done in support of IPsec, this can reduce the forwarding performance by as much as 70 percent. As described in Chapter 2, IP routers have a limited number of reassembly buffers, which may also limit the rate of packet retransmissions. Finally, as mentioned above in the previous bullet point, fragmentation often results in the generation of two packets—one large and one small. This intermingling of large and small packets can result in very uneven delays in encryption processing and serialization and may have significant impacts on latency and jitter-sensitive applications deployed across the IPsec VPN. Of course, the best scenario is to avoid fragmentation altogether. When applications are sending small data packets, fragmentation is never an issue. However, when large packets are involved, fragmentation consequences must be considered. There are a number of strategies for resolving fragmentation within the context of IPsec VPNs, and the best approach depends on your particular environment and on how much work you are willing to do to prevent fragmentation. There is no panacea, however, and some engineering effort IPsec VPN Services 389 must be expended to determine the best approach. The main approaches for preventing or managing fragmentation follow. The main idea for all of these techniques is to avoid both fragmentation and reassembly if possible. When this is not possible, minimize its impact on network performance by using these techniques. Host MSS Modification Hosts participating in IPsec VPNs can be hard coded to transmit IP packets that will not exceed a specified size. This technique completely eliminates fragmentation for all packet types. Many IPsec remote-access clients, including the Cisco client for example, provide options for setting this value on the host. (Typically, a value of 1400 bytes is used.) For hosts behind IPsec gateways, manual configuration of this value can be accomplished as well. More information on setting this value on common operating systems may be found in the Cisco Tech Note “Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems,” referenced in the “Further Reading” section. You should also review your host operating system guide for specific details on setting this value. Note, however, that you cannot trust a compromised host to send properly sized packets that will not require fragmentation and reassembly. Path MTU Discovery (PMTUD) PMTUD (RFC 1191) was designed to dynamically determine the lowest MTU between two endpoints. There are several inherent requirements for PMTUD to work successfully, and when it works correctly, it can eliminate fragmentation for certain packet types. First, from the originating end host perspective, PMTUD only works for TCP sessions. Second, PMTUD requires that originating packets be transmitted by the host with the IP header DF bit set to 1 (enabled). This causes these packets to be dropped along the path by any forwarding device that is unable to forward the packet when fragmentation is required. In such a case, when the packet is dropped, an ICMP Type 3, Code 4 message (Fragmentation Needed and DF Was Set) is sent from the device that cannot forward the packet due to fragmentation requirements, to the originating IP address. This ICMP Type 3 Code 4 message also contains the required MTU setting necessary for successful transmission. (See Appendix B for more details on this ICMP message type.) In this way, the end host can dynamically learn the correct MTU and reduce packet size automatically to accommodate IPsec overhead. IPsec participates in PMTUD conversations by default (per RFC 2401) and no extra configuration is required. When GRE is used in conjunction with IPsec, PMTUD must be enabled for the GRE tunnel as well by using the tunnel path-mtu-discovery command within the interface configuration mode. Any firewalls or ACLs along the return path that block ICMP packets will cause PMTUD to fail. PMTUD includes timers that age out the dynamically learned MTU value (the default is 10 minutes). This causes the PMTUD 390 Chapter 7: IP Services Plane Security process to be repeated periodically. Finally, from the end host perspective, TCP is the only protocol that participates in PMTUD. Hence, if other protocols are used—say, for example, you are “testing” your links with large ICMP Echo Request packets and setting the DF bit—they will fail to be transmitted. (Other options must be pursued for non-TCP applications.) Interface TCP MSS Modification The TCP protocol Maximum Segment Size (MSS) (or Maximum Send Segment as it is sometimes referred to) option is sent by hosts within the TCP SYN packet during the TCP connection establishment phase. Each TCP end host then obey the MSS value conveyed by the other end. When IP traffic involves the TCP protocol, Cisco IOS CLI provides a mechanism (per interface) to intercept TCP SYN packets and insert a specific MSS value. The relevant interface command is ip tcp adjust-mss <size>, where size represents the maximum TCP segment size (in bytes) and must account for the header lengths (in bytes) for IP (20), TCP (20), GRE (24), and IPsec (up to 60) header components, meaning the value for <size> could be as small as 1376 bytes. This command should be configured on ingress interfaces toward the private side (originating hosts), or on the GRE tunnel interface. Obviously, this configuration option applies only to TCP traffic, but it can eliminate fragmentation issues when TCP protocols are involved. Interface MTU Modification As previously discussed in the MPLS VPN section above, the interface MTU may be set at either Layer 2 or Layer 3 to leave room in advance for IPsec overhead. To modify the Layer 2 interface MTU, use the mtu <value> interface configuration command. To modify the Layer 3 interface MTU value, use the ip mtu <value> interface configuration command. The Layer 3 form of this command may be used for GRE tunnels as well. The difference between the Layer 2 interface MTU and the Layer 3 interface MTU is that the Layer 3 interface MTU is protocol-specific. Namely, the ip mtu command only applies to IP packets, whereas the Layer 2 mtu command applies to any upper-layer protocols transmitted on the interface (for example, MPLS, L2TPv3, ARP, CDP, and so on). Using either of these techniques will have one of two effects on fragmentation: • If PMTUD is enabled and host packets are TCP and originated with DF = 1, reducing the interface MTU will cause PMTUD to occur once (upon packet ingress to the router), which is not only much earlier in the processing, but also before the IPsec encryption occurs. This ensures that the receiving router will not be required to perform reassembly prior to decryption. If GRE is used, this configuration may save two PMTUD iterations (once prior to GRE encapsulation and a second after IPsec encryption. [...]... window-size 3 276 8 : ip tcp synwait-time 5 : ip tcp path-mtu-discovery :! :! : ip cef : ip domain name customer-a.com : no ip domain lookup continues 412 Chapter 8: Enterprise Network Case Studies Example 8-1 Case Study 1 Enterprise Customer Premises Edge Router Configuration (Continued) 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98... Enterprise Network Case Studies Example 8-1 Case Study 1 Enterprise Customer Premises Edge Router Configuration (Continued) 160 161 162 163 164 165 166 1 67 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 1 87 188 189 190 191 192 193 194 195 196 1 97 198 199 200 201 202 203 204 205 206 2 07 208 209 210 211 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :... Studies Example 8-1 Case Study 1 Enterprise Customer Premises Edge Router Configuration (Continued) 262 263 264 265 266 2 67 268 269 270 271 272 273 274 275 276 277 278 279 : : : : : : : : : : : : : : : : : : 280 : 281 : 282 : 283 : 284 : 285 : 286 : 2 87 : 288 289 290 291 292 293 294 295 296 2 97 298 299 300 301 302 303 304 305 306 3 07 308 309 : : : : : : : : : : : : : : : : : : : : : : permit udp host... VPNs Cisco Press, 2006 ISBN: 1-5 870 5- 179 -6 Rosenberg, J et al SIP: Session Initiation Protocol RFC 3261 IETF, June 2002 http://www.ietf.org/rfc/rfc3261.txt Song, S “SSL VPN Security. ” Cisco Documentation http://www .cisco. com/web/ about /security/ intelligence/05_08_SSL-VPN -Security. html “Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems.” (Doc ID: 1 370 9.) Cisco Tech Note http://www .cisco. com/warp/public/105/38.shtml... for IP/MPLS Networks Cisco Press, 2006 ISBN: 1-5 870 5-233-4 Andreasen, F., and B Foster Media Gateway Control Protocol (MGCP) Version 1.0 RFC 3435 IETF, Jan 2003 http://www.ietf.org/rfc/rfc3435.txt Behringer, M H., and M J Morrow MPLS VPN Security Cisco Press, 2005 ISBN: 1-5 870 5-183-4 Bollapragada, V., M Khalid, and S Wainner IPSec VPN Design Cisco Press, March 2005 ISBN: 1-5 870 5-111 -7 Evans, J W., and... 25885.) Cisco white paper http://www .cisco. com/en/US/tech/tk8 27/ tk369/ technologies_white_paper09186a00800d6 979 .shtml Security in SIP-Based Networks.” Cisco white paper http://www .cisco. com/warp/ public/cc/techno/tyvdve/sip/prodlit/sipsc_wp.htm “Why Can’t I Browse the Internet when Using a GRE Tunnel?” (Doc ID: 1 372 5.) Cisco Tech Note http://www .cisco. com/warp/public/105/56.html PART III Case Studies... Evans, J W., and C Filsfils Deploying IP and MPLS QoS for Multiservice Networks: Theory & Practice Morgan Kaufmann, 20 07 ISBN: 0-123 -70 549-5 Firestone, S., T Ramalingam, and S Fry Voice and Video Conferencing Fundamentals Cisco Press, 20 07 ISBN: 1-5 870 5-268 -7 Kuhn, D R., T J Walsh, and S Fries Security Considerations for Voice Over IP Systems NIST Special Publication 800-58 National Institute for Standards... http://www .cisco. com/en/US/products/sw/iosswrel/ ps1839/products_feature_guide09186a008013489a.html “Pre-Fragmentation for IPSec VPNs.” Cisco IOS Security Configuration Guide, Release 12.4 http://www .cisco. com/en/US/products/ps6350/ products_configuration_guide_chapter09186a0080455b91.html “Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC.” (Doc ID: 25885.) Cisco white paper http://www .cisco. com/en/US/tech/tk8 27/ tk369/... message-digest-key 1 md5 7 044858051D7258 no mop enabled ! interface FastEthernet1/0 description – Customer A HQ DMZ ip address 172 .16.0.1 255.255.255.0 ip access-group iACL-DMZ in ip verify unicast source reachable-via rx no ip redirects no ip unreachables no ip proxy-arp ip ospf message-digest-key 1 md5 7 00 174 00516081F no mop enabled ! interface FastEthernet1/1 no ip address shutdown ! router ospf 10 log-adjacency-changes... IPsec VPN and Internet Access 415 Example 8-1 Case Study 1 Enterprise Customer Premises Edge Router Configuration (Continued) 212 213 214 215 216 2 17 218 219 220 221 222 223 224 225 226 2 27 228 229 230 231 232 233 234 235 236 2 37 238 239 240 241 242 243 244 245 246 2 47 248 249 250 251 252 253 254 255 256 2 57 258 259 260 261 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : . Morrow. MPLS VPN Security. Cisco Press, 2005. ISBN: 1-5 870 5-183-4. Bollapragada, V., M. Khalid, and S. Wainner. IPSec VPN Design. Cisco Press, March 2005. ISBN: 1-5 870 5-111 -7. Evans, J. W.,. 20 07. ISBN: 0-123 -70 549-5 Firestone, S., T. Ramalingam, and S. Fry. Voice and Video Conferencing Fundamentals. Cisco Press, 20 07. ISBN: 1-5 870 5-268 -7. Kuhn, D. R., T. J. Walsh, and S. Fries. Security. VPNs. Cisco Press, 2006. ISBN: 1-5 870 5- 179 -6. Rosenberg, J. et al. SIP: Session Initiation Protocol. RFC 3261. IETF, June 2002. http://www.ietf.org/rfc/rfc3261.txt. Song, S. “SSL VPN Security. ” Cisco