Target release	6.8.0
Epic	BRKT-430 - Getting issue details... STATUS
Feature Request	BRKT-236 - Getting issue details... STATUS
Document status	FINAL
Document owner	John Shaheen

Goals

Implement support for SIP over TLS on the SR140
Method to secure the SIP signaling exchange, to protect headers, addresses and SDP
Method to protect SDES SRTP key exchange which occurs in the crypto attr of the SDP (without SIP TLS, SDES is unsecure)

Background and strategic fit

SIP TLS is also referred to as Secure SIP and represents a way to encrypt the SIP exchange.

SIP TLS is the method that VoIP networks use to secure signaling. Providing SIP TLS protects the SDES key exchange over public networks.

Assumptions

SIP TLS can be used with or without secure RTP

Information from Pablo DePaulis (Deactivated)

\\pysnas01.dialogic.com\Infofactory\MCPD Export Data\MCPD Program Information\HMP Generic\Planning\FRs\FRRDs\HMP TLS Requirements Document.doc

\\pysnas01\Infofactory\MCPD Export Data\MCPD Program Information\Protocols\Design Docs\SIP TLS.doc

\\pysnas01\Infofactory\MCPD Export Data\MCPD Program Information\Protocols\Design Docs\API Committee Proposal - SIP TLS.doc

The sources are more likely portable to any other RV implementation relatively easily… In fact it’s very clear we took the RV TLS examples and augmented them as required. The HMP interface resembles the RV interface a lot as you will see from the API committee document at a quick glance.

If you have CC access to our database (otherwise Brian O. will be able to provide), this is the subsystem build that contains it: \\pysnas02\INT_BLD\scm\subsystem_builds\iphost\5.0.1

Developer’s Config spec should be there…

I can walk you or anyone else thru the sources, to take you specifically where the files are (SIP Sigal subcomponent).

It might also be of interest in having a quick overview of the high-level components of the Iphost subsystem: \\pysnas01\Infofactory\MCPD Export Data\MCPD Program Information\Protocols\Training Docs\NJ

The IP CCLIB Overview is relatively short, and though very old it’s still relevant.

TLS requirements indicates TLS 1.0, i.e. RFC 2246 compliance:

\\pysnas01.dialogic.com\Infofactory\MCPD Export Data\MCPD Program Information\HMP Generic\Planning\FRs\FRRDs\HMP TLS Requirements Document.doc

That said the TLS support comes from RV stack… they support TLS v1.2 options, but it doesn’t look we have taken advantage of them. In fact:

http://www.dialogic.com/~/media/manuals/docs/globalcall_for_ip_hmp_v12.pdf

sip_tls_method indicates the version of SSL to use. Defined enumerations are: Dialogic® Global Call IP Technology Guide 679 TLS engine configuration information — SIP_TLS_ENGINE • ENUM_TLS_METHOD_TLS_V1 – use TLS ver. 1 (Default value)

if (ENUM_TLS_METHOD_TLS_V1 != pEngine->E_sip_tls_method)
   {
      pDbg->print (Dbg::M_SHM,Dbg::LEVEL_ERROR,0,__FILE__,__LINE__,
         "<< checkTLSEngineParams: invalid TLS method %d\n",pEngine->E_sip_tls_method);
      return IPERR_INVALID_TLS_PARAM;
   }

Information from Dan LoPresti (Deactivated)

I did find a few useful general topics on the links.

In our docs, we do also provide an overview and then get into the weeds on using it with out API

- Page 335 - http://www.dialogic.com/~/media/manuals/docs/globalcall_for_ip_hmp_v12.pdf

The security package for the SR140 will be an add-on component. This add-on package will contain the openssl library required by the Radvision SIP stack to provide security capabilities.

Security features for the SR140 will be enabled by a licensed keyword. This keyword may be installed as a standalone license to allow an existing system to enable security features. *Need to define keyword and allowed values. If the key does not exist, it shall default to 0 (disabled).

The config tool will be updated to detect if the security license is available. When enabled the config tool will display relevant fields pertaining to the configuration of the security options (TBD). The installation of a certificate will be a configuration option. If the user does not have a certificate, the config tool will provide a mechanism to generate a self-signed certificate.

The default port for SIP over TLS will be 5061. This port may configured by the end user.

Information on DMG and IMG Support

Both the IMG 1010 and the BND 2020 support SIP over TLS. Documentation is located at:

http://www.dialogic.com/webhelp/IMG1010/10.5.3/WebHelp/IMG.htm

http://www.dialogic.com/webhelp/BorderNet2020/2.2.0/WebHelp/default.htm

Requirements

#	Title	Notes
1	SHALL support SIP with TLS (RFC5246) and use cases shall follow SIP TLS examples shown in RFC6216 (SIP Secure Call Flows)
2	SHALL support SIP TLS with TLS v1.2, and older (SSLv3 and TLSv1)
3	SHALL support standard cipher suites, such as: TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_RC4_128_MD5.
4	SHALL allow SIP TLS to establish RTP media with G.711 or to establish T.38 SIP TLS SHALL be independent of media. It SHALL not be required to use SIP TLS to establish a secure media channel.
	Config Tool Requirements
5	SHALL allow a field to enable or disable the use of SIP over TLS.
6	SHALL allow a field to allow the end user to provide a configuration file for SIP over TLS. This configuration file will be used to config the required SIP over TLS parameters. Required parameters will be defined in a seperate TLS configuration document.	TLS configuration data.docx
7	If SIP over TLS is enabled and the configuration file can not be found, an error will be generated in the ECC log. When reading the SIP over TLS configuration file, the parsing of the parameters will be shown in the ECC log file.

10	SIP TLS implementation SHALL be tested against a variety of endpoints and network equipment for accurate implementation.	BN2020 gateway, Cisco Gateway. other Dialogic products.
	Licensing
20	SIP over TLS supported on by a single license keyword (Security). This keyword enables TLS functionality on a per system basis. To enabled security the system must have installed security licenses equal or greater than the number of fax channels installed. For example, if the customer has an 8 channel SR140 fax licenses and only 2 channels of security, the system will not support security features. If they are licensed for 8 or more security channels, security features will be available on the system. Add on part will need to be defined to add security to an existing SR140 deployment. This part will be added to the back office for normal order processing and will allow the end user to activate a security LAC via the current methods. The SR140 base feature license will not include Security support. Added support MUST require a separate add-on LAC for security.
	951-105-21 SR140-EVAL-Feature-Security (eDelivery) 951-105-22 SR140-NFR-1YR-Feature-Security (eDelivery) 951-105-23 SR140-2-Feature-Security (eDelivery) 951-105-24 SR140-4-Feature-Security (eDelivery) 951-105-25 SR140-8-Feature-Security (eDelivery) 951-105-26 SR140-12-Feature-Security (eDelivery) 951-105-27 SR140-24-Feature-Security (eDelivery) 951-105-28 SR140-30-Feature-Security (eDelivery) 951-105-29 SR140-48-Feature-Security (eDelivery) 951-105-50 SR140-60-Feature-Security (eDelivery) 951-105-51 SR140-DEV-1YR-Feature-Security (eDelivery)	BRKT-707
	Documentation Requirements TBD
50	COO Will need to be updated with changes to include OpenSSL into the product. Will be required for both Windows and Linux.
	Radvision Stack
60	The Ravision SIP stack will be updated to a version that support SIP over TLS v1.2. This update will be performed for the SIP portion of the stack only and will not impact the H.323 stack. Both the Windows and the Linux stack will be updated.

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome

Not Doing

Browser not supported