The IP Security Protocol, Part 1
IPSec has been designed to meet four different goals:
Privacy to ensure data confidentiality. In other words, it must not be possible for eavesdroppers to sniff your data over the network and read what you are sending. In one of its two working modes, IPSec also allows for traffic flow confidentiality; not only will the eavesdropper be prevented from reading your data, but he will not even know who you are communicating with.
Integrity to guarantee that data has not been tampered with. No one will be able to modify your data as it is flowing by without the legitimate receiver noticing it. An interesting property of IPSec is it provides connectionless integrity, in the sense that protection is applied to each individual IP datagram.
Authenticity to protect against identity spoofing. Attackers will no longer be able to pass themselves off as you by simply forging packets bearing your IP address or carrying data allegedly written by you. Each packet carries a type of "signature" that uniquely identifies you as the sender. This is also important for putting sophisticated access control mechanisms in place.
Robustness to prevent DoS and replay attacks. IPSec detects the arrival of duplicate IP datagrams, thus preventing attackers from recording a legitimate session and playing it back (by sending the packets again to the destination).
Depending on how IPSec is used either data integrity alone or data integrity and confidentiality are guaranteed. This allows for a modular adoption of IPSec's mechanisms. IPSec works with IPv4 as well as with IPv6, in which it is a mandatory component.
IPSec is specified by a set of IETF standard track documents, namely RFCs 2401 to 2411 and 2451, which define an architecture composed of an encryption facility (the IPSec protocol proper) and a key exchange infrastructure (named IKE, for internet key exchange). As we will see in part 2, IKE sets up the trust relationship between two peers.
The IPSec framework does not specify exactly which encryption algorithms must be used by its implementations. Instead, it provides an empty infrastructure where the desired algorithms may be set. This actually is a smart design decision, because it allows the implementations to be modular, customizable for specific problems and easily upgradable with new algorithms. A standard set of default algorithms is specified by the relevant RFCs in order to foster the early adoption of IPSec.
Depending on which devices it is deployed on, the adoption of IPSec takes the form of one of the following typical scenarios:
Host-to-host communication: IPSec is deployed on each host that requires secure communication services. Each host pair negotiates its own IPSec parameters and establishes its own connection. This is typically the case when two private users wish to share a private connection over the Internet.
Gateway-to-gateway communication: IPSec is deployed on network gateways (thus called security gateways), which can be either routers or special firewalls. Each pair of security gateways establishes a secure tunnel over which all the hosts in the LAN send protected packets. This is completely transparent to the hosts, hence it is well suited for connecting distant LANs over the Internet.
Host-to-gateway communication: IPSec is deployed both on a security gateway (as defined above) and on a host (typically, a mobile PC) that remotely connects to it. In this scenario, a remote user (e.g., a teleworker) is able to reach a private LAN (e.g., his office) without requiring a dedicated connection, such as a dial-up link. The IPSec connection between the PC and the gateway ensures that all the packets will be protected. This set up is often referred to as the "road warrior" scenario.
IPSec goals are met by two new mechanisms added to the plain IP protocol: the authentication header (AH) and the encapsulating security payload (ESP). The former guarantees data integrity, whereas the latter provides data confidentiality. Both mechanisms involve adding a new header to the IP packet. This header is placed between the normal IP header and the Layer 4 (TCP or UDP) header. In this way, an IPSec packet is not different from a plain IP packet as far as the network is concerned. Legacy routers will be able to handle IPSec packets without even knowing they are somewhat special. Only the two IPSec peers, either the communicating hosts or the tunnel endpoints, will need to deal with the additional headers. This is an important point, because it deploys only a few IPSec-compliant devices (i.e., routers) and leaves the rest of the Internet as it is.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- March 2015 Issue of Linux Journal: High-Performance Computing
- April 2015 Video Preview
- Users, Permissions and Multitenant Sites
- Not So Dynamic Updates
- Security in Three Ds: Detect, Decide and Deny
- DevOps: Everything You Need to Know
- Flexible Access Control with Squid Proxy
- Non-Linux FOSS: MenuMeters
- Tighten Up SSH
- Android Candy: Bluetooth Auto Connect