SA Info Section

An SA Info Section is used to configure the parameters required to establish an IPsecSA with a given Peer.

Configuration Example

In our configuration example, we define the listen section as shown below:

# SA Info Section

sainfo anonymous

{

lifetime time 3600 seconds;

encryption_algorithm aes 256;

authentication_algorithm hmac_md5,hmac_sha1;

compression_algorithm deflate;

}

Defining an SA Info Section

An SA Info section can be defined using the local and remote ids to be negotiated immediately following the sainfo keyword. An id is specified using an address, subnet value and protocol or anonymous as shown below:

sainfo subnet 10.1.2.0/24 any anonymous

{

...

}

Semi Anonymous SA Info section that matches the local 10.1.2.0/24 subnet for any Peer.

remote anonymous

{

...

}

Fully Anonymous SA Info section that would match any local subnet for any Peer.

For a Client to negotiate an IPsec security association, racoon must first locate a SA Info section that matches the requested local private network id. By specifying Semi-Anonymous SA Info sections, an administrator can limit what networks a Peer can communicate with. If Extended Authentication is used, an ldap or system group database can be used to limit access to certain networks based on the user's group membership as shown below:

sainfo subnet 10.1.3.0/24 any anonymous group "vpn-admin"

{

...

}

Semi Anonymous SA Info section that matches the local 10.1.3.0/24 subnet for an XAuth Peer that authenticated using a user account with vpn-admin group membership.

Reference

sainfo (source_id | anonymous) (destination_id | anonymous) from idtype [string]] [group string] { 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

subnet address [/ prefix] [[port]] ul_proto

The idtype modifier allows you to specify the exact content of ID payload to be matched (source is the local end, destination is the remote end). 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 identical.

The anonymous keyword can be used to match any id.

The group keyword allows an xauth group membership check to be performed for this sainfo section. When the mode_cfg auth source is set to system or ldap, the xauth user is verified to be a member of the specified group before allowing a matching sa to be negotiated.

The following are valid statements:

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.
remoteid number;	Sainfos will only be used if their remoteid matches the ph1id of the remote section used for phase 1. Defaults to 0, which is also the default for ph1id.
encryption_algorithm algorithms;	des, 3des, des_iv64, des_iv32, rc5, rc4, idea, 3idea, cast128, blowfish, null_enc, twofish, rijndael, aes, camellia (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)

Racoon does not have a 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 are algorithms which will not be used. These algorithms are defined 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 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(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 algorithm you have specified.