Case StudyUsing Dynamic Addressing with Low-Maintenance Small Home Office Deployments


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:

  • Agents do not manage the configuration of the VPN endpoints furnished by the firm. Instead, the configuration must be centrally managed by the insurance provider, limiting the involvement of the agent in the deployment process to strict "plug-and-play" behavior.

  • The firm realizes that numerous SOHO VPN deployments can lead to a high degree of change as agents move houses or locations within their region of coverage. The VPN deployment must therefore be able to dynamically reconfigure itself whenever there is such a change.

  • The NMS capabilities at the central site have no means by which to "push" the entire IPSec configuration to the VPN endpoints. Instead, the devices are minimally bootstrapped, and the user is simply instructed to enter a username/password for x-auth during IKE Phase 1 (see next requirement). This process is referred to as Easy Secure Device Deployment (EzSDD).

  • Because the deployment uses a combination of dynamic crypto maps and wildcard PSKs for IKE Phase 1 negotiation, Each VPN endpoint will perform x-auth at IKE "Phase 1.5." This enables the network administrators to "evict" agents from the deployment securely without compromising the authentication materials used when authenticating the IKE SA.

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:

  • Introducer A device that is trusted by both the petitioner and the registrar. In this case, the introducer would be the insurance agent.

  • Petitioner A new crypto endpoint that wishes to enroll in the PKI. In this case, the petitioner is the EzSDD endpoint that was drop-shipped directly from Cisco Systems or the selected reseller.

  • Registrar A cryptographic device that is used to authorize access of new petitioners to the network. In this case, the registrar is the firm's CA.

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 Process


Phase 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 Keys


The 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.

Router# Jul  1 12:49:02.131: %SSH-5-ENABLED: SSH 1.99 has been enabled Jul  1 12:49:02.131: %CRYPTO-6-AUTOGEN: Generated new 1024 bit key pair Router# Router#show crypto key mypubkey rsa % Key pair was generated at: 12:49:02 UTC Jul 1 2005 Key name: tti  Usage: General Purpose Key  Key is not exportable.  Key Data:   30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00CDA621   6A21BAA1 D65FFB0C 4C4839D2 19377EAD D10A180D 5ECDD28D 8081FF70 8618E341   6629D0BF FF2F2655 B38B8957 65D7002F F04C08BE DDE0846F C39B5943 193A2BDA   49075218 B1837622 37E40173 513841B5 EEB57CCF 55D216D8 9B56FB7C 23B61125   D57A8327 2E8C399B 6479B982 9AB684F2 9CBAD06A 0E7126E4 3E32EB8D 8B020301 0001 % Key pair was generated at: 12:49:02 UTC Jul 1 2005 Key name: tti.server  Usage: Encryption Key  Key is not exportable.  Key Data:   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00E1E40D 0CC98F6B   CFC7D37F 6DEA0068 1AD55330 475CA9DE C2136964 DFFB8A79 259F634D 8187F927   7BB42F39 66ACEF42 80EA530B 0B3B46E0 C6F9B7F3 B01CFFDE 0172D1C7 7EDB94C1   F514F15A EC8E94F9 0893FCBF 387382E2 E726E95D 1F37D6A0 41020301 0001 Router# Router#sh run Building configuration... Current configuration : 1453 bytes ! !<--Configuration Truncated--> ! !<--The EzSDD petitioner installs a trustpoint to use when enrolling in the PKI !in later phases of the TTI process--> crypto pki trustpoint tti  revocation-check crl  rsakeypair tti ! !<--Configuration Truncated--> ! end


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 Phase


Phase 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 Confirmation


At 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 Phase


It 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 TTI


Upon 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

