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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- Huge Package Overhaul for Debian and Ubuntu
- KDE Reveals Plasma Mobile
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python