sainfo ( source_id destination_id | source_id anonymous | anonymous
destination_id | anonymous ) [from idtype [string]] { statements }
defines the parameters of the IKE phase 2 (IPsec-SA establish-
ment). source_id and destination_id are constructed like:
address address [/ prefix] [[port]] ul_proto
or
subnet 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.
In case of longest prefix (selecting single host) address
instructs to send ID type of ADDRESS, while subnet instructs to
send ID type of SUBNET. Otherwise these instructions are identi-
cal.
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,
modp2048, modp3072, modp4096, modp6144, modp8192. Or you
can define 1, 2, 5, 14, 15, 16, 17, or 18 as the DH group
number.
lifetime time number timeunit;
define how long an IPsec-SA will be used, in timeunits.
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.
my_identifier idtype ...;
is obsolete. It does not make sense to specify an iden-
tifier in the phase 2.
racoon(8) does not have a list of security protocols to be nego-
tiated. The list of security protocols are passed by SPD in the
kernel. Therefore you have to define all of the potential algo-
rithms in the phase 2 proposals even if there are algorithms
which will not be used. These algorithms are define by using the
following three directives, with a 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(8) 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 exam-
ple, if des, 3des, hmac_md5, and hmac_sha1 are specified as algo-
rithms, we have four combinations for use with ESP, and two for
AH. Then, based on the SPD settings, racoon(8) 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 algo-
rithm you have specified.
encryption_algorithm algorithms;
des, 3des, des_iv64, des_iv32, rc5, rc4, idea, 3idea,
cast128, blowfish, null_enc, twofish, rijndael, aes (used
with ESP)
authentication_algorithm algorithms;
des, 3des, des_iv64, des_iv32, hmac_md5, hmac_sha1,
hmac_sha256, hmac_sha384, hmac_sha512, non_auth (used
with ESP authentication and AH)
compression_algorithm algorithms;
deflate (used with IPComp)