|
|
This chapter introduces the Cisco Network-Based IPSec VPN Solution Release 1.5 and includes the following sections:
The Cisco network-based IPSec VPN solution Release 1.5 is a network-based IP security (IPSec) Virtual Private Network (VPN) integrated solution that allows a service provider to offer scalable services to securely connect remote off-net locations to a customer's corporate VPN extranet or intranet.
The Cisco network-based IPSec VPN solution Release 1.5 leverages the Cisco 7200 series router as an IPSec aggregator/provider edge (PE) router to seamlessly integrate IPSec VPNs into MPLS-based VPNs or into VRFs to be sent out from other interfaces on the same VRFs.
IPSec sessions can be terminated at the edge of the MPLS backbone and each of these can be mapped into their respective VPNs. The mapping configuration depends on the deployment model.
For IPSec standards and specifications, as well as RFCs, see:
http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Internetworking:IPSec&s=Overvie w
IPSec provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through secure tunnels, and you define the parameters to use to protect these sensitive packets by specifying tunnel characteristics. When the IPSec peer encounters a sensitive packet, it sets up a secure tunnel and sends the packet through the tunnel to the remote peer. Figure 1-1 shows a high-level view of IPSec deployment across an IP network.
IPSec tunnels are sets of security associations (SAs) that are established between two IPSec peers. The security associations define which protocols and algorithms should be applied to sensitive packets, and also specify the keying material to be used by the two peers. Security associations are unidirectional and are established per security protocol [Authentication header (AH) or encapsulating security payload protocols (ESP)].
With IPSec, you define the traffic to be protected between two IPSec peers by configuring access lists and applying these access lists to interfaces by way of crypto map sets (a crypto map uses an access list to determine whether a packet needs to be passed through IPSec). Therefore, traffic can be selected based on source and destination address, and optionally Layer 4 protocol, and port. The access lists used for IPSec only determine which traffic should be protected by IPSec, not which traffic should be blocked or permitted through the interface. Separate access lists define blocking and permitting at the interface.
A crypto map set can contain multiple entries, each with a different access list. The crypto map entries are searched in order—the router attempts to match the packet to the access list specified in that entry. It is good practice to place the most important crypto map entries at the top of the list.
When a packet matches a permit entry in a particular access list, and the corresponding crypto map entry is tagged as cisco, then Cisco Encryption Technology (CET) is triggered, and connections are established if necessary. If the crypto map entry is tagged as ipsec-isakmp, IPSec is triggered.
If no security association that IPSec can use exists to protect this traffic to the peer, IPSec uses the Internet Key Exchange protocol (IKE) to negotiate with the remote peer to set up the necessary IPSec security associations on behalf of the data flow. The negotiation uses information specified in the crypto map entry as well as the data flow information from the specific access list entry.
If the crypto map entry is tagged as ipsec-manual, IPSec is triggered. If no security association exists that IPSec can use to protect this traffic to the peer, the traffic is dropped. In this case, the security associations are installed through the configuration, without the intervention of IKE. If the security associations did not exist, IPSec does not have all of the necessary pieces configured.
When established, the set of security associations (outbound, to the peer) is then applied to the triggering packet as well as to subsequent applicable packets as those packets exit the router. Applicable packets are packets that match the same access list criteria that the original packet matched. For example, all applicable packets could be encrypted before being forwarded to the remote peer. The corresponding inbound security associations are used when processing the incoming traffic from that peer.
If IKE is used to establish the security associations, the security associations will have lifetimes set so that they periodically expire and require renegotiation, thus providing an additional level of security.
Multiple IPSec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of security associations. For example, some data streams might be just authenticated while other data streams must both be encrypted and authenticated.
Access lists associated with IPSec crypto map entries also represent the traffic the router requires to be protected by IPSec. Inbound traffic is processed against the crypto map entries—if an unprotected packet matches a permit entry in a particular access list associated with an IPSec crypto map entry, that packet is dropped because it was not sent as an IPSec-protected packet.
Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms, and other settings to apply to IPSec protected traffic. During the IPSec security association negotiation, the peers agree to use a particular transform set when protecting a particular data flow.
IPSec implements network layer encryption and authentication, embedding end-to-end security within the network architecture. The advantage to this is that individual applications do not need to be modified to take advantage of strong security. All packets routed through the network are automatically secured.
IPSec provides three main facilities:
Because both features are generally desirable, most implementations are likely to use ESP rather than AH. The key exchange function allows for manual exchange of keys as well as an automated scheme.
Cisco IPSec includes the following technologies:
The IPSec technologies include the following:
IP-based data is vulnerable to hackers' tampering and eavesdropping. IP's strength is that it has small, manageable packets of electronic information that can be routed quickly and easily. These chunks of information create breaks in the data stream that allow them to be transmitted efficiently through the network. However, the way IP routes these packets causes large IP networks to be vulnerable to a number of security attacks, such as:
In each of these forms of network attack, an unauthorized individual gains access to private company information. To remedy the problem, an international group organized under the Internet Engineering Task Force (IETF) created the IPSec protocol suite, a set of IP protocols that provide security services at the network level. IPSec is based on state-of-the-art cryptographic technology that makes secure data authentication and privacy on large networks a reality.
The IPSec protocol suite has a foundation of powerful encryption technologies. The suite adds security services to the IP layer in a way that is compatible with both the existing IPv4 standard and the emerging IPv6 standard.
IPSec supports two encryption modes:
Figure 1-2 shows a typical network using IPSec in Tunnel mode:
In Tunnel mode, IPSec encapsulates an IP packet with IPSec headers and adds an outer IP header, as shown in Figure 1-3.
An IPSec Tunnel mode packet has two IP headers:
IPSec standards define several new packet formats, such as an Authentication Header (AH) to provide data integrity and the Encapsulating Security Payload (ESP) to provide confidentiality. IPSec parameters between devices are negotiated with the Internet Key Exchange (IKE) protocol, formerly referred to as the Internet Security Association Key Management Protocol (ISAKMP/Oakley).
IKE can use digital certificates for device authentication. The Encapsulating Security Payload and the Authentication Header use cryptographic techniques to ensure data confidentiality and digital signatures that authenticate the data's source.
The IP packet is the fundamental unit of communications in IP networks. IPSec handles encryption at the packet level, and the protocol it uses is the ESP. ESP supports any type of symmetric encryption. The default standard built into ESP that assures basic interoperability is 56-bit DES.
IPSec is a framework of open standards developed by the Internet Engineering Task Force (IETF) that provides security for transmission of sensitive information over unprotected networks such as the Internet. It acts at the network level and implements the following standards:
Essentially, if IPSec is used where IP is normally used (in the network layer), communications are secured for all applications and for all users more transparently than if any other approach was employed. With IPSec, a service provider can create a secure VPN as needed and with any other device that is using the IPSec standard. Because IPSec works with both existing and future IP standards, regular IP networks can still be used to carry data. The sending and receiving devices must be IPSec compliant, but the rest of the network between the sender and recipient does not have to be IPSec compliant.
The primary strength of the IPSec approach is that security works at a low network level. As a result, IP is transparent to the average user, and IPSec-based security services also function behind the scenes to ensure that all network communications are secure. IPSec meets a broad range of security needs and allows different networks around the world to interconnect and to communicate securely. In addition, IPSec offers almost infinite scalability with transparent and reliable service, no matter how demanding a company's security needs.
The Encapsulating Security Payload (ESP) contains six parts as described below. The first two parts are not encrypted, but they are authenticated. Those parts are as follows:
The remaining four parts of the ESP are all encrypted during transmission across the network. Those parts are as follows:
The ESP is added after a standard IP header. Because the packet has a standard IP header, the network can route it with standard IP devices. As a result, IPSec is backward-compatible with IP routers and other equipment even if that equipment is not designed to use IPSec. ESP can support any number of encryption protocols. It is up to the user to decide which protocols to use. Different protocols can be employed for every person a user communicates with. However, IPSec specifies a basic DES-Cipher Block Chaining mode (CBC) cipher as the default to ensure minimal interoperability among IPSec networks. ESP's encryption capability is designed for symmetric encryption algorithms. IPSec employs asymmetric algorithms for such specialized purposes as negotiating keys for symmetric encryption.
Tunneling encapsulates an original IP packet header within the ESP. Then, it adds a new IP header containing the address of a gateway device to the packet. Tunneling allows a user to send illegal IP addresses through a public network (like the Internet) that otherwise would not accept them. Tunneling with ESP offers the advantage of hiding original source and destination addresses from users on the public network. Hiding these addresses reduces the power of traffic analysis attacks. A traffic analysis attack employs network monitoring techniques to determine how much data and the type of data being communicated between two users.
The ESP Authentication field contains an Integrity Check Value (ICV), which functions as a digital signature that is computed over the remaining part of the ESP. The ESP Authentication field varies in length depending on the authentication algorithm used. This field can be omitted entirely if authentication is not needed for the ESP. Authentication is calculated on the ESP packet after encryption is complete. The current IPSec standard requires HMAC (a symmetric signature scheme) with hashes SHA1 and MD5 as algorithms for IPSec-compliant hardware and software in the ESP packet's Authentication field.
The Integrity Check Value supports symmetric type authentication.
The IPSec suite's second protocol, the Authentication Header (AH), provides authentication services. The AH may be applied alone, together with the ESP, or in a nested fashion when tunnel mode is used. Authentication provided by the AH differs from what is provided in the ESP in that the ESP's authentication capabilities do not protect the IP header that lies in front of the ESP, although an encapsulated IP header in tunneling mode is protected. The AH services protect this external IP header, along with the entire contents of the ESP packet. The AH does not protect all of the fields in the external IP header because some change in transit, and the sender cannot predict how they might change. The AH protects everything that does not change in transit. In the packet, the AH is located after the IP header but before the ESP (if present) or other higher level protocol, such as TCP. Like the ESP, the AH can implement tunneling mode. Also, like the ESP, IPSec requires specific algorithms to be available for the AH to be implemented.
The Authentication Header and Encapsulating Security Payload protocols are the building blocks of IPSec. The encryption services provided by the AH and ESP are powerful tools for keeping data secret, for verifying its origin, and for protecting it from undetected tampering. But these tools do not work unless there is a carefully designed infrastructure to work with them. VPN security succeeds or fails depending on the reliability and scalability of this infrastructure.
Secure communication with authentication and encryption requires negotiation, an exchange of keys, and a capability to keep track of the keys. The way that IPSec keeps track of the details, as well as which keys and algorithms to use, is by bundling everything together in a Security Association (SA). An association is a 1-way relationship between a sender and a receiver that affords security services to the traffic carried on it. The SA groups together all of the elements needed for two parties to communicate securely.
If a peer relationship is needed for 2-way secure exchange, two security associations are required. Security services are afforded to an SA for the use of AH or ESP, but not both. A security association is uniquely identified by three parameters:
An IPSec implementation includes a security association database that defines the parameters associated with each SA. A security association is defined by the following parameters:
A 32-bit value used to generate the sequence number field in AH or ESP headers.
Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP.
The key management mechanism that is used to distribute keys is coupled to the authentication and privacy mechanisms only by way of the security parameters index. Hence, authentication and privacy are specified independent of any specific key management mechanism.
The SA is the secure channel through the public network. The SA also lets the system construct classes of security channels. If more secure safeguards are needed, more care can be taken, and the rules of the SA can be changed to specify stronger measures.
Internet Key Exchange (IKE) is a protocol for protocol negotiation and key exchange through the Internet. IKE enables an agreement to be negotiated on which protocols, algorithms, and keys should be used. It ensures secure authentication services from the beginning of the exchange. It manages keys securely after they are agreed upon, and it exchanges those keys safely.
IKE provides four capabilities:
Key exchange is closely related to security association management. When a security association is created, keys must be exchanged. IKE wraps them together, and delivers them as an integrated package. IPSec specifies that compliant systems support manual keying as well. As a result, manual key exchange is possible in certain situations.
However, for most large enterprises, manual key exchange is impractical. Thus, IKE is expected to continue to negotiate SAs and exchange keys automatically through public networks. IKE functions in two phases:
An IKE peer is an IPSec-compliant node capable of establishing IKE channels and negotiating SAs. IKE provides three modes for the exchange of keying information and setting up IKE security associations: Main mode, Aggressive mode, and Quick mode.
Main mode provides a way to establish the first phase of an IKE SA, which is then used to negotiate future communications.
1. The first step, securing an IKE SA, occurs in three 2-way exchanges between the sender and the receiver. In the first exchange, the sender and receiver agree on basic algorithms and hashes.
2. In the second exchange, public keys are sent for a Diffie-Hellman exchange. Nonces (random numbers each party must sign and return to prove their identities) are then exchanged. In the third exchange, identities are verified, and each party is assured that the exchange has been completed.
Aggressive mode provides the same services as main mode. It establishes the phase one SA, and operates in much the same manner as main mode except that it is completed in two exchanges instead of three.
In aggressive mode, the sender generates a Diffie-Hellman pair at the beginning of the exchange, doing as much as is reasonable with the first packet (proposing an SA, passing the Diffie-Hellman public value, sending a nonce to the other party to sign, and so on). The recipient then sends back a consolidation of all three response steps that occur in Main mode.
The result is that aggressive mode accomplishes as much as main mode, with one exception. Aggressive mode does not provide identity protection for communicating parties. In other words, in aggressive mode, the sender and recipient exchange identification information before they establish a secure channel where the information is encrypted. As a result, a hacker monitoring an aggressive mode exchange can determine who has just formed a new SA. Aggressive mode's main value, though, is speed.
After two parties have established a secure channel using either aggressive mode or main mode, they can use Quick mode. Quick mode has two purposes—to negotiate general IPSec security services and to generate newly keyed material. Quick mode is much simpler than both Main and Aggressive modes. Quick mode packets are always encrypted under the secure channel (or an IKE SA established in phase 1) and start with a hash payload that is used to authenticate the rest of the packet. Quick mode determines which parts of the packet are included in the hash.
Key refreshing can be done in two different ways:
A method to generate a new key that does not depend on the current key is needed. The way that perfect forward secrecy is done through IKE is called "Diffie-Hellman."
A user can reduce the risk of hackers deciphering a message through the use of larger and larger keys. But, the larger the key, the slower encryption is accomplished, and network performance also decreases. Use of fairly large keys and frequent changes of them is a good compromise. However, the challenge is coming up with ways to generate these new keys.
Then, if a hacker knows the current key, he or she will know only a small amount of information. The hacker would have to find out an entirely unrelated key to get to the next part. This concept is called perfect forward secrecy.
A Diffie-Hellman exchange allows two users who wish to communicate with each other to randomly generate keys that are similar to a public/private key pair.
1. Each user sends a public key value to the other.
2. Each then combines the public key they receive with the private key they just generated using the Diffie-Hellman combination algorithm.
3. The resulting value is the same on both sides. No other users in the world can come up with the same key from the two public keys that traveled across the Internet, because the final key depends on each user's private key, which is secret.
The derived Diffie-Hellman key can be used either as a session key for subsequent exchanges or to encrypt another randomly generated key. Diffie-Hellman allows new shared keys, that are independent of older keys, to be generated for symmetric encryption, thus providing perfect forward secrecy. Because symmetric encryption operates quickly, Diffie-Hellman is valuable to network communications.
The IPSec-compliant secure VPN includes the Certification Authority (CA). Certification Authority interoperability:
While not an integral part of IPSec, the CA is, nevertheless, a critical element in the public key infrastructure. A CA is a trusted third-party, an entity whose identity has already been established and proven. The CA's role is to vouch for the identities of people with whom a user is trying to communicate.
When verifying online communications, the CA software issues certificates tying together the following three elements:
The CA defends against the "middle-man" hacker who attempts to work his way into key exchanges. Each time an exchange is initiated:
1. Users sign their communications packages with their digital signatures.
2. Those signatures are checked against the ones on record with the CA; they must match.
3. Users then check the CA certificate's signature with the CA's signature. They must match too. Otherwise, an SA cannot be established and no communication can take place.
For a more information on IPSec, see the SAFE VPN White Paper at: http://www.cisco.com/go/safe .
For information on configuring IPSec, see http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v51/config/ipsec.htm .
For information about IPSec security, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/ipsec.htm .
For information about configuring IPSec Network Security, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c /
scprt4/scdipsec.htm.
For more information on Internet Key Exchange Security Protocol, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/isakmp.htm#xtocid1
The Cisco network-based IPSec VPN solution Release 1.5 (Figure 1-4) maps off-net sites into a network-based Layer 3 VPN using IPSec tunnels. The network-based VPN is either a service provider MPLS VPN as described in RFC 2547bis or a service provider L2 network using Multi-VRF CE .
There are three types of off-net sites:
IPSec off-net access is established through one of two ways:
1. The off-net sites connect by way of an access technology [dial, digital subscriber line (DSL), or cable] to a customer edge (CE) device (typically a router). The CE connects over a data link to a provider edge (PE) router.
2. The CE establishes IPSec tunnels with the PE. After establishing the tunnel, the CE advertises the site's local VPN routes to the PE. The CE also learns remote VPN routes from the PE.
3. The PE exchanges routing information with the CE. The PE router also maintains VPN routing information for each VPN it connects to over the service provider network.
4. The PE router maintains a separate Virtual Routing and Forwarding (VRF) table for each off-net site that it connects to through the CE. It is this ability to support multiple VRFs permits per-VPN separation of routing information. Each off-net site connection maps to its specific VRF through a PE port.
 |