hostname Branch-Florida15 ! !<--This DHCP pool serves allows the Agent's workstations to dynamically learn !their IP addresses and default gateways, DNS servers, and domain names when !they attach to the network. This pool consists of non-routable IP address !space and is therefore translated before leaving the agents LAN--> ! ip dhcp pool rem-net    network 192.168.1.0 255.255.255.0     default-router 192.168.1.1 ! !<--This is the trustpoint used for enrolling this agent's VPN gateway into !the PKI. The certificates obtained from the CA will be used to authenticate !the agent's VPN gateway during Phase 1 negotiation with the headend router--> ! crypto pki trustpoint tti  enrollment url http:// IS-VPNConc-A:80  serial-number  revocation-check crl  rsakeypair tti ! !<--The following ISAKMP policy uses the IOS default authentication !method  RSA Signatures. This method is required when using EzSDD--> crypto isakmp policy 10 ! ! crypto ipsec transform-set field-transform esp-3des esp-sha-hmac ! !<--The agent's VPN gateway is served a configuration from the Registrar via !secure HTTP during the EzSDD Trusted Transitive Introduction process. !The configuration attained can be based on authentication with a !backend database. In this case, the agent authenticated as an agent based !in Florida and was served a configuration for 'Branch-Florida15'. !Note that while this gateway can use a static crypto map, as the remote peer !is known, the headend router cannot as the configuration of this branch !router is unknown until it attains its configuration via TTI.--> crypto map Branch-Florida15 10 ipsec-isakmp  set peer 200.1.1.1  set transform-set field-transform  match address 101 ! interface FastEthernet0/0  ip address 200.1.1.23 255.255.255.0  ip virtual-reassembly !<--Defines the outside NAT interface-->  ip nat outside  speed auto  full-duplex  crypto map Branch-Florida15 ! interface FastEthernet0/1  ip address 192.168.1.1 255.255.255.0  ip virtual-reassembly !<--Defines the inside NAT interface-->  ip nat inside  speed auto  full-duplex ! ip classless ! ! !<--The server configuration is required for EzSDD. This configuration uses !local authentication to authenticate the petitioners. HTTPS is used to secure !the communication between the introducer and the petitioner and registrar. !When HTTPS is used, the secure-trustpoint command must also be entered to !ensure interoperability with the defined trustpoint PKI.--> ip http server ip http authentication local ip http secure-server ip http secure-trustpoint ! !<--NAT is being used to maintain Layer 3 connectivity between the agent's !devices using non-routable IP address space and the enterprise resources on !the opposite end of the IPSec VPN. Note that the Service Provider will not !route non-routable address space, and that their publicly routed domain is !used for all communications between the agent's remote site and the Firm's !Enterprise Network. In this case, NAT is set up to translate any address in !the 192.168.0.0/16 address space on Fa0/1 into the IP address assigned to !Fa0/0 (200.1.1.1). This configuration uses ports to distinguish between !multiple hosts translating to the same address, 200.1.1.1--> ip nat inside source list 1 interface FastEthernet0/0 overload ! !<--ACL 1 defines the inside local address space to be translated into !200.1.1.1 (the IP address assigned to Fa0/0--> access-list 1 permit 192.168.0.0 0.0.255.255 !<--ACL 101 defines the address space to be included in the crypto switching !path (encrypted with IPSec). It is important to note that traffic from the !source of 200.1.1.1 is encrypted, not 192.168.0.0/16. This is due to the fact !that encryption decisions occur after NAT decisions. As such, if the ACL were !to include 192.168.0.0/16 as the source, the traffic from the agent's remote !site would not be processed in the crypto switching path and ISAKMP would !never initiate Phase 1 negotiation--> access-list 101 permit ip host 200.1.1.1 any ! End


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

