IPSec VPN Design [Electronic resources] نسخه متنی

IPSec Tunnel Endpoint Discovery

Traditional IPSec VPN configuration on a Cisco IOS router requires the static configuration of the IPSec peer endpoints via crypto maps. As the name suggests, Tunnel Endpoint Discovery (TED) allows for an IPSec peer to dynamically discover the corresponding IPSec peers. The TED model provides a scalable approach to dynamically building IPSec VPNs based on standard routing protocols. The benefits of using TED include the following:

Simplified crypto configuration

Dynamic crypto maps eliminating a priori peer configuration

IPSec protection built on demand

With TED, the initiating router dynamically determines an IPSec peer for secure IPSec communications. To configure a large, fully meshed network without TED, each peer must have static crypto maps to every other peer in the network. For example, if there are 100 peers in a large, fully meshed network, each router needs 99 static crypto maps, one for each of its peers. With TED, only a single dynamic crypto map with TED enabled is needed because the other peers are discovered dynamically. Thus, static crypto maps do not have to be configured for each peer, which significantly simplifies the configuration.

Principles of TED

Let's take a look at the operation of TED using the network topology described in Figure 7-1. The TED mechanism uses the inherent routing topology of the network to discover tunnel endpoints for prefixes that need to be protected. This means that the protected source and destination IP prefixes must be routable in the backbone between the two IPSec endpoints. The sequence outlined in the following steps is necessary to discover the remote peer endpoints and policies associated with each endpoint:

In this example, HOST-1-WEST sends an IP packet destined to HOST-2-WEST. Assume also that IP reachability information is available in all the routers shown in the figure for all destination subnets. The IP packet is routed to SPOKE-1-WEST where TED is configured on the egress interface destined to HOST-2-WEST. IPSec policy configured on SPOKE-1-WEST identifies that the packet destined to HOST-2-WEST needs to be encrypted, but there is no SA (security association) associated with this.

SPOKE-1-WEST sends a TED probe with a source address of HOST-1-WEST and a destination address of HOST-2-WEST. The TED probe is an IKE message with UDP source and destination port 500. The probe has the following payloads:

- Vendor payloadCisco vendor ID

