@@ -25,7 +25,7 @@ Gergely Kovacs

               5.6. callid_cache_limit (integer)

               5.7. certificate_cache_limit (integer)

               5.8. cainfo_path (string)

-              5.9. accept_pem_certs ([0|1])

+              5.9. accept_pem_certs (int)

         6. Functions

@@ -91,7 +91,7 @@ Chapter 1. Admin Guide

         5.6. callid_cache_limit (integer)

         5.7. certificate_cache_limit (integer)

         5.8. cainfo_path (string)

-        5.9. accept_pem_certs ([0|1])

+        5.9. accept_pem_certs (int)

    6. Functions

@@ -174,7 +174,7 @@ Chapter 1. Admin Guide

    5.6. callid_cache_limit (integer)

    5.7. certificate_cache_limit (integer)

    5.8. cainfo_path (string)

-   5.9. accept_pem_certs ([0|1])

+   5.9. accept_pem_certs (int)

 5.1. privatekey_path (string)

@@ -296,11 +296,12 @@ modparam("auth_identity","certificate_cache_limit",4096)

 modparam("auth_identity","cainfo_path","/etc/ssl/certs/ca-certificates.crt")

 ...

-5.9. accept_pem_certs ([0|1])

+5.9. accept_pem_certs (int)

    Note: this parameter is for verifier service.

    Enables the acquired certificate processing if it is in PEM format.

+   Value can be 0 or 1.

    This parameter is optional. The default value is "0".

deleted file mode 100644

@@ -1,629 +0,0 @@

-<?xml version='1.0'?>

-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"

-  "http://www.oasis-open.org/docbookid/id/g/4.5/docbookx.dtd">

-

-

-<refentry xml:id="module.auth_identity"

-          xmlns:xi="http://www.w3.org/2001/XInclude"

-          xmlns:serdoc="http://sip-router.org/xml/serdoc">

-  <refmeta>

-    <refentrytitle>auth_identity</refentrytitle>

-    <manvolnum>7</manvolnum>

-  </refmeta>

-  <refnamediv>

-    <refname>auth_identity</refname>

-    <refpurpose>Securely identify originator of SIP messages.</refpurpose>

-  </refnamediv>

-

-  <refsect1>

-    <title>Description</title>

-    <para>

-      The <command>auth_identity</command> SER module provides

-      functionalities for securely identifying originators of SIP

-      messages by implementing the mechanism described in RFC 4474

-      and known as SIP Identity framework.

-    </para>

-    <para>

-      The module provides two services:

-      The <emphasis>authorizer</emphasis> authorizes a message and adds

-      Identity and Identity-Info headers to forwarded requests.

-      The <emphasis>verifier</emphasis> verifies the identity of a

-      received message.

-    </para>

-    <para>

-      In order to use the <command>auth_identity</command> module you

-      have to provide a certificate. More information can be found in

-      the section

-      <serdoc:link linkend="module.auth_identity.certificates">Certificates

-      </serdoc:link> below.

-    </para>

-  </refsect1>

-

-  <refsect1 xml:id="module.auth_identity.functions">

-    <title>Functions</title>

-

-    <refsect2 xml:id="function.auth_add_identity">

-      <title>

-        <function>auth_add_identity</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>auth_add_identity()</function> function authorizes

-        a request by adding identity information to it.

-      </para>

-      <para>

-        It calculates a SHA1 hash over certain components of the message

-        and encrypts it using the private key given through the

-        <serdoc:modparam

-          module="auth_identity">privatekey_path</serdoc:modparam>

-        parameter. The resulting cyphertext is appended to the message

-        as the content of the Identity header field.

-      </para>

-      <para>

-        To allow the receiver to decypher the identity information, it adds

-        the URL where the receiver may find the certificate in the

-        Indentity-Info header field. This URL is set through the

-        <serdoc:modparam

-          module="auth_identity">certificate_url</serdoc:modparam>

-        parameter.

-      </para>

-      <para>

-        <emphasis>Note:</emphasis> After the function has been called,

-        the following header fields must not be modified:

-        From, To, Call-ID, CSeq, Date, Contact. Additionally, the

-        message body must remain unmodified, too.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="function.auth_date_proc">

-      <title>

-        <function>auth_date_proc</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>auth_date_proc()</function> checks the age of a

-        request to be authroized. If the time given in the Date header

-        field of the request differs by more than the amount of seconds

-        given by the

-        <serdoc:modparam module="auth_identity">msg_timeout</serdoc:modparam>

-        parameter, the function returns <literal>false</literal>. It also

-        returns <literal>false</literal> if the certificate used by the

-        authorizer has expired.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="function.vrfy_check_callid">

-      <title>

-        <function>vrfy_check_callid</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>vrfy_check_callid()</function> checks whether a

-        request for this call has been processed within the

-        time given by the

-        <serdoc:modparam

-          module="auth_identity">auth_validity_time</serdoc:modparam>

-        parameter.

-      </para>

-      <para>

-        The function generates a call identifier from the Call-ID and CSqe

-        header fields and the Tag parameter of the From header field and

-        compares it with the values stored in the Call-ID cache.

-      </para>

-      <para>

-        It returns <literal>false</literal> if the value is found and thus

-        the request is replayed or <literal>true</literal> otherwise.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="function.vrfy_check_certificate">

-      <title>

-        <function>vrfy_check_certificate</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>vrfy_check_certificate()</function> function

-        checks the downloaded certificate and returns <literal>true</literal>

-        if it is valid or <literal>false</literal> otherwise.

-      </para>

-      <para>

-        A certificate is considered valid if it has not yet expired and

-        if its subject is identical to the domain part of the URL.

-      </para>

-      <!-- XXX Er, which URL? -->

-      <para>

-        Before <function>vrfy_check_certificate()</function> can be called,

-        the function <function>vrfy_check_date()</function> must have been

-        called and returned <literal>true</literal>.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="function.vrfy_check_date">

-      <title>

-        <function>vrfy_check_date</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>vrfy_check_date()</function> function checks

-        the date of the request currently being processed. It returns

-        <literal>false</literal> if the time in the Date header field

-        of the request differs from the current system time by more than

-        the number of seconds given by the

-        <serdoc:modparam

-          module="auth_identity">auth_validity_time</serdoc:modparam>

-        parameter.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="function.vrfy_check_msgvalidity">

-      <title>

-        <function>vrfy_check_msgvalidity</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>vrfy_check_msgvalidity()</function> function

-        checks the integrity of the request currently being processed.

-      </para>

-      <para>

-        It does so by calculating a SHA1 hash over certain parts of the

-        message and comparing it with the hash value that results from

-        decrypting the content of the Identity header field using the

-        certificate previously retrieved using the

-        <function>vrfy_get_certificate()</function> function.

-      </para>

-      <para>

-        The function returns <literal>true</literal> if the two hashes

-        match.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="function.vrfy_get_certificate">

-      <title>

-        <function>vrfy_get_certificate</function>

-        ()

-      </title>

-      <para>

-        Allowed in request processing only.

-      </para>

-      <para>

-        The <function>vrfy_get_certificate()</function> tries to get

-        the certificate from the URL given in the Identity-Info header

-        field of the currently processed request.

-      </para>

-      <para>

-        It returns <literal>true</literal> if the certifcate was

-        successfully loaded in a format that the module can process or

-        <literal>false</literal> otherwise.

-      </para>

-    </refsect2>

-

-  </refsect1>

-

-

-  <refsect1 xml:id="module.auth_identity.parameters">

-    <title>Module Parameters</title>

-

-    <refsect2 xml:id="module.auth_identity.accept_pem_certs">

-      <title><parameter>accept_pem_certs</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>boolean</serdoc:paramtype>

-        <serdoc:paramdefault>no</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>accept_pem_certs</parameter> parameter defines,

-        whether the verifier should process certificates in PEM format.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.auth_validity_time">

-      <title><parameter>auth_validity_time</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>integer</serdoc:paramtype>

-        <serdoc:paramdefault>3600</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>auth_validity_time</parameter> parameter

-        sets the maximum age of a verified message.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.cainfo_path">

-      <title><parameter>cainfo_path</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>string</serdoc:paramtype>

-        <serdoc:paramdefault>""</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>cainfo_path</parameter> paramter contains the

-        path and name of a file that contains trusted certificates.

-      </para>

-      <para>

-        The file should contain one or more certificates in PEM format

-        concatenated together. It is necessary if the verifier should

-        accept self-signed certifcates.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.callid_cache_limit">

-      <title><parameter>callid_cache_limit</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>integer</serdoc:paramtype>

-        <serdoc:paramdefault>262144</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>callid_cache_limit</parameter> parameter

-        limits the number of entries in the Call-ID cache.

-      </para>

-      <para>

-        The Call-IDs of previously verified messages are stored in the

-        Call-ID cache for some time in order to recognize call

-        replay attacks. The cache uses shared memory. Each entry is

-        about 100 bytes in size.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.certificate_cache_limit">

-      <title><parameter>certificate_cache_limit</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>integer</serdoc:paramtype>

-        <serdoc:paramdefault>32768</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>certificate_cache_limit</parameter> parameter

-        limits the number of entries stored in the certificate cache.

-      </para>

-      <para>

-        Each retrieved certificate is placed in the certificate cache

-        to speed up processing should it be needed again.

-      </para>

-      <para>

-        The cahce uses shared memory. Each entry is approximately 600

-        bytes in size.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.certificate_path">

-      <title><parameter>certificate_path</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>string</serdoc:paramtype>

-        <serdoc:paramdefault>""</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>certificate_path</parameter> parameter must be

-        set to path and name of the file that contains the certificate

-        of the authentication service in PEM format.

-      </para>

-      <para>

-        The parameter is required for the authentication service to work.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.certificate_url">

-      <title><parameter>certificate_url</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>string</serdoc:paramtype>

-        <serdoc:paramdefault>""</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>certificate_url</parameter> parameter must be

-        set to the URL where a verifier can retrieve the certificate.

-        The URL will be stored in the Identity-Info header of any

-        authorized request.

-      </para>

-      <para>

-        The certificate must be available at the given URL in DER

-        format.

-      </para>

-      <para>

-        The parameter is required for the authentication service to work.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.msg_timeout">

-      <title><parameter>msg_timeout</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>int</serdoc:paramtype>

-        <serdoc:paramdefault>600</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>msg_timeout</parameter> parameter contains the

-        maximum age of a request to be authorized in seconds.

-      </para>

-      <para>

-        The authorizer will compare the time given in the Date header field

-        of the request with its own current time.

-      </para>

-    </refsect2>

-

-    <refsect2 xml:id="module.auth_identity.privatekey_path">

-      <title><parameter>privatekey_path</parameter></title>

-      <serdoc:paraminfo>

-        <serdoc:paramtype>string</serdoc:paramtype>

-        <serdoc:paramdefault>""</serdoc:paramdefault>

-      </serdoc:paraminfo>

-      <para>

-        The <parameter>privatekey_path</parameter> must be set to the paht

-        and name of the file that contains the private key of the

-        authentication service in PEM format.

-      </para>

-      <para>

-        The parameter is required for the authentication service to work.

-      </para>

-    </refsect2>

-

-  </refsect1>

-

-  <refsect1 id="modules.auth_identity.examples">

-    <title>Examples</title>

-    <para>

-      The <emphasis>authentifier</emphasis> is typically included in the

-      part of the routing

-      logic that sends a request to a foreign domain. In the

-      <filename>ser-oob.cfg</filename> configuration, this is the

-      <varname>route[OUTBOUND]</varname>. With an authentifier included,

-      it looks like this:

-    </para>

-    <programlisting><![CDATA[

-route[OUTBOUND]

-{

-	if ($f.did && !$t.did) {

-		# Authentication service

-		if (method=="INVITE" || method=="OPTION") {

-			# Identity and Identity-info headers must not exist

-			if (@identity) {

-				sl_reply("403", "Invalid Identity header");

-				drop;

-			}

-			if (@identity_info) {

-				sl_reply("403", "Invalid Identity-info header");

-				drop;

-			}

-

-			if (!auth_date_proc()) {

-				sl_reply("403", "Invalid Date value");

-				drop;

-			}

-

-			if (!auth_add_identity()) {

-				sl_reply("480", "Authentication error");

-				drop;

-			}

-		}

-		route(FORWARD);

-	}

-}

-]]></programlisting>

-    <para>

-      The <emphasis>verifier</emphasis> should be run after you discovered

-      that a request originates from a foreign domain (for your own domains,

-      you should be doing digest authentication instead).

-    </para>

-    <para>

-      While you should reject any request that does contain an Identity

-      header but does not verify, it is up to your local policy, what to

-      do with messages that do not contain an Identity header at all.

-      You could reject them or divert them to voice mail or any of a number

-      of other options.

-    </para>

-    <para>

-      The following config snippet rejects any message that does not have

-      an Identity header.

-    </para>

-    <programlisting><![CDATA[

-	if (method=="INVITE" || method=="OPTIONS") {

-		if (!@identity) {

-			sl_reply("428", "Use Identity Header");

-			drop;

-		}

-		if (!@identity_info) {

-			sl_reply("436", "Bad Identity-Info");

-			drop;

-		}

-

-		if (!vrfy_check_date()) {

-			sl_reply("403", "Outdated Date header value");

-			drop;

-		}

-

-		if (!vrfy_get_certificate()) {

-			sl_reply("436", "Bad Identity-Info");

-			drop;

-		}

-

-		if (!vrfy_check_certificate()) {

-			sl_reply("437", "Unsupported Certificate");

-			drop;

-		}

-

-		if (!vrfy_check_msgvalidity()) {

-			sl_reply("438", "Invalid Identity Header");

-			drop;

-		}

-

-		if (!vrfy_check_callid()) {

-			sl_reply("403", "Message is replayed");

-			drop;

-		}

-	}

-]]></programlisting>

-  </refsect1>

-

-  <refsect1 id="mdoule.auth_identity.how-it-works">

-    <title>The SIP Identity Mechanism</title>

-    <para>

-      The SIP Identity Mechanism is defined in RFC 4474 "Enhancements for

-      Authenticated Identity Management in the Session Initiation Protocol

-      (SIP)". Its main purpose is to affirm the identity of the originator

-      of a request as stated in the From header field of the request.

-      While basic SIP provides a mechanism for a user agent to proof its

-      authenticity to the proxy serving the domain of the address used

-      by the user agent, no such mechanism exists to proof the authenticity

-      to other proxies or end points. The SIP Identity Mechanism mends this

-      oversight.

-    </para>

-    <para>

-      The mechanism allows a proxy to cryptographically sign a message as

-      authentic before sending it to another proxy. It does so after

-      making sure the sender actually is who he claims and is allowed to

-      use the address in the context of the message.

-    </para>

-    <para>

-      If the proxy is satisfied, it creates two header fields: Identity and

-      Identity-Info. The Identity header field contains a signed hash over

-      the following components of the message:

-    </para>

-    <itemizedlist>

-      <listitem>

-        the address given in the From header field,

-      </listitem>

-      <listitem>

-        the address given in the To header field,

-      </listitem>

-      <listitem>

-        the Call-ID,

-      </listitem>

-      <listitem>

-        the content of the CSeq header field,

-      </listitem>

-      <listitem>

-        the content of the Date header field,

-      </listitem>

-      <listitem>

-        the address given in the Contact header field if present, and

-      </listitem>

-      <listitem>

-        the body of the message.

-      </listitem>

-    </itemizedlist>

-    <para>

-      The hash is signed with a certificate for the domain. A URL pointing

-      to a place where an interested party can download a copy of the

-      certificate is placed into the Identity-Info header field.

-    </para>

-    <para>

-      If the message arrives at a proxy or user agent that wishes to verify

-      the authenticity, this device downloads the certificate and itself

-      forms the hash over the above components. If both hashes match, the

-      message has been authenticated by the proxy of the domain of the

-      certificate and has not been tempered with on the way.

-    </para>

-  </refsect1>

-

-  <refsect1 id="modules.auth_identity.credentials">

-    <title>Certificates</title>

-    <para>

-      In order to use the <command>auth_identity</command> module, you need a

-      certificate for your domain. There is two options, how to get one: you

-      buy one from a certification authority or you create your own

-      certification authority and use a self-signed certificate.  If you plan

-      to provide real  inter-domain calls for your domain, you should pick the

-      first option. Although it is more expensive, it guarantees proper

-      interaction between domains.

-    </para>

-    <para>

-      Either way, you will end up with a private key and a certificate which

-      includes the public key for that private key. You can use the same key

-      and certificate as for the TLS encrypted SIP transport. Because of

-      this, details on the process of acquiring them can be found in 

-      <serdoc:module>tls</serdoc:module>.

-    </para>

-    <para>

-      Once you have the certificate and private key, you set the module

-      parameter

-      <serdoc:modparam module="auth_identity">certificate_path</serdoc:modparam>

-      to point to the file containing the certificate and

-      <serdoc:modparam module="auth_identity">privatekey_path</serdoc:modparam>

-      to point to the file with the private key.

-    </para>

-    <para>

-      Finally, you have to put a public version of your certificate onto

-      a web server somewhere. This version must be DER encoded and,

-      obviously, must not contain the private key. You can create this

-      by issuing

-    </para>

-    <programlisting><![CDATA[

-# openssl x509 -in your_certificate.crt -outform der -out your_certificate.der

-]]></programlisting>

-    <para>

-      You then place the DER encoded certificate into a publicly

-      available directory on your webserver and state the URL to the

-      file in the parameter

-      <serdoc:modparam module="auth_identity">certificate_url</serdoc:modparam>.

-    </para>

-  </refsect1>

-

-  <!--

-    Compilation sections only go into the Admin Guide since we assume

-    that if you read a manpage you already have installed the module.

-  --> 

-  <refsect1 role="admin-guide">

-    <title>Compilation</title>

-    <para>

-      This <command>auth_identity</command> module needs the following

-      headers and libraries:

-    </para>

-    <itemizedlist>

-      <listitem>

-        <emphasis>OpenSSL</emphasis> (version 0.9.8 or higher) for

-        cryptographic functions,

-      </listitem>

-      <listitem>

-        <emphasis>libcURL</emphasis> for HTTP, HTTPS functions.

-      </listitem>

-    </itemizedlist>

-    <para>

-      If you'd like to use the <emphasis>TLS</emphasis> module, too,

-      you will have to change <varname>LIB</varname> variable in the

-      Makefile to the value that is by default commented out.

-    </para>

-  </refsect1>

-

-  <refsect1>

-    <title>Known Limitations</title>

-    <para>

-      Both authorizer and verifier currently only support SIP requests

-      except for responses to CANCEL and REGISTER requests.

-    </para>

-    <para>

-      The verifier does not support the subjectAltName extension of

-      certificates.

-    </para>

-  </refsect1>

-

-  <refsect1 role="manpage">

-    <title>Authors</title>

-    <para>

-      Written by Gergely Kovacs and Martin Hoffmann.

-    </para>

-  </refsect1>

-

-  <refsect1 role="manpage">

-    <title>See Also</title>

-    <simplelist type="inline">

-      <member><serdoc:sbin>ser</serdoc:sbin></member>

-      <member><serdoc:file>ser.cfg</serdoc:file></member>

-    </simplelist>

-  </refsect1>

-

-</refentry>

-

-<!-- vim:sw=2 sta et sts=2 ai

-  -->

@@ -190,11 +190,11 @@ modparam("auth_identity","cainfo_path","/etc/ssl/certs/ca-certificates.crt")

 		</section>

 		<section id="accept_pem_certs">

-			<title><varname>accept_pem_certs</varname> ([0|1])</title>

+			<title><varname>accept_pem_certs</varname> (int)</title>

 			<para>Note: this parameter is for verifier service.</para>

 			<para>

 				Enables the acquired certificate processing if it is in PEM

-				format.

+				format. Value can be 0 or 1.

 			</para>

 			<para>

 				This parameter is optional. The default value is "0".

@@ -51,6 +51,8 @@ Tsvetomir Dimitrov

               3.6. ipsec_reuse_server_port (int)

               3.7. ipsec_spi_id_start (int)

               3.8. ipsec_spi_id_range (int)

+              3.9. ipsec_preferred_alg (string)

+              3.10. ipsec_preferred_ealg (string)

         4. Functions

@@ -68,9 +70,11 @@ Tsvetomir Dimitrov

    1.6. ipsec_reuse_server_port parameter usage

    1.7. ipsec_spi_id_start parameter usage

    1.8. ipsec_spi_id_range parameter usage

-   1.9. ipsec_create

-   1.10. ipsec_forward

-   1.11. ipsec_destroy

+   1.9. ipsec_preferred_alg parameter usage

+   1.10. ipsec_preferred_ealg parameter usage

+   1.11. ipsec_create

+   1.12. ipsec_forward

+   1.13. ipsec_destroy

 Chapter 1. Admin Guide

@@ -92,6 +96,8 @@ Chapter 1. Admin Guide

         3.6. ipsec_reuse_server_port (int)

         3.7. ipsec_spi_id_start (int)

         3.8. ipsec_spi_id_range (int)

+        3.9. ipsec_preferred_alg (string)

+        3.10. ipsec_preferred_ealg (string)

    4. Functions

@@ -130,6 +136,8 @@ Chapter 1. Admin Guide

    3.6. ipsec_reuse_server_port (int)

    3.7. ipsec_spi_id_start (int)

    3.8. ipsec_spi_id_range (int)

+   3.9. ipsec_preferred_alg (string)

+   3.10. ipsec_preferred_ealg (string)

 3.1. ipsec_listen_addr (string)

@@ -159,8 +167,7 @@ modparam("ims_ipsec_pcscf", "ipsec_listen_addr6", "")

 3.3. ipsec_client_port (int)

-   Start port number which will be bound for incoming (server) IPSec

-   traffic.

+   Port number which will be bound for incoming (server) IPSec traffic.

    Default value is 5062.

@@ -171,8 +178,7 @@ modparam("ims_ipsec_pcscf", "ipsec_client_port", 5062)

 3.4. ipsec_server_port (int)

-   Start port number which will be bound for incoming (server) IPSec

-   traffic.

+   Port number which will be bound for incoming (server) IPSec traffic.

    Default value is 5063.

@@ -183,11 +189,7 @@ modparam("ims_ipsec_pcscf", "ipsec_server_port", 5063)

 3.5. ipsec_max_connections (int)

-   Maximum IPSec connections for the process. E.g. if

-   ipsec_client_port=5100, ipsec_server_port=6100 and

-   ipsec_max_connections=10, all client ports between 5100 and 5109 and

-   all server ports between 6100 and 6109 will be used for maximum to 10

-   IPSec connections.

+   Maximum simultanious IPSec connections

    Default value is 2.

@@ -198,11 +200,10 @@ modparam("ims_ipsec_pcscf", "ipsec_max_connections", 10)

 3.6. ipsec_reuse_server_port (int)

-   Reuse (1) or not (0) the P-CSCF Server port for Re-registration for one

-   UA. When set to 0 - During Re-registration P-CSCF will distribute new

-   P-CSCF client and P-CSCF server ports. When set to 1 - During

-   Re-registration P-CSCF will reuse the old P-CSCF server port and will

-   distribute a new P-CSCF client port.

+   Reuse (1) or not (0) the P-CSCF IPSec information for Re-registration

+   for one UA. When set to 0 - During Re-registration P-CSCF will create

+   new IPSec tunnels. When set to 1 - During Re-registration P-CSCF will

