Overview of Design Considerations
When designing a network solution, we often are faced with a myriad of parameters that influence the design process and the selection of the final solution. A network designer ideally would want to control as many parameters as possible apart from the business requirements, which is the basic set of requirements that guide us to the right solution.
This study will focus on designing a solution for site-to-site virtual private networks (VPNs), using IPsec to provide virtualization and strong security for data in transit over the untrusted transport network.
Ideal Design Process
In an ideal environment, we would use a design process that can be split into the following major steps:
Identify business and technical requirements
In this step, we collect information about the applications and protocols that will be using this VPN service; their importance, performance and reliability requirements; technical specifications, quality of service requirements, etc.
Identify the most appropriate solution based on the given requirements
In this step, we process the requirements and try to map them to the solution that is best suited for this VPN.
Select the most appropriate equipment and transport network based on the selected solution and technical requirements
In the last step, we select the equipment that supports the chosen solution. Ideally, this is where the design process ends. In reality, however, we may need to return to the previous step and fine-tune the solution to minimize the cost if the required equipment is too expensive.
Realistic Design Process
In reality, we often are faced with additional initial requirements that precede and may affect the selection of the solution.
Very often, the transport network already is chosen. For example, a cost-cutting migration from a Frame Relay or ATM-based WAN to an MPLS VPN or the Internet sets the selection of the transport network as one of the business requirements. The designer cannot influence the selection of this transport network. On the contrary, the designer has to take into consideration the characteristics of the selected transport network, because not all IPsec implementation options are viable for every type of transport network.
Another example of reversed design order is when the equipment has been chosen and purchased before having a detailed design and understanding of the influence of the selected equipment on the final solution. The designer simply must hope that the chosen equipment supports at least one acceptable solution for implementing a site-to-site IPsec-based VPN.
Cisco IOS - IPsec Solutions
A series of articles will cover solutions using the following major implementation options with Cisco IOS routers:
Static and dynamic crypto maps
Point-to-point GRE tunnels over IPsec
Static and dynamic virtual tunnel interfaces (VTIs)
Dynamic multipoint VPNs (DMVPNs)
Group Encrypted Transport VPN (GET VPN)
Dynamic Group VPN (DGVPN)
This first article focuses on the oldest and most proven implementation option: using static and dynamic crypto maps.
Static and Dynamic Crypto Maps
"Once upon a time, in the land of IP, there was a wide area network (WAN) providing connectivity between clients and servers, and all was well. Then, suddenly, bad things started to happen, and paranoia spread throughout the land. Firewalls grew around hamlets to protect them from the unknown beyond the realm of calm, but then packets were forced to travel thorough the dark forests of the WAN. There was a need to provide them with protection."
Cisco developed a proprietary cryptographic solution called Cisco Encryption Technology (CET) that could be configured between a pair of Cisco IOS routers to encrypt some or all of the traffic being exchanged across the untrusted transport network. At the time, no hardware accelerators existed, although they were soon to follow. Because WANs of the time were private networks (e.g., Frame Relay or ATM-based), there was no requirement for the solution to provide virtualization - only cryptography. Additionally, cryptography consumed significant resources, so a compromise often had to be made, protecting only the sensitive traffic. This situation led to the introduction of crypto maps that could be applied to interfaces, selectively providing protection to traffic passing through the WAN.
Listing 1
CET example
!
crypto map Knight 10
set algorithm 40-bit-des
set peer Armour
match address 101
!
interface Serial0
ip address 192.168.1.1 255.255.255.252
crypto map Knight
!
access-list 101 permit tcp 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
!
NOTE
The example above does not show the manual generation and exchange of public keys.
As the need for cryptography in IP networks grew, the Internet Engineering Task Force (IETF), the Internet’s standardization organization, started developing a standard cryptographic method that could be used on the network layer in a multi-vendor environment. IPsec was born.
IPsec was introduced into Cisco IOS, but it used the existing command structure that was also used for CET - crypto maps. Additionally, IPsec uses a control session called the Internet Key Exchange (IKE) protocol to authenticate peers and negotiate IPsec security associations.
Listing 2
IPsec example with static crypto maps
!
crypto isakmp key mtt3rvLBO3jCoV50zoE address 192.168.1.2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
hash sha
!
crypto ipsec transform-set TS esp-des esp-sha-hmac
!
crypto map Knight 10 ipsec-isakmp
set transform-set TS
set peer 192.168.1.2
match address 101
!
interface Serial0
ip address 192.168.1.1 255.255.255.252
crypto map Knight
!
access-list 101 permit tcp 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
!
As long as static crypto maps are used in a private WAN without any redundancy, implementing them is relatively simple. Problems arise when redundancy is introduced and the Internet is used for transport:
It is difficult to determine which router has an active IPsec tunnel.
All sites must have statically assigned IP addresses.
Central sites aggregating large numbers of IPsec tunnels have large configurations (i.e., one key and crypto map entry for each remote site).
Dynamic crypto maps were introduced to accept IPsec sessions dynamically from an arbitrary source without having to specify the peer’s IP address statically. Although this tool was intended primarily for implementing remote-access IPsec VPNs, it also can be used to implement large-scale site-to-site IPsec VPNs. The complexity of the configuration at the central site is not affected by the number of IPsec tunnels.
Listing 3
IPsec example with dynamic crypto maps
!
crypto isakmp policy 10
encr 3des
authentication rsa-sig
hash sha
!
crypto ipsec transform-set TS esp-des esp-sha-hmac
!
crypto dynamic-map DM 10
set transform-set TS
reverse-route tag 10
!
crypto map Knight 10 ipsec-isakmp dynamic DM
!
interface Serial0
crypto map Knight
!
NOTE
The example above uses digital signatures (i.e., certificates) for authentication. Using wildcard, pre-shared secrets would greatly simplify the implementation, but also may pose a danger to the VPN because the entire VPN can be compromised if any of the routers is compromised. Using per-peer pre-shared secrets is also an option, but would require all sites to have static IP addresses, and the central site would need to have a key configured for each site. An alternative to having static IP addresses is to use aggressive-mode IKE with hostname-based identity.
Reverse route injection (RRI), shown in Figure 1, can be used to create a static route dynamically for IKE-negotiated remote networks. This approach allows a remote router to switch to a backup peer when dead-peer detection (DPD) within IKE determines that the primary peer is no longer reachable. The new peer in the central site then installs a new route and advertises it internally to ensure that all routers find the right return path.
Figure 1
Operation of failure detection and rerouting in native IPsec implementations
Due to typical traffic patterns and the complexity of managing meshed VPNs, this solution typically is deployed in a redundant hub-and-spoke topology, as depicted in Figure 2. Multiple central routers can be used to implement load balancing; some remote sites use one central router as primary and another as secondary, while other remote sites use a different router as primary.
Figure 2
Architecture of a redundant hub-and-spoke topology of point-to-point IPsec sessions
High Availability Using Crypto Maps
To achieve high availability (HA), we have to consider the possible failures:
Link failure
Path failure
Device failure
Redundant links, paths (i.e., transport networks) and devices are used to mitigate single points of failure.
Failure detection can be performed using multiple options:
Dead-peer detection (DPD) within IKE detects failures in the path or of the peering device. A secondary peer can be defined in a crypto map, which will be used if DPD detects a failure of the primary peer.
Listing 4
IPsec HA example with a single crypto map and two peers
!
! On-demand DPD every 10 seconds (two seconds if first DPD lost)
crypto isakmp keepalive 10 2 on-demand
!
crypto map Knight 10 ipsec-isakmp
set transform-set TS
set peer 10.1.1.1 prefer
set peer 10.1.1.2
match address 101
!
interface Serial0
crypto map Knight
!
interface Serial1
crypto map Knight
!
Routing protocols on the transport network detect failures in the path.
Hot Standby Routing Protocol (HSRP) detects failures of adjacent redundant devices (typically in the central site or in larger sites with redundant routers). Virtual Router Redundancy Protocol (VRRP) and Gateway Load Balancing Protocol (GLBP) also can be used. HSRP in combination with stateful switchover (SSO) functionality can be used in central sites that require minimum downtime. IPsec with SSO allows IPsec to continue to operate even if a central device fails, because the state of IPsec SAs is being duplicated actively on a standby HSRP device. This setup enables sub-second convergence.
The choice of options is greatly influenced by the type of transport network:
A private WAN such as an MPLS VPN enables us to design private addressing and routing where classic HA designs are possible using routing protocols. Convergence can be fine-tuned using Interior Gateway Protocol (IGP) customization. To prevent failure of IPsec, SAs and IKE sessions during times of convergence, we can do one of the following:
Ensure that the backup tunnel is always up, by using IP SLA to generate “interesting” traffic on the backup path periodically. Source IPsec from a loopback interface and ensure that IGP convergence is faster than DPD, to prevent unnecessary flaps of IKE sessions (i.e., existing IKE and IPsec SAs are rerouted onto the secondary path).
Listing 5
IPsec HA example with one crypto map sourced from a loopback interface
!
crypto map Knight local-address Loopback0
!
crypto map Knight 10 ipsec-isakmp
set transform-set TS
set peer 10.1.1.1 prefer
set peer 10.1.1.2
match address 101
!
interface Serial0
description Primary path
crypto map Knight
!
interface Serial1
description Backup path
crypto map Knight
!
The Internet does not allow us to have arbitrary addressing, and BGP is the only routing protocol that can be used. Even BGP cannot ensure the detection of a failure (e.g., a default route does not reveal a failure in the path). For that reason, we usually use DPD to detect failures. We also can use the Reliable Static Routing Backup Using Object Tracking feature to detect whether the remote IPsec peer is no longer reachable over the primary path and reroute onto the secondary path.
Listing 6
IPsec HA example with two crypto maps and object tracking
!
crypto map Knight 10 ipsec-isakmp
set transform-set TS
set peer 10.1.1.1 prefer
set peer 10.1.1.2
match address 101
!
crypto map Prince 10 ipsec-isakmp
set transform-set TS
set peer 10.1.1.2
match address 101
!
interface Serial0
description Primary path
crypto map Knight
!
interface Serial1
description Backup path
crypto map Prince
!
ip sla 1
icmp-echo 10.1.1.1
timeout 1000
frequency 3
threshold 2
!
ip sla schedule 1 life forever start-time now
!
track 100 ip sla 1 reachability
!
access list 100 permit icmp any host 10.1.1.1 echo
!
route-map PBR permit 10
match ip address 100
set interface Serial0 Null 0
!
! Use policy-based routing to make sure IP SLA only tracks
! reachability over primary path
ip local policy route-map PBR
!
! Primary default route if primary peer is reachable
ip route 0.0.0.0 0.0.0.0 Serial0 track 100
! Backup default route
ip route 0.0.0.0 0.0.0.0 Serial1 254
Summary
The main advantages of using static and dynamic crypto maps include the following:
Mature and well-known implementation method
Interoperability in multi-vendor environments
Supported on all Cisco platforms that support IPsec
The main challenges with static and dynamic crypto maps include the following:
Lack of support for non-IP protocols and IP multicast
No logical interface to simplify routing designs by using routing protocols
Management complexity and static addressing requirements in meshed implementations
Nessun commento:
Posta un commento