In this case study, we will discuss a large enterprise IPSec VPN deployment. The enterprise, in this case, is a large insurance provider that services customers nationally. In order to increase their scope of coverage and to keep operational expenses down, the provider is primarily comprised of small branch offices throughout the country. Additionally, the insurance provider has a pilot program that allows agents the opportunity to contract independently with the firm. As a result, the enterprise network must accommodate secure connectivity from a large number of small home offices. When data is transferred from the small branch offices and small office/home office (SOHO) environments to administration databases at the corporate campus headquarters, it is required by law to be done so with confidentiality. Therefore, the insurance provider has decided to invest in a highly flexible and scalable architecture for delivering confidential data transfer between small branches and SOHO environments and the corporate campus network. Of paramount importance to this discussion is the fact that the deployment of VPN endpoints to the thousands of SOHO and branch offices relies on dynamic crypto map usage at the headend. Dynamic crypto maps are required for the following reasons:
To meet these needs, the firm has decided to deploy a dynamic crypto map at the headend router. The VPN endpoints at agent offices are dynamically bootstrapped when they are installed at the remote location. To accomplish this, each device is minimally configured using EzSDD to initiate the bootstrap process with minimal assistance from the agent at the remote office. The agent's routers are therefore drop-shipped directly from Cisco Systems or their chosen reseller with EzSDD enabled by default. This allows the agent to simply plug in and power up the router, then follow several simple instructions on their web browser while connected to the router's LAN port. Once the agent receives the drop-shipped router at their remote branch location, they power up the router, attach it to the cable or DSL modem supplied by their service provider, attach their workstation to an Ethernet port on the LAN side of the router and open a web browser to the HTTP server running on the supplied router. The agent follows several minimal instructions over the presented web interface on their workstation to complete the configuration of their crypto endpoint. This process is commonly referred to as Trusted Transitive Introduction (TTI), consisting of three components:
Figure 12-5 illustrates the TTI process between a remote site acting as a petitioner and registrar on the firm's enterprise network. Figure 12-5. EzSDD Trusted Transitive Introduction ProcessPhase 1 is referred to as the Welcome Phase. The agent connects their VPN gateway to their service provider. The device gets an IP address via DHCP and is now capable of contacting the registrar at the firm's corporate HQ to request an enrollment. In this phase, the agent initiates either an HTTP or HTTPS session to the web server enabled on their new router. Note Of critical importance to this design is the use of DHCP in the initial bootstrap configuration. Because this configuration relies on DHCP to determine its IP address, it is difficult for the firm to deploy static crypto maps at the headend (the peer would have to have been defined). When the petitioner's HTTP server sees the session initiation come in from the introducer, it automatically generates the cryptographic keys required to enroll in the PKI. Likewise, a partial trustpoint (labeled TTI) is generated to facilitate this enrollment. Figure 12-6 illustrates the Welcome Phase web browser interface to the TTI process. Figure 12-6. TTI Welcome Phase Generation of Cryptographic KeysThe corresponding cryptographic keys are created on the petitioner, as illustrated in Example 12-9. When the introducer authenticates to the petitioner, the agent's VPN gateway in this case, the petitioner installs a 1024-bit (default modulus) RSA keypair for future use when authenticating IKE Phase 1 using the RSA Signatures method of authentication. Output from the running configuration reflects the creation of a trustpoint for enrollment to the PKI using TTI and is also shown in Example 12-9. Example 12-9. Automatic Petitioner Configuration Elements During the TTI Welcome Phase.
In the final stages of the EzSDD TTI Welcome Phase, the agent is prompted to enter the website used on the registrar to enroll their cryptographic endpoint into the secure domain. Figure 12-7 displays the instance in which the agent provides the TTI process with the URL necessary to transition from the Welcome Phase to the Introduction Phase. Figure 12-7. EzSDD Transition from Welcome Phase to Introduction PhasePhase 2, called the Introduction Phase, is executed when the introducer (in this case, the insurance agent) is ready to authenticate their crypto endpoint on the registrar. Once the registrar's website is entered, as in Figure 12-7, the petitioner will be prompted for a username and password, if required. In this case, the registrar is configured to use an external AAA database via RADIUS, such as Cisco Secure ACS, which in turn uses the firm's MS Active Directory backend infrastructure to validate the authentication credentials. Figure 12-8 illustrates the next step in the TTI Introduction Phase, providing confirmation that the agent's credentials have been accepted by the registrar. Figure 12-8. EzSDD Introduction Phase Registrar Credential ConfirmationAt this point, the registrar and petitioner have been successfully introduced, and the petitioner can therefore receive its configuration from the petitioner and enroll with the PKI. This is done in the third and final phase of the EzSDD TTI process, the Completion Phase. Figure 12-9 illustrates the completion of the TTI process for a remote branch, Branch-Florida15. At this point Branch-Florida15 has a full working configuration, and has successfully enrolled in the PKI. Figure 12-9. EzSDD Completion PhaseIt is important to note that the registrar must be configured to support the authentication requests, configuration requests and pushes, and the certificate enrollment requests inbound from the petitioner. Upon successful authentication, the remote VPN gateway or TTI petitioner at the agent's site requests a configuration from the database. The configuration database pushes the configuration to the remote VPN gateway, including routing protocol configuration, IPSec configuration, device AAA information, and x-auth configuration. Note At this point, the agent's VPN gateway (petitioner) should be capable of temporarily negotiating a Phase 1 SA with the IPSec aggregation headend in the campus network at corporate headquarters. It is important to note that the VPN aggregation headend will use dynamic crypto maps, since the remote petitioner IP address are not known in advance. This enables the aggregation headend to accommodate the introduction of petitioners into the PKI dynamically, without manual configuration or maintenance from the firm's IT staff. Phase 3, the Completion Phase of the TTI process, consists mainly of the user enrolling with the PKI. Phase 3 is facilitated with the automatically generated keying material and trustpoint configuration obtained in Phases 1 and 2, accordingly. The introducer will be notified that the TTI process has been completed successfully on the web interface presented on their workstation. Figure 12-10 provides output from the Completion Phase of the TTI process, including the running configuration downloaded to the petitioner. Figure 12-10. Branch-Florida15 Configuration Verification Using TTIUpon completion of these steps, IPSec and ISAKMP SAs can be established between the remote IPSec VPN gateway and the IPSec headend gateway. The configurations in Examples 12-10 and 12-11 illustrate the required configuration on the branch (TTI petitioner) and headend IPSec VPN gateways, respectively. Observe that while both VPN endpoints in this case study use static crypto maps, the headend router at the corporate headquarters must use a dynamic crypto map to accommodate the various agent SOHO devices. This element of the overall architecture exists primarily because the headend will never initiate Phase 1 negotiation to the branch. Instead, the branch will always initiate Phase 1 negotiation to the headend. This allows the dynamic crypto map at the headend to learn about remote peers with no additional configuration as the agents bring their IPSec gateways online. Example 12-10. Low-Touch SOHO and Small Branch IPSec VPN Endpoint DeploymentsRemote IPSec VPN Endpoint/Petitioner Final Configuration
The configuration shown in Example 12-11 illustrates a sample configuration of the headend router in this case study. Remember that this case study was written to illustrate the need for dynamic crypto maps. Note that without the dynamic crypto map on IS-VPNConc-A in Example 12-11, each remote user would require their own static crypto map entry on IS-VPNConc-A. The use of dynamic crypto maps on the headend, however, allows IS-VPNConc-A to learn about its peers dynamically as they are brought online by the insurance agents at the remote sites. This greatly reduces the configuration and administration costs required to support the overall remote access VPN (RAVPN) system, ultimately resulting in drastically reduced operating expenses for the firm. Example 12-11. Low-Touch SOHO and Small Branch IPSec VPN Endpoint DeploymentsHeadend IPSec Concentrator/Registrar
In this example, the headend router (IS-VPNConc-A) acts as the registrar for the EzSDD trusted transitive introduction process. In reality, the registrar will reside on another, separate IOS-based RA or CA within the enterprise network. Because the focus of this chapter is on dynamic crypto maps, the EzSDD registrar functionality is configured on the headend router for simplicity. Note For more information on EzSDD, log on to the following CCO resource with a valid user account: http://www.cisco.com/en/US/partner/tech/tk583/tk372/technologies_white_paper0900aecd80128d1f.shtml http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide09186a008028afbd.html Once the EzSDD process has completed, the user can then verify the establishment of the IPSec tunnel between the newly introduced router of the secure domain at the agent site and the headend router. Example 12-12 shows that the two crypto endpoints have established Phase 1 and Phase 2 SAs successfully. Note that the source of the SAs (the agent's IPSec VPN gateway) is randomly attained via service provider's DHCP server, rendering it impossible to manually configure the remote peer statically on the firm's headend VPN routera dynamic crypto map must be used to learn the remote peer's address when the agent's VPN gateway comes online. Note Although the VPN gateway at the remote site technically uses a static crypto map to manually define the peer IP of the VPN concentrator on the enterprise network, it is not initially configured as such. Instead, this address is provided to the VPN gateway (the petitioner) during the EzSDD TTI process, along with the full configuration of the router. The router is also enrolled in the enterprise's PKI during this process. Example 12-12 shows the establishment of Phase 1 and 2 SAs on the IPSec headend router, 3745-Registrar. The source of the Phase 1 SA below is dynamically learned via the TTI process. Also note the consistency of the source IP addresses in the Phase 1 and 2 SAsthe source IP address of the remote peer (TTI petitioner) is the same as the dynamically learned source IP address in the Phase 1 SA. Example 12-12. Verifying SA Establishment on the IPSec Headend
|