Managing the Security Association Database using setkey
As we mentioned in the Introduction to IPsec the kernel maintains two databases, the Security Policy Database (SPD) and the Security Association Database (SAD). In this section we shall explore the basic use of the setkey application to query and modify the Security Association Database (SAD).
Querying the IPsec SAD
The Security Association Database (SAD) contains information relating to the security associations which have been established between the local host and any other IPsec enabled devices. You can display the currently configured security associations using the setkey application as shown in the example below.
83.56.124.167[4500] 62.149.40.78[4500] esp-udp mode=tunnel spi=208683742(0x0c7042de) reqid=0(0x00000000) E: aes-cbc 56fec334 5ff810f1 1c68701e 1bbf6c37 A: hmac-sha1 b9bf975b d0b9a418 5ceb2ae4 641dd215 101244a8 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jan 23 18:08:27 2012 current: Jan 23 18:33:17 2012 diff: 1490(s) hard: 28800(s) soft: 23040(s) last: Jan 23 18:08:29 2012 hard: 0(s) soft: 0(s) current: 127676(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 330 hard: 0 soft: 0 sadb_seq=1 pid=5708 refcnt=0 62.149.40.78[4500] 83.56.124.167[4500] esp-udp mode=tunnel spi=253221875(0x0f17dbf3) reqid=0(0x00000000) E: aes-cbc 2878ad61 cbfb67c0 7fd1f9bc 7e388484 A: hmac-sha1 b79ebd0c f729e9b5 1f7ad0bf 3c1f1001 ae77cf36 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jan 23 18:08:27 2012 current: Jan 23 18:33:17 2012 diff: 1490(s) hard: 28800(s) soft: 23040(s) last: Jan 23 18:08:30 2012 hard: 0(s) soft: 0(s) current: 270573(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 332 hard: 0 soft: 0 sadb_seq=0 pid=5708 refcnt=0
The two associations above describe the same Virtual Private Network (VPN) as in the previous example. As you can see we are using the IPsec Encapsulating Security Payload protocol (further encapsulated in UDP datagrams for NAT traversal) using the AES-CBC cryptographic cipher and the HMAC-SHA1 secure hash algorithm.
Declaring Security Associations
In the previous section we created a setkey configuration file defining the security policy for a Virtual Private Network and a Secure Subnet. Before either configuration is actually usable however we need to create the relevant security associations. To accomplish this we need to use the add command, the basic syntax of which is shown below.
add [-46n] src dst protocol spi [extensions] algorithm ... ;
The following table describes the first four parameters of the add command.
| Description of basic parameters of the setkey add command | |
|---|---|
| src dst | These two parameters specify the network addresses of the peers taking part in this security association. As you may expect the first specifies the source address and the second specifies the destination address. |
| 10.0.0.1 | |
| protocol | The protocol field allows the protocol for this SA to be specified. One of either esp (for ESP based on RFC-2406◳), esp-udp (for ESP further encapsulated in UDP for NAT traversal based on RFC-3948◳) esp-old (for ESP based on RFC-1827◳), ah (for AH based on RFC-2402◳), ah-old (for AH based on RFC-1826◳), ipcomp (for IPComp based on RFC-2393◳) or tcp (for TCP-MD5 based on RFC-2385◳). |
| esp-udp | |
| spi | This field represents the Security Parameter Index (SPI) for the SAD and the SPD which may be either a decimal number or a hexadecimal number prefixed with 0x. SPI values between 0 and 255 are reserved for future use by IANA and therefore should not be used. TCP-MD5 associations must use 0x1000 which also means that only per-host granularity is supported at this time. |
| 0x10001 | |
After these four parameters an optional set of extensions may be specified. The syntax for the most commonly used of these is described below. As usual more information may be located in the setkey man pages.
| Description of extension parameters of the setkey add command | |
|---|---|
| -m mode | This parameter specifies which modes of operation this security association should be used. A value of transport, tunnel, or any may be used. |
| -m tunnel | |
| -r size | This parameter allows for control of the size of the window used for replay prevention. Any positive decimal value less than 32-bits is valid. A value of zero disables replay prevention. |
| -r 4 | |
| -lh time -ls time | These two parameters control the limits (hard and soft respectively) for the maximum duration that this security association is valid in seconds. |
| 43200 | |
| -bh bytes -bs bytes | These two parameters control the limits (hard and soft respectively) for the maximum duration that this security association is valid in bytes. |
| 268435456 | |
The table below describes the algorithm parameters of the add command.
| Description of algorithm parameters of the setkey add command | |
|---|---|
| -E algorithm key | For any protocol supporting encryption (such as ESP, for example) an encryption algorithm must be specified followed by a key either in double-quoted string format or a hexadecimal number prefixed with 0x. A variety of encryption standards are supported (see the setkey man page for more information) including aes-cbc, 3des-cbc, blowfish-cbc, camellia-cbc and aes-ctr. |
| -E aes-cbc 0x56fec3445ff820f116f8701e1abf6c37 | |
| -A algorithm key | For any protocol supporting authentication (such as AH, for example) an authentication algorithm must be specified followed by a key either in double-quoted string format or a hexadecimal number prefixed with 0x. A variety of authentication standards are supported (see the setkey man page for more information) including hmac-sha1, keyed-sha1 and hmac-sha512. |
| -A hmac-sha1 "An example of a string based key" | |
| -C algorithm | For any protocol supporting compression (at the moment only IPcomp) a compression algorithm must be specified. Currently the only supported compression algorithm is deflate. |
| -C deflate | |
Example Security Associations
Given the complexity of the add syntax a complete example is provided below so that you can see the relevant parts used in context.
IPsec Virtual Private Network (VPN)
#! /usr/sbin/setkey -f
# Flush the SPD and SAD
spdflush;
flush;
# Security Policies
spdadd 10.0.0.0/16 10.1.0.0/16 any
-P out ipsec
esp/tunnel/83.56.124.167-62.149.40.78/require;
spdadd 10.1.0.0/16 10.0.0.0/16 any
-P in ipsec
esp/tunnel/62.149.40.78-83.56.124.167/require;
# Security Associations
add 83.56.124.167 62.149.40.78 esp-udp 0x0c7042de
-m tunnel -r 4
-E aes-cbc 0x56fec3445ff820f116f8701e1abf6c37
-A hmac-sha1 0xb9bf971bdab9a41d5ceb2ae4641dd215101f44a8
add 62.149.40.78 83.56.124.167 esp-udp 0x0f17dbf3
-m tunnel -r 4
-E aes-cbc 0x2878ad61abfb63c07ad1f9bc7e358484
-A hmac-sha1 0xb79e3d0cf723e9b51f7a20bf3c1f10d1ae77af36
IPsec Secure Subnet
#! /usr/sbin/setkey -f
# Flush the SPD and SAD
spdflush;
flush;
# Security Policies
spdadd 10.0.0.0/16 10.0.0.0/16 any
-P out ipsec
esp/transport//require;
spdadd 10.0.0.0/16 10.0.0.0/16 any
-P in ipsec
esp/transport//require;
# Security Associations
add 10.0.0.1 10.0.0.2 esp 0x01631293
-m transport -r 4
-E aes-cbc "Shared secret between machine 1 and 2"
add 10.0.0.1 10.0.0.3 esp 0x01631293
-m transport -r 4
-E aes-cbc "Shared secret between machine 1 and 3"
add 10.0.0.2 10.0.0.1 esp 0x021f3a1b
-m transport -r 4
-E aes-cbc "Shared secret between machine 2 and 1"
add 10.0.0.3 10.0.0.1 esp 0x021f3a1b
-m transport -r 4
-E aes-cbc "Shared secret between machine 3 and 1"
...
As you can see, the example above clearly demonstrates one of the most significant drawbacks of using static keying. Because a security association is required between every machine on the secured subnet a separate entry will be required in the /etc/ipsec-tools.conf file for communication between each machine in both directions.
In the next section we shall examine the use of the racoon daemon and the Internet Security Association and Key Management Protocol (ISAKMP) to provide dynamic key exchange which solves the problem of proliferation of security associations demonstrated above.