- ID Endpoint PayloadID, encoded as IP address (SPOKE-1-WEST's IP address)

- ID Proxy PayloadThe proxy address (HOST-1-WEST's subnet derived from the IPSec proxy configured)

The TED probe is intercepted by SPOKE-2-WEST. The TED probe is an IPSec packet that matches the crypto proxy policy defined by an ACL on SPOKE-2-WEST. The intercepting router knows the packet should have been encrypted based on its IPSec policy; however, it also knows that TED is configured. As a result, the router evaluates the packet and determines that it is a probe packet that conforms to the IPSec proxy policies designed to protect the hosts behind SPOKE-2-WEST. SPOKE-2-WEST determines that the flow from HOST-1-WEST to HOST-2-WEST should be protected. The SPOKE-2-WEST then sends a TED reply. The TED response has the SPOKE-2-WEST's IKE identity and the IP subnet that is associated with the IPSec proxy protecting the HOST-2-WEST.

Note

An IPSec proxy policy that matches only TCP traffic will not intercept the TED probes based on protocol type UDP and port 500. If your intent is to protect only TCP traffic between the hosts, then an additional entry is required in the crypto ACL in order to match the UDP TED probes.

When SPOKE-1-WEST receives the TED response, it reads the ID payloads to get the peer's (SPOKE-2-WEST's) IKE identity IP address, and the peer's half of the IPSec proxy.

SPOKE-1-WEST initiates IKE to SPOKE-2-WEST and follows the usual IKE exchange to establish the IKE and IPSec SAs between the peers.

The sequence of events described in the previous numbered list emphasizes the discovery process of TED between two IPSec gateways. Figure 7-2 shows where the Tunnel Endpoint Discovery process occurs relative to the traditional routing updates, IKE initialization, and IPSec data transfer.

Limitations with TED

Although TED reduces configuration complexity and enables dynamic discovery of IKE endpoints in large-scale IPSec VPN deployments, it has several limitations.

The most critical limitation with the TED mechanism is the assumption that routing information for every protected subnet behind each VPN gateway is available in every routing node between the IPSec endpoints. As you learned in previous chapters. One of the biggest motivations for an IPSec VPN is the cost savings reaped by building a VPN over a public network such as the Internet. Typically, the private protected subnets use private addresses (RFC 1918) that are not reachable over a public network. If an IPSec VPN is deployed using private addresses that are not routable across the public network, TED cannot be used because the probe and response packets rely on end-to-end reachability of the source and destination hosts in the private subnets. In IPSec deployments without this limitation (for example, in MPLS/VPN or Frame Relay networks), TED can be quite useful in reducing the configuration complexity.

Some other limitations with TED are:

The crypto proxy configurations must adequately represent the address space (both source and destination) that will be protected; therefore, that address space must be known in advance.

The destination may be represented as "all" routes while the source must represent the address space that the VPN gateway is protecting.

Because the peer is not known at the time of configuration, key management must also be addressed. One option is to use a pre-shared key that is consistent across all VPN gateways in the network. The other alternative is to use a PKI system to dynamically create the key material between the peers.

Note

The creation of IPSec SAs requires the presence of viable VPN routes throughout the network, including the backbone. The TED proxy profiles must not include protection of the VPN routing updates to backbone routers between the IPSec gateways because these backbone routers must be able to process the routing updates. Most routing protocols, such as OSPF or EIGRP, use a multicast or broadcast address to establish adjacencies and send routing updates; these addresses are typically excluded from the IPSec proxy policy. Therefore, inadvertent encryption of the routing protocol between the TED end-point and the next-hop gateway is usually not an issue. Special care must be taken when BGP is used as it relies on unicast to establish neighbor adjacencies.

TED Configuration and State

Figure 7-2 highlighted the establishment of a direct IPSec relationship between SPOKE-1-WEST and SPOKE-2-WEST using TED. The listing in Example 7-1 shows the necessary configuration elements.

Example 7-1. SPOKE-1-WEST Configuration for TED

spoke-1-west#show running-config
!
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
crypto ipsec transform-set ted-transform esp-des esp-md5-hmac
!
crypto dynamic-map ted-map 10
set transform-set ted-transform
match address ted
!
!
crypto map tedtag 10 ipsec-isakmp dynamic ted-map discover
!
interface FastEthernet0/0
ip address 10.0.64.1 255.255.255.0
duplex half
speed 100
!
interface Serial1/0:0
ip address 9.1.1.130 255.255.255.252
crypto map tedtag
!
ip route 0.0.0.0 0.0.0.0 9.1.1.129
!
ip access-list extended ted
permit ip 10.0.64.0 0.0.0.255 10.0.0.0 0.255.255.255
!

Note that the TED configuration does not require the configuration of each IPSec peer relationship. The IPSec SA is dynamically established after traffic matches the IPSec proxy on the backbone uplink interface. Let's assume that the traffic is initiated from the host (10.0.64.5), behind SPOKE-1-WEST, to the host (10.0.65.5), behind SPOKE-2-WEST. The backbone routing protocol must create a path for the destination that forwards the traffic over the interface where IPSec protection is applied. The IP route table listing in Example 7-2 shows that the route process will forward the traffic over the serial interface where the crypto map is applied.

Example 7-2. Routing State for SPOKE-1-WEST

Spoke-1-west#show ip route
9.0.0.0/8 is variably subnetted, 1 subnets, 1 masks
C       9.1.1.128/30 is directly connected, Serial1/0:0
10.0.0.0/8 is variably subnetted, 1 subnets, 1 masks
C       10.0.64.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 9.1.1.129

You can see that the routing table will force traffic destined to 10.0.65.0 out the serial interface where the crypto map is applied. Example 7-3 shows the crypto map state on the serial interface before and after the establishment of SAs between the VPN gateways.

Example 7-3. Spoke IPSec Security Association

spoke-1-west#show crypto map
Crypto Map "tedtag" 10 ipsec-isakmp
Dynamic map template tag: ted-map
Discover enabled
Serial1/0:0
... After IPSec Establishment ...
spoke-1-west#show crypto map
Crypto Map "tedtag" 10 ipsec-isakmp
Dynamic map template tag: ted-map
Discover enabled
Crypto Map "tedtag" 20 ipsec-isakmp
Peer = 9.1.1.134
Extended IP access list
access-list permit ip 10.0.64.0 0.0.0.255 10.0.65.0 0.0.0.255
dynamic (created from dynamic map ted-map/10)
Current peer: 9.1.1.134
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ ted-transform, }
Interfaces using crypto map tedtag:
Serial1/0:0

