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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?



42 min 5 sec ago
2 hours 35 min ago
9 hours 29 min ago
9 hours 45 min ago
11 hours 37 min ago
17 hours 28 min ago
22 hours 25 sec ago
22 hours 1 min ago
1 day 1 min ago
1 day 8 hours ago