This chapter describes how to configure the IP Security (IPSEC) and SETKEY protocols. IPSEC provides per-packet authenticity/confidentiality guarantees between peers that communicate using IPSEC.
IPSEC provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSEC acts at the network layer, protecting and authenticating IP packets between participating IPSEC devices.
IPSEC consists of a couple of separate protocols that are listed below:
Authentication Header (AH): Provides authenticity guarantee for packets, by attaching strong crypto checksums to packets. Unlike other protocols, AH covers the whole packet, from the IP header to the end of the packet.
If you receive a packet with AH and the checksum operation was successful, you can be sure about two things if you and the peer share a secret key, and no other party knows the key:
· The packet was originated by the expected peer. The packet was not generated by impersonator.
· The packet was not modified in transit.
Encapsulating Security Payload (ESP): Provides confidentiality guarantee for packets, by encrypting packets with encryption algorithms. If you receive a packet with ESP and have successfully decrypted it, you can be sure that the packet was not wiretapped in the middle, provided that you and the peer share a secret key, and no other party knows the key.
IP payload compression (IPcomp): ESP provides encryption service to the packets. However, encryption tends to give negative impact to compression on the wire (such as ppp compression). IPcomp provides a way to compress packets before encryption by ESP. (Of course, you can use IPcomp alone if you wish to).
Internet Key Exchange (IKE): An alternate form of keying is called Internet Key Exchange.
Note! Security of IPSEC protocols depends on the secrecy of secret keys. If secret keys are compromised, IPSEC protocols can no longer be secure. Take precautions about permission modes of configuration files, key database files, or whatever may lead to information leakage.
Both ESP and AH rely on security associations. A security association (SA) consists of a source, destination and an instruction. The collection of all SA’s maintained by the network kernel for a system is termed the security association database (SAD). A sample authentication SA may look like this:
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 ”1234567890123456”;
This says “traffic going from 10.0.0.11 to 10.0.0.216 that needs an AH can be signed using HMAC-MD5 using secret 1234567890123456”. This instruction is labelled with SPI (“Security Parameter Index”) id “15700” (SPI’s will be covered later). SAs are symmetrical; both sides of a conversation share exactly the same SA, it is not mirrored on the other side. Note that there is no ‘autoreverse’ rule - this SA only describes a possible authentication from 10.0.0.11 to 10.0.0.216. For two-way traffic, two SAs are needed.
Following is a sample SA:
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc “123456789012123456789012”;
This says “traffic going from 10.0.0.11 to 10.0.0.216 that needs encryption can be encyphered using 3des-cbc with key 123456789012123456789012”. The SPI id is “15701”.
SAs describe possible instructions, but do not in fact describe policy as to when these need to be used. In fact, there could be an arbitrary number of nearly identical SAs with only differing SPI ids. To do actual cryptography, we need to describe a security policy (SP). This policy can include things such as “use ipsec if available” or “drop traffic unless we have ipsec”. The collection of SPs for a system is termed the security policy database (SPD).
A typical simple Security Policy (SP) looks like this:
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require ah/transport//require;
If entered on host 10.0.0.216, this means that all traffic going out to 10.0.0.11 must be encrypted and be wrapped in an AH authenticating header. Note that this does not describe which SA is to be used, that is left as an exercise for the kernel to determine.
In other words, a Security Policy specifies what we want; a Security Association describes how we want it.
Outgoing packets are labelled with the SA SPI (“the how”) which the kernel used for encryption and authentication so the remote can look up the corresponding verification and decryption instruction.
The configuration file for IPSEC is loaded by the SETKEY program. The default name and location of this file is MULTINET:IPSEC.CONF, but other filenames may be used when specifying the -f switch for SETKEY.
The configuration file describes all the Security Associations (SA) and Security Policies (SP) for the system. Lines starting with the “#” character are treated as comment lines. Configuration descriptions can be spread over multiple lines in the file. Each description must end with a semicolon.
add [-4n] src dst protocol spi [extensions] algorithm ...;
Add an SAD entry. This can fail with multiple reasons, including when the key length does not match the specified algorithm.
get [-4n] src dst protocol spi;
Show an SAD entry.
delete [-4n] src dst protocol;
Remove all SAD entries that match the specification.
deleteall [-4n] src dst protocol;
Removes all SAD entries that match the specification.
flush [protocol];
Clears all SAD entries matched by the options. -F on the command line achieves the same functionality.
dump [protocol];
Dumps all SAD entries matched by the options. -D on the command line achieves the same functionality.
spdadd [-4n] src_range dst_range upperspec policy;
Adds an SPD entry.
spdflush ;
Clears all SPD entries. -FP on the command line achieves the same functionality.
spddump ;
Dumps all SPD entries. -DP on the command line achieves the same functionality.
Arguments for the configuration file operations are as follows:
src/dst
Source/destination of the secure communication is specified as IPv4/IPv6 addresses. SETKEY can resolve a FQDN into numeric addresses. If the FQDN resolves into multiple addresses, SETKEY will install multiple SAD/SPD entries into the kernel by trying all possible combinations. -4 and -n restricts the address resolution of FQDN in certain ways. -4 restricts results into IPv4/IPv6 addresses only. -n avoids FQDN resolution and requires addresses to be numeric addresses.
Protocol (where protocol is one of the following):
· esp ESP based on RFC 2406
· esp-old ESP based on RFC 1827
· ah AH based on RFC 2402
· ah-old AH based on RFC 1826
· ipcomp IPComp
spi
Security Parameter Index (SPI) for the SAD and the SPD. spi must be a decimal number or a hexadecimal number prefixed by ‘0x’.
SPI values between 0 and 255 are reserved for future use by IANA.
extensions
May take the following values:
-m mode
Specify a security protocol mode for use. Mode is one of the following: transport, tunnel or any. The default value is any.
-r size
Specify window size in bytes for replay prevention. size must be a decimal number in 32-bit word. If size is zero or not specified, replay checks don’t take place.
-u id
Specify the identifier of the policy entry in SPD. See policy.
-f pad_option
Defines the content of the ESP padding, and must be one of the following:
· zero-pad All of the padding are zero.
· random-pad A series of randomized values are set.
·
seq-pad A series of sequential
increasing numbers started from 1 are set.
-f nocyclic-seq
Don’t allow cyclic sequence number.
-ls
time_in_seconds
Specify the soft lifetime duration of the SA.
-lh time_in_seconds
Specify the hard lifetime duration of the SA.
Algorithm
-E ealgo key
Specify an encryption algorithm for ESP.
-E ealgo key -A aalgo key
Specify an encryption algorithm ealgo, as well as a payload authentication algorithm aalgo, for ESP.
-A aalgo key
Specify an authentication algorithm for AH.
-C calgo [-R]
Specify a compression algorithm for IPComp. If -R
is specified, the spi field value will be used
as the IPComp CPI (compression parameter index). If -R is not specified, the
kernel
will use well-known CPI, and the spi field will be used only as an index
for kernel internal
usage.
key must be a double-quoted character string, or a series of hexadecimal digits preceded by “0x”.
src_range
dst_range
These are selections of the secure communication specified as an IPv4/IPv6 address or an IPv4/IPv6 address range, and it may also include a TCP/UDP port specification. The addresses may take one of the following forms (an example of each is shown):
|
Address |
192.168.0.15 |
|
Address/prefixlen |
192.168.0.15/24 |
|
Address[port] |
192.168.0.15[1234] |
|
Address/prefixlen[port] |
192.168.0.15/24[1234] |
Note that prefixlen and port must be decimal numbers. The square brackets around port are necessary. For FQDN resolution, the rules applicable to src and dst apply here as well.
upperspec
Upper-layer protocol to be used. icmp6, ip4,
and any
can be specified, where any indicates “any
protocol.” The protocol number may also be used.
policy
policy is one of the following three formats:
-P direction discard protocol/mode/src-dst/level[...]
-P direction none protocol/mode/src-dst/level[...]
-P direction ipsec protocol/mode/src-dst/level[...]
· direction must be out or in.
· discard means the packet matching indexes will be discarded.
· none means that IPsec operations will not take place on the packet.
· ipsec means that IPsec operations will take place on the packet.
· protocol/mode/src-dst/level specifies the rule as to how the packet will be processed:
o protocol must be one of ah, esp or ipcomp.
o mode must be transport. Note that only transport is valid for the implementation of MultiNet, as tunneling isn’t supported.
o Both src and dst can be omitted.
o level must be one of the following:
§ default means the kernel consults the system-wide default against the protocol specified.
§ use means that the kernel uses a SA if one is available.
§ require means SA is required whenever the kernel sends a packet matched with the policy.
§ unique is the same as require; in addition, it allows the policy to bind with the unique outbound SA.
The following table shows the supported algorithms that can be used as aalgo in a -A aalgo protocol parameter:
|
Algorithm |
Key Length in Bits |
|
hmac-md5 |
128 |
|
hmac-sha1 |
160 |
|
keyed-md5 |
128 |
|
keyed-sha1 |
160 |
|
null |
0 to 2048 |
The following table shows the supported algorithms that can be used as ealgo in a -E ealgo protocol parameter:
|
Algorithm |
Key Length in Bits |
|
blowfish-cbc |
40 to 448 |
|
cast128-cbc |
40 to 128 |
|
des-cbc |
64 |
|
3des-cbc |
192 |
|
des-deriv |
64 |
|
rijndael-cbc |
128/192/256 |
Only deflate may be used as calgo in a -C ealgo protocol parameter.
What follows is a very simple configuration for talking from host 10.0.0.216 to 10.0.0.11 using encryption and authentication.
On host 10.0.0.216:
add 10.0.0.216 10.0.0.11 ah 24500
-A hmac-md5 “1234567890123456”;
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc “12345678901212345678901222”;
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require
ah/transport//require;
On host 10.0.0.11, the same Security Associations, no Security Policy:
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5
“1234567890123456”;
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc “12345678901212345678901222”;
With the above configuration in place, $MU PING 10.0.0.11 from 10.0.0.216 looks like this using TCPDUMP:
22:37:52
10.0.0.216>10.0.0.11:AH(spi=0x00005fb4,seq=0xa):ESP(spi=0x00005fb5,seq=0xa)(DF)
23:37:52 10.0.0.11>10.0.0.216:icmp:echo reply
Note how the ping back from 10.0.0.11 is plainly visible. The forward ping cannot be read by TCPDUMP (as the packet is encrypted), but it does show the Security Parameter Index of AH and ESP, which tells 10.0.0.11 how to verify the authenticity of our packet and how to decrypt it.
A problem with the previous example is that it specifies a policy on how 10.0.0.216 should treat packets going to 10.0.0.11, and that it specifies how 10.0.0.11 should treat those packets. However it does not instruct 10.0.0.11 to discard unauthenticated or unencrypted traffic. Hence, anybody could insert spoofed and completely unencrypted data and 10.0.0.11 will accept it. To remedy the above, we need an incoming Security Policy on 10.0.0.11, as follows:
spdadd 10.0.0.216 10.0.0.11 any -P in ipsec esp/transport//require ah/transport//require;
This instructs 10.0.0.11 that any traffic coming in to it from 10.0.0.216 is required to have valid ESP and AH.
To complete this configuration, the return traffic needs to be encrypted and authenticated as well. Therefore, the following configurations will be required:
On 10.0.0.216:
flush;
spdflush;
# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 “1234567890123456”;
add 10.0.0.11 10.0.0.11 ah 24500 -A hmac-md5 “1234567890123456”;
# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc “1234567890123456789012”;
add 10.0.0.11 10.0.0.216 esp 24501 -E 3des-cbc “1234567890123456789012”;
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require
ah/transport//require;
spdadd 10.0.0.11 10.0.0.216 any -P in ipsec esp/transport//require
ah/transport//require;
And on 10.0.0.11:
flush;
spdflush;
# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 “1234567890123456”;
add 10.0.0.11 10.0.0.11 ah 24500 -A hmac-md5 “1234567890123456”;
# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc “1234567890123456789012”;
add 10.0.0.11 10.0.0.216 esp 24501 -E 3des-cbc “1234567890123456789012”;
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require
ah/transport//require;
spdadd 10.0.0.11 10.0.0.216 any -P in ipsec esp/transport//require
ah/transport//require;
Note that in this example, identical keys were used for both directions of traffic. However, it’s not required to use identical keys for both directions.
The configuration file for IPSEC is loaded by the SETKEY program. A foreign command must be defined to invoke SETKEY:
$ setkey :== $multinet:setkey
setkey [-v] -f filename
setkey [“-aPlv”] “-D”
setkey [“-Pv”] “-F”
setkey [-h] -x
The possible command options for SETKEY are:
|
-D |
Dump the SAD entries. If with -P, the SPD entries are dumped. |
|
-f filename |
Read the configuration commands from the specified file. |
|
-F |
Flush the SAD entries. If with -P, the SPD entries are flushed. |
|
-a |
A dead SAD entry means that it has been expired but remains in the system because it is referenced by some SPD entries. |
|
-h |
Add hexadecimal dump on -x mode. |
|
-l |
Loop forever with short output on -D. |
|
-v |
Be verbose. The program will dump messages exchanged on PF_KEY socket, including messages sent from other processes to the kernel. |
|
-x |
Loop forever and dump all the messages transmitted to PF_KEY socket. |
Example 1: Parse and load the policies in the file MULTINET:IPSEC.CONF into the kernel (note that the output from parsing can be quite verbose, so part of the output has been deleted from the middle this example to keep it to a reasonable size):
$ setkey “-f” multinet:ipsec.conf
Starting parse
Entering state 0
Reducing via rule 1 (line 126), -> commands
state stack now 0
Entering state 1
Reading a token: Next token is 261 (ADD)
Shifting token 261 (ADD), Entering state 2
Reducing via rule 57 (line 537), -> ipaddropts
state stack now 0 1 2
entering state 23
Reading a token: Next token is 292 (STRING)
Shifting token 292 (STRING), Entering state 36
Reducing via rule 61 (line 568), STRING -> ipaddr
state stack now 0 1 2 23
Entering state 39
...
Entering state 19
Reducing via rule 9 (line 141),spdadd_command -> command
state stack now 0 1
Entering state 12
Reducing via rule 2 (line 127), commands command -> commands
state stack now 0
Entering state 1
Reading a token: Now at end of input.
Shifting token 0 ($), Entering state 137
Now at end of input.
Example 2: Dump out the policies in the kernel:
$ setkey “-PD”
192.168.154.10/24[any] 192.168.228.100/24[any]any
out ipsec
esp/transport//use
ah/transport//use
spid=1 seq=0 pid=149
refcnt=1
Example 3: Dump out the SAD entries in the kernel:
$ setkey “-D”
192.168.228.100 192.168.154.10
ah mode=any spi=1000(0x00002711)reqid=0(0x00000000)
A:hmac -sha1 6d6f6761 6d6f6761 6d6f6761 6d6f6761
replay=0 flags=0x00000040 state=mature seq=3 pid=149
created: Dec 22 15:52:49 2003 current: Dec 22 15:54:30 2003
diff: 101(s) hard:0(s) soft:0(s)
last: hard:0(s) soft:0(s)
current:0(bytes) hard:0(bytes) soft:0(bytes)
allocated:0 hard:0 soft:0
refcnt=1
192.168.154.10.192 168.228.100
ah mode=any spi=9877(0x00002695)reqid=0(0x00000000)
A:hmac -sha1 686f6765 686f6765 686f6765 686f6765
replay=0 flags=0x00000040 state=mature seq=2 pid=149
created: Dec 22 15:52:49 2003 current: Dec 22 15:54:30 2003
diff: 101(s) hard:0(s) soft:0(s)
last: hard:0(s) soft:0(s)
current:0(bytes) hard:0(bytes) soft:0(bytes)
allocated:0 hard:0 soft:0
refcnt=1
192.168.228.100.192 168.154.10
ah mode=transport spi=10000(0x00002710)reqid=0(0x00000000)
E:3des-cbc deadbeef deadbeef deadbeef deadbeef deadbeef
replay=0 flags=0x00000040 state=mature seq=1 pid=149
created: Dec 22 15:52:49 2003 current: Dec 22 15:54:30 2003
diff: 101(s) hard:0(s) soft:0(s)
last: hard:0(s) soft:0(s)
current:0(bytes) hard:0(bytes) soft:0(bytes)
allocated:0 hard:0 soft:0
refcnt=1
192.168.154.10 192.168.228.100
ah mode=transport spi=9876(0x00002694)reqid=0(0x00000000)
E:3des-cbc 686f6765 686f6765 686f6765 686f6765 686f6765
replay=0 flags=0x00000040 state=mature seq=0 pid=149
created: Dec 22 15:52:49 2003 current: Dec 22 15:54:30 2003
diff: 101(s) hard:0(s) soft:0(s)
last: hard:0(s) soft:0(s)
current:0(bytes) hard:0(bytes) soft:0(bytes)
allocated:0 hard:0 soft:0
refcnt=1
Example 4: Dump the messages out on the PF_KEY socket.
$ setkey “-hx”
14:38:47.009961
00000000:02 0b 00 00 06 00 00 00 00 00 00 00 00 00 00 00
0000000010:02 0b 00 01 02 00 00 00 00 00 00 95 00 00 00
sadb_msg { version=2 type=1 1 errno=0 satype=1
len=2 reserved=0 seq=0 pid=149
14:38:47 057809
00000000:02 0b 00 01 02 00 00 00 00 00 00 00 95 00 00 00
Example 5: Flush all of the entries from the kernel.
$ setkey “-F”
$ setkey “-D”
No SAD entries.
If you want to run host-to-host (transport mode) encryption with manually configured secret keys, the following configuration should be sufficient:
# multinet:ipsec.conf
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
add 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;
add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use;
From 10.1.1.1 to 10.2.1.1, use the 3DES-CBC algorithm with SPI 9876, with secret key “hogehogehogehhogehogehoge”.The traffic will be identified by SPI 9876.
From 10.2.1.1 to 10.1.1.1, use 3DES-CBC algorithm with SPI
10000, with secret key
0xdeadbeefdeadbeefdeadbeefdeadbeef.
The last line configures per-packet IPSEC policy for the node. Using this configuration, the transmit node (10.1.1.1) used to send packets to the peer (20.1.1.1), is encrypted whenever a secret key is configured in to the kernel. The configuration does not prohibit unencrypted packets from 20.1.1.1 to reach 10.1.1.1. To reject unencrypted packets, the following line would be added to the configuration file:
spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//require;
On the peer’s node (10.2.1.1), the configuration will look similar to what is shown in the following example. Note that the addresses need to be swapped on the spdadd line, but add lines do not need to be swapped.
# multinet:ipsec.conf
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.2.1.1, peer is on 10.1.1.1
add 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;
add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
spdadd 10.2.1.1 10.1.1.1 any -P out ipsec esp/transport//use;
The previous example uses human-readable secret keys. However, using human-readable secret keys is discouraged by the IPSEC policy specification, since they are more likely to be compromised than binary keys. Binary keys should be used for normal operations.
Key length is determined by algorithms. See the sections Authentication Algorithms and Encryption Algorithms for the required key lengths. For 3des-cbc, the secret key must be 192 bits (24 bytes). If a shorter or longer key is specified, SETKEY will return an error when parsing the line.
The following is an example of rijndael-cbc (also known as AES) using 128-bit keys.
# multinet:ipsec.conf
#
# the packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 10.2.1.1
# rijndael -cbc with 128bit key
add 10.1.1.1 10.2.1.1 esp 9876 -E rijndael -cbc “hogehogehogehoge”;
add 10.2.1.1 10.1.1.1 esp 10000 -E rijndael -cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use;
The following example shows a sample configuration for host-to-host authentication:
# multinet:ipsec.conf
#
# packet will look like this: IPv4 AH payload
# the node is on 10.1.1.1, peer is on 10.2.1.1
add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “hogehogehogehoge”;
add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “mogamogamogamoga”;
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec ah/transport//use;
The following example shows sample keys that are configured for both AH and ESP.
Note! It is recommended that you apply AH after ESP.
# multinet:ipsec.conf
#
# packet will look like this: IPv4 AH ESP payload
# the node is on 10.1.1.1, peer is on 10.2.1.1
add 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;
add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/transport//use;
The MultiNet IPSEC implementation conforms to the following IPSEC standards: RFC 2401, RFC 2402, RFC 2404, RFC 2406, RFC 4835, RFC 4868. The IKEv2 (Racoon2) implementation provides support for RFC 4306, RFC 4307 and RFC 4718.
The RACOON service performs the task of securely creating security associations for participating systems. When a security policy senses the need of a security association, RACOON is notified and securely communicates with an Internet Key Exchange daemon on the other system to establish the security association. Security Policies must still be configured manually with the SETKEY program.
The RACOON service can be controlled through the following MULTINET NETCONTROL commands:
· DEBUG - set the debug level for a currently running Racoon IKE daemon.
· ESTABLISH remote-ip-address [local-ip-address] – initiate key exchange protocol communication between the remote ip-address and the local ip-address. If local-ip-address is not specified then the value of MULTINET_HOST_NAME is used. This does not install Security Associations, but does the initial negotiation necessary to allow Security Associations to be established when necessary. It is not necessary to manually establish the negotiation information – RACOON will do it automatically when necessary.
· FLUSH – flush all existing keys
· NOOP - No Operation
· SHOW – show existing key associations
· SHUTDOWN – Shut down the Racoon IKE Daemon. All established keys are flushed as part of this process.
· START – Start the Racoon IKE Daemon
· STOP – Same as SHUTDOWN
· VERSION – Display control interface version
The configuration file (MULTINET:RACOON.CONF) can be configured to handle all systems in general, or specific systems.
RACOON negotiates security associations for itself (ISAKMP SA, or phase 1 SA) and for kernel IPsec (IPsec SA, or phase 2 SA). The file consists of a sequence of directives and statements. Each directive is composed by a tag, and statements are enclosed by ‘{‘ and ‘}’. Lines beginning with ‘#’ are comments.
Note that you have to pay attention when this section of the manual is describing port numbers. The port number is always enclosed by ‘[‘ and ‘]’ (square brackets). In this case, the port number is not an optional keyword. If it is possible to omit the port number, the expression becomes [[port]]. Major parameters are listed below.
· Number - means a hexadecimal or a decimal number. The former must be prefixed with `0x'.
· string path file means any string enclosed in ‘"‘ (double quote).
· Address means IPv4 address.
· Port means a TCP/UDP port number. The port number is always enclosed by ‘[‘ and ‘]’.
· Timeunit is one of following: sec, secs, second, seconds, min, mins, minute, minutes, hour, hours.
path include path;
specifies a path to include a file. See File Inclusion.
path pre_shared_key file;
specifies a file containing pre-shared key(s) for various ID(s). See Pre-shared key File.
path certificate path;
racoon will search this directory if a certificate or certificate request is received.
path backupsa file;
specifies a file to be stored a SA information which is negotiated by racoon. racoon will install SA(s) from the file with a boot option -B. The file is increasing because racoon simply adds a SA to the file at the moment. You should maintain the file manually.
include file
other configuration files can be included.
timer { statements }
specifies various timer values.
counter number;
the maximum number of retries to send. The default is 5.
interval number timeunit;
the interval to resend, in seconds. The default time is 10 seconds.
persend number;
the number of packets per send. The default is 1.
phase1 number timeunit;
the maximum time it should take to complete phase 1. The default time is 15 seconds.
phase2 number timeuni;
the maximum time it should take to complete phase 2. The default time is 10 seconds.
listen { statements }
If no listen directive is specified, racoon will listen on all of the available interface addresses. The following is the list of valid statements:
isakmp address [[port]];
If this is specified, racoon will only listen on address. The default port is 500, which is specified by IANA. You can provide more than one address definition.
strict_address;
require that all addresses for ISAKMP must be bound. This statement will be ignored if you do not specify any addresses.
remote (address | anonymous) [[port]] { statements }
specifies the parameters for IKE phase 1 for each remote node. The default port is 500. If anonymous is specified, the statements apply to all peers which do not match any other remote directive.
The following are valid statements:
exchange_mode (main | aggressive | base);
defines the exchange mode for phase 1 when racoon is the initiator. Also it means the acceptable exchange mode when racoon is responder. More than one mode can be specified by separating them with a comma. All of the modes are acceptable. The first exchange mode is what racoon uses when it is the initiator.
doi ipsec_doi;
means to use IPSEC-DOI as specified RFC 2407. You can omit this statement.
situation identity_only;
means to use SIT_IDENTITY_ONLY as specified RFC 2407. You can omit this statement.
my_identifier idtype ...;
specifies the identifier sent to the remote host and the type to use in the phase 1 negotiation. address, fqdn, user_fqdn, keyid and asn1dn can be used as an idtype. they are used like:
my_identifier address [address];
the type is the IP address. This is the default type if you do not specify an identifier to use.
my_identifier user_fqdn string;
the type is a USER_FQDN (user fully-qualified domain name).
my_identifier fqdn string;
the type is a FQDN (fully-qualified domain name).
my_identifier keyid file;
the type is a KEY_ID. my_identifier asn1dn [string]; the type is an ASN.1 distinguished name. If string is omitted, racoon will get DN from Subject field in the certificate.
peers_identifier idtype ...;
specifies the peer's identifier to be received. If it is not defined then racoon will not verify the peer's identifier in ID payload transmitted from the peer. If it is defined, the behavior of the verification depends on the flag of verify_identifier. The usage of idtype is same to my_identifier.
verify_identifier (on | off);
If you want to verify the peer's identifier, set this to on. In this case, if the value defined by peers_identifier is not same to the peer's identifier in the ID payload, the negotiation will failed. The default is off.
certificate_type certspec;
specifies a certificate specification. certspec is one of followings:
x509 certfile privkeyfile;
certfile means a file name of certificate. privkeyfile means a file name of secret key.
peers_certfile (dnssec | certfile);
If dnssec is defined, racoon will ignore the CERT pay- load from the peer, and try to get the peer's certificate from DNS instead. If certfile is defined, racoon will ignore the CERT payload from the peer, and will use this certificate as the peer's certificate.
send_cert (on | off);
If you do not want to send a certificate for some reason, set this to off. The default is on.
send_cr (on | off);
If you do not want to send a certificate request for some reason, set this to off. The default is on.
verify_cert (on | off);
If you do not want to verify the peer's certificate for some reason, set this to off. The default is on.
lifetime time number timeunit;
define a lifetime of a certain time which will be proposed in the phase 1 negotiations. Any proposal will be accepted, and the attribute(s) will be not proposed to the peer if you do not specify it(them). They can be individually specified in each proposal.
initial_contact (on | off);
enable this to send an INITIAL-CONTACT message. The default value is on. This message is useful only when the implementation of the responder choices an old SA when there are multiple SAs which are different established time, and the initiator reboots. If racoon did not use the message, the responder would use an old SA even when a new SA was established. The KAME stack has the switch in the system wide value, net.key.preferred_oldsa. when the value is zero, the stack always use a new SA.
passive (on | off);
If you do not want to initiate the negotiation, set this to on. The default value is off. It is useful for a server.
proposal_check level;
specifies the action of lifetime length and PFS of the phase 2 selection on the responder side. The default level is strict. If the level is:
• obey the responder will obey the initiator anytime.
• Strict If the responder's length is longer than the initiator's one, the responder uses the initiator's one. Otherwise it rejects the proposal. If PFS is not required by the responder, the responder will obey the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal.
• Claim If the responder's length is longer than the initiator's one, the responder will use the initiator's one. If the responder's length is shorter than the initiator's one, the responder uses its own length AND sends a RESPONDER-LIFETIME notify message to an initiator in the case of lifetime. About PFS, this directive is same as strict.
• exact If the initiator's length is not equal to the responder's one, the responder will reject the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal.
support_mip6 (on | off);
If this value is set on then both values of ID payloads in phase 2 exchange are always used as the addresses of end-point of IPsec-SAs. The default is off.
generate_policy (on | off);
This directive is for the responder. Therefore you should set passive on in order that racoon only becomes a responder. If the responder does not have any policy in SPD during phase 2 negotiation, and the directive is set on, then racoon will choice the first proposal in the SA payload from the initiator, and generate policy entries from the proposal. It is useful to negotiate with the client which is allocated IP address dynamically. Note that inappropriate policy might be installed by the initiator because the responder just installs policies as the initiator proposes. So that other communication might fail if such policies installed. This directive is ignored in the initiator case. The default value is off.
nonce_size number;
define the byte size of nonce value. Racoon can send any value although RFC2409 specifies that the value MUST be between 8 and 256 bytes. The default size is 16 bytes.
proposal { sub-substatements }
encryption_algorithm algorithm;
specify the encryption algorithm used for the phase 1 negotiation. This directive must be defined. algorithm is one of following: des, 3des, blowfish, cast128 for Oakley. For other transforms, this statement should not be used.
hash_algorithm algorithm;
define the hash algorithm used for the phase 1 negotiation. This directive must be defined. algorithm is one of following: md5, sha1 for Oakley.
authentication_method type;
defines the authentication method used for the phase 1 negotiation. This directive must be defined. type is one of: pre_shared_key, rsasig, gssapi_krb.
dh_group group;
define the group used for the Diffie-Hellman exponentiations. This directive must be defined. group is one of following: modp768, modp1024, modp1536. Or you can define 1, 2, or 5 as the DH group number. When you want to use aggressive mode, you must define same DH group in each proposal.
lifetime time number timeunit;
define lifetime of the phase 1 SA proposal. Refer to the description of lifetime directive immediately defined in remote directive.
gssapi_id string;
define the GSS-API endpoint name, to be included as an attribute in the SA, if the gssapi_krb authentication method is used. If this is not defined, the default value of `ike/hostname' is used, where hostname is the FQDN of the interface being used.
The policy directive is obsolete, policies are now in the SPD. racoon will obey the policy configured into the kernel by setkey, and will construct phase 2 proposals by combining sainfo specifications in racoon.conf, and policies in the kernel.
sainfo (source_id destination_id | anonymous) { statements }
defines the parameters of the IKE phase 2 (IPsec-SA establishment). source_id and destination_id are constructed like:
address address [/ prefix] [[port]] ul_proto
or
idtype string
It means exactly the content of ID payload. This is not like a filter rule. For example, if you define 3ffe:501:4819::/48 as source_id. 3ffe:501:4819:1000:/64 will not match.
pfs_group group;
define the group of Diffie-Hellman exponentiations. If you do not require PFS then you can omit this directive. Any proposal will be accepted if you do not specify one. group is one of following: modp768, modp1024, modp1536. Or you can define 1, 2, or 5 as the DH group number.
lifetime time number timeunit;
define the lifetime of amount of time which are to be used IPsec-SA. Any proposal will be accepted, and no attribute(s) will be proposed to the peer if you do not specify it(them). See the proposal_check directive.
racoon does not have the list of security protocols to be negotiated. The list of security protocols are passed by SPD in the kernel. Therefore you have to define all of the potential algorithms in the phase 2 proposals even if there is a algorithm which will not be used. These algorithms are define by using the following three directives, and they are lined with single comma as the separator. For algorithms that can take variable-length keys, algorithm names can be followed by a key length, like ``blowfish 448''. racoon will compute the actual phase 2 proposals by computing the permutation of the specified algorithms, and then combining them with the security protocol specified by the SPD. For example, if des, 3des, hmac_md5, and hmac_sha1 are specified as algorithms, we have four combinations for use with ESP, and two for AH. Then, based on the SPD settings, racoon will construct the actual proposals. If the SPD entry asks for ESP only, there will be 4 proposals. If it asks for both AH and ESP, there will be 8 proposals. Note that the kernel may not support the algorithm you have specified.
encryption_algorithm algorithms;
des, 3des, des_iv64, des_iv32, rc5, rc4, idea, 3idea, cast128, blowfish, null_enc, twofish, rijndael (used with ESP)
authentication_algorithm algorithms;
des, 3des, des_iv64, des_iv32, hmac_md5, hmac_sha1, non_auth (used with ESP authentication and AH)
compression_algorithm algorithms;
deflate (used with IPComp)
Logging level
log level;
define logging level. level is one of following: notify, debug and debug2. The default is notify. If you put too high logging level on slower machines, IKE negotiation can fail due to timing constraint changes.
Specifying the way to pad
padding { statements }
specified padding format. The following are valid statements:
randomize (on | off);
enable using a randomized value for padding. The default is on.
randomize_length (on | off);
the pad length is random. The default is off.
maximum_length number;
define a maximum padding length. If randomize_length is off, this is ignored. The default is 20 bytes.
exclusive_tail (on | off);
means to put the number of pad bytes minus one into last part of the padding. The default is on.
strict_check (on | off);
means to be constrained the peer to set the number of pad bytes. The default is off.
Special directives
complex_bundle (on | off);
defines the interpretation of proposal in the case of SA bundle. Normally ``IP AH ESP IP payload'' is proposed as ``AH tunnel and ESP tunnel''. The interpretation is more common to other IKE implementations, however, it allows very limited set of combinations for proposals. With the option enabled, it will be pro- posed as ``AH transport and ESP tunnel''. The default value is off.
Pre-shared key File
Pre-shared key file defines a pair of the identifier and the shared secret key which are used at Pre-shared key authentication method in phase 1. The pair in each lines are separated by some number of blanks and/or tab characters like hosts(5). Key can be included any blanks because all of the words after 2nd column are interpreted as a secret key. Lines start with `#' are ignored. Keys which start with `0x' are hexadecimal strings. Note that the file must be owned by the user ID running racoon (usually the privileged user), and must not be accessible by others.
#
# Basic Racoon configuration file
#
path pre_shared_key "multinet:psk.txt" ;
remote anonymous
{
exchange_mode aggressive, main, base ;
lifetime time 24 hour ;
proposal {
encryption_algorithm blowfish 448;
hash_algorithm md5; #sha1;
authentication_method pre_shared_key ;
dh_group 5 ;
}
}
sainfo anonymous
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish 448;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
192.168.1.2 deadbeef
192.168.1.3 deadbeef
192.168.1.4 deadbeef
192.168.1.5 face0ff0
The following restrictions exist regarding the use of IPSEC in MultiNet V 5.5. These restrictions may be lifted in future releases of MultiNet.
· Security may not be set on a socket-by-socket basis via the use of setsockopt().
· Only transport mode is supported to both AH and ESP. Tunnel mode (primarily used for VPN’s) is not supported in any mode (AH or ESP).
· IPcomp is not currently implemented.
Racoon2 is the new IPSEC key management package that replaces Racoon. The MultiNet implementation is based upon racoon2-20090327c from the WIDE project and uses the OpenSSL-0.9.8k crypto library. MultiNet Racoon2 is available on OpenVMS Alpha and Integrity platforms and offers IKEv1 in main mode and IKEv2. Racoon2 consists of three images:
• SPMD – the Security Policy Management Daemon, which installs security policies and acts on various requests from IKED
• SPMDCTL – the program to send SPMD control messages while it is running
• IKED – the IPSEC Key Exchange Daemon, which authenticates the identification of a remote system and establishes security associations. IKED supports the following specifications:
• Internet Key Exchange (IKEv2) Protocol
• RFC 4306, Internet Key Exchange (IKEv2) Protocol
• RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4718, IKEv2 Clarifications and Implementation Guidelines
• The Internet Key Exchange (IKE)
• RFC 2409, The Internet Key Exchange (IKE)
• RFC 3947, Negotiation of NAT-Traversal in the IKE
• RFC 3948, UDP Encapsulation of IPsec ESP Packets
All images assume a default configuration file of MULTINET:RACOON2.CONF
Additional information on Racoon2 is available from http://www.racoon2.wide.ad.jp/ .
Note! KINKD is not provided because there are a number of Kerberos routines that it needs that are not visible in the packages provided for OpenVMS by HP.
SPMD manages IPsec Security Policy for racoon2, the key management daemon (IKED). It can also serve as a local DNS proxy server if you set on in racoon2 configuration file.
usage:
spmd [-dhV] [-f config] [-D
level]
-V show version number
-f specify config file
-d increase debug level(max ddd)
-D specify debug level(1-3)
-h show this help
Note! When using command line options, make sure to enclose them in double quotes to preserve case.
SPMD must be started first. Users who are familiar with SPMD on Unix platforms will notice that SPMD on MultiNet only runs in “foreground mode”.
• SPMD can provide name resolution for IKED on systems that do not run a name server. This can be either as a name server proxy, or based completely upon the HOSTS.LOCAL file. The logical MULTINET_SVCORDER can be used to define the order of name resolution and can be defined to any combination of local and bind. The default value is bind.
$ define/system MULTINET_SVCORDER “local, bind”
spmdctl connects to the spmd interface which is specified in the racoon2 configuration file, and requests operations to spmd. These requests can be changes to the currently managed security policies and name servers, if SPMD is acting as a proxy name server.
usage:
spmdctl [-d] [-f
RACOON2_CONF_FILE] COMMAND
-d : display messages corresponded with spmd
-f RACOON2_CONF_FILE : specify racoon2 configuration file
COMMAND:
ns {add|delete}
address : add/delete nameserver
ns list : show nameservers
policy add selector_index \
lifetime(sec) {transport|tunnel} \
sp_src_ipaddr sp_dst_ipaddr \
[sa_src_ipaddr sa_dst_ipaddr]
: add policy
policy delete selector_index
: delete policy
policy dump : show policies under spmd management
interactive : process only login
shutdown : tell spmd to shutdown
status : show statistics
Note! When using command line options, make sure to enclose them in double quotes to preserve case.
IKED is a key management daemon, which supports the Internet Key Exchange (IKE) protocol version 1 (RFC2409) and version 2 (RFC4306). It is driven by messages from the kernel via the PF_KEYv2 interface or by negotiation requests from remote peers, and manages IPSec Security Associations according to racoon2.conf. Users who are familiar with IKED on Unix platforms will notice that IKED on MultiNet only runs in “foreground mode”.
usage:
iked [-f file] [-p port] [-46]
[-I address] \
[-S selector_index]
[-D number] [-dvVh] [-l logfile]
-f specify the
configuration file.
-p specify the isakmp port number to listen to.
-4 use IPv4 only.
-6 use IPv6 only.
-I immediately initiate to the address specified.
-S immediately initiate using the selector specified.
-D specify the debug flags.
-d increase the debug level.
-v specify to output messages to standard error,
in addition to syslog.
-V show the iked version.
-h show this help.
-l specify log output file (instead of syslog).
Debug option:
0x0001 DEBUG_FLAG_DEBUG log debug messages.
0x0002 DEBUG_FLAG_TRACE show internal processing trace.
0x0004 DEBUG_FLAG_CONFIG show config parsing trace.
0x0008 DEBUG_FLAG_PFKEY PFKEY and SPMIF are ignored.
Note! When using command line options, make sure to enclose them in double quotes to preserve case.
IKED uses the entire contents of the PSK file as the key, so watch for any trailing newlines that might get inadvertently added. This is different from Racoon, which uses a PSK file that is keyed by IP Address to designate the key.
The following steps are required to get two hosts using Racoon2 IKED to authenticate each other with certificates when using the IKEv1 or IKEv2 protocol:
• Create a Certificate Signing Request with an unencrypted private key
• Send the CSR file to the Certificate Authority (CA) for signing. Make sure that the CA includes the following information in the CRT (or PEM) file that is returned:
• SubjectAtlName = DNS:FQDN
• SubjectAltName = email:email_address_of_contact
• SubjectAltName = IP:ip_address_of_system
If the VMS OpenSSL software is used, then the above information needs to be added to the SSL$CONF:SSL$CA.CNF file before signing each certificate under the [CA_x509_extensions] section.
• Convert the CRT files to PEM files (if necessary) with the following commands:
• Openssl x509 –in host.crt –out host.der –outform DER
• Openssl x509 –in host.der –inform DER –out host.pem –outform PEM
• Hash certificates (PEM files) (option 9 with SSL$COM:SSL$CERT_TOOL)
• Distribute the PEM files and hashed files to the hosts involved.
The default format for the SubjectAltName IP address is a binary value. If your CA encodes this as a text string then define the logical MULTINET_RACOON2_BINARY_IPV4_SUBJECTALTNAME FALSE (or MULTINET_RACOON2_BINARY_IPV6_SUBJECTALTNAME for IPv6).
In addition to the above, IKEv2 needs the following in the Racoon2 configuration:
Send_peers_id on;
The OpenSSL code that IKED is built with looks in SSLCERTS: (not SSL$CERTS:) for the CA certificate, so you need to define the logical SSLCERTS to point to the directory that contains the CA certificate and any intermediate certificates in the chain.
Command files (or scripts) can be invoked when certain events occur. The command files are passed up to 8 parameters in the following format:
• Parameter_name=parameter_value
• Possible parameter names:
• LOCAL_ADDR
• LOCAL_PORT
• REMOTE_ADDR
• REMOTE_PORT
• SELECTOR_INDEX
• IPSEC_MODE
• UPPER_LAYER_PROTOCOL
• INTERNAL_ADDR4
• APPLICATION_VERSION
• OLD_SRC
• OLD_DST
• NEW_SRC
• NEW_DST
• INTERNAL_ADDR
• INTERNAL_DNS4
• INTERNAL_WINS4
• INTERNAL_DHCP4
• INTERNAL_ADDR6
• INTERNAL_DNS6
• INTERNAL_DHCP6
• LOCAL_NET_ADDR
• LOCAL_NET_PREFIXLEN
• LOCAL_NET_PORT
• REMOTE_NET_ADDR
• REMOTE_NET_PREFIXLEN
• REMOTE_NET_PORT
See “scripts” under “Directive details” for more information about which parameters can be used with which scripts.
The MultiNet implementation of IKED has been modified so that it works with Racoon with more encryption keys than the typical IKED implementation would. Unfortunately, these changes will prevent it from working with other implementations of IKED in IKEv1 mode for some encryption methods. To disable this change define the following logical to No/False/0 before starting IKED:
$ DEFINE/SYSTEM MULTINET_RACOON2_IKEV1_MORE_DEFAULT_KEYLENS NO
The first step in troubleshooting is to start IKED with “-D7”. If possible, this should be done on both sides of the connection because one side may provide more useful information than the other as to why the security associations could not be negotiated. Potential causes of problems are:
• Identification parameters (FQDN and IPADDR)
• Authentication (pre-shared key or certificate)
• IPSec requirements (requested combinations of ESP and AH, encryption and hash algorithms.)
For IKEv1 there may be a set of lines similar to:
2010-03-24 09:34:24 [DEBUG]:
IPSEC_DOI.C;23:372: Compared: DB:Peer
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:373: (lifetime = 28800:600)
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:376: (lifebyte = 0:0)
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:382: enctype = 3DES-CBC:3DES-CBC
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:387: (encklen = 0:0)
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:389: hashtype = MD5:SHA1
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:394: authmethod = pre-shared
key:pre-shared key
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:399: dh_group = 1536-bit MODP
group:1536-bit MODP group
2010-03-24 09:34:24 [DEBUG]: IPSEC_DOI.C;23:271: no suitable proposal found.
The above information points out the differences in the IKEv1 transport configurations between the two systems. The values compared are a combination of program defaults, values in the default configuration file, and values in the transport_ike configuration file, so all configuration files must be checked for the differences.
PSKGEN is a simple program to write a text string to a specified file such that there is no record information in the file and no extraneous carriage control characters. This makes the file compatible with a file that might be generated on a Unix system. Use PSKGEN to generate a pre-shared key file, if that is the authentication method you have chosen. To use the program, define a symbol
$ pskgen :== $multinet:pskgen
$ pskgen multinet:racoon2_psk.txt deadbeef
usage:
pskgen file_specification pre_shared_key_text
1. 1. copy configuration file templates and edit them
$ copy multinet:racoon2_conf.template
multinet:racoon2.conf
etc...
2. 2. start SPMD with the following command lines
$ spmd :== $multinet:spmd
$ spawn/nowait spmd -f multinet:racoon2.conf
3. 3. start IKED with the following command lines
$ iked :== $multinet:iked
$ iked -f multinet:racoon2.conf
Steps 2 and 3 above may be issued by hand in a terminal window. If you wish this to be started automatically with MultiNet, submit START_SPMD.COM as a batch job from MULTINET:LOCAL_INITIALIZATION.COM using the /after qualifier with a delta time such that SPMD/IKED startup takes place after MultiNet startup has completed. A future release of MultiNet will have this integrated into the MultiNet Master Server.
$ submit/noprint/after=”+0:1:00” multinet:start_spmd.com
The above line placed in MULTINET:LOCAL_INITIALIZATION.COM will submit to SYS$BATCH the procedure START_SPMD.COM for starting in 1 minute. You may need to adjust the delta time depending on your system configuration. It may also be necessary to uncomment the wait command between the startup of spmd and iked in START_SPMD.COM.
(The following is copied from the doc directory in the Racoon2 distribution; some misspellings and grammatical errors have been corrected and some information has been changed to match the MultiNet implementation.)
The iked of Racoon2 supports Configuration Payload in IKEv2 protocol. This section describes how to use it with iked.
Introduction
The Configuration Payload (CP) is used to exchange configuration information between IKE peers. There are several kinds of information to be exchanged with CP in RFC4306. The current implementation however supports only the following pieces of information:
• INTERNAL_IP4_DNS
• INTERNAL_IP4_NBNS
• INTERNAL_IP4_DHCP
• APPLICATION_VERSION
• INTERNAL_IP6_DNS
• INTERNAL_IP6_NBNS
• INTERNAL_IP6_DHCP
The Configuration Payload has two types of exchange. One is request/reply and the other is set/ack. The current specification only defines the request/reply usage. The iked support only request/reply exchange accordingly.
How iked works
The iked of an initiator side sends a request to the responder and it receives the reply. Then it parses the reply and validates. The iked exports the information from the Configuration Payload as environment variables and calls the scripts in the configuration files. An administrator can use the information to configure callback scripts.
The iked of a responder side receives a request from the initiator. It looks up the configuration and sends the reply. There is no callback interface which the responder calls in the process of the Configuration Payload.
Configuration
Initiator side
There are two directives to configure the Configuration Payload. One is "request" and the other is "script". They are in the "ikev2" directive in the "remote" directive.
The "request" is used to configure what information will be requested.
For example:
request { ip4_dns; application_version; };
Specifies that iked will request INTERNAL_IP4_DNS and APPLICATION_VERSION.
"script" is used to configure the callback scripts of the Configuration Payload exchange. To use the Configuration Payload, we should configure child_up and child_rekey. For example:
script {
child_up "multinet:child-up";
child_rekey "multinet:child-rekey";
};
In child-up and child-rekey, the information from the Configuration Payload is available as parameters to the command procedure containing the name and value of environment variables corresponding to the information. For example, the environment variable INTERNAL_DNS4 stores INTERNAL_IP4_DNS.
Responder side
There are directives to configure the Configuration Payload. The "provide" directive specifies the information that will be provided to the initiators. The directive is in the "ikev2" directive in the "remote" directive. For example:
provide {
dhcp { 192.168.39.10; };
application_version "Racoon2";
};
It specifies that the iked can provide "192.168.39.10" as an INTERNAL_IP4_DNS and "Racoon2" as an APPLICATION_VERSION.
Configuration Syntax
This portion of the document describes the syntax of the configuration of racoon2.
The syntax of the racoon2 configuration is not compatible with the syntax of old racoon. Note that this syntax might be changed in the future because racoon2 is still under development.
Structure
There are ten main directives in the configuration. Details are described at "Directives details".
• setval - It defines a constant string value which is unique in the whole configuration file.
• default - It defines default values.
• interface - It defines interfaces of each protocol.
• resolver - It defines the resolver.
• remote - It defines parameters for the remote KMP peer.
• selector - It defines parameters of a selector.
• policy - It defines a behavior when a packet is matched to a selector.
• ipsec - It defines a SA or a SA bundle.
• sa - It defines parameters of a SA.
• addresspool - It defines the address ranges for address pool.
The following picture shows how each directive relates to the others.
setval default interface resolver
+---(selector_index)--- remote
| ^
| |
| (remote_index) +-(sa_index)->
sa
v | |
selector -+ | +-(ipsec_index)-> ipsec
-+-(sa_index)-> sa
| | |
selector -+-(policy_index)-> policy -+-(ipsec_index)-> ipsec
---(sa_index)-> sa
| |
selector -+ +-(ipsec_index)-> ipsec ...
: :
Limitation of string
A string consists of the following characters:
0x30-0x39 0-9
0x41-0x5a A-Z
0x61-0x7a a-z
0x25 %
0x2a *
0x2d -
0x2e .
0x2f /
0x3a :
0x3f ?
0x40 @
0x5f _
A non-reserved string must be enclosed by double-quotations (" : 0x22).
When characters are closed by double-quotations, it is distinguished as just a string.
An index, selector_index for example, should consist of alpha-numeric characters (0-9 a-z A-Z). An index is not required to be enclosed by ". An IP address and a port number are not required to be enclosed by ".
Representation of IP addresses
An IPv4 address must consist of numeric characters (0-9) and periods (.).
e.g. 203.178.141.194
An IPv6 address must consist of hexadecimal-digit (0-9 a-f A-F), colons (:) and a percentage-mark (%) if necessary.
e.g. 2001:200:0:8002:203:47ff:fea5:3085
When a port number is required, the string "port" must follow an IP address string, and must be followed by a port number or a service name defined by the platform generally defined by /etc/services. The string "any" means that it will match with all port numbers.
e.g.
2001::1 port 80
203.178.141.194 port any
A network prefix is represented by a number delimited by a slash (/).
e.g. ::1/0
A range of addresses is represented by IP addresses delimited by a hyphen (-). NOTE THAT IT IS NOT IMPLEMENTED YET.
e.g. 10.0.0.0-10.1.255.255
Some reserved strings can be used.
• MY_IP - all of IP addresses assigned to the interfaces.
• MY_IPV6 - all of IPv6 addresses assigned to the interfaces.
• MY_IPV6_GLOBAL - all of IPv6 global addresses assigned to the interfaces.
• MY_IPV6_LINKLOCAL - all of IPv6 link-local addresses assigned to the interfaces.
• MY_IPV4 - all of IPv4 addresses assigned to the interfaces.
An interface name can be specified with a percentage-mark (%) followed by the interface name.
e.g. MY_IPV6%fxp0
The following strings will be implemented.
IP_ANY means ::0 and 0.0.0.0.
Representation of bytes
The following directives are followed by a numeric byte amount specification as its parameter.
• nonce_size
• max_pad_len
• max_retry_to_send
• kmp_sa_lifetime_byte
• ipsec_sa_lifetime_byte
The following units can be used.
• B
• Byte
• Bytes
• KB
• MB
• GB
Representation of time
The following directives are followed by a numeric time data.
• interval_to_send
• times_per_send
• kmp_sa_lifetime_time
• kmp_sa_nego_time_limit
• kmp_sa_grace_period
• ipsec_sa_nego_time_limit
• ipsec_sa_lifetime_time
• dpd_delay
• dpd_retry
The following units can be used.
• infinite
• sec
• secs
• second
• seconds
• min
• mins
• minute
• minutes
• hour
• hours
• day
• days
• 0(zero) means infinite.
Cryptographic algorithm and its representation
The following directives define an algorithm type.
• kmp_enc_alg
• esp_enc_alg
• esp_auth_alg
• ah_auth_alg
All of them are sent as a proposal, and a receiver evaluates the proposal with logical OR.
They can define a size of a key and a key if needed.
(algorithm name)[,(key length)[,(key)]]
(key) is hexadecimal-digits or string. A string of hexadecimal-digits must start with (0x).
e.g. 0x0123456789abcdef
In the string case, it must be closed by (").
Note that some algorithms specify the length of the key.
If you do not specify size of key, you can define like below:
(algorithm name),,(key)
If you need to specify multiple algorithms, defining an algorithm list for example, you can define it by using (;) as delimiter.
e.g.
kmp_enc_alg { aes192_cbc,,0x1234; aes192_cbc; 3des_cbc; };
The following lists cryptographic functions and algorithm names. Note that some algorithms are not implemented.
kmp_enc_alg directive and esp_enc_alg directive can have one of the following algorithm types.
• des_cbc_iv64
• des_cbc
• 3des_cbc
• rc5_cbc
• idea_cbc
• cast128_cbc
• blowfish_cbc
• 3idea_cbc
• des_cbc_iv32
• rc4_cbc
• null_enc
• rijndael_cbc
• aes128_cbc
• aes192_cbc
• aes256_cbc
• twofish_cbc
kmp_hash_alg directive can have one of the following algorithm types.
• md5
• sha1
• tiger
• sha2_256
• sha2_384
• sha2_512
In case of IKEv2, kmp_hash_alg directive is used to specify an integrity check (MAC) algorithm for IKE_SA communication, and the following algorithm types are accepted.
• hmac_md5
• hmac_sha1
• sha2_256
• sha2_384
• sha2_512
• aes_xcbc
• aes_cmac
• kmp_prf_alg directive can have one of the following algorithm types.
• hmac_md5
• hmac_sha1
• hmac_sha2_256
• hmac_sha2_384
• hmac_sha2_512
• aes_xcbc
• aes_cmac
• des_mac
• kpdk_md5
In case of IKEv1, kmp_prf_alg directive is not used. Instead, HMAC version of hash algorithm specified by kmp_hash_alg is used.
kmp_dh_group directive can have the group number or one of the following algorithm types.
• 1 modp768
• 2 modp1024
• 3 ec2n155
• 4 ec2n185
• 5 modp1536
• 14 modp2048
• 15 modp3072
• 16 modp4096
• 17 modp6144
• 18 modp8192
kmp_auth_method directive can have one of the following algorithm types.
• psk
• dss
• rsasig
• rsaenc
• rsarev
• gssapi_krb
esp_auth_alg and ah_auth_alg directive can have one of the following algorithm types.
• hmac_md5
• hmac_sha1
• aes_xcbc
• hmac_sha2_256
• hmac_sha2_384
• hmac_sha2_512
• kpdk_md5
• non_auth
ipcomp_alg directive can have one of the following algorithm types.
oui
deflate
lzs
Variable substitution
Environment variables can be referred from configuration files. The form is like $[environment variable].
e.g. $[HOME]
The C getenv routine is used to determine the value of the variable. You can also define variables by using setval directives. They are evaluated at once after all configuration files are read. When there is a duplicate string, it fails and stops evaluation of the configuration file.
To define a variable, a variable name must be followed by a string:
(string) (value) ;
The string must begin with a capital alphabet, followed by alpha-numeric capital characters. Alpha-numeric capital characters are:
0x30-0x39 0-9
0x41-0x5a A-Z
0x5f _
To refer the variable, the form is like ${string}.
e.g. ${HISNAME}
setval can have a environment variable referred by $[variable] as its parameter.
Comments
When (# 0x23) is found, all characters from it to a new line are ignored.
Directives details
• A directive consists of a string, a value and ";"(semi-colon) e.g.
string value ;
Values can be enclosed by "{" and "}" like
directive {
value ;
value ;
:
};
A value might be a directive recursively.
Values enclosed with ({) and (}) must also end with a semi-colon(;). The word is case-sensitive. The following lists the syntax of each directive.
include
include (file) ;
The parser includes (file). Note that variables defined by setval are not allowed here. Environment variables can be used.
setval
setval { (definitions) } ;
It defines a constant string value which is unique in the whole configuration file. It will be basically expanded after the whole configuration files are loaded. See Variable substitution for detail.
default
default { (directives) } ;
It defines default values. Each directive can be included. Default values are overwritten by each specific value.
interface
interface { (directives) } ;
It defines interfaces of each protocol.
Sub-directives are:
ike (address) [port (port)] ;
It defines port numbers which iked uses.
spmd (address) [port (port)] ;
Defines port numbers by which spmd makes communication with IKED. The loopback address (127.0.0.1) is recommended.
spmd_password (file) ;
Defines the file name which contains the password to be used for communication between spmd and iked.
application_bypass (on|off) ;
When on (default) KMP daemons bypass the IPsec policies.
When off, they rely on explicit policies but they can run encapsulated into IPsec tunnels for instance. Note the last configuration can be unsafe when a KMP uses a non-privileged port.
resolver
resolver { (directives) } ;
It defines the spmd resolver proxy configuration. Sub-directives in the resolver directive are the followings.
resolver (on|off) ;
It controls the behavior of spmd as the resolver.
When the directive is on, the spmd behaves as a resolver.
Default is off.
nameserver (address) [port (port)] ;
It defines IP addresses of the upper DNS servers.
The port number can be defined if needed.
The default port number is 53.
dns_query (address) [port (port)] ;
It defines IP addresses to be listened to for DNS requests.
The port number can be defined if needed.
The default port number is 53.
remote
remote (remote_index) { (directives) } ;
It defines parameters for the remote KMP peer. remote_index is a string value to identify a remote directive.
A remote directive is referred from one or more policies by the remote_index.
A remote might refer to the selector directive with the selector_index.
Sub-directives in the remote directive are the followings.
ikev1 { (directives) } ;
It defines the IKEv1 configuration.
ikev2 { (directives) } ;
It defines the IKEv2 configuration.
acceptable_kmp (ikev1|ikev2) ;
It defines key management protocols to be used.
The list defines the KMPs whom the responder allows to accept.
The first protocol in the list defines the mode that the initiator uses.
selector_index (selector_index) ;
IT IS NOT IMPLEMENTED YET.
It has a selector_index to be used in the road warrior case of the responder.
The following sub directives are for each key management protocol.
logmode (normal|debug) ;
IT IS NOT IMPLEMENTED YET.
It defines the logging mode.
The default is normal.
logfile (file) ;
IT IS NOT IMPLEMENTED YET.
It defines the logfile.
When the log file is defined here, the log still dumps to the system log or the log file specified by the parameter of each program.
passive (on|off) ;
It controls the behavior of the daemon. When this directive is on, the daemon acts as responder only.
The default is off.
peers_ipaddr (address) [port (port)];
It defines the IP addresses of the peer. The port number may be specified if needed. It can be used as the first search key to match with the IKE initial packet from initiator. Omitting this field or writing it as IP_RW requires default directive to handle IKE initial packets.
verify_id (on|off) ;
IT IS NOT TESTED YET.
Works only for the responder (the initiator has to configure its peer to authenticate it).
verify_pubkey (on|off) ;
IT IS NOT TESTED YET.
send_cert (on|off) ;
IT IS NOT TESTED YET.
send_cert_req (on|off) ;
IT IS NOT TESTED YET.
nonce_size (number) ;
IT IS NOT TESTED YET.
initial_contact (on|off) ;
IT IS NOT TESTED YET.
support_proxy (on|off) ;
IT WILL BE DONE ANOTHER WAY.
It is enabled that the IP addresses delivered by the ID payloads in IKEv1 or the TS payloads in IKEv2 are used as the end point's IP addresses of the SAs in the transport mode case.
my_id (ipaddr|email|fqdn|keyid|x509_subject) (value) ;
They are valid in all KMP directives.
It defines identifiers for the local-side entity.
ipaddr (ip address)
IPv4 or IPv6 address
fqdn (FQDN)
Fully Qualified Domain Name
email (e-mail address)
E-Mail address
keyid ([file]|tag) (filename|data)
A binary data a.k.a KEY-ID.
Use a filename (default) or directly the data.
x509_subject (filename)
Subject Name in the certificate.
peers_id (ipaddr|email|fqdn|keyid|x509_subject) (value) ;
They are valid in all KMP directives.
It defines the identifiers for the remote-side entity.
send_peers_id (on|off) ;
It enables the initiator to send the peer's ID.
The default is off.
selector_check (obey|exact) ;
IT IS NOT IMPLEMENTED YET.
It is valid for the ikev2 directive.
It defines the way to compare the ID and the TS value.
obey
It means that the policy from the initiator will be installed.
It is same as "generate_policy on;" in the IKEv1 case.
exact
If there is no policy matching with the intiator's one, it is rejected.
The default is obey.
proposal_check (obey|strict|claim|exact) ;
IT IS NOT IMPLEMENTED YET.
They are valid for both directives of the ikev1 and ikev2.
It defines the way to compare the policies in the responder
side.
obey
It means that the initiator's policy will be used.
strict
It means that the initiator's policy will be used if the lifetime in the policy from the initiator is less than the responder's one, AND the PFS is required.
If it is not suitable, it is rejected.
claim
It is valid for the ikev1 directive. It means that the responder will use own policy if the specified value is smaller than peer's proposal, and sends a RESPONDER_LIFETIME notification.
exact
It means that the policy from the initiator exactly matches with the responder's one.
If it is not suitable, it is rejected.
The default is obey.
random_pad_content (on|off) ;
padlen_random (on|off) ;
max_padlen (number) ;
They are valid in all KMP directives.
They define the padding.
max_retry_to_send (number) ;
interval_to_send (number) ;
times_per_send (number) ;
They are valid in all KMP directives.
They define the retransmission timer.
kmp_sa_lifetime_time (number) ;
kmp_sa_lifetime_byte (number) ;
kmp_sa_nego_time_limit (number) ;
kmp_sa_grace_period (number) ;
ipsec_sa_nego_time_limit (number) ;
They are valid for both directives of the ikev1 and ikev2.
They define the lifetime.
kmp_enc_alg (algorithm) ;
kmp_hash_alg (algorithm) ;
kmp_prf_alg (algorithm) ;
kmp_dh_group (algorithm) ;
kmp_auth_method (algorithm) ;
They are valid for both directives of the ikev1 and ikev2.
They define the algorithms for each function.
(algorithm) is described at the cryptographic algorithm and its representation. For IKEv1, kmp_prf_alg directive is not used. Instead, HMAC version of hash algorithm specified by kmp_hash_alg is used as prf algorithm.
exchange_mode (main|aggressive|base|all) ;
IT IS NOT IMPLEMENTED YET.
It is valid for the ikev1 directive.
It defines the exchange modes to be used.
The list defines the modes that the responder is allowed to accept.
The first mode in the list defines the mode that the initiator uses.
my_gssapi_id (string) ;
IT IS NOT IMPLEMENTED YET.
It is valid for the ikev1 directive.
It defines the GSSAPI ID.
It will be replaced by the my_principal directive.
cookie_required (on|off);
It is valid for the ikev2 directive.
It controls whether the responder requires the cookie.
Default is off.
need_pfs (on|off) ;
It is valid for both directives of the ikev1 and ikev2.
It controls to enable PFS or not.
The daemon will send a KE payload in the phase 2 of IKEv1.
Default is off.
my_public_key (x509pem|pkcs12|ascii) (pubkey) (privkey)
IT IS NOT FULLY IMPLEMENTED YET.
It is valid for both directives of the ikev1 and ikev2.
It defines the file names contained both my public key and my private key.
The following string specifies the format of the file.
x509pem
X.509 PEM format
pkcs12
PKCS12 format
ascii
PGP ASCII ARMORED format
peers_public_key (x509pem|pkcs12|ascii) (pubkey)
IT IS NOT FULLY IMPLEMENTED YET.
It is valid for both directives of the ikev1 and ikev2.
It defines the file names contained both the peer's public key.
pre_shared_key (file)
It is valid for both directives of the ikev1 and ikev2.
It defines the file name contained the pre-shared key.
my_principal (principal-id)
It is valid for the kink directive.
It defines my principal identifier to be used.
(principal-id) is like "principal@realm".
peers_principal (principal-id)
It is valid for the kink directive.
It defines the peer's principal identifier.
mobility_role (agent|mobile|correspondent)
It is valid in all KMP directives.
It is used by mobile IPv6 daemons.
request { (config_request_list) };
(available with IKEv2 only)
Request Configuration Payload option to peer.
config_request_list is an arbitrary list of following:
dns;
ip4_dns;
ip6_dns;
dhcp;
ip4_dhcp;
ip6_dhcp;
application_version;
dns is equivalent to specifying both ip4_dns and
ip6_dns; dhcp is equivalent to specifying both
ip4_dhcp and ip6_dhcp;
provide { (provide_option_list) } ;
(available with IKEv2 only)
Provide Configuration Payload option to peer.
provide_option_list is a list of following options:
addresspool (addresspool_index) ;
dhcp (address) ;
dns (address) ;
application_version (string) ;
dpd (boolean) ;
(available with IKEv1 only)
This option (default on) enables negotiating RFC 3706
Dead Peer Detection.
For IKEv2, DPD (liveliness check) is always enabled.
dpd_delay (number) ;
(available with IKEv1 or IKEv2)
This option activates the DPD and sets the time (in seconds) allowed between two proof of life requests.
For IKEv1, the default value is 0, which disables DPD monitoring, but still negotiates DPD support. For IKEv2, the default value is 3600 (1 hour).
dpd_retry (number) ;
(available with IKEv1 only)
If dpd_delay is set, this sets the delay (in seconds) to wait for a proof of life before considering it failed and sending another request. The default value is 5.
For IKEv2, normal retransmission time is used instead.
dpd_maxfail (number) ;
(available with IKEv1 only)
If dpd_delay is set, this sets the maximum number of proofs of life to request before considering the peer dead.
The default value is 5.
For IKEv2, normal retransmission algorithm with max_retry_to_send is used instead.
script { (script_list) } ;
(available with IKEv1 or IKEv2)
Defines a list of hook scripts. script_list is a list of following items.
phase1_up (script_path) ;
phase1_down (script_path) ;
phase2_up (script_path) ;
phase2_down (script_path) ;
phase1_rekey (script_path) ;
phase2_rekey (script_path) ;
migration (script_path) ;
Also, ike_sa_up, ike_sa_down, ike_sa_rekey, child_up,
child_down, child_rekey are synonymous to phase1_up,
phase1_down, phase1_rekey, phase2_up, phase2_down,
phase2_rekey, respectively.
For IKEv1, only the phase1_up and phase1_down are effective. No other events are available.
Scripts' argv[1] is equivalent to the event name.
Parameters are passed using the environment variables.
For phase1_up and phase1_down, following environment variables are defined:
LOCAL_ADDR
LOCAL_PORT
REMOTE_ADDR
REMOTE_PORT
For phase2_up and phase2_down:
LOCAL_ADDR
REMOTE_ADDR
SELECTOR_INDEX
IPSEC_MODE
LOCAL_NET_ADDR
LOCAL_NET_PREFIXLEN
LOCAL_NET_PORT
REMOTE_NET_ADDR
REMOTE_NET_PREFIXLEN
REMOTE_NET_PORT
UPPER_LAYER_PROTOCOL (decimal number or any)
INTERNAL_ADDR (only if an address is leased to peer)
INTERNAL_ADDR4 (leased from peer)
INTERNAL_DNS4
INTERNAL_WINS4
INTERNAL_DHCP4
INTERNAL_ADDR6
INTERNAL_DNS6
INTERNAL_DHCP6
For migration:
OLD_SRC
OLD_DST
NEW_SRC
NEW_DST
selector
selector (selector_index) { (directives) } ;
It defines parameters of a selector.
selector_index is a string value to identical a selector directive.
A selector directive refers to the policy directive with the policy_index.
Sub-directives in the selector directive are the followings.
order (number) ;
IT IS NOT IMPLEMENTED YET.
It defines the evaluation order in the kernel.
It is not required to be unique.
direction (inbound|outbound);
It defines the direction of the packet.
src (address) [port (port)];
dst (address) [port (port)];
It defines an IP address to be matched with packets.
It can not be listed.
A port number can be defined if needed.
upper_layer_protocol (protocol) [(options)];
It defines the last upper layer protocol to be matched with packets.
any and strings in /etc/protocols can be used in (protocol).
(options) depends on the protocol.
for example, ipv6-icmp (type) (code)
next_header_including (protocol)[:(option)];
IT IS NOT IMPLEMENTED YET.
IT CAN DEFINE ONLY ONE PORT NUMBER CURRENTLY, NOT LISTED.
It defines upper layer protocols in the extension header chain to be matched with packets.
any and strings in /etc/protocols can be used in (protocol).
tagged (pf_tag_name);
It overloads at the bootstrap installation the previous selectors by a pf tag. The usual selectors are still taken into account by KMPs but not by the kernel.
Dynamic operations have to be done on pf rules, not on the SPD.
policy_index (policy_index) ;
It has policy_index to define a policy.
reqid (number);
It defines the request ID for SA sharing
(cf. unique ipsec_level).
It is used to support Mobile-IP.
policy
policy (policy_index) { (directives) } ;
It defines a behavior after a packet is matched to a selector.
policy_index is a string value to identical a policy directive.
A policy is referred from one or more selectors by the policy_index(es).
A policy refers to one or more ipsec directives.
The ipsec directives will evaluate in logical OR by a KMP daemon.
A policy may refer to a remote directive.
Sub-directives in the policy directive are the followings.
action (auto_ipsec|static_ipsec|discard|none) ;
It defines an action of the policy.
auto_ipsec
It means the policy needs a key management.
static_ipsec
IT IS NOT IMPLEMENTED.
discard
It means the policy discards packets.
none
It means the policy bypasses the IPsec stack.
install (on|off) ;
Default is on, it makes possible to only declare the policy.
remote_index
It has a remote_index.
ipsec_index
It has ipsec_index(es) to define proposals of IPsec.
It is valid when the action directive is auto_ipsec.
my_sa_ipaddr (address) ;
It defines an IP address of the end points of the SAs on my side. (address) is an IP address.
It must be defined when the action directive is static_ipsec or tunnel.
peers_sa_ipaddr (address) ;
It defines an IP address of the end points of the SAs on the peer's side. Write IP_RW to generate policy dynamically.
ipsec_level (unique|require|use) ;
use
NOT IMPLEMENTED
When there is no SA for the packet, the kernel sends an acquire for the SA to KMPs, and sends the packet.
require
When there is no SA for the packet, the kernel sends an acquire for the SA to KMPs, and discards the packet. This SA installed will be used from other policies.
unique
PARTIALLY IMPLEMENTED, NOT EXPECTED TO WORK
In addition to require directive, this SA will not be used from any other policy.
ipsec_mode (transport|tunnel) ;
It defines a IPsec mode.
ipsec
ipsec (ipsec_index) { (directives) } ;
It defines a SA or a SA bundle.
ipsec_index is a string value to identical a ipsec directive.
An ipsec directive refers to one or more sa directives with sa_index(es).
An ipsec directive is referred from the policy directive by the ipsec_index.
Sub-directives in the ipsec are the followings.
ipsec_sa_lifetime_time (number) ;
It defines a life time of the SA in time.
ipsec_sa_lifetime_byte (number) ;
It defines a life time of the SA in bytes.
ext_sequence (on|off) ;
It enables extended sequence number processing described in the 2401bis.
The default is off.
sa_index (sa_index) ;
It has sa_index(es) to define an SA bundle.
It can have three sa_indexes in maximum.
When you want to define multiple SAs as an SA bundle, note that the following patterns are only allowed.
AH
ESP
IPCOMP
AH_ESP
AH_IPCOMP
ESP_IPCOMP
AH_ESP_IPCOMP
sa
sa (sa_index) { (directives) } ;
It defines parameters of an SA.
sa_index is a string value to identical the sa directive.
A sa directive is referred from the ipsec directive by the sa_index.
Sub-directives in the sa are the followings.
sa_protocol (ah|esp|ipcomp) ;
It defines a protocol to be used.
esp_enc_alg (algorithm) ;
It defines encryption algorithms to be used.
It is valid when the sa_protocol is esp.
esp_auth_alg (algorithm) ;
It defines authentication algorithms to be used.
It is valid when the sa_protocol is esp.
ah_auth_alg (algorithm) ;
It defines authentication algorithms to be used.
It is valid when the sa_protocol is ah.
ipcomp_alg (algorithm) ;
It defines compression algorithms to be used.
It is valid when the sa_protocol is ipcomp.
spi (spi) ;
NOTE THAT IT MAY BE OBSOLETE.
It defines a SPI for a static SA.
addresspool
addresspool (addresspool_index) { (address_ranges) } ;
It defines address ranges to make available for remote host.
For the address range, the first and last IP addresses of the range should be specified, separated with a - (hyphen-minus), followed by a ; (semicolon):
(address) - (address) ;
Note: you should put spaces before and after the hyphen, or else it may be parsed as a part of address string.
Sample configuration
The sample configuration files below are intended to show some of the functionality available, and do not illustrate the complete configuration language.
racoon2.conf
# Edit racoon2_vals.conf for your
environment
include "multinet:racoon2_vals.conf";
# interface info
interface
{
ike {
MY_IP port 500;
};
#
# For VMS specify loopback address and port number.
#
spmd {
127.0.0.1 port 5500;
};
spmd_password "multinet:spmd.pwd";
};
# resolver info
resolver
{
resolver off;
# resolver on;
# nameserver {
# 192.168.0.3 port 53;
# };
# dns_query {
# 127.0.0.1 port 53;
# ::1 port 53;
# };
};
#
# This line includes default configuration file;
# Please don't touch this line (especially novice user);
#
include "multinet:racoon2_default.conf";
## Transport mode IKEv2 or IKEv1
include "multinet:transport_ike.conf";
racoon2_vals.conf
setval {
### Directory Settings ###
# Preshared key file directory : specify if you want to use preshared
# keys
PSKDIR "multinet:";
# Cert file directory : specify if you want to use certs
CERTDIR "SSL$CERTS:";
### ID Settings ###
# your FQDN : specify if you want to use FQDN as your ID
MY_FQDN "client.example.com";
# Peer's FQDN : specify if you want to use FQDN as peer's ID
PEERS_FQDN "server.example.com";
### Preshared Key Setting ###
# Preshared Key file name
# You can generate it by pskgen.
PRESHRD_KEY "psk2.txt";
### Certicate Setting ###
# Set following parameters if you use certificates in
# IKE negotiation and
#_SET_ 'kmp_auth_method { rsasig;};' in each remote{}
# section of tunnel_ike{_natt}.conf/transport_ike.conf
# files.
# For more information, please see USAGE.
#
# Your Public Key file name
MY_PUB_KEY "client.pem";
# Your Private Key file name
MY_PRI_KEY "client.key";
# Peer's Public Key file name
PEERS_PUB_KEY "server.pem";
### Transport Mode Settings ###
# Your IP Address
MY_IPADDRESS "192.168.0.1”;
# Peer's IP Address
PEERS_IPADDRESS "198.168.0.2";
### Configuration Payload Settings (for IKEv2)###
# IPv4 Address Pool For Assignment
CP_ADDRPL4_START "10.7.73.128";
CP_ADDRPL4_END "10.7.73.254";
# IPv6 Address Pool For Assignment
CP_ADDRPL6_START "fd01::1000";
CP_ADDRPL6_END "fd02::2000";
# DNS Server Address(es) (ex. "10.7.73.1; 10.7.73.2")
CP_DNS "10.7.73.1";
# DHCP Server Address(es)
CP_DHCP "10.7.73.1";
# Application Version String
CP_APPVER "Racoon2 iked"
### Scripts
## IKEv2
# IKESAUP_SCR "multinet:ikesa-up.com";
# IKESADOWN_SCR "multinet:ikesa-down.com";
# CHILDUP_SCR "multinet:child-up.com";
# CHILDOWN_SCR "multinet:child-down.com";
# IKESAREKEY_SCR "multinet:ikesa-rekey.com";
# CHILDREKEY_SCR "multinet:child-rekey.com";
# MIGRATION_SCR "multinet:migration.com";
## IKEv1
# PH1UP_SCR "multinet:ph1-up.com";
# PH1DOWN_SCR "multinet:ph1-down.com";
racoon2_default.conf
#
# default section
#
default
{
remote {
acceptable_kmp { ikev2; ikev1; };
ikev1 {
logmode normal;
kmp_sa_lifetime_time 600 sec;
kmp_sa_lifetime_byte infinite;
interval_to_send 10 sec;
times_per_send 1;
ipsec_sa_nego_time_limit 40 sec;
kmp_enc_alg { 3des_cbc; };
kmp_hash_alg { sha1; md5; };
kmp_dh_group { modp3072; modp2048; modp1024; modp1536;};
kmp_auth_method { psk; };
random_pad_content off;
};
ikev2 {
logmode normal;
kmp_sa_lifetime_time infinite;
kmp_sa_lifetime_byte infinite;
max_retry_to_send 3;
interval_to_send 10 sec;
times_per_send 1;
kmp_sa_nego_time_limit 60 sec;
ipsec_sa_nego_time_limit 40 sec;
kmp_enc_alg { 3des_cbc; };
kmp_prf_alg { hmac_md5; hmac_sha1; };
kmp_hash_alg { hmac_sha1; hmac_md5; };
kmp_dh_group { modp3072; modp2048; modp1024; };
kmp_auth_method { psk; };
random_pad_content on;
random_padlen on;
max_padlen 50 bytes;
};
};
policy {
ipsec_mode transport;
ipsec_level require;
};
ipsec {
ipsec_sa_lifetime_time infinite;
ipsec_sa_lifetime_byte infinite;
};
sa {
esp_enc_alg { 3des_cbc; };
esp_auth_alg { hmac_sha1; hmac_md5; };
};
};
ipsec ipsec_ah_esp {
ipsec_sa_lifetime_time 28800 sec;
sa_index { ah_01; esp_01; };
};
ipsec ipsec_esp {
ipsec_sa_lifetime_time 28800 sec;
sa_index esp_01;
};
sa ah_01 {
sa_protocol ah;
ah_auth_alg { hmac_sha1; hmac_md5; };
};
sa esp_01 {
sa_protocol esp;
esp_enc_alg { 3des_cbc; };
esp_auth_alg { hmac_sha1; hmac_md5; };
};
transport_ike.conf
# ike transport mode (esp/tcp)
remote ike_trans_remote {
acceptable_kmp { ikev2; ikev1;};
ikev2 {
# my_id fqdn "${MY_FQDN}";
my_id ipaddr "${MY_IPADDRESS}";
# peers_id fqdn "${PEERS_FQDN}";
peers_id ipaddr "${PEERS_IPADDRESS}";
peers_ipaddr "${PEERS_IPADDRESS}" port 500;
kmp_sa_nego_time_limit 600 sec;
# ipsec_sa_nego_time_limit 360 sec;
## Use Preshared Key
# kmp_auth_method { psk; };
# pre_shared_key "${PSKDIR}${PRESHRD_KEY}";
## Use Certificate
kmp_auth_method { rsasig; };
my_public_key x509pem "${CERTDIR}${MY_PUB_KEY}"
"${CERTDIR}${MY_PRI_KEY}";
peers_public_key x509pem "${CERTDIR}${PEERS_PUB_KEY}"
"";
send_peers_id on;
# script {
# phase1_up "${PH1UP_SCR}";
# phase1_down "${PH1DOWN_SCR}";
# };
};
ikev1 {
my_id ipaddr "${MY_IPADDRESS}";
peers_id ipaddr "${PEERS_IPADDRESS}";
# kmp_auth_method {psk; };
# pre_shared_key "${PSKDIR}${PRESHRD_KEY}";
kmp_auth_method { rsasig; };
my_public_key x509pem "${CERTDIR}${MY_PUB_KEY}"
"${CERTDIR}${MY_PRI_KEY}";
peers_public_key x509pem "${CERTDIR}${PEERS_PUB_KEY}"
"";
peers_ipaddr "${PEERS_IPADDRESS}" port 500;
nonce_size 16;
kmp_hash_alg {sha1; md5;};
# initial_contact on;
# script {
# phase1_up "${PH1UP_SCR}";
# phase1_down "${PH1DOWN_SCR}";
# };
};
selector_index ike_trans_sel_in;
};
selector ike_trans_sel_out {
direction outbound;
src "${MY_IPADDRESS}";
dst "${PEERS_IPADDRESS}";
upper_layer_protocol "tcp";
policy_index ike_trans_policy;
};
selector ike_trans_sel_in {
direction inbound;
dst "${MY_IPADDRESS}";
src "${PEERS_IPADDRESS}";
upper_layer_protocol "tcp";
policy_index ike_trans_policy;
};
policy ike_trans_policy {
action auto_ipsec;
remote_index ike_trans_remote;
ipsec_mode transport;
ipsec_index { ipsec_esp; };
ipsec_level require;
};