The IP Security Protocol, Part 2
Up to now, we have been talking about IPSec relationships between two communicating peers, taking for granted the existence of some kind of trusted liaison between them. In IPSec jargon, this relationship is called a security association (SA). For each IPSec instance (i.e., each peer it is communicating with), a host or gateway keeps an SA that collects all the information related to the instance itself. For example, it may contain the following:
IPSec mode (either tunnel or transport)
negotiated encryption algorithms
SA granularity (which depends on the selector, described below)
An SA is uniquely identified by three parameters:
SPI (Security Parameter Index)
destination IP address
security protocol (either AH or ESP)
The SA represents a monodirectional, secure logical channel working with a single security protocol. If a bidirectional data exchange is required (normally it is), two SAs are needed. Also, if both AH and ESP are required for communication, two SAs for each direction are needed.
For each network interface enabled to "talk" IPSec, two databases are maintained: the SA database (SAD) and the security policy database (SPD). When a packet is being sent, the IPSec layer looks for its destination address in the SAD. If an entry is found, the relevant information is extracted and used to properly protect and encapsulate the packet.
On the receiving side, the arrival of a packet triggers a search by the SPD, which identifies the policies that should be applied to the packet. The key used for the look up in the SPD is called the packet selector. In IPSec terminology, this is information extracted from the packet (e.g., IP source and destination addresses, TCP or UDP ports and so on) sufficient to define the packet flow belonging to the SA. Depending on whether the selector is fine- or coarse-grained, an SA may be applied to all the packets exchanged between two peers (regardless of L4 protocols and ports) or to a specific packet flow. For example, if you wanted to define an IPSec channel for receiving HTTP data from a specific IPSec-enabled web server, the selector would be (<destination address: your IP>, <source address: web server's IP>, <L4 protocol: TCP>, <source port: 80>).
Three policies may be applied to a received packet, depending on the result of the SPD search:
discard the packet
bypass IPSec and process the packet normally (IPSec is not used for this packet flow)
apply IPSec according to what is specified in the SAD
According to these procedures, each packet going through an IPSec-enabled interface is subject to IPSec policies. In particular, packets that do not contain any IPSec fields are filtered. When no entry is found in the SPD for a particular packet's selector, the default behavior is to discard the packet.
As we have seen, the whole IPSec architecture is based on the presence of some common secret keys on both peers. Before any secure communication may begin, such keys are used to establish the SA. Keys may be manually configured on the peers (e.g., a passphrase may be agreed between the security administrators), or they may be automatically distributed using the IKE procedure. The keys may range from simple two-host shared secrets to digital certificates issued by official certification authorities. Hence, IKE can scale from a simple point-to-point data exchange mechanism to a complex network of encrypting hosts.
The IKE procedure creates a secure tunnel between two peers and then uses it to negotiate the SA. Note, this tunnel has nothing to do with the data tunnel that will be used eventually to exchange IPSec packets. More specifically, the IKE procedure in split into two phases. In Phase 1, the two peers establish a secure channel over which configuration data can be safely exchanged. In Phase 2, the IPSec SA is actually negotiated.
The first operation of Phase 1 is the authentication of the remote peer. As noted above, encryption without proper authentication can be extremely dangerous. Different authentication mechanisms can be employed, ranging from shared secret keys (manually configured) to public key cryptography. In the latter case, key exchange is based on the Diffie-Hellman algorithm reinforced with the usage of public key signatures.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Android's Limits
- Weechat, Irssi's Little Brother
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?