The recipient node of the TED request (SPOKE-2-WEST) establishes a corresponding IPSec proxy state such that return traffic will be directed to the appropriate initiating router. Recall that SPOKE-2-WEST has an aggregate IPSec proxy defined as 10.0.65.0 -> 0.0.0.0. If this aggregate were used solely for SPOKE-1-WEST, any traffic leaving SPOKE-2-WEST would have to be directed solely to SPOKE-1-WEST. Clearly, that is not the goal, as each spoke should be able to pass traffic to any number of peers. The originating IKE connection specifies that SPOKE-1-WEST is only providing protection for the subnet 10.0.64.0/24; therefore, SPOKE-2-WEST installs only a subset of its IPSec proxy (that is, 10.0.65.0/24 -> 10.0.64.0/24). This restriction allows any subsequent request from a different peer to establish the appropriate IPSec proxy statement that does not overlap with the IPSec proxy established between SPOKE-1-WEST and SPOKE-2-WEST. The listing in Example 7-4 shows the crypto IPSec SA on SPOKE-1-WEST after the establishment of the IPSec SA. Note the explicit IPSec proxy profile defined between SPOKE-1-WEST and SPOKE-2-WEST.

Example 7-4. TED Recipient IPSec Crypto State

spoke-1-west#show crypto ipsec sa
interface: Serial1/0:0
Crypto map tag: tedtag, local addr. 9.1.1.130
local  ident (addr/mask/prot/port): (10.0.64.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.65.0/255.255.255.0/0/0)
current_peer: 9.1.1.134
PERMIT, flags={}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 9.1.1.130, remote crypto endpt.: 9.1.1.134
path mtu 1500, media mtu 1500
current outbound spi: 17339A3B
inbound esp sas:
spi: 0x52B2154D(1387402573)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: tedtag
sa timing: remaining key lifetime (k/sec): (4607998/3489)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x17339A3B(389257787)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: tedtag
sa timing: remaining key lifetime (k/sec): (4607999/3489)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:

Note

The IPSec proxy established between two TED endpoints is the logical intersection between the two proxies defined at either end. The initiator has a proxy profile that includes protection of many more remote addresses than the receiver protects. Likewise, the receiver has a proxy profile that includes protection of many more sources than the receiver protects. Typically, the receiver's IPSec proxy policy must be an inverse superset of the initiator's proxy policy in order to accept the proposal. TED allows the receiver to accept the initiator's IPSec proxy policy despite the fact that it is a superset of the receiver's IPSec proxy policy. The receiver's TED process reconciles the discrepancy between the two IPSec proxy policies by identifying a non-mutually exclusive IPSec proxy policy that is a subset of both the initiator's and the receiver's IPSec proxy policy.

We note that the existence of multiple connections from unique peers requires the instantiation of a unique IPSec proxy for each peer. Over time, each peer will dynamically build IPSec state for traffic flows that match a full mesh. With minimal configuration, the TED method is able essentially to provide fully meshed network connectivity. The TED solution is also able to conserve resources, as you will establish IPSec SAs only between gateways that sustain user data traffic flows. In addition, the IPSec SAs may expire after a period of inactivity, thereby preserving memory in the security association database. Next, you'll investigate what happens when the routing state of the backbone network changes such that the IPSec state is no longer valid.

TED Fault Tolerance

