|
|
This section describes deployment models for the Cisco network-based IPSec VPN solution Release 1.5:
In this topology, the service provider has an existing MPLS backbone and operates a MPLS VPN that interconnects all customer sites. This includes remote customer sites that are part of the MPLS VPN.
This service model enables secure off-net access to MPLS VPNs through IPSec. It allows MPLS providers to extend access to their on-net MPLS VPNs to include worldwide Internet access. Customers who wish to deploy a dynamic routing model can use GRE combined with IPSec.
A remote customer site initiates an IPSec session from the CE that terminates on a unique interface on the aggregating Cisco 7200 provider edge (PE) router. The Cisco 7200 PE then maps the site from the interface to its respective VPN.
The service provider can either:
In this model a Cisco 7200 series router serves as an aggregating router and as a PE and uses VRFs to provide multiple routing instances with each instance independent of others (Figure 2-1).
A VRF consists of an IP routing table, a derived Cisco express forwarding (CEF) table and a set of interfaces that use this forwarding table. You can associate the VRF with one or more VPNs.
As a PE on the MPLS network, the Cisco 7200 advertises the connected routes to the remote PEs containing the same VPN.
For information on configuring IPSec to MPLS VPN, refer to Chapter 2 in the Cisco Network-Based IPSec VPN Solution Release 1.5 Implementation Guide.
This setup uses the Multi-VRF on CE routers feature of Cisco IOS software (Figure 2-2).
This feature brings PE functionality to the CE and uses VRF interfaces to form a VLAN-like setup on the customer side. Each VRF on the CE then maps to a VRF on the PE on separate logical or physical interfaces.
You can connect the IPSec aggregating router to the PE through various L2 technologies, including Frame Relay, ATM, or 802.1q interfaces. Each interface forwards remote sessions traffic belonging to a specific VPN.
A typical scenario: You have a GSR as a PE but want to terminate IPSec too. Terminate IPSec on a Cisco 7200 router and map to the appropriate VRF. The Cisco 7200 router on the MPLS side connects to the GSR 802.1q interface with each 802.1q mapped to the appropriate VRF.
For information on configuring IPSec to MPLS VPN, refer to Chapter 2 in the Cisco Network-Based IPSec VPN Solution Release 1.5 Implementation Guide.
The IPSec to L2VPN model is very similar to the IPSec to MPLS topology described in the previous section, except the service provider has an L2 core instead of an MPLS core (Figure 2-3).
The L2 core can be Frame Relay, ATM, 802.1q, or wireless.
This topology enables an L2 service provider to extend secured access service beyond its core into the Internet. Sessions terminate on the aggregator platform, similarly to the IPSec to MPLS model.You can then perform an L3 lookup in the routing table and send it out of the appropriate L2VPN VRF interface (Frame Relay, ATM, or 802.1q).
At an L3 level, the IPSec aggregator connects directly to the customer site that has L2 service. The service provider does not need to address the customer routing issue in its core. The IPSec aggregator and the L2 customer site can use either static routes or a dynamic routing protocol to establish end-to-end connectivity.
For information on configuring IPSec to L2VPN, refer to Chapter 3 in the Cisco Network-Based IPSec VPN Solution Release 1.5 Implementation Guide.
In this model, the IPSec aggregator aggregates any remote sites/clients and then forwards the information to a headend enterprise VPN device (Figure 2-4).
Because traffic is going over an open IP network, IPSec provides the necessary encryption over the IP backbone. This also permits private overlapping IP addressing schemes between enterprises.
For information on configuring IPSec to IPSec, refer to Chapter 4 in the Cisco Network-Based IPSec VPN Solution Release 1.5 Implementation Guide.
The IPSec to GRE model is useful when the service provider has a IP backbone but still wants to provide VPN-like functionality (Figure 2-5).
Remote sites and clients terminate as in the IPSec to IPSec model, however they are then encapsulated into GRE and forwarded to a customer headend router that is the other endpoint for GRE.
Using GRE also lets you run a routing protocol on per-VRF basis with the headend customer router. The GRE tunnels towards the headend can also be encrypted.
The packets traveling from remote clients and sites are decrypted, routed to the GRE tunnel interface where they are encapsulated with the GRE header. The GRE packet is then encrypted by IPSec to provide secure connectivity across the IP backbone.
For information on configuring IPSec to GRE, refer to Chapter 5 in the Cisco Network-Based IPSec VPN Solution Release 1.5 Implementation Guide.
The PE to PE encryption configuration is useful when the service provider wants to encrypt the traffic between the PE devices and an MPLS network (Figure 2-6).
A service provider may want to use this configuration because:
This model allows a service provider to encrypt the traffic between PE devices while continuing to maintain the traffic separation that MPLS provides.
In this configuration, the service provider creates a network of GRE tunnels between all PE devices. Because the VPN tag is maintained across the MPLS network, only a single GRE tunnel is required between two PEs to service all the VPNs.
The MPLS PE is configured to route all traffic to the IPSec PE through a GRE tunnel which that is encrypted. Similarly, the IPSec PE is configured to route all traffic to the MPLS PE through the same encrypted GRE tunnel. Tag switching is configured on the tunnel endpoints.
For information on configuring PE to PE Encryption, refer to Chapter 5 in the Cisco Network-Based IPSec VPN Solution Release 1.5 Implementation Guide.
off-net access is typically required for:
IPSec site-to-site access is for use by remote sites that require access to a specific VPN. It requires that you preconfigure each remote site (with IPSec access configuration) to communicate with the edge of the VPN. Because each site is a remote location requiring dynamic routing, you must configure a GRE tunnel for each site.
off-net sites using the peer-to-peer IPSec model access network-based VPN through:
In the Cisco network-based IPSec VPN solution Release 1.5, IPSec in tunnel mode is used in each possible instance (because VPNs require tunnels).
You must use GRE tunnels to enable dynamic routing between off-net sites and the network-based VPN.
off-net sites typically connect to the network-based VPN in a pre-provisioned hub-and-spoke topology using IPSec tunnel mode and IPSec-protected GRE.
In an off-net site, the IPSec VPN may begin in the customer edge router (the router with the WAN interface to the Internet) or in a device behind the WAN.
If the IPSec VPN originates in the customer edge router, you must provision the router for both Internet access as well as IPSec VPN. You (service provider) and the ISP may both manage this configuration (the customer may also manage parts of the configuration that you and the ISP are not responsible for).
Joint management is not necessary (except that the customer may choose to jointly manage the device) when the IPSec VPN is in a device separate from the WAN router. For the purposes of this document, the following assumptions are made:
You (the service provider) are responsible for configuring:
When an on-net customer subscribes for service, the customer typically provides the location of the headquarter site, and on-net and off-net branch sites. This information identifies the set of PE routers necessary to service the customer.
The customer also provides the following information:
You (the service provider) can use this information to configure all necessary PEs router to provide VPN access over the MPLS backbone in a specified topology. For each on-net or off-net CE router that is brought online, you (the service provider) must configure PE-CE connectivity.
For the peer-to-peer IPSec model, there are no mechanisms for a device to autoconfigure. You must pre-provision configuration information on a peer by peer basis, one end at a CE router and one end at a PE router.
 |
