Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current Restore this Version View Page History

« Previous Version 7 Next »

Target release6.8.0
Epic
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Feature Request
Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Document status
DRAFT
Document owner

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.  The feature helps provide inter-working between secure SIP and secure WebRTC 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

#TitleImportanceNotes
1SHALL support SIP with TLS (RFC5246) and use cases shall follow SIP TLS examples shown in RFC6216 (SIP Secure Call Flows)
2SHALL support SIP TLS with SSLv3 and TLSv1 security  
3SHALL support standard cipher suites, such as: TLS_RSA_WITH_AES_128_CBC_SHA
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  
5SHALL allow a configurable port for SIP TLS(through the Config Tool); the default port SHALL be 5061  
6SHALL provide certificate management capability. Customers will require a method to create, store and select certificates, as well as to export certificate to use on the remote endpoint.  This capability SHALL be built into (Config Tool?).  
    
7SIP TLS implementation SHALL be tested against a variety of endpoints and network equipment for accurate implementation. BN2020 gateway, Cisco Gateway, SIP registrar (such as OpenSIPS)
8SIP over TLS supported on by a single license keywork (TBD). This keyword enables TLS functionality on a per system basis.  
 Documentation Requirements TBD  
 COO Will need to be updated with changes to include OpenSSL into the product  
 Part numbers will need to be defined for SR140 with Security.
Add on part will need to be defined to add security to an existing SR140 deployment. 
  
    

User interaction and design

Questions

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

QuestionOutcome

Not Doing