The Network-Based IPSec Solution: IOS FeaturesYou have seen conceptually how a network-based IPSec VPN solution enables service providers to expand their VPN portfolio with secure off-net remote access and remote site-to-site services. This section focuses on understanding IOS features that are key to implementing this solution. The following three key features will be discussed:
Virtual Routing and Forwarding (VRF) tables
Crypto keyrings
ISAKMP profiles The Virtual Routing and Forwarding TableThe notion of a VRF table was defined in RFC 2547 for MPLS VPNs. As the name suggests, a VRF is a unique routing and forwarding table per VPN. A given PE router may be connected to sites from different VPNs and hence may have multiple VRFs. To provide per-VPN routing segregation and avoid accidentally forwarding packets from one VPN to another, VRFs are kept on the PE routers. A CE connected to a PE is associated with a VPN by explicit configuration of the VRF on the PE interface connecting the CE. The association between a given VRF and its attached set of interfaces or subinterfaces is determined by explicit configuration. When a packet arrives from a CE, the routing or forwarding lookup for the destination is performed in the associated VRF table ensuring packets are only forwarded to destinations in the VRF. The VRF itself is populated by learning IPv4 routes from the CE by typical routing protocols such as OSPF, eBGP, static, RIPv2, and EIGRP. The PE advertises the routes learned from the CE to all other PEs via multiprotocol extensions to BGP (MP-BGP). The routes advertised by the PE via MP-BGP are known as VPNv4 routes. A couple of key attributes that are tagged to the VPNv4 routes in MP-BGP are the route target (RT) and the route distinguisher (RD). The RD enables overlapping address pools between VPNs or VRFs, whereas the RT determines the distribution of the routes into the remote PE's VRF. Both attributes are manually configured. Crypto KeyringsYou learned in previous chapters that when you configure IPSec, you must configure the Internet Security Association and Key Management Protocol (ISAKMP) policies. If the authentication scheme used is a pre-shared key, then you have to configure the corresponding key for each IPSec endpoint. In the traditional IPSec model, all the IPSec terminations are for connectivity into a single IPSec VPN, whereas in the network-based IPSec model you need to terminate IPSec tunnels belonging to different VPNs on the same IPSec aggregator. This means you need a mechanism to demarcate the keys of different VPNs, which is exactly what crypto keyrings are about. With crypto keyrings, each VPN has its own unique keyring. Example 9-1 shows crypto keyrings for two different VPNs. A crypto keyring is in use if it is attached to one or more ISAKMP profiles. A crypto keyring cannot be deleted while it is in use by one of the profiles. Example 9-1. Crypto Keyring Configurationcrypto keyring vpn1 description keys for vpn1 pre-shared-key address 9.1.1.145 key vpn1aes crypto keyring vpn2 description keys for vpn2 pre-shared-key address 9.1.1.149 key vpn2ikev2 If the VRF keyword is not specified in the crypto keyring command, the keyring is bound to the global VRF (global routing table). When a VRF keyword is used in the command, the keyring is associated with the front-door VRF (FVRF). Operation of Network-Based IPSec VPNs" section, later in this chapter. Example 9-2. Crypto Keyring with FVRF Associationcrypto keyring vpn1 vrf vpn1 description keys for vpn1 pre-shared-key address 9.1.1.145 key vpn1aes ISAKMP ProfilesAn ISAKMP profile can be viewed as a placeholder for holding phase 1 and phase 1.5 (x-auth/mode-cfg) configuration applicable to an aggregation of peers. The ISAKMP profile selected for a specific peer during Internet Key Exchange (IKE) negotiation can be identified by using one of the following:
Phase 1 IKE identity. The identities could be of type IP Address, FQDN, USER-FQDN, DN, and ID_KEY_ID.
Matching fields in the certificate forwarded by the peer during authentication. Chapter 4, "IPSec Authentication and Authorization Models," ID_KEY_ID is the groupname for Cisco Unity clients. You can also see that in the case of remote access, you can configure all the AAA attributes within the ISAKMP profile, as shown in Example 9-3. Example 9-3. ISAKMP Profile Configurationcrypto isakmp profile vpn1 vrf vpn1 description IVRF keyring vpn1 match identity address 9.1.1.145 255.255.255.255 match identity hostname domain vpn1.com accounting vpn ! crypto isakmp profile vpn1-ra vrf vpn1 match identity user-fqdn user@vpn1.com match identity group vpn1group client authentication list vpn isakmp authorization list vpn client configuration address respond accounting vpn If the FVRF interface is in a VRF (not in global), then you must make sure there is a configuration that has the match identity statement with the VRF option, as shown in Example 9-4. Example 9-4. Configuration Showing FVRF Association with Match Identity for Site-to-Site IPSec VPNscrypto isakmp profile vpn2 vrf vpn2 keyring vpn2 match identity address 9.1.1.149 255.255.255.255 vrf vpn2 accounting vpn If the match criteria for the selection of the ISAKMP profile is based on certificates, then define the corresponding certificate map and assign that map to the match certificate, as shown in Example 9-5. Example 9-5. Use of Certificates to Bind to a Profile and VRFcrypto isakmp profile vpn1-ra vrf vpn1 ca trustpoint vpn1 match certificate foo client configuration group vpn1group client authentication list vpn isakmp authorization list vpn client configuration address respond accounting vpn ! crypto ca certificate map foo subject-name co ou=EAST subject-name co o=VPN1 The main reason for using certificate matching is for cases in which the assignment of an ISAKMP profile cannot depend solely on the identity sent by the peer, and the intent is to be much more granular. For telecommuter clients wherein the group information cannot be retrieved from the certificate, you can assign a group to the clients. Note The ISAKMP profile must specify at least one "match" subcommand. An ISAKMP profile is regarded as incomplete without a match statement, and any traffic that matches a crypto map to which such a profile is attached will be dropped. Any number of match statements can be specified in a single ISAKMP profile. The match statements should be used with care. An incoming identity will be matched in accordance with the following rules: If the identity is of type IP address, the keyring and the match statement will be used. No two profiles should include the same match identity address and a common keyring. For identities of type ID_FQDN, or ID_USER_FQDN, the longest match will be chosen as the correct match.
|