The establishment of TED IPSec SAs clearly makes use of the current state of the backbone routing topology. Note that an interesting situation may occur when routing topology changes. There are two cases that should be considered: routing topology changes between the IPSec endpoints and routing topology changes around the IPSec endpoints. The TED process uses IPSec tunnel mode to encapsulate the protected traffic; therefore, the encrypted traffic uses the IPSec VPN gateway encapsulating addresses to route the packets across the backbone.

In the first scenario (that is, backbone topology change), the IPSec-encapsulated packets will simply follow an alternate path to reach the same IPSec peer endpoint. Assuming the convergence interval of the backbone is short enough, the IPSec IKE process will not detect the loss of the peer, and the IPSec session state will be sustained. A more interesting situation occurs when the backbone routing topology changes such that optimal path to the destination host is no longer through the same VPN gateway. If an alternate remote peer router advertises the protected address space, the originating router will continue to send data using the existing crypto SPI (security parameter index) to the original remote peer router. The alternate router will not receive the packets because it has no crypto state and is not the remote peer defined by the tunneling header. Only when return packets from the remote site invoke a probe packet from the alternate remote VPN gateway, is it possible for the responding host's packets to return to the initiating host. Let's take a look at the topology described in Figure 7-3.

Assume that the primary path to the subnet 10.1.2.0/24 from the backbone network is via VPN-GW1-WEST. When HOST-1-WEST needs to establish a connection to a host on 10.1.2.0/24, SPOKE-1-WEST initiates a TED probe to target the host on 10.1.2.0/24. The TED probe follows the primary route to VPN-GW1-WEST. The VPN-GW1-WEST subsequently responds to SPOKE-1-WEST indicating that an IPSec proxy should be established between the two gateways protecting traffic between 10.0.64.0/24 and 10.1.0.0/16. Once the IPSec SA is established, SPOKE-1-WEST encapsulates the packets using the designated identities (9.1.1.130 <-> 9.1.1.22). If a routing change occurs such that the backbone now routes packets to 10.1.2.0/24 to VPN-GW2-WEST, you have an interesting dilemma. For traffic leaving SPOKE-1-WEST, there may be no routing change. Therefore, SPOKE-1-WEST may continue to direct packets from 10.1.2.0 to VPN-GW1-WEST. If the LAN interface of VPN-GW1-WEST is down, the packets will be dropped for lack of a viable path to the destination host.

Note

The remote peer receiving the packet may decrypt the packet and may have discovered an alternate route to the destination via the backbone (that is, forwarding the packet back out the same interface from which it came); however, the IPSec policy on this remote peer does not provide protection for packets sourced from addresses other than those on its associated LAN.

Only when return traffic from the 10.1.2.0/24 subnet forces VPN-GW2-WEST to issue a TED probe to SPOKE-1-WEST does SPOKE-1-WEST realize a new IPSec SA is being requested. SPOKE-1-WEST may now respond to VPN-GW2-WEST with the appropriate IPSec proxy information such that the two gateways may establish a replacement IPSec SA.

Clearly, there are scenarios in which traffic flows may be interrupted while routing gateways try to determine a more appropriate TED path. The scenario described previously is typically rectified quickly because clients and servers with persistent connections (such as TCP connections) will periodically retry the connection before closing the session. Application connection retries in both directions force the discovery of a new TED path. In scenarios in which clients do not maintain persistent TCP connections to the servers (for example, HTTP, POP3, SMTP, and others), the servers never initiate connections to the clients. Scenarios using applications such as these will lead to long periods of lost connectivity. If the remote peer is still accessible but the hosts behind the peer are inaccessible, the TED state can lead to a persistent "black hole," in which packets are persistently dropped. The situation is only rectified when IKE expires and the initiator establishes a new IKE session. This will lead to the discovery of the alternate peer and will restore the data path between the hosts.

In summary, TED is a reasonable method for dynamically establishing partial- and full-mesh IPSec topologies. It significantly simplifies configuration and allows for redundant topologies with a reasonably quick convergence interval. The one major limitation of TED is that the protected subnet address ranges must be routable in the backbone between the IPSec endpoints, a situation that is not feasible when the protected subnets are private IP networks that are not routable across public networks such as the Internet. Dynamic Multipoint VPN (DMVPN), discussed in the next section, addresses other limitations of TED.