Note You can associate multiple interfaces on a PE router with a single VRF if all the sites participate in the same VPN. |
5. After learning routing information from the CE, the PE router advertises the site's local VPN routes over an MPLS or L2 network through provider core (P) routers (P router is out of the scope of this solution) to other PE routers, and then to other CE routers.
|
Note MPLS VPN supports a hub-and-spoke topology only if the spokes connect to two different PE routers, or the spokes are placed in different VRFs. |
The Cisco network-based IPSec VPN solution Release 1.5 supports the following four deployment modes:
Cisco network-based IPSec VPN solution Release 1.5 components include:
The Cisco 7204 and Cisco 7206 series routers serve as an IPSec aggregator/PE. The Integrated Service Adapter (ISA) and the VPN Acceleration Module (VAM) for Cisco 7200 and 7100 Series routers are supported as hardware encryption modules. All of the port adapters supported on the Cisco 7204 and Cisco 7206 series routers are supported by the Cisco network-based IPSec VPN solution Release 1.5 as interfaces.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/core/7202/index.htm .
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/core/7206/index.htm .
You can use any RADIUS server (for example, Cisco Access Registrar) that understands Cisco AV pairs to authenticate and authorize remote access clients. If a 2-factor secure-ID-based authentication is required, an RSA server must be installed on the SP management network for local AAA or on the customer premises for proxy authentication.
The service provider or the customer manages the RADIUS servers.
The service-provider managed RADIUS server:
Customer-managed information is typically per-user information (for example, user authentication information).
|
Note It is important that you (the service provider) must manage IP address assignment for the VPN (using RADIUS or IPSEC Aggregator) because you know the network topology. The customer does not know the topology. |
For more information about RADIUS servers, see http://www.cisco.com/en/US/tech/tk648/tk367/tk547/tech_protocol_home.html .
The Cisco network-based IPSec VPN solution Release 1.5 supports the Cisco Unity VPN client. The client has wide support on various operating systems including:
Table 1-1 lists Cisco platforms can be used as customer premises equipment at remote locations for IPSec termination to the Cisco 7200 series router.
Table 1-1 Customer Premises Components of the Cisco Network-Based IPSec VPN Solution Release 1.5
|
This section briefly describes the new features introduced in the Cisco network-based IPSec VPN solution Release 1.5.
For an overview of scalability and performance, system redundancy, and management, see subsequent sections of this document. For software requirements, refer to the Release Notes for the Cisco Network-Based IPSec VPN Solution Release 1.5.
The IP virtual private network (VPN) feature for multiprotocol label switching (MPLS) allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone services. An IP VPN is the foundation companies use for deploying or administering value-added services including applications and data hosting network commerce, and telephony services to business customers.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm.
The IPSec VPN High Availability feature consists of two new features that work together to simplify network design for VPNs and reduce configuration complexity on remote peers with respect to defining gateway lists:
For more information, see http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/products_feature_guide09186a00800ed370. html.
Reverse Route Injection (RRI) simplifies network design for Virtual Private Network (VPNs) in which there is a requirement for redundancy or load balancing. RRI works with both dynamic and static crypto maps.
RRI allows dynamic installation of client routes in the routing table. This in conjunction with HSRP prevents asymmetrical routing problems.
For more information, see Reverse Route Injection at http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/products_feature_guide09186a00800ed370. html#1024537.
Hot Standby Router Protocol (HSRP) and IPSec provides high network availability by routing IP traffic from hosts on Ethernet networks without relying on the availability of any single router. HSRP is particularly useful for hosts that do not support a router discovery protocol, such as ICMP Router Discovery Protocol (IRDP), and do not have the functionality to switch to a new router when their selected router reloads or loses power. Without this functionality, a router that loses its default gateway because of a router failure is unable to communicate with the network.
You can use HSRP to create a stateless failover mechanism. In case of a failure on the active router, the backup router can then assume IPSec aggregation functions.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e9/ipsecha.htm#29050.
Using the Per VRF AAA feature on the IPSec Aggregator/PE, Internet Service Providers (ISPs) can partition authentication, authorization, and accounting (AAA) services based on Virtual Route Forwarding (VRF). This permits the IPSec Aggregator/PE to communicate directly with the customer RADIUS server associated with the customer VPN, without having to go through a RADIUS proxy. Thus, ISPs can scale their VPN offerings more efficiently because they no longer need to proxy AAA to provide their customers the flexibility demanded.
For more information, see
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftvrfaaa.htm.
The Cisco 7200 Series Network Processing Engine NPE-G1 (NPE-G1) addresses the demand for performance and flexibility by doubling its processing capacity and enabling unprecedented LAN performance.
For more information, see http://www.cisco.com/en/US/products/hw/routers/ps341/products_data_sheet09186a00800c6bd6.html .
The VRF Aware IPSec feature introduces full IP security (IPSec) tunnel mapping to VRF-aware core virtual private networks (VPNs) supporting Multiprotocol Label Switching (MPLS), ATM, and Frame Relay. Using the VRF Aware IPSec feature, you can map IPSec tunnels to VRFs based on IPSec authentication. Hard-configured interface-VRF bindings are not required.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_vrfip.htm .
The IPSec VPN Accounting feature allows for a session to be accounted for by indicating when the session starts and when it stops.
A VPN session is defined as an Internet Key Exchange (IKE) security association (SA) and the one or more SA pairs that are created by the IKE SA. The session
starts when the first IP Security (IPSec) pair is created and stops when all IPSec SAs are deleted.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_evpna.htm #wp1027129.
This feature monitors SAs for activity and then removes idle SAs after some specified period of inactivity.
When a Cisco software-based IOS router creates an IPSec security association (SA) for a peer, it allocates a certain amount of resources to maintain the SA; the SA requires memory and several managed timers. For idle peers, these resources are wasted, and wasted resources could eventually prevent the router from creating new SAs with other peers.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ftsaidle.htm .
The Distinguished Name Based Crypto Maps feature allows you to configure the router to restrict access to selected encrypted interfaces for those peers with specific certificates, especially certificates with particular Distinguished Names (DNs).
Previously, if the router accepted a certificate or a shared secret from the encrypting peer, Cisco IOS software did not have a method of preventing the peer from communicating with any encrypted interface other than the restrictions on the IP address of the encrypting peer. This feature allows you to configure which crypto maps are usable to a peer based on the DN that a peer used to authenticate itself, thereby, enabling you to control which encrypted interfaces a peer with a specified DN can access.
For more information, see http://www.cisco.com/en/US/products/sw/iosswrel/ps1839 /
products_feature_guide09186a0080087b70.html#xtocid225341.
The Cisco Easy VPN Remote feature eliminates tedious work by implementing the Cisco Unity Client protocol, which allows most VPN parameters to be defined at a VPN remote access server. This server can be a dedicated VPN device such as a VPN 3000 concentrator or a Cisco PIX Firewall, or a Cisco IOS router that supports the Cisco Unity Client protocol.
Many applications require the security of VPN connections that perform a high level of authentication and that encrypt the data between two particular endpoints. However, establishing a VPN connection between two routers can be complicated, and typically requires tedious coordination between network administrators to configure the two routers' VPN parameters.
The Cisco Easy VPN Remote feature:
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122y/122ya/122 ya4/ftezvpcm.htm#xtocid0.
The Cisco Easy VPN Remote feature provides enhancements and additional capabilities to Phase I features. In Phase II, the Cisco Easy VPN Remote feature provides:
For more information on these, as well as additional enhancements, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122y/122yj/ftez vp2.htm#xtocid3.
The Easy VPN Server feature introduces server support for the Cisco VPN client Release 3.x software clients and Cisco VPN hardware clients. It allows a remote end user to communicate using IP Security (IPSec) with any Cisco IOS Virtual Private Network (VPN) gateway. Centrally managed IPSec policies are "pushed" to the client by the server, minimizing configuration by the end user.
|
Note This feature also supports hardware VPN clients, such as the Cisco 800 device, Cisco 900 device, Cisco 1700 device, VPN 3002 device, and PIX 501 devices. |
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087d1e.html#xtocid1.
The IPSec NAT Transparency feature lets IPSec peers establish a connection through a NAT device. It does this by encapsulating IPSec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T autodetects any NAT devices, and only encapsulates IPSec traffic when necessary.
For more information, see h ttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftipsnat.htm.
The VPN Acceleration Module (VAM) is a single-width acceleration module. It provides high-performance, hardware-assisted tunneling and encryption services suitable for virtual private network (VPN) remote access, site-to-site intranet, and extranet applications.
The VAM provides hardware-accelerated support for the following multiple encryption functions:
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122y/122ye/122 9ye/12ye_vam.htm.
This feature allows an encrypting router to predetermine the encapsulated packet size from information available in transform sets, which are configured as part of the IPSec security association (SA).
When a packet is nearly the size of the maximum transmission unit (MTU) of the outbound link of the encrypting router, and it is encapsulated with IPSec headers, it is likely to exceed the MTU of the outbound link. This causes packet fragmentation after encryption, which makes the decrypting router reassemble in the process path. Prefragmentation for IPSec VPNs increases the decrypting router's performance by enabling it to operate in the high performance CEF path instead of the process path.
If it is predetermined that the packet will exceed the MTU of the output interface, the packet is fragmented before encryption. This function avoids process level reassembly before decryption and helps improve decryption performance and overall IPSec traffic throughput.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftprefrg.htm .
The Cisco IOS Server Load Balancing (SLB) feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, you can define a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment, the clients connect to the IP address of the virtual server. When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load-balancing algorithm.
For more information, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e9/iossl b9e.htm#2711438.
Cisco IPSec VPN access provider, service provider, and customer CPE, CE, PE, concentrator, access server, aggregation, gateway, and headend hardware components use Cisco IOS software. Cisco IOS software provides the capability to configure Cisco routers and switches using command-line interface (CLI) commands.
Keep in mind the following when configuring your Cisco IOS software:
|
Note Cisco IOS software is feature specific and licensed on an "as is" basis without warranty of any kind, either expressed or implied. The version of Cisco IOS software used in this guide varies depending on configuration requisites for presentation purposes, and should not be construed as the Cisco IOS software version of choice for your system or internetwork environment. Consult your Cisco sales representative regarding your Cisco IOS requirements. |
Cisco routers/servers are configured from user interfaces, known as ports, which provide hardware connectivity. They are accessed from the console port on a router or Telnet into a router interface from another host. Typical interfaces are Serial 0 (S0), Serial 1 (S1), and Ethernet (E0). Token Ring interfaces are referenced as (T0) and FDDI interfaces use (F0).
When you use the CLI, a command interpreter called EXEC is employed by the operating system to translate any command and execute its operation. This command interpreter has two access modes, user and privileged, which provide security to the respective command levels. Each command mode restricts you to a subset of mode-specific commands.
There are many modes of configuration within privileged mode that determine the type of configuration desired, such as interface configuration (AS5800(config-if)#), line configuration (AS5800(config-line)#), and controller configuration (AS5800(config-controller)#). Each configuration command mode restricts you to a subset of mode specific commands.
In the following command sequence, command prompts are automatically modified to reflect command mode changes. A manual carriage return is implied at the end of each line item.
The last message is an example of a system response. Press Enter to get to the AS5800# prompt.
Table 1-2 lists common configuration modes. Configure global parameters in global configuration mode, interface parameters in interface configuration mode, and line parameters in line configuration mode.
Table 1-2 Common Cisco IOS Software Command Modes
Context-sensitive help is available at any command prompt. Enter a question mark (?) for a list of complete command names, semantics, and command mode command syntax. Use arrow keys at command prompts to scroll through previous mode-specific commands for display.
|
Note Cycle through mode specific commands at a mode specific prompt. |
Refer to the chapter "Configuring the User Interface" in the Configuration Fundamentals Configuration Guide for more information about working with the user interface in the Cisco IOS software.
|
Note You can press Ctrl-Z in any mode to immediately return to enable mode (AS5800#), instead of entering exit, which returns you to the previous mode. |
To prevent losing the Cisco AS5800 configuration, save it to NVRAM using the following steps:
AS5800#.
|
Note Press Ctrl-Z to return to privileged EXEC mode. Any subsequent system response message is normal and does not indicate an error. |
Step 2 Execute the copy running-config startup-config command to save configuration changes to nonvolatile random-access memory (NVRAM) so configuration data is not lost during a system reload, power cycle, or outage.
The following prompt appears after a successful configuration copy.
To undo a command or disable a feature, enter the keyword no before the command; for example, no ip routing.
Several passwords are used when configuring your Cisco IOS software. Passwords are used to identify user authorization and permission rights, virtual terminal configuration, and network management software initialization. Most passwords can use the same notation.
You need the following types of passwords when configuring Cisco IOS software:
|
Note The enable password and enable secret password should be different. In both cases, a number cannot be the first character. Spaces are also valid password characters, but only when following valid characters; lead spaces are ignored. |
Posted: Tue Aug 5 09:10:36 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.