| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IPSec Security Associations and the Security Association Database (SAD); Security Policies and the Security Policy Database (SPD); Selectors; the Security Parameter Index (SPI) (Page 2 of 2) Selectors One issue we haven't covered yet is how a device determines what policies or SAs to use for a specific datagram. Again here, IPSec defines a very flexible system that lets each security association define a set of rules for choosing datagrams that the SA applies to. Each of these rule sets is called a selector. For example, a selector might be defined that says that a particular range of values in the Source Address of a datagram, combined with another value in the Destination Address, means a specific SA must be used for the datagram. Let's now come back to security associations, which are a very important concept in IPSec. Each secure communication that a device makes to another requires that an SA be established. SAs are unidirectional, so each one only handles either inbound or outbound traffic for a particular device. This allows different levels of security to be implemented for a flow from device A to device B, than for traffic coming from device B to device A. In a bidirectional communication of this sort, both A and B would have two SAs; A would have SAs we could call "SAdeviceBin" and "SAdeviceBout". Device B would have SAs "SAdeviceAin" and "SAdeviceAout". Security associations don't actually have names, however. They are instead defined by a set of three parameters, called a triple:
As you can see, the two security protocols AH and ESP are dependent on security associations and policies and the various databases that control their operation. Management of these databases is important, but another whole complex subject. Generally, SAs can either be set up manually (which is of course extra work) or an automated system can be deployed using a protocol like IKE. Confused? I don't blame you, despite my best efforts, and remember that this is all highly simplified. Welcome to the wonderful world of networking security. If you are ever besieged by insomnia, I highly recommend RFC 2401. J
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |