sainfo section ( Phase 2 )

Previous  Next

---

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)