This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
IPsec is best thought of as a set of features that protects IP data as it travels from one location to another. The locations involved in the VPN typically define the type of VPN. A location could be an end client (such as a PC), a small remote office, a large branch office, a corporate headquarters, a data center, or even a service provider. The combination of any two of these locations determines the type of VPN in use. For example, a small remote office connecting to a corporate headquarters would be a site-to-site VPN.
It is important to remember that IPsec can protect only the IP layer and up (transport layer and user data). IPsec cannot extend its services to the data link layer. If protection of the data link layer is needed, then some form of link encryption is needed. Such encryption is typically performed within a trusted infrastructure, where the security of the link can be assured. Such encryption is not feasible in the Internet because intermediate links are not controlled by the end users.
Often, the use of encryption is assumed to be a requirement of IPsec. In reality, encryption, or dataconfidentiality, is an optional (although heavily implemented) feature of IPsec. IPsec consists ofthe following features,
Data confidentiality involves keeping the data within the IPsec VPN private between the participants of the VPN. As noted earlier, most VPNs are used across the public Internet. As such, it is possible for data to be intercepted and examined. In reality, any data in transit is subject to examination, so the Internet should not be viewed as the only insecure media.
Data confidentiality involves the use of encryption to scramble the data in transit. Encrypted packets cannot be easily, if ever, understood by anyone other than the intended recipient. The use of encryption involves the selection of an encryption algorithm and a means of distributing encryption keys to those involved. IPsec encryption algorithms are covered later in this chapter. Data confidentiality, or encryption, is not required for IPsec VPNs. More often than not, packets are encrypted as they pass through the VPN. But data confidentiality is an optional feature for IPsec.
Data integrity is a guarantee that the data was not modified or altered during transit through the IPsec VPN. Data integrity itself does not provide data confidentiality. Data integrity typically uses a hash algorithm to check if data within the packet was modified between endpoints. Packets that are determined to have been changed are not accepted.
Data origin authentication validates the source of the IPsec VPN. This feature is performed by each end of the VPN to ensure that the other end is exactly who you want to be connected to. Note that the use of the data origin authentication feature is dependent upon the data integrity service. Data origin authentication cannot exist on its own.
Anti-replay ensures that no packets are duplicated within the VPN. This is accomplished through the use of sequence numbers in the packets and a sliding window on the receiver. The sequence number is compared to the sliding window and helps detect packets that are late. Such late packets are considered duplicates, and are dropped. Like data confidentiality, anti-replay is considered an optional IPsec feature.
The features, or services, of IPsec are implemented by a series of standards-based protocols. It is important that the implementation of IPsec is based on open standards to ensure interoperability between vendors. The IPsec protocols do not specify any particular authentication, encryption algorithms, key generation techniques, or security association (SA) mechanisms. The three main protocols that are used by IPsec are as follows:
- Internet Key Exchange (IKE)
- Encapsulating Security Payload (ESP)
- Authentication Header (AH)
Site-to-Site VPN Overview
Even before the remarkable growth of the Internet, corporations had deployed remote offices, disbursed data centers, and establish global operations. Before the Internet was embraced as a trusted conduit to fulfill such corporate communications requirements, however, carriers were called upon to provide local, regional, national, and international conduits between locations. The following figure shows two corporate sites connected "the old way."
Before the Internet became the ubiquitous means of global connectivity that it is today, various carriers created enormous networks and provided connectivity services for a fee. Corporations often tried to use a single carrier to provide connections between the various remote offices. This is depicted in the above figure. However, the use of a single carrier was often not possible due to the location of remote offices outside the carrier presence.
The circuit-based connections provided by the carriers can be thought of as the first site-to-site VPNs. They were indeed private connections between endpoints. Whether they were "nailed-up" permanent virtual circuits (PVC) or "create as needed" switched virtual circuits (SVC), the carriers ensured that the data was delivered as promised between the sites. PVCs tended to offer fixed-sized pipes across the carrier's network, while SVCs had fixed minimum data rates with burst capabilities.
When the Internet grew beyond its academic beginnings, corporations started to experiment with using it to transport data. Soon, the same carriers who offered VC services became Internet service providers (ISP) and offered Internet connectivity. The difference was that instead of providing end-to-end connections, they simply provided accessââ‚¬"access to the entire Internet. It is difficult to provide throughput guarantees across the Internet due to its open and shared nature.
The need to create private, secure communications channels between sites saw the rise of site-to-site IPSec VPNs. The following figure shows such a connection.
The networks depicted in both Figures are similar, and for a reason. The corporate sites shown have not changed all that much from the days of the carriers. Back then, a remote site had connectivity only back to the main campus or to some other central location. In today's networks, a remote site can use its generic Internet connectivity to get anywhere in the Internet (as depicted by the arrows to the great beyond) and use its IPsec VPN to securely communicate with the main campus.
Creating a Site-to-Site IPsec VPN
There are five generic steps in the lifecycle of any IPsec VPN. The steps described here are applied specifically to site-to-site VPNs, but these steps are true whenever any two endpoints wish to establish an IPsec VPN between them. The five steps in the life of an IPsec VPN are as follows:
- Step 1: Specify Interesting Traffic
- Step 2: IKE Phase 1
- Step 3: IKE Phase 2
- Negotiation of IPsec security parameters via IPsec transforms sets
- Establishment of IPsec SAs (unidirectional IPsec tunnels)
- Periodic renegotiation of IPsec SAs to ensure security
- An additional Diffie-Hellman exchange (optional)
- Step 4: Secure Data Transfer
- Step 5: IPsec Tunnel Termination
This concept of interesting traffic also implies that packets that are not interesting do not enjoy the benefits of the IPsec VPN. They are not encrypted or protected in any way. They may travel to any destination, including the remote destination where the VPN tunnel terminates.
Once the first packet deemed interesting arrives, the process of creating the site-to-site IPsec VPN tunnel commences. IKE exchanges the security parameters and symmetric encryption keys used to create the IPsec tunnels that the data will eventually flow in. IKE phase 1 creates a very secure communications channel (its own SAs) so that the IPsec tunnels (SAs) can be created for data encryption and transport
The following functions are performed in IKE phase 2:
After the IPsec transform sets have been agreed upon by the two endpoints and the SAD and SPD have been updated at each end (which implies that the SAs have been built), traffic can flow through the IPsec tunnel. Only the interesting traffic that caused the tunnel to be created is permitted to use the tunnel. All other traffic continues to flow through the interface, but not through the IPsec VPN tunnel.
There are two events that can cause an IPsec tunnel to be terminated. If the SA lifetime expires (time and/or byte count), then the tunnel must be torn down. However, if secure transfer is still needed between the two endpoints, then a new pair of SAs is normally created before the old the old set is retired. It is also possible to manually delete an IPsec tunnel.
Sources of Failures
The network has a number of possible points vulnerable to failure. Remember that an IPsec VPN is an end-to-end connection. It typically travels across untrusted networks (such as the Internet), and through many different network devices. The loss of any one of these components can cause the IPsec VPN to fail. Such potential failure points include
- Access link failure
- Remote peer failure
- Device failure
- Path failure
An access link failure could include the failure of a physical interface on any transit network device (although the access link is typically seen at your end of the IPsec VPN), a module that contains many interfaces, or the "cable" (electrical, optical, or wireless) that provides transport.
Failure of the remote peer is typically attributed to "the other guy." Unless you have some network management reachability into the remote site, it is difficult to determine what the exact cause of the failure is.
A device failure is typically a failure of any device between, and including, the source and destination of the IPsec VPN. In many cases, these devices are beyond your administrative control, and the reason for failure cannot be determined.
A path failure could be a routing or circuit issue in a network between the two IPsec VPN endpoints. The failure is typically outside of your administrative reach, and cannot be easily determined.
The IPsec VPN design must consider all facets of potential network failure and implement redundancy accordingly to ensure that the secure traffic continues to flow from one site to another.
Each of the failure sources mentioned earlier can be mitigated by employing one or more redundancy mechanisms. It is important to remember that the greater the level of high availability in the network, the greater the implementation cost. The primary failure points and some preventive solutions are as follows:
- Access link failure: To overcome the loss of an access link, multiple interfaces and devices can be used. A single IPsec VPN endpoint could have multiple interfaces, multiple interface cards, or multiple endpoint devices.
- Remote peer failure: Failure of the remote peer is mitigated in a similar manner to the way in which access link failure is mitigated. Multiple interfaces and devices can be used to survive a failure. Such duplication allows multiple IPsec VPN tunnels to securely connect the two sites, and each uses a different infrastructure.
- Device failure: Device failure comes in many flavors. As described for both the access link and remote peer, duplicate interfaces and devices can help overcome a local failure. However, a device failure outside of your administrative control is a challenge to correct. So rather than fix someone else's equipment, simply avoid it. Ensure that you have multiple diverse paths between endpoints in case a problem arises in the untrusted network.
- Path failure: A path failure is typically beyond your control. Path redundancy can be used to circumvent a path failure in an untrusted network.
It is important to consider what is truly required to achieve path redundancy. Any single point of failure should be removed from the path. Within your network, this would mean duplicate equipment and wiring. It would also imply separate and diverse paths into and out of the building. Many costly redundancy plans have been knocked out with a single swipe of a backhoe cutting the single physical path into the building.
The use of different ISPs ensures that the traffic starts in different pieces of the Internet. But it is difficult to ensure that a common circuit (from an upstream ISP) is not used "somewhere" between the source and destination points.