+   reuse the old IPSec tunnels.

    Default value is 1.

@@ -238,6 +239,33 @@ modparam("ims_ipsec_pcscf", "ipsec_spi_id_start", 100)

 modparam("ims_ipsec_pcscf", "ipsec_spi_id_range", 1000)

 ...

+3.9. ipsec_preferred_alg (string)

+

+   A name of an authentication algorithm which the Proxy-CSCF will prefer

+   when creating IPSec tunnels.

+

+   Default value is empty string (null) - the last algorithm in the

+   Sec-Agree header will be used.

+

+   Example 1.9. ipsec_preferred_alg parameter usage

+...

+modparam("ims_ipsec_pcscf", "ipsec_preferred_alg", "hmac-sha-1-96")

+...

+

+3.10. ipsec_preferred_ealg (string)

+

+   A name of an encrytion algorithm which the Proxy-CSCF will prefer when

+   creating IPSec tunnels.

+

+   Default value is empty string (null) - the last algorithm in the

+   Sec-Agree header will be used. Note that the possibility of it being

+   the "null" algorithm is not insignificant.

+

+   Example 1.10. ipsec_preferred_ealg parameter usage

+...

+modparam("ims_ipsec_pcscf", "ipsec_preferred_ealg", "aes-cbc")

+...

+

 4. Functions

    4.1. ipsec_create(domain)

@@ -258,7 +286,7 @@ modparam("ims_ipsec_pcscf", "ipsec_spi_id_range", 1000)

        every registration. This is an optional parameter, default value -

        0.

-   Example 1.9. ipsec_create

+   Example 1.11. ipsec_create

 ...

 ipsec_create("location");

 # or

@@ -278,7 +306,7 @@ ipsec_create("location", "1");

        the memory. Useful when contact alias is disabled. This is an

        optional parameter, default value - 0.

-   Example 1.10. ipsec_forward

+   Example 1.12. ipsec_forward

 ...

 ipsec_forward("location");

 # or

@@ -293,7 +321,7 @@ ipsec_forward("location", "1");

      * domain - Logical domain within the registrar. If a database is used

        then this must be name of the table which stores the contacts.

-   Example 1.11. ipsec_destroy

+   Example 1.13. ipsec_destroy

 ...

 ipsec_destroy("location");

 ...

@@ -50,7 +50,6 @@

 #include "ipsec.h"

 #include "spi_gen.h"

-#include "port_gen.h"

 #include "cmd.h"

 #include "sec_agree.h"

@@ -351,57 +350,26 @@ static int update_contact_ipsec_params(ipsec_t* s, const struct sip_msg* m, ipse

     s->ik.len = ik.len;

     // Generate SPI

-    if((s->spi_pc = acquire_spi()) == 0) {

-        LM_ERR("Error generating client SPI for IPSEC tunnel creation\n");

-        shm_free(s->ck.s);

-        s->ck.s = NULL; s->ck.len = 0;

-        shm_free(s->ik.s);

-        s->ik.s = NULL; s->ik.len = 0;

-        return -1;

+    if(s_old) {

+        if(s_old->spi_pc && s_old->spi_ps && s_old->port_pc && s_old->port_ps) {

+            LM_INFO("Reusing IPSEC tunnel\n");

+            s->spi_pc = s_old->spi_pc;

+            s->spi_ps = s_old->spi_ps;

+            s->port_pc = s_old->port_pc;

+            s->port_ps = s_old->port_ps;

+            return 0;

+        }

     }

-    if((s->spi_ps = acquire_spi()) == 0) {

-        LM_ERR("Error generating server SPI for IPSEC tunnel creation\n");

+    if(acquire_spi(&s->spi_pc, &s->spi_ps, &s->port_pc, &s->port_ps) == 0) {

+        LM_ERR("Error generating client SPI for IPSEC tunnel creation\n");

         shm_free(s->ck.s);

         s->ck.s = NULL; s->ck.len = 0;

         shm_free(s->ik.s);

         s->ik.s = NULL; s->ik.len = 0;

-