Note ISC assumes IP connectivity to the CE routers and that the IP address of the CE router is known. |
RADIUS servers can be used to:
For more information on the Unity client, see http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_software_versions_home.html .
If the IKE SA negotiates use of XAUTH:
1. The client waits for a challenge and responds.
2. The server authenticates the user, typically using AAA.
3. The client requests MODE-CONFIG parameters from the server. These include:
For more information on the Unity client, see http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_software_versions_home.html .
The Unity protocol maps to a VRF in the same way as the peer-to-peer model described in the section titled "Mapping Unity Client into VRF" section. The Unity client must be configured with the IP address (or FQDN) of the appropriate tunnel-end point address. The group name that you configure on the Unity client for preshared key authentication is also used as the identity. You can also use RSA digital signature authentication where the DN name serves as the identify.
Figure 2-7 shows a typical connection sequence for remote sites.
The following provides typical connection sequences for remote sites (see Figure 2-7).
1. At the remote site CE4, 10.1.1.1 initiates a FTP file transfer to 10.2.1.1 on the corporate side of a network behind REM-CE3. CE4 connects to the Internet gateway by way of an access technology (dial, digital subscriber line [DSL], or cable).
2. When the packet reaches CE4, CE4 performs a route lookup for the destination address and then determines the outbound interface through which to send the packet.
3. After determining the outbound interface, CE4 checks for all the features defined on the outbound interface; this includes a crypto map check.
4. CE4 determines crypto map is configured on the egress interface and identifies the Security Policy Database (SPD) for the crypto entry.
5. CE4 determines from SPD that this traffic is interesting (meaning that it should be protected).
6. CE4 determines if existing SA in the SADB covers this policy.
|
Note If there is no Security Association, CE4 initiate an IKE exchange to the IPSec-Agg PE to negotiate transforms and their corresponding proposals. |
7. CE4 sends IKE SA offer (des, sha, D-H Group, lifetime). ISKAMP Phase 1, Main mode begins.
8. IPSec-Agg PE returns policy match accepting offer.
9. CE4 initiates D-H and Nonce (i) exchange to IPSec-Agg PE.
10. IPSec-Agg PE responds to CE4 with D-H and Nonce (r) exchange.
11. CE4 authenticates D-H Apply sha hash (bidirectional IKE SA established).
12. IPSec-Agg PE authenticates D-H Apply sha hash (bidirectional IKE SA is established. ISKAMP Phase 1, Main mode ends.
13. CE4 sends IPSec offer (transform, mode, lifetime, authen). ISKAMP Phase 2, Quick Mode begins.
14. IPSec-Agg PE identifies policy match and accepts offer.
15. If PFS (perfect forward secrecy) is enabled, CE4 initiates a new D-H exchange to generate new Keying Material (KEYMAT).
16. IPSec-Agg PE initiates D-H exchange or refresh key for IPSec. Unidirectional SA is established; ISKAMP Phase 2, Quick mode ends.
|
Note Routing updates can be exchanged with the CE4 if GRE tunnels are configured for that purpose. Otherwise, static routes corresponding to the remote LAN must be defined in the VRF. |
17. IPSec SAs are associated with the VRF in the SADB table; CE4 transmits packets using SA associated with the egress interface.
18. IPSec-Agg PE checks incoming encrypted packets for decryption and the encryption SA is found. IPSec-Agg PE decrypts the packet and places it in the VRF associated with the SA.
19. IPSec-Agg PE selects an MPLS label for the address of the remote site (10.1.1.1).
20. IPSec-AGG PE advertises the route to REM-PE.
21. CE3 receives the route advertisement and installs the route to 10.1.1.1.
22. IPSec-AGG PE sends the data to CE3 through MPLS using previously learned label for 10.2.1.1.
The client connection is very similar, however the Unity client negotiates SAs differently. The following provides typical connection sequences for remote access (see Figure 2-7).
1. For remote access, a user/client (for example, 170.20.1.1) sends packets (for transfer to main office or to another site) by way of an access technology [dial, digital subscriber line (DSL), or cable].
2. User/client launches custom-installed VPN client and uses a predefined server profile for IPSec-VPN connectivity.
3. DNS resolves server name to a public IP address.
4. Client sends IKE SA offer (des, sha, D-H Group, lifetime). ISKAMP Phase 1, Main mode begins.
5. IPSec-Agg PE returns policy match.
6. Client initiates D-H exchange to IPSec-Agg PE.
7. IPSec-Agg PE responds to client with D-H exchange.
8. Client authenticates D-H Apply sha hash (bidirectional IKE SA established).
9. IPSec-Agg PE authenticates D-H Apply sha hash. The bidirectional IKE SA is established; ISKAMP Phase 1, Main mode ends. IPSec-Agg PE associates IKE SA with the VRF defined in the profile.
10. At user/client, XAUTH prompts for user name and password and forwards to IPSec-Agg PE.
11. IPSec-Agg PE sends authentication request to RADIUS server.
12. RADIUS server accepts (or rejects) request and notifies IPSec-Agg PE.
13. Client requests Mode-Config from IPSec-Agg PE.
14. IPSec-Agg PE sends authorization request to RADIUS server (or provides requested info to client).
15. RADIUS server (or IPSec-Agg PE) provides Mode-Config info to client.
16. Client sends IPSec offer (transform, mode, lifetime, authen). ISKAMP Phase 2, Quick Mode begins.
17. IPSec-Agg PE identifies policy match and accepts offer.
18. Client initiates D-H exchange or refresh key for IPSec.
19. IPSec-Agg PE initiates D-H exchange or refresh key for IPSec. Unidirectional SA established; ISKAMP Phase 2, Quick Mode ends.
20. CE4 transmits packets using SA associated with the egress interface.
21. IPSec-Agg PE checks incoming encrypted packets for decryption and locates the encryption SA. The IPSec-Agg PE decrypts the packet and places it in the VRF associated with the SA.
22. IPSec-Agg PE selects an MPLS label for the address of the remote site (10.1.1.1).
23. IPSec-AGG PE advertises the route to REM-PE.
24. CE3 receives the route advertisement and installs the route to 10.1.1.1.
25. IPSec-AGG PE sends the data to CE3 through MPLS using a previously learned label for 10.2.1.1.
Posted: Tue May 20 14:32:25 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