hostname IS-VPNConc-A ! ip domain name cisco.com ! ! !<--This is the PKI server used to enroll new VPN gateways at agent remote sites !into the PKI during the EzSDD TTI. It is set up to automatically grant !certificates to its requestors. This parameter can be manually changed to !require an administrator to grant each certificate request as it comes !in from the requestor.--> crypto pki server cs1  grant auto ! !<--IOS will automatically install a trustpoint for the corresponding !certificate server once the certificate server is administratively !enabled (no shut)--> crypto pki trustpoint cs1  revocation-check crl  rsakeypair cs1 ! !<--Because this headend is also serving as a Registrar and Certificate !Authority, this trustpoint was configured to obtain a certificate to use to !negotiate IKE Phase 1 SAs with the remote peers. In reality, the certificate !authority and registrar would be bundled together on a separate device. !This trustpoint configuration would still be required to enroll the !Headend router in the PKI.--> crypto pki trustpoint IS-VPNConc-A  enrollment url http://IS-VPNConc-A:80  serial-number  ip-address FastEthernet0/1  revocation-check none  rsakeypair 1024 ! ! !<--The following registrar configuration is required for EzSDD Petitioners !(Agent Remote VPN Gateways) to obtain their final configuration. !This registrar uses the PKI server cs1 (via the trustpoint configuration !on this router), and instructs the petitioner and introducer to obtain the !petitioner configuration on the http server "confserv-main" which resides !on the enterprise network DMZ--> crypto provisioning registrar  pki-server cs1  template config http://confserv-main/Branch-Florida15-confg username remuser1 privilege 15 password 0 cisco ! !<--The following ISAKMP policy uses the IOS default authentication !method  RSA Signatures. This method is required when using EzSDD--> crypto isakmp policy 10 ! ! crypto ipsec transform-set RAVPN-trans esp-3des esp-sha-hmac ! !<--Dynamic crypto maps are used when the addresses of remote peers are !unknown in advance. In this case, because the remote peers are obtaining !their IP addresses dynamically from the service provider, the administrators !of the VPN concentrator do not know the remote peers in advance. Therefore a !dynamic crypto map is used to "learn" the peer's IP addresses after they are !brought online by the agent via the TTI process--> crypto dynamic-map RAVPN-dyn 10  set transform-set RAVPN-trans ! ! !<--To apply a dynamic crypto map, it must first be referenced !in a static crypto map--> crypto map RAVPN-stat 10 ipsec-isakmp dynamic RAVPN-dyn ! ! interface FastEthernet0/1  ip address 200.1.1.1 255.255.255.0  duplex auto  speed auto !<--The static crypto map referencing the dynamic crypto map is applied to !the appropriate crypto interface-->  crypto map RAVPN-stat ! !<--The server configuration is required for EzSDD. HTTPS is used to secure the !communication between the introducer and the petitioner and registrar. !When HTTPS is used, the secure-trustpoint command must also be entered !to ensure interoperability with the defined trustpoint PKI.--> ip http server ip http secure-server ip http secure-trustpoint ! End


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

3745-Registrar#show crypto isakmp sa dst             src             state          conn-id slot status 200.1.1.1       200.1.1.23      QM_IDLE             24    0 ACTIVE 3745-Registrar#show crypto ipsec sa interface: FastEthernet0/1     Crypto map tag: campus-stat, local addr 200.1.1.1    protected vrf: (none)    local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)    remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)    current_peer 200.1.1.23 port 500      PERMIT, flags={}     #pkts encaps: 307, #pkts encrypt: 307, #pkts digest: 307     #pkts decaps: 307, #pkts decrypt: 307, #pkts verify: 307     #pkts compressed: 0, #pkts decompressed: 0     #pkts not compressed: 0, #pkts compr. failed: 0     #pkts not decompressed: 0, #pkts decompress failed: 0     #send errors 0, #recv errors 0      local crypto endpt.: 200.1.1.1, remote crypto endpt.: 200.1.1.23      path mtu 1500, ip mtu 1500      current outbound spi: 0x1C5F47BE(476006334)      inbound esp sas:       spi: 0x46C2BDC4(1187167684)         transform: esp-3des esp-sha-hmac ,         in use settings ={Tunnel, }         conn id: 2003, flow_id: AIM-VPN/HPII:3, crypto map: campus-stat         sa timing: remaining key lifetime (k/sec): (4459514/2316)         IV size: 8 bytes         replay detection support: Y         Status: ACTIVE      inbound ah sas:      inbound pcp sas:      outbound esp sas:       spi: 0x1C5F47BE(476006334)         transform: esp-3des esp-sha-hmac ,         in use settings ={Tunnel, }         conn id: 2004, flow_id: AIM-VPN/HPII:4, crypto map: campus-stat         sa timing: remaining key lifetime (k/sec): (4459514/2314)         IV size: 8 bytes         replay detection support: Y         Status: ACTIVE      outbound ah sas:      outbound pcp sas: 3745-Registrar#





IPsec Virtual Private Network Fundamentals
IPSec Virtual Private Network Fundamentals
ISBN: 1587052075
EAN: 2147483647
Year: N/A
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net