This chapter covers the following topics:
Identify VPN technologies
Identify SSL VPNs
Describe why VPNs are used
Describe the uses of a hash algorithm
Describe the uses of encryption algorithms
Describe the security impact of commonly used hash algorithms
Describe the security impact of commonly used encryption algorithms and secure communications protocols
In Chapter 6, “Fundamentals of Cryptography and Public Key Infrastructure (PKI),” you learned the fundamentals of cryptography, public key infrastructure (PKI), encryption and hashing algorithms, and what they apply to. This chapter covers virtual private networks and their related technologies.
The “Do I Know This Already?” quiz helps you identify your strengths and deficiencies in this chapter’s topics. The nine-question quiz, derived from the major sections in the “Foundation Topics” portion of the chapter, helps you determine how to spend your limited study time. You can find the answers in Appendix A Answers to the “Do I Know This Already?” Quizzes and Q&A Questions.
Table 7-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.
Table 7-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
|
Foundation Topics Section |
Questions Covered in This Section |
|
What Are VPNs? |
1–2 |
|
Site-to-site vs. Remote-Access VPNs |
3–4 |
|
An Overview of IPsec |
5–7 |
|
SSL VPNs |
8–9 |
1. Which of the following are examples of protocols used for VPN implementations?
a. TCP
b. Secure Sockets Layer (SSL)
c. UDP
d. Multiprotocol Label Switching (MPLS)
e. Internet Protocol Security (IPsec)
2. Which of the following VPN protocols do not provide data integrity, authentication, and data encryption?
a. L2TP
b. GRE
c. SSL
d. IPsec
e. MPLS
3. VPN implementations are categorized into which of the following two general groups?
a. Encrypted VPNs
b. Non-encrypted VPNs
c. Site-to-site (LAN-to-LAN) VPNs
d. Remote-access VPNs
4. Which of the following is an example of a remote-access VPN client?
a. Cisco Encrypted Tunnel Client
b. Cisco AnyConnect Secure Mobility Client
c. Cisco ASA Client
d. Cisco Firepower Client
5. Which of the following attributes are exchanged in IKEv1 phase 1?
a. Encryption algorithms
b. Hashing algorithms
c. Diffie-Hellman groups
d. Vendor-specific attributes
6. Which of the following hashing algorithms are used in IPsec?
a. AES 192
b. AES 256
c. Secure Hash Algorithm (SHA)
d. Message Digest Algorithm 5 (MD5)
7. In IKEv1 phase 2, each security association (SA) is assigned which of the following?
a. A unique security parameter index (SPI) value
b. An IP address
c. The DNS server IP address
d. A public key
8. Which of the following statements is true about clientless SSL VPN?
a. The client must use a digital certificate to authenticate.
b. The remote client needs only an SSL-enabled web browser to access resources on the private network of the security appliances.
c. Clientless SSL VPNs do not provide the same level of encryption as client-based SSL VPNs.
d. Clientless SSL VPN sessions expire every hour.
9. Which of the following are some of the commonly used SSL VPN technologies?
a. Tor browser
b. Reverse proxy technology
c. Port-forwarding technology and smart tunnels
d. SSL VPN tunnel client (such as the AnyConnect Secure Mobility Client)
Individuals and organizations deploy VPNs to provide data integrity, authentication, and data encryption to ensure confidentiality of the packets sent over an unprotected network or the Internet. VPNs are designed to avoid the cost of unnecessary leased lines. Individuals also use VPNs to remain anonymous online. Even threat actors use VPN technologies to encrypt data from compromised sites, command and control communications, and to maintain anonymity for the purposes of malfeasance in underground sites and darknet marketplaces.
Many different protocols are used for VPN implementations, including the following:
Point-to-Point Tunneling Protocol (PPTP)
Layer 2 Forwarding (L2F) protocol
Layer 2 Tunneling Protocol (L2TP)
Generic Routing Encapsulation (GRE)
Multiprotocol Label Switching (MPLS)
Internet Protocol Security (IPsec)
Secure Sockets Layer (SSL)
NOTE
L2F, L2TP, GRE, and MPLS VPNs do not provide data integrity, authentication, and data encryption. On the other hand, you can combine L2TP, GRE, and MPLS with IPsec to provide these benefits. Many organizations use IPsec or SSL VPNs as their preferred protocols because they support all three of these features.
Enterprises use VPNs to allow users and other networks to connect to network resources in a secure manner. On the other hand, individuals also use VPN services to maintain confidentiality when browsing the Internet and in combination with The Onion Router (Tor) to maintain anonymity. Tor was initially a worldwide network of servers developed with the United States Navy. It enables people to browse the Internet anonymously. Nowadays, Tor is maintained by a nonprofit organization dedicated to the development of online privacy tools. The Tor network masks your identity by “routing” your traffic across different Tor servers and then encrypting that traffic so it isn’t traced back to you. It is important to know that Tor is not really a VPN.
Typically, VPN implementations are categorized into two general groups:
Site-to-site VPNs: Enable organizations to establish VPN tunnels between two or more network infrastructure devices in different sites so that they can communicate over a shared medium such as the Internet. Many organizations use IPsec, GRE, and MPLS VPNs as site-to-site VPN protocols.
Remote-access VPNs: Enable users to work from remote locations such as their homes, hotels, and other premises as if they were directly connected to their corporate network.
In most cases, site-to-site VPN tunnels are terminated between two or more network infrastructure devices, whereas remote-access VPN tunnels are formed between a VPN head-end device and an end-user workstation or hardware VPN client.
Figure 7-1 illustrates a site-to-site IPsec tunnel between two sites: a site in New York (corporate headquarters) and a branch office in Raleigh, North Carolina.
In Figure 7-1 a Cisco IOS router (R1) terminates an IPsec tunnel from the Cisco ASA firewall in the Raleigh office. Figure 7-2 shows an example of a remote-access VPN.
Two clients are connecting to the Cisco ASA in the Raleigh office in Figure 7-2. Client 1 is connecting using an SSL VPN, and client 2 is connecting using IPsec.
There are two main categories of remote-access VPNs:
Clientless: The user connects without a client, typically using a web browser. The major benefit of clientless SSL VPNs is that you do not need a client to be installed on your PC. One of the disadvantages is that only TCP-based applications are supported. Clientless SSL VPNs are typically used in kiosks, shared workstations, mobile devices, and when users just want to encrypt web traffic.
Client based: The user connects to the VPN terminating device (router, firewall, and so on) using a client. An example of a VPN client is the Cisco AnyConnect Secure Mobility Client.
IPsec uses the Internet Key Exchange (IKE) protocol to negotiate and establish secured site-to-site or remote-access VPN tunnels. IKE is a framework provided by the Internet Security Association and Key Management Protocol (ISAKMP) and parts of two other key management protocols—namely, Oakley and Secure Key Exchange Mechanism (SKEME).
IKE is defined in RFC 2409, “The Internet Key Exchange (IKE).” IKE version 2 (IKEv2) is defined in RFC 5996, “Internet Key Exchange Protocol Version 2 (IKEv2).”
IKE has two phases. Phase 1 is used to create a secure bidirectional communication channel between the IPsec peers. This channel is known as the ISAKMP security association (SA). Phase 2 is used to negotiate the IPsec SAs.
Within Phase 1 negotiation, several attributes are exchanged:
Encryption algorithms
Hashing algorithms
Diffie-Hellman groups
Authentication method
Vendor-specific attributes
In Chapter 6, you learned the fundamentals of cryptography and the different encryption algorithms. The following are the typical encryption algorithms used in IPsec:
Data Encryption Standard (DES): 64 bits long
Triple DES (3DES): 168 bits long
Advanced Encryption Standard (AES): 128 bits long
AES 192: 192 bits long
AES 256: 256 bits long
The hashing algorithms used in IPsec include the following:
Secure Hash Algorithm (SHA)
Message Digest Algorithm 5 (MD5)
The common authentication methods are preshared keys (where peers use a shared secret to authenticate each other) and digital certificates with the use of Public Key Infrastructure (PKI).
Small- and medium-sized organizations use preshared keys as their authentication mechanism. Many large organizations use digital certificates for scalability, centralized management, and additional security mechanisms.
You can establish a Phase 1 SA in main mode or aggressive mode. In main mode, the IPsec peers complete a six-packet exchange in three round trips to negotiate the ISAKMP SA, whereas aggressive mode completes the SA negotiation in three packet exchanges. Main mode provides identity protection if preshared keys are used. Aggressive mode offers identity protection only if digital certificates are employed.
NOTE
Cisco products that support IPsec typically use main mode for site-to-site tunnels and use aggressive mode for remote-access VPN tunnels. This is the default behavior when preshared keys are employed as the authentication method.
Figure 7-3 illustrates the six-packet exchange in main mode negotiation.
In Figure 7-3, two Cisco ASAs are configured to terminate a site-to-site VPN tunnel between them. The Cisco ASA labeled as ASA-1 is the initiator, and ASA-2 is the responder. The following steps are illustrated in Figure 7-3:
1. ASA-1 (the initiator) has two ISAKMP proposals configured. In the first packet, ASA-1 sends its configured proposals to ASA-2.
2. ASA-2 evaluates the received proposal. Because it has a proposal that matches the offer of the initiator, ASA-2 sends the accepted proposal back to ASA-1 in the second packet.
3. The Diffie-Hellman exchange and calculation process is started. Diffie-Hellman is a key agreement protocol that enables two users or devices to authenticate each other’s preshared keys without actually sending the keys over the unsecured medium. ASA-1 sends the Key Exchange (KE) payload and a randomly generated value called a nonce.
4. ASA-2 receives the information and reverses the equation, using the proposed Diffie-Hellman group/exchange to generate the SKEYID. The SKEYID is a string derived from secret material that is known only to the active participants in the exchange.
5. ASA-1 sends its identity information. The fifth packet is encrypted with the keying material derived from the SKEYID. The asterisk in Figure 7-3 is used to illustrate that this packet is encrypted.
6. ASA-2 validates the identity of ASA-1, and ASA-2 sends its own identity information to ASA-1. This packet is also encrypted.
IKE uses UDP port 500 for communication. UDP port 500 is employed to send all the packets described in the previous steps.
Phase 2 is used to negotiate the IPsec SAs. This phase is also known as quick mode. The ISAKMP SA protects the IPsec SAs because all payloads are encrypted except the ISAKMP header.
A single IPsec SA negotiation always creates two security associations—one inbound and one outbound. Each SA is assigned a unique security parameter index (SPI) value—one by the initiator and the other by the responder.
The security protocols (AH and ESP) are Layer 3 protocols and do not have Layer 4 port information, unlike TCP and UDP. If an IPsec peer is behind a PAT device, the ESP or AH packets are typically dropped. To work around this, many vendors, including Cisco Systems, use a feature called IPsec pass-through. The PAT device that is IPsec pass-through capable builds the translation table by looking at the SPI values on the packets.
Many industry vendors, including Cisco Systems, implement another feature called NAT Traversal (NAT-T). With NAT-T, the VPN peers dynamically discover whether an address translation device exists between them. If they detect a NAT/PAT device, they use UDP port 4500 to encapsulate the data packets, subsequently allowing the NAT device to successfully translate and forward the packets.
Another interesting point is that if the VPN router needs to connect multiple networks over the tunnel, it must negotiate twice as many IPsec SAs. Remember, each IPsec SA is unidirectional, so if three local subnets need to go over the VPN tunnel to talk to the remote network, then six IPsec SAs are negotiated. IPsec can use quick mode to negotiate these multiple Phase 2 SAs, using the single pre-established ISAKMP (IKEv1 Phase 1) SA. The number of IPsec SAs can be reduced, however, if source and/or destination networks are summarized.
Many different IPsec attributes are negotiated in quick mode, as shown in Table 7-2.
|
Attribute |
Possible Values |
|
Encryption |
None, DES, 3DES, AES128, AES192, AES256 |
|
Hashing |
MD5, SHA, null |
|
Identity information |
Network, protocol, port number |
|
Lifetime |
120–2,147,483,647 seconds 10–2,147,483,647 kilobytes |
|
Mode |
Tunnel or transport |
|
Perfect Forward Secrecy (PFS) group |
None, 1, 2, or 5 |
In addition to generating the keying material, quick mode also negotiates identity information. The Phase 2 identity information specifies which network, protocol, and/or port number to encrypt. Hence, the identities can vary anywhere from an entire network to a single host address, allowing a specific protocol and port.
Figure 7-4 illustrates the Phase 2 negotiation between the two routers that just completed Phase 1.
The following steps are illustrated in Figure 7-4.
1. ASA-1 sends the identity information, IPsec SA proposal, nonce payload, and (optionally) the Key Exchange (KE) payload if Perfect Forward Secrecy (PFS) is used. PFS is used to provide additional Diffie-Hellman calculations.
2. ASA-2 evaluates the received proposal against its configured proposal and sends the accepted proposal back to ASA-1, along with its identity information, nonce payload, and the optional KE payload.
3. ASA-1 evaluates the ASA-2 proposal and sends a confirmation that the IPsec SAs have been successfully negotiated. This starts the data encryption process.
IPsec uses two different protocols to encapsulate the data over a VPN tunnel:
Encapsulation Security Payload (ESP): IP Protocol 50
Authentication Header (AH): IP Protocol 51
ESP is defined in RFC 4303, “IP Encapsulating Security Payload (ESP),” and AH is defined in RFC 4302, “IP Authentication Header.”
IPsec can use two modes with either AH or ESP:
Transport mode: Protects upper-layer protocols, such as User Datagram Protocol (UDP) and TCP
Tunnel mode: Protects the entire IP packet
Transport mode is used to encrypt and authenticate the data packets between the peers. A typical example is the use of GRE over an IPsec tunnel. Tunnel mode is employed to encrypt and authenticate the IP packets when they are originated by the hosts connected behind the VPN device. Tunnel mode adds an additional IP header to the packet, as illustrated in Figure 7-5.
Figure 7-5 demonstrates the major difference between transport mode and tunnel mode. It includes an example of an IP packet encapsulated in GRE and the difference when it is encrypted in transport mode versus tunnel mode. As demonstrated in Figure 7-5, tunnel mode increases the overall size of the packet in comparison to transport mode.
TIP
Tunnel mode is the default mode in Cisco IPsec devices.
IKE version 2 (IKEv2) is defined in RFC 5996 and enhances the function of performing dynamic key exchange and peer authentication. IKEv2 simplifies the key exchange flows and introduces measures to fix vulnerabilities present in IKEv1. Both IKEv1 and IKEv2 protocols operate in two phases. IKEv2 provides a simpler and more efficient exchange.
Phase 1 in IKEv2 is IKE_SA, consisting of the message pair IKE_SA_INIT. IKE_SA is comparable to IKEv1 Phase 1. The attributes of the IKE_SA phase are defined in the Key Exchange Policy. Phase 2 in IKEv2 is CHILD_SA. The first CHILD_SA is the IKE_AUTH message pair. This phase is comparable to IKEv1 Phase 2. Additional CHILD_SA message pairs can be sent for rekey and informational messages. The CHILD_SA attributes are defined in the Data Policy.
The following differences exist between IKEv1 and IKEv2:
IKEv1 Phase 1 has two possible exchanges: main mode and aggressive mode. There is a single exchange of a message pair for IKEv2 IKE_SA.
IKEv2 has a simple exchange of two message pairs for the CHILD_SA. IKEv1 uses an exchange of at least three message pairs for Phase 2.
SSL-based VPNs leverage the SSL protocol. SSL, also referred to as Transport Layer Security (TLS), is a mature protocol that has been in existence since the early 1990s. The Internet Engineering Task Force (IETF) created TLS to consolidate the different SSL vendor versions into a common and open standard.
One of the most popular features of SSL VPN is the capability to launch a browser such as Google Chrome, Microsoft Internet Explorer, or Firefox and simply connect to the address of the VPN device, as opposed to running a separate VPN client program to establish an IPsec VPN connection. In most implementations, a clientless solution is possible. Users can access corporate intranet sites, portals, and email from almost anywhere. Even airport kiosks can establish clientless SSL VPN tunnels to access required resources. Because most people allow SSL (TCP port 443) over their firewalls, it is unnecessary to open additional ports.
The most successful application running on top of SSL is HTTP, because of the huge popularity of the World Wide Web. All the most popular web browsers in use today support HTTP over SSL/TLS (HTTPS). This ubiquity, if used in remote-access VPNs, provides some appealing properties:
Secure communication using cryptographic algorithms: HTTPS/TLS offers confidentiality, integrity, and authentication.
Ubiquity: The ubiquity of SSL/TLS makes it possible for VPN users to remotely access corporate resources from anywhere, using any PC, without having to preinstall a remote-access VPN client.
Low management cost: The clientless access makes this type of remote-access VPN free of deployment costs and free of maintenance problems at the end-user side. This is a huge benefit for the IT management personnel, who would otherwise spend considerable resources to deploy and maintain their remote-access VPN solutions.
Effective operation with a firewall and NAT: SSL VPN operates on the same port as HTTPS (TCP/443). Most Internet firewalls, proxy servers, and NAT devices have been configured to correctly handle TCP/443 traffic. Consequently, there is no need for any special consideration to transport SSL VPN traffic over the networks. This has been viewed as a significant advantage over native IPsec VPN, which operates over IP protocol 50 (ESP) or 51 (AH), which in many cases needs special configuration on the firewall or NAT devices to let traffic pass through.
As SSL VPN evolves to fulfill another important requirement of remote-access VPNs (namely, the requirement of supporting any application), some of these properties are no longer applicable, depending on which SSL VPN technology the VPN users choose. But overall, these properties are the main drivers for the popularity of SSL VPNs in recent years and are heavily marketed by SSL VPN vendors as the main reasons for IPsec replacement.
Today’s SSL VPN technology uses SSL/TLS for secure transport and employs a heterogeneous collection of remote-access technologies such as reverse proxy, tunneling, and terminal services to provide users with different types of access methods that fit different environments. Subsequent chapters examine some commonly used SSL VPN technologies, such as the following:
Reverse proxy technology
Port-forwarding technology and smart tunnels
SSL VPN tunnel client (AnyConnect Secure Mobility Client)
Integrated terminal services
HTTPS provides secure web communication between a browser and a web server that supports the HTTPS protocol. SSL VPN extends this model to allow VPN users to access corporate internal web applications and other corporate application servers that might or might not support HTTPS, or even HTTP. SSL VPN does this by using several techniques that are collectively called reverse proxy technology.
A reverse proxy is a proxy server that resides in front of the application servers (normally web servers) and functions as an entry point for Internet users who want to access the corporate internal web application resources. To the external clients, a reverse proxy server appears to be the true web server. Upon receiving the user’s web request, a reverse proxy relays the user request to the internal web server to fetch the content on behalf of the user and then relays the web content to the user with or without presenting additional modifications to the data.
Many web server implementations support reverse proxy. One example is the mod_proxy module in Apache. With so many implementations, you might wonder why you need an SSL VPN solution to have this functionality. The answer is that SSL VPN offers much more functionality than traditional reverse proxy technologies:
SSL VPN can transform complicated web and some non-web applications that simple reverse proxy servers cannot handle. The content transformation process is sometimes called webification. For example, SSL VPN solutions enable users to access Windows or UNIX file systems. The SSL VPN gateway must be able to communicate with internal Windows or UNIX servers and “webify” the file access in a web browser–presentable format for the VPN users.
SSL VPN supports a wide range of business applications. For applications that cannot be webified, SSL VPN can use other resource access methods to support them. For users who demand ultimate access, SSL VPN provides network-layer access to directly connect a remote system to the corporate network, in the same manner as an IPsec VPN.
SSL VPN provides a true remote-access VPN package, including user authentication, resource access privilege management, logging and accounting, endpoint security, and user experience.
The reverse proxy mode in SSL VPN is also known as clientless web access or just clientless access because it does not require any client-side applications to be installed on the client machine. Client-based SSL VPN provides a solution where you can connect to the corporate network by just pointing your web browser to the Cisco ASA without the need of additional software being installed on your system.
The SSL VPN implementation on Cisco ASAs provides the most robust feature set in the industry. In the current software release, Cisco ASA supports all three flavors of SSL VPN:
Clientless: In the clientless mode, the remote client needs only an SSL-enabled browser to access resources on the private network of the security appliances. SSL clients can access internal resources such as HTTP, HTTPS, and even Windows file shares over the SSL tunnel.
Thin client: In the thin client mode, the remote client needs to install a small Java-based applet to establish a secure connection to the TCP-based internal resources. SSL clients can access internal resources such as HTTP, HTTPS, SSH, and Telnet servers.
Full Tunnel: In the full tunnel client mode, the remote client needs to install an SSL VPN client first that can give full access to the internal private over an SSL tunnel. Using the full tunnel client mode, remote machines can send all IP unicast traffic such as TCP-, UDP-, or even ICMP-based traffic. SSL clients can access internal resources such as HTTP, HTTPS, DNS, SSH, and Telnet servers.
In many recent Cisco documents, clientless and thin client solutions are grouped under one umbrella and classified as clientless SSL VPN.
Before you implement the SSL VPN services in Cisco ASA, you must analyze your current environment and determine which features and modes might be useful in your implementation. You have the option to install a Cisco IPSec VPN client or a Cisco AnyConnect VPN client, or you can go with the clientless SSL VPN functionality. Table 7-3 lists the major differences between the Cisco VPN client solution and the clientless SSL VPN solution. Clientless SSL VPN is an obvious choice for someone who wants to check email from a hotel or an Internet cafe without having to install and configure a Cisco VPN client.
Table 7-3 Contrasting Cisco VPN Client and SSL VPN
|
Feature |
Cisco VPN Client |
Clientless SSL VPN |
|
VPN client |
Uses Cisco VPN client software for complete network access. |
Uses a standard web browser to access limited corporate network resources. Eliminates the need for separate client software. |
|
Management |
You must install and configure Cisco VPN client. |
You do not need to install a VPN client. No configuration is required on the client machine. |
|
Encryption |
Uses a variety of encryption and hashing algorithms. |
Uses SSL encryption native to web browsers. |
|
Connectivity |
Establishes a seamless connection to the network. |
Supports application connectivity through a browser portal. |
|
Applications |
Encapsulates all IP protocols, including TCP, UDP, and ICMP. |
Supports limited TCP-based client/server applications. |
Before designing and implementing the SSL VPN solution for your corporate network, you need to determine whether your users will connect to your corporate network from public shared computers, such as workstations made available to guests in a hotel or computers in an Internet kiosk. In this case, using a clientless SSL VPN is the preferred solution to access the protected resources.
The features supported in a VPN device need to be taken into consideration when designing your VPN deployment. For instance, Cisco security appliances can run various features, such as IPsec VPN tunnels, routing engines, firewalls, and data inspection engines. Enabling the SSL VPN feature can add further load if your existing appliance is already running a number of features. You must check the CPU, memory, and buffer utilization before enabling SSL VPN.
Because SSL VPN provides network access to remote users, you have to consider the placement of the VPN termination devices. Before implementing the SSL VPN feature, ask the following questions:
Should the Cisco ASA be placed behind another firewall? If so, what ports should be opened in that firewall?
Should the decrypted traffic be passed through another set of firewalls? If so, what ports should be allowed in those firewalls?
Network security administrators need to determine the size of the SSL VPN deployment, especially the number of concurrent users that will connect to gain network access. If one Cisco ASA is not enough to support the required number of users, the use of Cisco ASA VPN load balancing must be considered to accommodate all the potential remote users.
The SSL VPN functionality on the ASAs requires that you have appropriate licenses. For example, if your environment is going to have 75 SSL VPN users, you can buy the SSL VPN license that can accommodate up to 100 potential users. The infrastructure requirements for SSL VPNs include, but are not limited to, the following options:
ASA placement: If you are installing a new security appliance, determine the location that best fits your requirements. If you plan to place it behind an existing corporate firewall, make sure you allow appropriate SSL VPN ports to pass through the firewall.
User account: Before SSL VPN tunnels are established, users must authenticate themselves to either the local database or to an external authentication server. The supported external servers include RADIUS (including Password Expiry using MSCHAPv2 to NT LAN Manager), RADIUS one-time password (OTP), RSA SecurID, Active Directory/Kerberos, and Generic Lightweight Directory Access Protocol (LDAP). Make sure that SSL VPN users have accounts and appropriate access. LDAP password expiration is available for Microsoft and Sun LDAP.
Administrative privileges: Administrative privileges on the local workstation are required for all connections with port forwarding if you want to use host mapping.
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 7-4 lists these key topics and the page numbers on which each is found.
|
Key Topic Element |
Description |
Page |
|
List |
Describe clientless and client-based SSL VPNs |
341 |
|
List |
Compare remote access VPNs and site-to-site VPNs |
341 |
|
List |
Describe the phases of IPSec |
343 |
|
List |
Define and identify hashing algorithms used in VPNs |
343 |
|
Table 7-2 |
Identify the different IPsec attributes |
346 |
|
List |
Compare IKEv1 and IKEv2 |
348 |
|
List |
Identify SSL VPN technologies |
349 |
Print a copy of Appendix B, “Memory Tables,” (found on the book website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the website, includes completed tables and lists to check your work.
Define the following key terms from this chapter, and check your answers in the glossary:
IKE
Diffie-Hellman
IKEv1 vs. IKEv2
The answers to these questions appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Questions.” For more practice with exam format questions, use the exam engine on the website.
1. Why can’t ESP packets be transferred by NAT devices?
a. Because ESP packets are too big to handle.
b. Because the ESP protocol does not have any ports like TCP or UDP.
c. Because ESP packets are encrypted.
d. ESP is supported in NAT devices.
2. What is the difference between IPsec tunnel and transport mode?
a. Tunnel mode uses encryption and transport mode uses TCP as the transport protocol.
b. Tunnel mode uses encryption and transport mode uses UDP as the transport protocol.
c. Transport mode protects upper-layer protocols, such as UDP and TCP, and tunnel mode protects the entire IP packet.
d. Tunnel mode protects upper-layer protocols, such as UDP and TCP, and transport mode protects the entire IP packet.
3. Which of the following is true about Diffie-Hellman?
a. Diffie-Hellman is a key agreement protocol that enables two users or devices to authenticate each other’s preshared keys without actually sending the keys over the unsecured medium.
b. Diffie-Hellman is an encapsulation protocol that enables two users or devices to send data to each other.
c. Diffie-Hellman is a part of the RSA encryption suite.
d. Diffie-Hellman has three phases, and the second and third are used to encrypt data.
4. Which of the following is not true about SSL VPNs?
a. SSL VPNs are used in Cisco IOS routers as a site-to-site VPN solution.
b. SSL VPNs are used in Cisco IOS routers as a remote access VPN solution.
c. SSL VPNs are used in Cisco ASA firewalls as a remote access VPN solution.
d. SSL VPNs can be client based or clientless.
5. Which of the following is not true about IKEv2?
a. IKEv1 Phase 1 has two possible exchanges: main mode and aggressive mode. There is a single exchange of a message pair for IKEv2 IKE_SA.
b. IKEv2 has a simple exchange of two message pairs for the CHILD_SA. IKEv1 uses an exchange of at least three message pairs for Phase 2.
c. IKEv1 has a simple exchange of two message pairs for the CHILD_SA. IKEv2 uses an exchange of at least three message pairs for Phase 2.
d. IKEv2 is used in VPN technologies such as FlexVPN.
6. Which of the following encryption protocols is the most secure?
a. DES
b. 3DES
c. 4DES
d. AES
7. Which of the following is not an SSL VPN technology or feature?
a. Reverse proxy features
b. Port-forwarding technology and smart tunnels
c. NAT Traversal
d. SSL VPN tunnel client (AnyConnect Secure Mobility Client)
8. Which browser is used by individuals to maintain anonymity on the Internet and to surf the dark web?
a. OnionBrowser
b. Tor
c. Chrome
d. Firefox
9. Which of the following are reasons why an attacker might use VPN technology?
a. Attackers cannot use VPN technologies without being detected.
b. To exfiltrate data.
c. To encrypt traffic between a compromised host and a command and control system.
d. To evade detection.
10. Which of the following are hashing algorithms?
a. RSA
b. MD5
c. AES
d. SHA
