Alcatel-Lucent Enterprise Communication Solutions 2013...

Alcatel-Lucent Enterprise Communication Solutions

2013 Offers

Standard Offer

Chapter 15 Security

October 2013 Offer- Ed.01

Ref.: ENT_MLE_015926

ENT_MLE_015926 ed 01 Chapter 15: Security

2/75 Alcatel-Lucent Enterprise Communication Solutions October 2013 Offer

Copyright Alcatel-Lucent 2000-2013. All rights reserved.

Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.

Notice:

While reasonable effort is made to ensure that the information in this document is complete and accurate at the time of printing, we can not assume responsibility for any errors. Changes and/or corrections to the information contained in this document may be incorporated into future issues.

This document introduces the Alcatel-Lucent OpenTouch and OmniPCX Enterprise Communication Server, their products and features. All documents associated to this introduction cover most of the aspects for designing offers based on current manufacturers and business partner agreements. They include introductory explanations to position the offer in relation to client needs. References to in-depth documentation are indicated to direct you to product descriptions or product sites.

Who Should Use this Document?

As an introductory offer, this document can be used by Alcatel-Lucent vendors, clients, partners and associates involved with the implementation of Alcatel-Lucent systems.



Table of content

1 Global security view ____________________________________________________________ 6

1.1 The user-centric security blueprint ___________________________________________________ 6

1.2 Applying the security blueprint ______________________________________________________ 6

1.2.1 Perimeter security ________________________________________________________________________ 7 1.2.2 Network access control ____________________________________________________________________ 8 1.2.3 Identity management _____________________________________________________________________ 8 1.2.4 Application security _______________________________________________________________________ 8 1.2.5 Mobile security __________________________________________________________________________ 9 1.2.6 Security management _____________________________________________________________________ 9

2 PBX and applications security: core platforms ______________________________________ 11

2.1 Security features list overview _____________________________________________________ 11

2.2 Com server _____________________________________________________________________ 12

2.2.1 Linux OS advantages _____________________________________________________________________ 12 2.2.2 Linux: customized for the OmniPCX Enterprise ________________________________________________ 13 2.2.3 VLAN segmentation ______________________________________________________________________ 13 2.2.4 Defense actions _________________________________________________________________________ 13 2.2.5 Access controls (passwords, filters, etc.) _____________________________________________________ 14 2.2.6 Internal security _________________________________________________________________________ 16 2.2.7 Network time protocol ___________________________________________________________________ 17 2.2.8 Log and Syslog files ______________________________________________________________________ 17

2.3 Media gateway __________________________________________________________________ 18

2.3.1 Resistance against DoS attacks _____________________________________________________________ 18 2.3.2 Separation of TDM and IP traffic ____________________________________________________________ 18 2.3.3 Binaries signature check __________________________________________________________________ 20

2.4 Voice mail application ____________________________________________________________ 20

2.5 OmniVista 8770 _________________________________________________________________ 20

2.5.1 Password policy enforcement ______________________________________________________________ 20 2.5.2 Back up and disaster recovery process _______________________________________________________ 21 2.5.3 Sending e-mail __________________________________________________________________________ 21 2.5.4 PKI (public key infrastructure) ______________________________________________________________ 21

2.6 Alcatel-Lucent OmniTouch 8400 Instant Communications Suite ___________________________ 21

2.6.1 Authentication __________________________________________________________________________ 22 2.6.2 High availability _________________________________________________________________________ 22

2.7 IP terminals _____________________________________________________________________ 22

2.7.1 Business continuity ______________________________________________________________________ 22 2.7.2 Anti-ARP spoofing _______________________________________________________________________ 23 2.7.3 Anti-ARP cache poisoning _________________________________________________________________ 23 2.7.4 Protection against DHCP server intrusion _____________________________________________________ 23 2.7.5 Anti-MAC spoofing _______________________________________________________________________ 23 2.7.6 TFTP request check ______________________________________________________________________ 23 2.7.7 Connect message filtering _________________________________________________________________ 23 2.7.8 Verification of binaries ___________________________________________________________________ 23 2.7.9 MMI protections ________________________________________________________________________ 24 2.7.10 PC port and traffic isolation _____________________________________________________________ 24 2.7.11 802.1X ______________________________________________________________________________ 24



2.7.12 SIP/TLS and SRTP ______________________________________________________________________ 25

3 Network security _____________________________________________________________ 26

3.1 VoIP firewall THALES “TeoZ” (Alcatel-Lucent Applications Partner Program) ________________ 26

3.2 Reverse proxy Blue Coat (Alcatel-Lucent Applications Partner Program) ____________________ 27

3.3 OpenTouch Session Border Controller _______________________________________________ 29

3.3.1 Introduction ____________________________________________________________________________ 29 3.3.2 Features/Benefits _______________________________________________________________________ 29 3.3.3 Solutions _______________________________________________________________________________ 30 3.3.4 OpenTouch SBC Physical Description ________________________________________________________ 36 3.3.5 Architecture ____________________________________________________________________________ 37 3.3.6 OpenTouch SBC Functionality ______________________________________________________________ 37 3.3.7 OpenTouch SBC Non-Functionality Aspects ___________________________________________________ 47

4 Security of configuration and management ________________________________________ 55

4.1 Authentication __________________________________________________________________ 55

4.1.1 Communication server authentication _______________________________________________________ 55 4.1.2 OmniVista 8770 authentication ____________________________________________________________ 55 4.1.3 OmniTouch 8400 ICS authentication ________________________________________________________ 56

4.2 Securing management exchanges ___________________________________________________ 56

4.2.1 Secured SNMP __________________________________________________________________________ 56 4.2.2 Secured shell (SSH) ______________________________________________________________________ 56 4.2.3 Secured HTTP (HTTP over SSL) _____________________________________________________________ 57 4.2.4 Secured legacy remote management ________________________________________________________ 57

5 Communication security _______________________________________________________ 59

5.1 Protection against theft of service (Toll fraud) _________________________________________ 59

5.1.1 Transfer protection ______________________________________________________________________ 59 5.1.2 Forwarding protection ____________________________________________________________________ 59 5.1.3 Protection on internal phones _____________________________________________________________ 59 5.1.4 External call restriction ___________________________________________________________________ 59 5.1.5 Restricted access to a phone set ____________________________________________________________ 59 5.1.6 Out of service option _____________________________________________________________________ 60 5.1.7 Discrimination calendar for external calls ____________________________________________________ 60 5.1.8 DISA (direct inward system access) protection ________________________________________________ 60 5.1.9 Control ________________________________________________________________________________ 60 5.1.10 Calling line identification ________________________________________________________________ 60 5.1.11 Call monitoring feature _________________________________________________________________ 61

5.2 IP Touch security ________________________________________________________________ 61

5.2.1 Encryption architecture ___________________________________________________________________ 63 5.2.2 Security modules ________________________________________________________________________ 65 5.2.3 MGSec ________________________________________________________________________________ 68 5.2.4 Signaling and voice encryption on IP media gateway): SoftMSM __________________________________ 69 5.2.5 IP Touch security in an ABC network ________________________________________________________ 70 5.2.6 Encryption compatibilities _________________________________________________________________ 70 5.2.7 SIP/TLS support _________________________________________________________________________ 71

5.3 Verticals certification _____________________________________________________________ 73

5.3.1 Payment card industry data security standard _________________________________________________ 73 5.3.2 Health insurance portability and accountability ________________________________________________ 74

6 Antivirus software ____________________________________________________________ 75



6.1 Antivirus software and the OmniPCX Enterprise _______________________________________ 75

6.2 OmniVista 8770-specific recommendations for anti-virus ________________________________ 75



1 Global security view

Securing communications for all voice and data applications as well as employee mobility is the key to supporting new business models and enabling a trusted dynamic enterprise that competes effectively in today’s business environment. Security must become a positive enabler to drive business performance. To achieve this objective, enterprises must have a corporate-wide strategy — a security blueprint — that allows the enterprise to be open for business and, at the same time, provide a trusted environment. This requires a shift to a user-centric approach to security, delivered from within the network to protect networks, people, processes and knowledge.

1.1 The user-centric security blueprint A user-centric security blueprint can enable a powerful shift to a trusted, dynamic enterprise. At the same time, enterprises manage risk, protect private data, and maintain compliance.

With a security blueprint, enterprises can keep satisfying the demands of employees, business partners, and customers for always-on, always available voice and data applications, that can be accessed from anywhere and at any time.

The blueprint looks at security for the enterprise as being delivered from within the network to protect networks, people, processes and knowledge. If abiding by the blueprint, the enterprise benefits from:

• A network that is user-aware and provides security for voice, data and mobility, and enables compliance with policy enforcement and audit

• People securely collaborating across organizational boundaries, leveraging business-to-business relationships, Web 2.0, and cloud computing without security-imposed human productivity barriers

• Processes that are agile, automated and always secured

• Knowledge in the form of protected private data, as well as secured knowledge sharing

The user-centric security blueprint prescribes a global, corporate-wide security infrastructure that provides a consistent and corporate-wide application of security.

1.2 Applying the security blueprint If following a user centric security blueprint, enterprises are positioned to leverage new business models made possible by Web 2.0, cloud computing and mobile communications technology.

Applying this security blueprint for a trusted, dynamic enterprise, requires an end-to-end approach to security. Enterprises must move beyond looking at point solutions that address specific security requirements for one area of the enterprise, to integrated solutions that enable the user centric security blueprint. figure: User-centric security deployment offers a visual representation of the solution map that meets these objectives.

Deploying solutions complying with the user centric security blueprint starts with gaining an understanding of what perimeter security exists within the enterprise. Moving along the path laid out by the blueprint, the next step is to examine the need for network access control solutions to ensure that adequate controls are in place to allow a user and or a device onto the network. Fine grained controls may be required to enable users to access the network resources and applications they want access to, once they have been accepted onto the network.



Once the voice and data fabric are secured and appropriate fine grained controls are in place, the next consideration is to target directly specific applications that require extra special treatment. This is followed by solutions to protect the mobile user and mobile assets of the corporation, such as laptops.

1.2.1 Perimeter security

Choosing a perimeter security solution usually implies different choices according to the various types of enterprises. It is also greatly dependent on security strategy.

If an enterprise prefers to follow a best-of-breed approach to threat management - then separate solutions are required for firewall/VPN, anti-virus, anti-malware and web filtering. If an integrated approach to threat management is preferred, then a unified threat management and firewall solution is attractive.

If an enterprise has many independent branch offices, an integrated solution which includes routing functionality, referred to as a security router, is an approach to be considered.

In today’s network, a web application firewall is a must to protect web servers and web-facing applications. One overall consideration in controlling security operations costs is scalability and manageability of the perimeter solution chosen, especially for enterprises with many locations to protect.



1.2.2 Network access control

Network access control can be achieved by looking at several categories of solutions. Starting with IP address management that offers the ability to provide an address to devices connected to the network, followed by host integrity check solutions that ensure that it is safe to allow a device on the network, ending with role-based access control solutions.

Host integrity check solutions will determine if a device is configured in accordance with enterprise policy and that it contains no malware before the device is allowed onto the network. It is a must in any wireless environment where users connect devices to the network at will. Enterprises that have a stringent need to protect certain servers and applications or are in highly regulated industries, should consider role-based access control solutions to provide the required controls with audit. These solutions can be deployed without having to re-configure networks on a physical level to achieve security requirements.

1.2.3 Identity management

Identity management is essential to user-centric security and starts with an enterprise-wide password management platform and directory server farm. Many organizations today will consider the move to some form of strong authentication based on certificates coupled with two factor-identifications of end users and devices. Providing a rich set of interface and control points to the voice and data fabric of the enterprise is key to the deployment of an Authentication, Authorization and Accounting (AAA) infrastructure.

Of course, an enterprise-wide single sign-on capability is also important to provide an internal secured environment that remains enabling for employees. With the move to Web 2.0 and cloud computing the addition of a federated identity management capability may be necessary.

1.2.4 Application security

The deployment of new applications such as VoIP, the adoption of new business models leveraging Web 2.0 and the Cloud, and new compliance regulations create the need for security solutions that protect user activity with an understanding for the application being used by the end user.

With the deployment of VoIP, it is important that the existing enterprise security can ensure that the new virtualized perimeter defense and possibly encryption requirements for VoIP are met.

In the case of Web 2.0 and the Cloud, solutions that secure individual Web services and can act as a trusted intermediary with the Cloud are becoming a must have for protecting enterprises. Solutions ensuring that enterprises are compliant with regulation in the processing of monetary transactions and control the cost of being compliant are important to many enterprises.



1.2.4.1 Security enabling the reliability of IP telephony

Alcatel-Lucent is partnered with Thales, a major security player in the domain of Defense and Enterprises, in order to provide a high performance encryption solution responding to real time voice criteria (delay and commutation time).

The IP Touch security solution brings:

• Secure download of binaries and configuration files in IP Phones and IP Media gateways

• The integrity of call control signaling (ensuring that messages have not been modified)

• The capability to encrypt call control signaling and voice flows

The equipment concerned with encryption includes:

• The range of communications servers (IPAS, IPRS, IPCS) and passive communication servers (PCS)

• The Media Gateways IP range (Common Hardware or Crystal)

• The IP Touch range (Alcatel-Lucent 8 series)

• IP Desktop Softphone application (software emulation of Alcatel-Lucent IP Touch 4068 Phone set)

• OmniTouch 8600 MIC client (softphone)

• OmniTouch 8400 ICS servers (application servers and media servers)

IP Touch security is a commercial option of Alcatel-Lucent OmniPCX Enterprise Communication Server (both hardware and software).

1.2.5 Mobile security

Many enterprises today have employees that spend much of their working hours outside the enterprise perimeter using mobile computing devices such as laptops. Solutions for securing mobile laptops must address the concern of private information stored on them risking being lost or stolen and also address the need to be able to configure laptops at any time.

1.2.6 Security management

Security management requires a number of platform choices covering performance and event management, patch management, vulnerability detection and compliance management. Solutions deployed for performance and event management must be able to install in a global enterprise, collect a rich set of data from the voice and data fabric, and provide a robust event response and



escalation engine. Solutions for patch management must be able to integrate with enterprise platforms that manage mobility.



2 PBX and applications security: core platforms

Alcatel-Lucent provides mechanisms, tools and protocols to ensure a secure fully-fledged global solution.

In-depth defenses

Global security of the information system within a company is based on:

• An individualized perception of the hardening of each component of the system (networks, servers, Com Servers, media gateway…) supporting client applications

• Secure access to this system and filtering of the traffic going through the system (type of traffic expected, concepts of bandwidths allocated by reservation or by prioritization of the applications)

• Protection of the configuration of these elements (restricted access, definition of administrator rights)

• Protection of critical applications (confidentiality, integrity, availability)

In order to protect the core of the information system, company security is deployed on several levels. Each level, from the physical element to the deployed application, implements a specific function delaying access to confidential information for non-authorized parties.

The OmniPCX Enterprise products and solutions are part of the global Alcatel-Lucent security polices and best practices framework (security-by-default strategy).

2.1 Security features list overview

Authentication

• IPBX server management

o Local authentication database (password policy enforcement)

o Remote authentication (RADIUS)

• Client/device (IP Touch) network access

o IEEE 802.1X (MD5 and TLS)

Traffic filtering

• IPBX server

o Trusted hosts file

o TCP wrapper function

• Client/device (IP Touch)

o ARP spoofing protection

o PC port switch VLAN filtering

Encryption

• IPBX server configuration mode



o SSHv2 for secure sessions (Telnet, FTP, etc.)

o SSLv2/v3 for secure HTTP session

o SNMP v1/v2c/v3 for complete NMS integration

• Client/device (hardphone and softphone) confidentiality (signaling protocol and media)

o IPSEC and Secure RTP (AES 128 bits)

o SIP TLS and Secure RTP (AES 128 bits) for NOE/SIP

Integrity

• Media gateway and IP Touch binaries signatures

• System maintenance and access

o Dual port (hot standby mode)

o Local and remote logging (Syslog)

o Serial console port for local and remote (call back modem dialup) access

o Network time protocol (NTP) server and client for network-wide time synchronization

User authorization to communication services

• Call monitoring feature with OmniVista 8770 for a better protection against Toll fraud

• Internal Toll fraud protection by using class of services

• Definition of PIN codes for business or personal call

• Restricted access for transfer/forwarding barring categories against Toll fraud

• Secure access to direct inward system access (DISA) function

2.2 Com server

The operating system used by the Alcatel-Lucent OmniPCX Enterprise Communication Server is based on Linux (kernel 2.4.17).

Historically, the open nature of the Linux source code has allowed the Linux community to audit operating system development and solve potential security problems before they become actual problems on customer systems. Alcatel-Lucent has invested the time and effort to further harden the Linux operating system environment for OmniPCX Enterprise use.

2.2.1 Linux OS advantages

The advantages that make Linux one of the most stable and secure operating systems available as a free operating system include:

• A source code fully open in terms of kernel and utilities - there is no "security by obscurity"

• A large and active developer base that ensures constant security auditing of the source code

• The massive worldwide user base for Linux ensures that each aspect of Linux security is tested within a vast range of different computing environments on all kinds of hardware



• The on-going development of Linux ensures that it stays on the cutting edge of many Unix security developments

2.2.2 Linux: customized for the OmniPCX Enterprise

As part of Alcatel-Lucent hardening of the Linux operating system, all non-essential software has been removed from the Alcatel-Lucent customized version of the OS. The advantages include reducing:

• The provided distribution size (the Alcatel-Lucent package is 50 MB while the public version is 700 MB)

• The potential security risks imposed by the excess software

Although Alcatel-Lucent has eliminated over 85% of the standard Linux core distribution, several optional features remain within the Alcatel-Lucent distribution. Only those services that are vital for operation are enabled by default. For example telnet remains within the Alcatel-Lucent distribution of Linux, but is disabled by default because it is unsecured, and replaced by SSH. There are no Graphic User Interface (GUI) environments such as X11, KDE or Gnome.

There are no resource tools for remote file and print sharing available in the Alcatel-Lucent distribution. Features such as LPR, NFS and Samba (Microsoft compatible) are not present in any format.

2.2.3 VLAN segmentation

For the highest possible levels of security, Alcatel-Lucent strongly recommends segmentation between voice and data networks. In this way, strong security methodologies and perimeter controls can be used to ensure the integrity of both environments.

For Quality of Service, ease of management and security reasons; voice and data traffic should be logically separated. From a security perspective, separating traffic into differing Ethernet broadcast domains provides for better DoS resilience and allows for the establishment of strong boundary security practices.

In addition to the VLAN segmentation, and if information exchanges are necessary between the different logical networks, a security policy should be deployed to control the flows between VLANs using Access Control List. This security policy can be based on addresses end-users and IP flows used by these end-users or VLAN identities.

For more information about VLAN segmentation and descriptions about assignment, see module More Information - Additional IP Services - Automatic VLAN Assignment (AVA)

2.2.4 Defense actions

• Defenses against Denial-of-Service – DoS attacks

The Com Server is hardened to resist attacks by broadcast flooding. An internal defense mechanism allows for a minimum reservation of processor power to the primary function of the Com Server: Call Handling.

For each release, test campaigns are systematically carried out to address all categories of attack. Alcatel-Lucent Enterprise Solutions Division has implemented the set of security tools recommended by the Corporate Alcatel-Lucent Network Security Group to audit, test and harden the products, and track potential issues.

• Defenses against “erroneous data” attacks, tools (generating Teardrop)



Timeout, Land, Ping of Death) and Nessus suite are used to address the most famous denial of service (DoS) attacks. Part of the test campaign is also based on tools (built by companies like Codenomicom) for verifying the implementation and the resilience of protocols such as H323, SIP, etc. Regarding the storm packets or flooding attacks, various tools generating TCP flood, SYN, ACK, FIN, URG, RST, PSH-Ping flood, Echo Reply flood, Bad TTL flood, and broadcast storm are used.

All audit results are analyzed by the Alcatel-Lucent R&D department. For instance, critical issues reported in Nessus results are corrected in maintenance releases of the OmniPCX Enterprise.

Independent consultants (Miercom) have already tested our solutions, including the security aspects. For example, using similar tools they confirmed Alcatel-Lucent’s results concerning DoS attacks.

For more information in connection with the Media Gateway, see Media gateway

For more information about IP terminal protection, see IP terminals

2.2.5 Access controls (passwords, filters, etc.)

Our ToIP application is installed on a customized Linux system. The number of generic system accounts is reduced to the minimum and some specific system accounts used to access functions of our application are automatically created at installation.

The following table provides a summary of available system accounts after installation:

Name Function Origin Creation Login FTP

Root superadmin account Linux by default YES (console only)

NO

Bin Owner of several binaries Linux by default NO NO

Daemon Owner of /var/spool/at Linux by default NO NO

Ftp Anonymous FTP access Linux by default NO YES

Httpd HTTP owner Linux by default NO NO

Nobody Owner of TFTP daemon Linux by default NO NO

Ppp Setup IP link on V24 Linux by default NO YES

Swinst Software installation and configuration

Alcatel-Lucent

by default YES (console only)

YES

Mtcl Maintenance and configuration Alcatel-Lucent

by default YES YES

Adfexc File transfer with OmniVista 8770

Alcatel-Lucent

by default NO YES

Client Limited maintenance access Alcatel- optional YES YES



Name Function Origin Creation Login FTP

Lucent

The "client" account, not present by default, can be optionally created. Shell access and FTP access are restricted to some accounts. Only the system accounts present in this table are available. No new account can be created.

As a result, the use of shared system Ids for logging to the Com Server is mandatory.

Note: Certain accounts that were available in previous releases, but are unnecessary for system operations, have been suppressed in order to restrict unauthorized access by a backdoor. These accounts include mtch, adm, halt, sync, shutdown and install.

2.2.5.1 Security by default design

During the initial installation of the product, security is activated and password configuration in the system (accounts access) is forced into operation by default.

The customer takes the responsibility for changing the user passwords (root, mctl, swinst, and adfexc).

2.2.5.2 Expiring passwords

The expiration of passwords is activated. The "time to live" of passwords can be configured with a maximum of 999 days before access to the account is blocked by the system. Five days before the expiration date, a warning stating that "the password will expire in x days" is displayed at each login.

2.2.5.3 Password policy

Minimum length The new password must be made of a minimum of 8 digits (lower or upper case, figures, punctuation signs)

Comparison between the new password and previous ones

The new password must be different from the last three passwords. At least half of the digits must be different from the last used password

Maximum useful life From 11 to 999 days

Warning before expiration time

5 days (for each login)

Maximum number of failed authentication attempts

3

Note: It is not possible to use the "root" access directly from telnet. Access is only available via a direct console port, and the user must be physically on the site.

2.2.5.4 Disabling account

A quarantine mechanism can be configured by the administrator to block access to a system account for a short period of time (15 seconds) when the maximum number of failed authentication attempts (3 by default) is reached. This mechanism is a protection against brutal force attacks.

Note: At login, if there is no user action for 300 seconds, the session is stopped.



2.2.5.5 Shadow passwords

On a Linux system without the Shadow Suite installed, user information (including passwords) is stored in clear in the typical /etc/passwd file. With the Shadow Suite, the MD5 algorithm hashes all passwords and stores them in a specific file /etc/shadow with restricted access rights. Although not altogether impossible, it is very difficult to take a randomly encoded password and recover the original one.

2.2.6 Internal security

Internal security measures include:

• Shadow passwords

• Trusted Hosts

• TCP Wrapper

2.2.6.1 Trusted hosts

The trusted hosts function isolates the OmniPCX Enterprise network interface of the LAN. When an IP device is not explicitly registered no dialog (incoming or outgoing) is allowed between this IP device on the network and the Com Server via Ethernet. All IP routes are deleted, including default routes. When the trusted hosts function is configured to cater for several trusted IP devices, an IP static route is created for each IP device.

The trusted hosts are the IP phones, media gateways, network management stations, etc.

The hostname field contains the name of the trusted hosts from which remote access is possible. Enabled by default, this security feature allows the customer to deny remote access for unfamiliar IP devices to the CPU supporting the Com Server.

There are two trusted hosts groups: those connected to Ethernet interfaces and those connected to other links (SLIP, PPP). Configuration is performed using a specific menu (within the Netadmin tool) which specifies a list of trusted hosts (and their IP addresses).

On Linux operating systems, the file /etc/hosts.equiv lists the hosts of the network trusted by your computer; this is your trusted hosts file. This file consists of one column with the hostname or the IP address of each trusted device.

It is possible to declare a range of IP addresses (for IP phones) in the trusted hosts file.

2.2.6.2 TCP Wrapper

TCP Wrapper is a public domain tool that provides filtering services for Linux or Unix servers.

When an unprotected Linux computer is connected to a network, the computer's system is exposed to other computer users connected to the network. A hacker can determine which users are logged on to a given server, and may also be able to find out the identities of individual computers. The hacker can then determine when a workstation is likely to be idle, and access and use that workstation while it is unattended.

TCP Wrapper Firewall Capability

TCP Wrapper operates by intercepting and filtering incoming requests for the network services. For example, if an external host attempts to use the FTP service, TCP Wrapper checks to see if that external entity is authorized to transfer files. If it is authorized, then access is permitted; if not, access is denied.



TCP Wrapper IP Security

TCP Wrapper, embedded on our system, provides enhanced security IP services. It will log and control access for many IP services (such as FTP, telnet, shell, login, and TFTP) and services relating to the OmniPCX Enterprise (save-restore, audit, etc.).

For each IP device defined in the list of trusted hosts, the customer must specify each IP application that is allowed remote access.

It is possible to assign a profile that contains a minimum list of services for use in the OmniPCX Enterprise.

The available profiles are:

• VoIP resources (IP-Phone, INTIPA/INTIPB, GA, GD, and LIOE): only TFTP is allowed

• 47XX (management): FTP, Telnet, Netaccess, Saverrest are allowed

• CPU: Shell, FTP, Telnet, TFTP, Rlis, Saverrest, Builddistant, Loaddistant are allowed

• Router: no service is allowed

Only the "super user" is allowed to configure TCP Wrapper. When configuring security parameters, the manager must login as "root".

Note: Unlike TCP-wrapper, the trusted hosts function is not available with a PPP link. Alcatel-Lucent recommends that telnet and login services are inhibited via TCP-wrapper to avoid reaching a host on the LAN.

2.2.7 Network time protocol

The need for synchronized time is critical for today’s network environments. As organizations grow and the network services they provide continue to increase, the challenges involved with providing accurate time to their systems and applications also increase.

Every aspect of managing, securing and debugging a network involves determining when events occur. Time is the critical element that allows an event on one network node to be mapped to a corresponding event on another by using a log.

In many cases, these challenges can be overcome by deployment of the NTP Service. The NTP (RFC 1305) is an Internet protocol used to synchronize the clocks of devices to a designated time reference, providing the benefits of a standard based time and the synchronization of logs and traps.

The clocking information is synchronized via UTC (Universal Time Coordinated).

NTP service is based on client-server architecture where a server provides clocking information to multiple clients over an IP network. The OmniPCX Enterprise can operate as an NTP server or client in order to provide or get clocking information.

2.2.8 Log and Syslog files

2.2.8.1 Log Files

Log files are available for several OmniPCX Enterprise applications/system operations:

• Storage of all management operations performed on the Com Server (Syslog mechanism)

• Storage of telephonic database updating

• Storage of communication costs



• Storage of OmniPCX Enterprise applications "incidents"

2.2.8.2 Syslog file for intrusion management

With the security-by-default mechanism, Syslog support is enabled on the Com Server. It registers all network events, as part of the process to prevent security issues.

All events, regarding the kernel, the network interface, login, etc. monitored by the Linux system are distributed by origin and severity in files located in the directory /var/log (ex: messages, secure, auth.log, etc.). The Syslog files keep records or logs relating to:

• Connections (who is connected, and at what time)

• Unauthorized attempts to enter the system

• History of the system commands used

• Kernel and registration of the daemons used on devices

No user interface is available via swinst or netadmin to access these files. The only way to read or modify them is via Linux commands such as vi or more. To avoid congestion on the disc caused by these files, an automatic mechanism rotates log files. They are compressed and renamed by this mechanism. The rotational schedule is weekly and/or when the file exceeds 500 Kb (before compression).

2.3 Media gateway

2.3.1 Resistance against DoS attacks

There is no Operating System that can be exploited to this purpose on interface boards or media gateway controllers. These include only function specific LINUX micro-kernels.

Flood Limiting is similar to the protection provided by Alcatel-Lucent IP Phones. The TSC-LIOE, LIOE, INTIP, IOIP, GD and GA boards are designed to identify excessive Ethernet broadcast traffic rates, and ignore all broadcast traffic in excess of 300 pps. If an OmniPCX Enterprise IPMG interface receives traffic in excess of 300pps, only the first 300 packets will be accepted.

2.3.2 Separation of TDM and IP traffic

IP networking functions are completely isolated from voice and signaling transport contamination. No service has been implemented (by Alcatel-Lucent or any third party) in OmniPCX Enterprise media gateway devices that would allow user access from TDM resources (ISDN, PSTN, analogue trunk, etc.) to IP networking resources within the IP Media Gateway.

The only services supported through the TDM trunking interfaces to IP are:

• Tunneling of trunk signaling protocols

Tunneling of trunk signaling protocols (ISDN, CAS, etc.) is handled via the Com Server through IP, where they are processed by the call handling application. Call processing of the Com Server is an automated function dedicated to specific signaling packets. All the packets that are not in strict compliance with the Alcatel-Lucent specification are discarded.

• Media (voice) is encapsulated into RTP streams



The destination of RTP streams is under the control of the Com Server and can only reach RTP compliant devices, which excludes standard PCs (with the possible exception of IP softphones).

• e-Remote Maintenance application

The e-Remote Maintenance application provides network administrators with the ability to access and manipulate IPMG resources remotely. This optional feature can terminate inbound calls to the local console interface, but does not allow for any PPP/SLIP type of remote access.

Primary IPMG Functions:

In addition to the above, it is important to remember the primary functions performed by IPMG:

• IP Media Gateways can host Public and Private TDM trunking interfaces (e.g. PRA boards) which are capable of only processing signaling protocols (ISDN, QSIG, etc.) and transferring Voice streams to and from the TDM backplanes of the IPMG.

• IP Media Gateways can host VoIP interface/resource boards that are solely able to process signaling protocols (H323, H245, H225, SIP, RAS, etc.) and transfer Voice streams to and from the LAN.

Hard barrier between TDM and IP within the IPMG

The Linux micro-kernels of Alcatel-Lucent IP Media Gateway VoIP boards offer a link between the circuit-switched and packet-switched realms. This means that a hard barrier exists between the TDM and IP halves of the IPMG which only voice media and call control signaling can go through, only in the form of payload, and not as an interactive element of the communication. There is no IP routing, IP forwarding, or ICMP redirect between the TDM and IP portions of the IPMG.

For security reasons, remote IP console (telnet) sessions to GD boards of IP Media Gateways are only available from the Com Server.

Vulnerability advisories

Security is not only a set of features in a product but also a continuous corporate process to track vulnerabilities. Alcatel-Lucent is a founding and active member of CERT-IST) and mailing lists such as Bugtraq.

A Corporate-level Incident Response Team is in charge of tracking vulnerabilities issued by the CERT community The Incident Response Team also ensures that proper actions have been taken at the product-line level to analyze, evaluate impact on products, fix vulnerabilities and to keep distributors and customers informed. For example, in 2006 approximately 546 alerts were brought to our R&D for the whole group of our enterprise products.

Logging and Accounting

All management operations performed by an administrator are stored in a dedicated log file.

This ensures traceability and accountability required by many official rules (e.g. Sarbanes-Oxley in finance business). Thanks to an external RADIUS authentication, the administrator is identified by its corporate identity that will be carried out into the log file.

All logs are timed with the Network Time Protocol (NTP) service. Information in the log files can therefore be cross-matched between several systems. It is also possible to activate an “on the fly” transmission of the log files to an external secured server.

For more information about NTP, see Network time protocol



2.3.3 Binaries signature check

Embedded in the OmniPCX Enterprise product, is a mechanism that can be used on IP Media Gateways to control the integrity of binaries received from the TFTP server at initialization.

When a new binary is produced by Alcatel-Lucent for the IP Media Gateway, it is signed with a specific Alcatel-Lucent private key. When the IP Media Gateway receives its binary through TFTP, it first checks the integrity of the file with the corresponding Alcatel-Lucent public key (mechanism based on SHA1 and ECC 384 bits). If this control fails, the new binary is ignored and the IP Media Gateway starts with the previous verified binary stored in its flash memory.

2.4 Voice mail application

The OmniTouch 8440 MS solution provides several security features to ensure protection of both system and user data managed by the system.

The voice mail system is based on a hardened Red Hat Enterprise 5.0 Linux OS. It can be configured with the high availability feature (N+1 mode). Administrators can backup/restore system and user data. Administration is secured by a specific protocol (HTTPS). A verified authentication of users can be configured with an external authentication server (RADIUS).

The OmniTouch 8440 MS solution is compatible with the IP Touch Security feature to provide encryption of user communications to voice mailboxes.

Hardened password policy with:

- Limit password attempts

- Block mailbox on bad password tempts

- Impose minimum password length

- Disable outcell notification and callback sender by default

2.5 OmniVista 8770

OmniVista 8770 is designed to address specific security issues for administration applications. The architecture is based on a server/client model. The client is hosted on a PC to allow creation and modification of configuration settings. It connects to the server through secured IPSec channels.

2.5.1 Password policy enforcement

Authentication of administrators and users (to access directory information for example) is required with a login and password.

This is made more reliable by strictly conforming to standard security policies such as:

• Control on password minimum length, forbidding trivial passwords, remembering previous passwords, forcing the change of a password at first login

• Aging password (expiration time, minimum time, warning before expiration)

• Automatic blocking of a user account after several failed authentication attempts

These features are available on the server of the OmniVista 8770 and are made by the Sun One directory.

Password verification can also be performed with an external RADIUS server.



2.5.2 Back up and disaster recovery process

Critical Information such as system configuration, phone book , call accounting tickets, etc. are regularly saved in a database.

This data can be archived automatically on a daily basis on the OmniVista 8770 platform, so as to:

• Enable automatic report generation on billing and network performance

• Store up-to-date data enabling fast and smooth recovery in case of disaster

Raid Array and optical disk storage can be used for this backup. Up to four release and configuration combinations can be stored to offer rapid roll back recovery from upgrade/modification failures.

2.5.3 Sending e-mail

OmniVista 8770 can send alarms, reports or an accounting files monitoring notification to an e-mail server by specifying the name (or IP address) of the e-mail server to be used for this transmission. There is no need to grant the OmniVista 8770 services rights to use specific accounts for e-mail transmission.

2.5.4 PKI (public key infrastructure)

On the OmniVista 8770, you can use the PKI solution provided by Alcatel-Lucent, It is an enterprise class PKI Certificate Authority built on JEE technology. This feature allows the customer to create his own certificates to be use to replace the certificates by-default embedded on our platforms such as IP Phones etc. In the Alcatel-Lucent environment we can use certificates to provide mutual authentications between end-devices and servers.

In general a PKI can be used to issue certificates for different purposes such as:

• Strong authentication for users accessing your intranet/extranet/internet resources

• Secure communication with SSL servers and SSL clients

• Signing and encrypting email

• Client VPN access with certificates in users VPN clients

• Single sign-on by using a single certificate to secure logon to web applications

• Creating signed documents

• And many more...

2.6 Alcatel-Lucent OmniTouch 8400 Instant Communications Suite

Alcatel-Lucent OmniTouch 8400 Instant Communications Suite (ICS) is a suite of software applications to improve real-time communications across the enterprise.

OmniTouch 8400 ICS provides unified messaging, audio/data and video conferencing, personal routing, instant messaging (IM), sophisticated softphone capabilities, universal directory access and presence information.



2.6.1 Authentication

2.6.1.1 Single sign on through NTLM/Kerberos

With Single Sign-On (SSO), a single user authentication and authorization allows access to all the systems for which this user has access permission. There is no need to enter multiple login/passwords.

SSO reduces human error, a major component in system failures and is therefore highly desirable. NTLM (NT LAN Manager) is an authentication protocol used in various Microsoft network protocol implementations and supported by the NTLM Security Support Provider. This feature applies to Telephony/One Number/Messaging services.

2.6.1.2 External RADIUS and LDAP authentication

RADIUS implemented in OmniTouch 8400 ICS provides a strong central server authentication mechanism for users (and system administrators). For redundancy and high availability purpose, a secondary RADIUS server may be defined, should the primary RADIUS server fail.

OmniTouch 8400 ICS can authenticate users based on an existing LDAP server with existing user accounts.

2.6.2 High availability

The Operating system used for Alcatel-Lucent OmniTouch 8400 Instant Communications Suite servers is Red Hat Enterprise. This OS provides a native redundancy mechanism based on a cluster duplication and allows an "n+1" backup for OmniTouch 8400 ICS servers:

• "n+1 redundancy for the standard package (Telephony/One Number/Messaging services)

• An additional "n+1" redundancy capability for Teamwork service

2.7 IP terminals

2.7.1 Business continuity

A service continuity is offered on IP Touch EE in case of IP failure:

� IP Touch is able to maintain the active communication even if the connection with the Communication Server fails. The communication is maintained until either user or remote party hang’s up

� When Com Server is lost,

� User is able to handle the audio: HP+/HP-, mute/un-mute, voice mode switch (Handset, Hands-free, Headset)

� An error message is displayed on the phone screen

� After call completion (hanging-up of called or callee), the IP Touch restarts and registers automatically to either a PCS (in NOE mode) or an AudioCodes SIP survival gateway (in SIP mode)



2.7.2 Anti-ARP spoofing

Alcatel-Lucent IP terminals can identify multiple (differing) ARP replies. These can indicate an attack. After detection, the IP Touch logs information about potential attacks (MAC address, IP addresses, time) and sends an incident to the Com Server. This information is passed from the Com Server to OmniVista 4760 or OmniVista 8770 platforms for administrator notification (through an SNMP TRAP). The phone set also starts a temporary (60 seconds) quarantine for the concerned IP address, meaning that any packet originating from this address is rejected by the set.

2.7.3 Anti-ARP cache poisoning

Alcatel-Lucent IP terminals only update their internal ARP tables after they have initiated an ARP request. An Alcatel-Lucent IP terminal will reject any ARP reply that is not offered in direct response to an ARP request made by itself. Gratuitous ARP replies are ignored by Alcatel-Lucent IP terminals, thus eliminating this attack threat.

2.7.4 Protection against DHCP server intrusion

When the DHCP client starts up, it sends a DHCP discover frame to find a DHCP server. If the IP Touch set is configured in Alcatel Dynamic (DHCP option), the DHCP server must provide an offer containing the specific vendor option “alcatel.a4400.0" (offer provided by an Alcatel-Lucent DHCP server). This vendor option allows the IP Touch set to select the true customer DHCP server (Com server) and to ignore the DHCP intrusion server (not knowing this vendor ID).

2.7.5 Anti-MAC spoofing

This is an additional control on the Com Server. At the end of IP Touch set initialization, the Com Server requests its MAC address in a specific message. When returned by the set, it is compared to the MAC address previously given by the IP Touch in its startNOE message. If MAC addresses do not match, a reset order is sent by the Com Server to the set.

2.7.6 TFTP request check

During its initialization, the first action performed by an IP Touch set is to send a TFTP request (to an internal TFTP server) that contains the MAC address of the set. The Com Server level checks that a signaling link is not already established with a set with this MAC Address. If this is the case, an attack could be undergoing, where the hacker tries to spoof the identity of an existing set (based on its MAC Address). The Com Server reacts by rejecting the rogue TFTP request.

2.7.7 Connect message filtering

At initialization, an IP Touch set receives a Connect message from the Com Server initiating a control link between the two elements. It is critical to ensure at this time that it is the Com Server that has sent this message, to avoid possible Man-In-The-Middle attacks where the phone set could be controlled by a rogue server. To protect the IP Touch set, the source IP address of the Connect message is compared to the actual Com Server IP address received previously in the configuration file. If IP addresses do not match, then Connect message is refused.

2.7.8 Verification of binaries

IP Touch phones use the TFTP protocol to download new binaries at initialization. Prior to being used, binaries are checked by the set based on their CRC checksum. If the verification fails, the IP Phones maintain existing binaries.



Another level of binary check is provided and based on the Alcatel-Lucent public/private key feature. IP Touch binaries are digitally signed at production time with a specific Alcatel-Lucent private key. Based on the corresponding public key, the IP Touch set is able to check the integrity of files before starting to use them (this is the default behavior with Extended Edition telephone sets).

2.7.9 MMI protections

The Man Machine Interface Control is a mechanism to restrict access to the configuration of IP Touch terminals. Passwords are managed by the Com Server to restrict entry into the local configuration menu with a password (6 to 12 character).

The global password is the same for all terminals.

All local terminal menus and data are protected in a "secure" zone of their flash memory.

The only method of disabling this protection is to reset the phone locally to default factory settings.

2.7.10 PC port and traffic isolation

IP Touch telephones have two Ethernet ports, one of which can be attached to a PC. The Embedded Switch controls this "PC" port. The Com Server has the ability to disable secondary switch port of IP Touch terminals (global and/or phone by phone setting).

Three different behaviors can be configured independently for each IP Touch set:

a. PC port security not activated (default): the integrated switch of the IP Touch passes transparently all traffic from/to the PC port

b. Block PC port: the traffic from/to the PC is blocked (RX and TX bits of the PC port are disabled)

c. Filter VLAN: the IP Touch replaces any 802.1q tag to VLAN ID 0 for frames coming from the PC to the LAN, and remove 802.1q tags for frames coming from the LAN to the PC. The goal is to protect the voice network against possible intrusions from the PC port, by preventing the PC from sending traffic in the voice VLAN

2.7.11 802.1X

The aim of the 802.1x Port-based Network Access Control, also named dot1x, is the ability to deploy LAN based infrastructure, where users or devices first need to log in prior to any activity.

dot1x manages access rights to the Local Area Network (LAN) wired or wireless (WLAN). It implements an effective framework to authenticate and control user traffic to a protected network. dot1x ties a protocol called EAP (Extensible Authentication Protocol) to the LAN media and supports multiple authentication methods.

The MD5-challenge authentication protocol is supported by Alcatel-Lucent 8 series and Alcatel-Lucent IP Touch 8 series phone Extended Edition sets.

The TLS authentication protocol is available on Alcatel-Lucent IP Touch 4028/4038/4068 with 16MB of RAM, Alcatel-Lucent IP Touch 4008/4018, and Alcatel-Lucent IP Touch 8 series phone Extended Edition sets.

TLS is activated by default provided the set supports it and a certificate is present in the Phone. If a customer certificate exists and has been activated through a pass phrase, this certificate is used. If not, the Alcatel-Lucent certificate is used.



Both TLS and MD5 can be activated on a set. The server determines which authentication method is used for EAP exchanges.

Login, password and certificate are specific to the set rather than the set user. Authentication (or re-authentication) requires no user intervention, such as password input.

Note: IP Touch Behavior if disconnected from the PC Port:

• An IP Touch set monitors 802.1x messages between the authenticating switch and supplicants (i.e. the system to be authenticated, e.g. an IP Touch set) connected to its PC port. A terminal can manage up to 5 supplicant MAC addresses.

• When the PC port of a terminal is disconnected, the terminal sends an EAPOL-Logoff message on behalf of the supplicants connected to its PC port to the authenticator, so that the authenticator sets its MAC address to an unauthorized status and terminates the 802.1x session. This prevents unauthorized access to a device plugged on the PC port of a terminal, gaining access to the LAN by spoofing the MAC address of the authenticated device which was previously plugged on this PC port.

2.7.12 SIP/TLS and SRTP

The Alcatel-Lucent IP Touch 4028/4038/4068 phone Extended Edition, can encapsulate the NOE proprietary protocol within the SIP Protocol.

The SIP protocol is required to carry NOE information through the IP network. It is used as a network transport protocol.

SIP is not required to provide SIP functional or telephony services. NOE is used to guarantee all existing telephony features:

• “Level 1” proprietary signaling messages (Connect, Keepalives…) are encapsulated in SIP-OPTIONS messages.

• “Level 2” proprietary signaling messages (NOE widgets messages, START-RTP…) are encapsulated in SIP-INFO messages. SIP sessions are established and released depending on the phone activity.

Compatibility with SIP-TLS/ SRTP encryption mode (To be confirmed):

• Encryption based on certificates via SIP TLS support for the transport layer and SDP media negotiation

• SRTP to encrypt voice flows. Keys are exchanged through UA protocol (not TLS)



3 Network security

3.1 VoIP firewall THALES “TeoZ” (Alcatel-Lucent Applications Partner Program)

The firewall is an essential element of any secured network system. A firewall operates on the assumption that nothing is allowed except what is specifically authorized. The way in which it is configured must reflect an efficient security policy.

Alcatel-Lucent recommends the use of a firewall performing stateful packet inspection

(SPI) to improve real-time performance. Note that such a firewall is better suited for VoIP protection.

The firewall must be installed so as to compartmentalize your critical voice servers against unauthorized access.

Ideally, a VoIP security solution dynamically adapts network resources and security based on VoIP application requests, regardless of the signaling protocol used or whether or not the signaling or media traffic is encrypted.

A viable VoIP security solution must also:

• Be compliant with SIP, NOE and H.323 protocols to prevent the introduction of fraudulent packets

• Conduct packet inspection during SIP, NOE and H.323 call setup to obtain the necessary information to dynamically open and close the appropriate ports

• Be aware of emerging applications that require protection – for example audio, web and video conferencing, as well as Unlicensed Mobile Access (UMA) for WiFi/cellular dual-mode handsets

• Support low latency, minimal jitter and negligible packet loss to ensure call quality and customer satisfaction

• Offer high availability to avoid loss of VoIP sessions in case of security or network device failure

All these features are not commonly supported by the majority of firewalls available on the market.

With this security solution, VoIP deployments can be implemented to meet changing requirements in a secure, always available, and scalable manner.

The Thales TeoZ (AAPP) has a specific ALG (Application Layer Gateway) or Application Filter dedicated to the signaling call control protocols used by Alcatel-Lucent OmniPCX Enterprise Communication Server/OmniTouch 8400 ICS solutions.

ALGs are available for standard protocols, such as: SIP

ALGs are also available for the proprietary protocols used by Alcatel-Lucent OmniPCX Enterprise Communication Server/OmniTouch 8400 ICS:

• UA/NOE for the signaling call control exchanged between the Communication Server and IP Touch sets

• IPLink for the signaling call control exchanged between the Communication Server and IP Media Gateways



• ABC for the signaling call control exchanged between two networked Communication Servers

ALGs allow operations of dynamic pinholing for RTP flows based on the knowledge of the used signaling call control protocol.

In addition, OmniPCX Enterprise Communication Server local redundancy is supported, the TeoZ (AAPP) can monitor all traffic between main/standby CS and IP Touch sets or Media Gateways.

OmniPCX Enterprise Communication Server spatial redundancy is supported with one TeoZ appliance in front of each CS (Main and Standby).

Detailed information is available in an IWR (Internetworking Report) on the AAPP web site which describes all the architectures and the tested and supported functions.

3.2 Reverse proxy Blue Coat (Alcatel-Lucent Applications Partner Program)

Globally in addition to a web policy management, content filtering, blocking, web content virusscanning and network protection, companies can implement what is known as a reverse proxy to front end their Web applications. Implementing a reverse proxy has the following advantages:

• The reverse proxy terminates the session with the client and establishes another session with the Web server

• The internal web server only sees the IP address of the reverse proxy

• An administrator can implement granular policies with authentication, authorization and logging

• A company can achieve higher performance benefits with caching

• Protect internal users and networks from spyware and other attacks.

• Accelerate application performance for files, email, Web, SSL, and rich media applications.

Why a Reverse Proxy for Alcatel-Lucent’s applications ?

MIC mobile client for Android and iPhone is connected to the application server through Internet and consequently a reverse proxy is required in order to :

- secure data connection thanks to authentication, SSL termination and web server isolation,

- manage URL rewriting (public and private IP @).



A reverse proxy with flexible advanced forwarding architecture coupled with caching provides organizations a best of breed solution to leverage their network.

Alcatel-Lucent strongly recommends the Blue Coat ProxySG to protect the flows from the remote workers.

Blue Coat ProxySG appliances offer a comprehensive foundation for the Blue Coat Secure Web Gateway solution and advanced WAN Optimization feature sets. ProxySG appliances combine high-performance hardware with Blue Coat SGOS, a custom, object-based operating system that enables flexible policy control over content, users, applications and protocols.

The following list details the Blue Coat ProxySG Reverse Proxy Deployment features that are used for the Alcatel-Lucent solution deployment:

• HTTPS Reverse Proxy service configured to associate a certificate with a public IP

• Importing SSL keyrings and CA

• Hostname or domain name based SSL certificates

• Proxy supports portal mode optimization

• HTTP basic and cookie based Authentication based on AD/LDAP or RADIUS

• Powerful and flexible CPL policy

• HTTP header rewriting

• Cookie sharing between the different FQDN

• SSL rule modification to ignore hostname mismatch

• Support for “split brain” DNS architecture, where the public FQDN published on the WAN side is the same as the one on the Intranet.

OXE

Cellular network InternetICS

DMZ

Enterprise

https

MyIC Desktop SIP

Reverse Proxy

xDSLBox

https SIP

RTP/RTCP



Detailed information is available in an IWR (Internetworking Report) on the AAPP web site which describes all the architectures and the tested and supported functions.

3.3 OpenTouch Session Border Controller

3.3.1 Introduction

The OpenTouch SBC (Session Border Controller) enables OpenTouch multimedia conversations to securely traverse the enterprise IP border while controlling quality and ensuring interoperability.

The OpenTouch SBC will enable seamless connectivity to SIP trunking providers and deployment of OpenTouch clients on the internet, outside the enterprise firewall.

The OpenTouch SBC is a software-only solution running on a standard server, avoiding the costs associated with dedicated hardware (logistics, inventory) while providing high scalability and high availability. The OpenTouch SBC is moreover ready to be virtualized to integrate in the future into different environments and platforms.

Besides OpenTouch family, the SBC can also be used with the Alcatel-Lucent OXE, ICS and ACS solutions.

Aimed at mid-size to large-size enterprise customers, the OpenTouch SBC's maximum capacity is 1,000 SIP sessions but typical capacity is from a few tens to a few hundreds of sessions.

The SBC is an OEM product developed by AudioCodes, referred to as the Mediant Software E-SBC. The SBC benefits from the rich capabilities of AudioCodes' E-SBC product series. AudioCodes' E-SBC is already used for SIP interoperability between Alcatel Lucent Enterprise OmniPCX Enterprise, and Microsoft™ Exchange and Lync® Server 2010.

3.3.2 Features/Benefits

FEATURES

• Enterprise perimeter defense against SIP denial of service, fraud and eavesdropping

• Certified with SIP service providers

• Addresses the communication security requirements of mid-size and large enterprises

• Enables SIP protocol adaptations for interoperability

• Provides secure SIP/media connectivity and NAT traversal for OpenTouch voice and video

collaborative conversations over the Internet

• Acts as a secure softphone proxy for enterprises that need a demarcation point between a

segregated voice network and softphones that are in an all-purpose data network

• Provides business continuity over redundant servers with SIP and media session preservation

• Runs on a commercial off-the-shelf (COTS) server

• Provides easy-to-use web-based management

BENEFITS



• Provides security between the enterprise and SIP trunking providers

• Complements the enterprise firewall with dedicated protection against SIP-based attacks

• Simplifies interoperability with various flavors of SIP trunking

• Enables cost-effective and secure conversations with OpenTouch remote workers over the Internet

• Solves SIP and media traversal of Network Address Translation (NAT) devices

• Provides an easy-to-manage central demarcation point between softphones on an untrusted

network and the communications network

• Monitors voice quality for Service Level Agreements (SLA)

• Improves the TCO with a high-performance solution running on a COTS server

3.3.3 Solutions

The OpenTouch SBC is an enabler of the OpenTouch family of applications for interworking with SIP Service Providers and users connected on an external IP network (typically, the Internet).

A number of use cases are supported:

3.3.3.1 SIP Trunking to Service Providers

Incumbent and alternative carriers are upgrading their networks to NGN and IMS. SIP Business Trunking is a key offering in Service Providers' portfolios, connecting the enterprise PBX or IP-PBX to the core VoIP infrastructure natively in SIP, without using TDM gateways.

But interconnecting customers with its VoIP platform is not simple for an operator. It implies numerous technical challenges like interoperability or NAT traversal as well as security and QoS management issues.

Carriers are consequently putting carrier-grade SBCs at the edge of their VoIP network.

From an enterprise perspective, SIP Business Trunking also creates some challenges. NAT traversal for VoIP may be resolved by a carrier's SBC but depending on carrier services, this can also be resolved by the enterprise.

The enterprise IP network is interconnected to the carrier VoIP network through a Virtual Private Network (VPN), an IP-managed service, or the Internet. Depending on the type of connectivity and the customer's security awareness, an OXE IP-PBX can be directly connected to the carrier SBC or, if necessary, an intermediate device can be connected for the protection of the enterprise network from the external network.

The OpenTouch SBC connects the OXE and OT to VoIP operators while ensuring masking of its own enterprise network. This solution protects the entire enterprise network by forcing the VoIP carrier's traffic through one interconnection point to prevent the diffusion of any of the addresses of the VoIP terminals and equipment. The enterprise can thus retain a private IP addressing plan for voice over IP while authorizing the connection to third parties.

Other security functions are performed by the OpenTouch SBC. Protection against Distributed DOS attacks, IP spoofing, integrity check, stateful inspection and VoIP firewalling is also provided.



Interoperability: SIP trunking implementations may be different between IP-PBXs and NGN/IMS networks. The OpenTouch SBC can help for 'protocol normalization' so that incompatible SIP options are solved at the SBC level.

This provides a very flexible way of solving a number of interoperability issues at the edge (in the SBC) without impacting the core SIP-based IP-PBX.

The SBC can furthermore facilitate a High Availability solution deployment. The OXE uses spatial redundancy which is not simple to manage on the carrier side, requiring specific configuration on the carrier's SBC. The OpenTouch SBC will allow decoupling OXE HA (either spatial or local) from PBX HA management supported by the carrier. Either the enterprise SBC, local HA or two or more SBCs can be used and managed from the carrier network as one or several devices with load balancing or sequential routing.

Eg: customer with OXE spatial HA, OpenTouch SBC local HA: consequently no management of PBX HA on carrier side.

SIP routing: The enterprise may want to hide its SIP gateways topology from the carrier (if several OXEs, each with one SIP gateway, are deployed). The carrier may also not want to manage the topology of the customer network (building one SIP gateway per OXE and managing the routing between the gateways). Using the OpenTouch SBC between the OXE/OpenTouch network and the carrier network will allow the routing of SIP sessions between the carrier and IP-PBX network.

In the event that the enterprise gets services from several SIP carriers, the SBC ensures the connectivity and security aspects as well as routing between multiple carriers.

Quality of Experience: The OpenTouch SBC's advantageous geographical location at the border of enterprise/carrier IP networks has a number of mechanisms to ensure and monitor Quality of Service for voice calls:

• Call Admission Control, complementing CAC on OXE/OpenTouch, avoids overbooking the WAN bandwidth with real-time traffic.

• Rewriting TOS/DiffServ Service Classes to adapt to carrier constraints without impacting enterprise policy.

• QoS probe and Call Detail Records deliver accurate information on voice communications quality to maintain the Service Level Agreement with the carrier.

3.3.3.1.1 Topologies

SIP trunking poses new challenges to IP Telephony as VoIP must run on several IP networks - the enterprise network as well as the WAN and the Service Provider's core network.

Challenges may differ depending on the type of IP connectivity between enterprise and carrier.

3.3.3.1.1.1 MPLS VPN (Multiprotocol Label Switching for a Virtual Private Network)



Figure 1: SIP Trunking Carrier/Enterprise Architecture

The diagram above shows typical NGN architecture with the corporate network, the carrier IP network and the Border Element (SBC) between the two domains.

Call Control signalling is between the OXE and the carrier proxy. The media flow (RTP) goes directly from IP Touch phone to Border Element.

All enterprise sites are interconnected via VPN. The customer-facing side of an SBC has an IP address (private) in the customer's routing plan.

In this case, there's no NAT between the OXE and the carrier's network: the NAT is between the customer's VPN and the Service Provider's core network and is managed by the carrier's SBC.

The SBC is not required for connectivity reasons but if a customer wants, it can be used to clearly separate the internal from the external network, for security, SLA monitoring or SIP mediation reasons. Specific constraints from the carrier, such as fixed media, can also be enforced there.



Figure 2: SIP Trunking with an MPLS VPN (Multiprotocol Label Switching for a Virtual Private Network)

3.3.3.1.1.2 Shared WAN Network (Internet or Managed IP)

Figure 3: SIP Trunking on a Shared IP Network

Another case is when the enterprise and the Service Provider's SBC are interconnected through a shared network (shared between anybody, in the case of the Internet, or with other customers, in the case of IP-managed). A NAT for SIP issue will consequently occur on the CPE side. It will disrupt VoIP. In this case, an OpenTouch SBC located between the enterprise network and the WAN will solve the issue.


Some carriers also offer Hosted NAT Traversalrouter is in the CPE, without a SIP ALG (a

This possibility is mainly used for small PBX configurations

Nevertheless, use of an SBC can help to force the media to a single point of connection (to avoid direct RTP) and as a result, simplify interoperability.

SIP public trunking using the SBC is available for

3.3.3.2 Remote Worker

Employees are increasingly working outside their enterprise's geographical borders. They want the same services they'd have if they were sitting at their desk.

For the enterprise itself, cost must be contained, and using the Internet as a connemployee and the enterprise for voice is very cost effective (versus using the PSTN or cellular networks).

The OpenTouch SBC resolves the issue of 'remote SIP device connectivity through the Internet' by providing hosted NAT traversal for SIP (as terminals are located behind a remote router performing Level 3 NAT), as well as strong security, QoS, bandwidth management, routing functions and SIP interoperability.

This allows SIP-based terminals/clients to securely access the enterprise witan additional VPN client. This option presents an alternative to VPN, to provide more direct access to enterprise communications.

As the SBC addresses only SIP traversal, the SBC is often complemented with a reverse proxy that addresses the HTTP access side of the communication clients (and other data applications).

The SBC can moreover be leveraged to integrate users unaffiliated with the enterprise (anonymous users) into audio/video conferences initiated by OpenTouch users (or OXE

Alcatel-Lucent terminals are customized with the capability of addressing the SBC. Nevertheless, small adaptations are required to allow management of configuration parameters so that all clients are not SBC-enabled on the day of deployment.

Figu

34/75 Alcatel-Lucent Enterprise Communication Solutions

Hosted NAT Traversal for SIP. It solves the issue when a NAT layer 3 CPE, without a SIP ALG (an SBC) in the CPE.

small PBX configurations.

help to force the media to a single point of connection (to avoid simplify interoperability.

SBC is available for OpenTouch and the OXE.

Employees are increasingly working outside their enterprise's geographical borders. They want the same services they'd have if they were sitting at their desk.

For the enterprise itself, cost must be contained, and using the Internet as a connection between the employee and the enterprise for voice is very cost effective (versus using the PSTN or cellular

The OpenTouch SBC resolves the issue of 'remote SIP device connectivity through the Internet' by r SIP (as terminals are located behind a remote router performing

Level 3 NAT), as well as strong security, QoS, bandwidth management, routing functions and SIP

based terminals/clients to securely access the enterprise without needing to support an additional VPN client. This option presents an alternative to VPN, to provide more direct access to

As the SBC addresses only SIP traversal, the SBC is often complemented with a reverse proxy that sses the HTTP access side of the communication clients (and other data applications).

The SBC can moreover be leveraged to integrate users unaffiliated with the enterprise (anonymous users) into audio/video conferences initiated by OpenTouch users (or OXE users).

Lucent terminals are customized with the capability of addressing the SBC. Nevertheless, small adaptations are required to allow management of configuration parameters so that all clients

enabled on the day of deployment.

Figure 4: Remote Worker on OpenTouch

Lucent Enterprise Communication Solutions October 2013 Offer

for SIP. It solves the issue when a NAT layer 3

help to force the media to a single point of connection (to avoid

Employees are increasingly working outside their enterprise's geographical borders. They want the

ection between the employee and the enterprise for voice is very cost effective (versus using the PSTN or cellular

The OpenTouch SBC resolves the issue of 'remote SIP device connectivity through the Internet' by r SIP (as terminals are located behind a remote router performing

Level 3 NAT), as well as strong security, QoS, bandwidth management, routing functions and SIP

hout needing to support an additional VPN client. This option presents an alternative to VPN, to provide more direct access to

As the SBC addresses only SIP traversal, the SBC is often complemented with a reverse proxy that sses the HTTP access side of the communication clients (and other data applications).

The SBC can moreover be leveraged to integrate users unaffiliated with the enterprise (anonymous

Lucent terminals are customized with the capability of addressing the SBC. Nevertheless, small adaptations are required to allow management of configuration parameters so that all clients


3.3.3.3 LAN Segmentation within the Corporate LAN

VoIP and IP telephony are now common in enterprise networks.

The VoIP network is expected to be as reliable as the former TDM voice network. Best recommend that the VoIP network be separated to a certain extent from the data network so that a security attack in the data network won't affect voice communications resources.

IP hard phones are therefore put in voice VLANs and PCs network elements prevents direct communications between voice and data VLANs.

This protects IP hard phones from threats from the end user PCs, specifically, from Microsoftend user PCs, which are more prone to attacks (wo

With increasing demand for softphones (softwarefor PCs and IP phones to interoperate. Media flows (RTP) must go directly from the PC to the IP phone without traversing servers, to dif

This creates a new security challenge. RTP flows must go from data VLAN to voice VLAN without introducing any security flaw in the global network security.

VoIP softphones stay in the data VLAN, meaning that VoIP floRTP) across the data VLAN before being routed to VoIP servers or endpoints.

As routing between voice endpoints VLANs and PCs data VLAN is forbidden through routers, other equipment will allow secure traversal of VoIP f

Figure

SIP TLS is also supported between SIP softphones and the SBC, independently of what is done on the voice VLAN: The SBC will act as a SIP TLS proxy, i.RTP.


LAN Segmentation within the Corporate LAN

VoIP and IP telephony are now common in enterprise networks.

The VoIP network is expected to be as reliable as the former TDM voice network. Best recommend that the VoIP network be separated to a certain extent from the data network so that a security attack in the data network won't affect voice communications resources.

put in voice VLANs and PCs are put in data VLANs. Configuration of network elements prevents direct communications between voice and data VLANs.

This protects IP hard phones from threats from the end user PCs, specifically, from Microsoftend user PCs, which are more prone to attacks (worms, viruses, etc.).

With increasing demand for softphones (software-based VoIP clients running on PCs), there's a need for PCs and IP phones to interoperate. Media flows (RTP) must go directly from the PC to the IP

to differentiate from client-server traffic.

This creates a new security challenge. RTP flows must go from data VLAN to voice VLAN without introducing any security flaw in the global network security.

VoIP softphones stay in the data VLAN, meaning that VoIP flows from the softphone (signalling and RTP) across the data VLAN before being routed to VoIP servers or endpoints.

As routing between voice endpoints VLANs and PCs data VLAN is forbidden through routers, other equipment will allow secure traversal of VoIP flows between voice and data VLANs.

Figure 5: VLAN Segmentation with OpenTouch

SIP TLS is also supported between SIP softphones and the SBC, independently of what is done on the voice VLAN: The SBC will act as a SIP TLS proxy, i.e., translating SIP TLS to SIP UDP and SRTP to


The VoIP network is expected to be as reliable as the former TDM voice network. Best practices recommend that the VoIP network be separated to a certain extent from the data network so that a

data VLANs. Configuration of

This protects IP hard phones from threats from the end user PCs, specifically, from Microsoft-based

based VoIP clients running on PCs), there's a need for PCs and IP phones to interoperate. Media flows (RTP) must go directly from the PC to the IP

This creates a new security challenge. RTP flows must go from data VLAN to voice VLAN without

ws from the softphone (signalling and

As routing between voice endpoints VLANs and PCs data VLAN is forbidden through routers, other

SIP TLS is also supported between SIP softphones and the SBC, independently of what is done on e., translating SIP TLS to SIP UDP and SRTP to



The benefit of using SIP TLS and SRTP is that it allows voice traffic to be logically 'separated' from data traffic in the data VLAN. Voice cannot be sniffed from a data VLAN as if it were in a VPN tunnel or if it were in a different (voice) VLAN.

Note: This case is different from that of the remote worker because the softphone is on the customer LAN and not on the Internet. It is not a remote worker scenario. Furthermore, the softphone is connected to a different network than the voice network. There's no need for hosted NAT traversal at the SBC level.

3.3.4 OpenTouch SBC Physical Description

Technical Specifications

Function Specification

Networking Interfaces

LAN � Two 1000Base-T (Gigabit Ethernet) LAN port interfaces

� Physical port separation by selecting port group per network interface

High Availability (HA)

Full HA Two devices deployed for 1+1 High Availability, communicating through a Maintenance network interface. If the active device fails, all functionality is switched over to the redundant device.

Media Processing

IP Transport VoIP (RTP/RTCP) per IETF RFC 3550 and 3551, IPv6

Control and Management

Control Protocols � SIP-TCP, UDP, TLS

� Stand Alone Survivability for service continuity

Operations & Management � Embedded HTTP Web Server, Telnet,

� Remote configuration and software download via TFTP, HTTP, HTTPS, DHCP

� RADIUS, Syslog (for events, alarms and CDRs)

IP/VoIP Quality of Service

� IEEE 802.1p, TOS, DiffServ

� IEEE 802.1Q VLAN tagging

� Shaping, Policing, Queuing, Bandwidth Reservation

Session Border Control

� SIP Header conversion: IP to IP Routing translations of SIP, UDP, TCP, TLS

� Translation of RTP, SRTP; Support SIP trunk with multi-ITSP (Registrations to ITSPs is invoked independently); Topology hiding; Call Admission Control; Call Black/White list

� Intrusion detection/prevention (NIDS); Anti SPIT & SPAM mechanisms (SIP messages policing)



Function Specification

Hardware Specifications

Platform � Platform: HP ProLiant DL120 G7

� Processor: Intel Xeon E3-1220 (8M Cache, 3.10 GHz), 4 Cores

� Memory: 4 GB

� Disk space: 72 GB or more

� CD-ROM: Local

� CLI support:

�� VGA monitor and keyboard �� RS-232 serial port (optional)

3.3.5 Architecture

The OpenTouch SBC is designed as a complete 'software appliance', to be installed on a dedicated Intel-based server or virtual machine. OpenTouch SBC installation media includes all required software components and doesn’t depend on any additional software.

Although the OpenTouch SBC was designed in concept with platform independency, it must be run in the first version on a dedicated certified server with a specific parts list to guarantee correct functioning and to guarantee that published limits can be provided.

Virtualization will allow providing platform independency of the OpenTouch SBC 'software appliance' in a future version of the software.

3.3.6 OpenTouch SBC Functionality

3.3.6.1 Connectivity

3.3.6.1.1 Multiple IP Interfaces and VLANs for Physical and Logical Port Separation

OT SBC is using an off the shelf HP hardware platform

Two Ethernet ports are available in this release but they can be used for multiple logical interfaces.

The hardware platform features four Ethernet interfaces for further add-on functionalities.



Figure 6: Typical Configuration

The OpenTouch SBC is typically configured with three network interfaces for:

•••• Operations, Administration, Maintenance and Provisioning (OAMP) applications

•••• Call Control applications

•••• Media

The multiple interfaces scheme allows configuration of different IP addresses, each associated with a unique VLAN ID. Configuration is performed using the Multiple Interface table, configurable using the ini file, Web, and SNMP interfaces.

3.3.6.1.2 NAT Traversal

The OpenTouch SBC supports NAT traversal that (for example) enables communication with ITSPs with globally unique IP addresses, for LAN-to-WAN VoIP signaling (and bearer) using two independent legs. Additionally, it enables communication for 'far-end' users located behind a NAT on the WAN.

The OpenTouch SBC supports this by:

• Continuously registering far-end users in its dynamic database

• Maintaining a remote NAT binding state by frequent registrations, thereby off-loading far-end registrations from the LAN IP-PBX

• Using Symmetric RTP (RFC 4961) to overcome bearer NAT traversal

Network Address Translation (NAT) is a mechanism that maps a set of internal IP addresses used within a private network, to global IP addresses, providing transparent routing to end hosts. The primary advantages of NAT include (1) reduction in the number of global IP addresses required in a



private network (global IP addresses are only used to connect to the Internet) and (2) better network security by hiding its internal architecture.

SIP design creates a problem for VoIP traffic to pass through NAT. SIP uses IP addresses and port numbers in its message body. The NAT server cannot modify SIP messages and therefore cannot change local to global addresses. Two different streams traverse through NAT: signaling and media. A device (located behind a NAT) that initiates a signaling path has problems in receiving incoming signaling responses (they are blocked by the NAT server). Furthermore, the initiating device must notify the receiving device where to send the media.

To resolve these issues, these mechanisms are available:

• First Incoming Packet Mechanism (see 'First Incoming Packet Mechanism')

• RTP No-Op packets, according to the avt-rtp-noop draft (see 'No-Op Packets' )

3.3.6.1.2.1 First Incoming Packet Mechanism

If the remote device resides behind a NAT device, it’s possible that the device can activate the RTP/RTCP/T.38 streams to an invalid IP address / UDP port. To avoid this, the device automatically compares the source address of the incoming RTP/RTCP/T.38 stream with the IP address and UDP port of the remote device. If the two are not identical, the transmitter modifies the sending address to correspond with the address of the incoming stream. The RTP, RTCP and T.38 can thus have independent destination IP addresses and UDP ports.

You can disable the NAT mechanism by setting the ini file parameter DisableNAT to 1. The two parameters EnableIpAddrTranslation and EnableUdpPortTranslation allow you to specify the type of compare operation that occurs on the first incoming packet. To compare only the IP address, set EnableIpAddrTranslation to 1 and EnableUdpPortTranslation to 0. In this case, if the first incoming packet arrives with only UDP port different, the sending addresses won’t change. If both IP address and UDP port need to be compared, both parameters must be set to 1.

3.3.6.1.2.2 No-Op Packets

The device's No-Op packet support can be used to verify Real-Time Transport Protocol (RTP) and T.38 connectivity, and to keep NAT bindings and Firewall pinholes open. No-Op packets are available for sending in RTP and T.38 formats.

You can control the activation of No-Op packets by using the ini file parameter NoOpEnable. If No-Op packet transmission is activated, you can control the time interval in which No-Op packets are sent in the case of silence (i.e., no RTP or T.38 traffic). This is performed using the ini file parameter NoOpInterval.

• RTP No-Op: RTP No-Op support complies with IETF Internet-Draft draft-wing-avt-rtp-noop-03 ('A No-Op Payload Format for RTP'). This IETF document defines a No-Op payload format for RTP. The draft defines the RTP payload type as dynamic. You can control the payload type with which the No-Op packets are sent.

• T.38 No-Op: T.38 No-Op packets are sent only while a T.38 session is activated. Sent packets are a duplication of the previously sent frame (including duplication of the sequence number).

3.3.6.1.3 SIP Routing

The device's SBC application employs a comprehensive and flexible routing scheme:

• Routing rules according to Layer-3/4 and SIP characteristics



• Routing to different destination types:

� Request-URI (of incoming SIP dialog initiating requests)

� Specific destination IP address (based on IP address, host name, port, transport type, and/or SRD). Routing to a host name can be resolved using NAPTR/SRV/A-Record.

� Specific FQDN (NAPTR/SRV/A-Record Resolutions)

� Registered User Contact listed in the device's database (only for USER-type IP Groups)

� Destination IP Group (address defined by Proxy Set associated with the IP Group) with load balancing and redundancy capability

� ENUM query

• Alternative Routing

• Routing between two different Layer-3 networks

• Transport protocol translator (UDP to TCP to TLS)

• Source and destination user name manipulation (pre/post routing)

The device supports SIP URI user part (source and destination) manipulations for inbound and outbound routing. These manipulations can be applied to a source IP group, source and destination host and user prefixes, and/or user-defined SIP request (e.g., INVITE, OPTIONS, SUBSCRIBE, and/or REGISTER). Since outbound manipulations are performed after routing, the outbound manipulation rule matching can also be done by destination IP Group.

Manipulated destination user and host are performed on the following SIP headers: Request-URI, To, and Remote-Party-ID (if it exists). Manipulated source user and host are performed on the following SIP headers: From, P-Asserted (if it exists), P-Preferred (if it exists), and Remote-Party-ID (if it exists).

3.3.6.1.3.1 Alternative Routing on Detection of Failed SIP Response

The device can detect failure of a sent SIP response (e.g., TCP timeout and UDP ICMP). In this scenario, the device re-sends the response to an alternative destination. This support is in addition to alternative routing if the device detects failed SIP requests.

For example, assume the device sends a SIP 200 OK in response to a received INVITE request. If the device does not receive a SIP ACK in response to this, it sends a new 200 OK to the next alternative destination (e.g., to the next given IP address resolved from a DNS from the Contact or Record-Route header in the request related to the response).

3.3.6.1.4 Configuring Alternative Routing Reasons

The SBC Alternative Routing Reasons page allows you to define up to five different call release (termination) reasons for call releases. If a call is released as a result of one of these reasons, provided in SIP 4xx, 5xx, and 6xx response codes, the device attempts to locate an alternative route for the call. The call release reason type can be configured, for example, when there is no response to an INVITE message (after INVITE re-transmissions), where the device issues an internal 408 'No Response' implicit release reason.

Release reasons can also be configured to indicate that a route for an SRD or IP Group has reached its call admission control limit (i.e., maximum concurrent calls and/or call rate)). In such a scenario, an alternative route configured in the IP-to-IP Routing table can be used.



3.3.6.2 Interoperability

3.3.6.2.1 SIP Normalization

The device supports SIP normalization whereby the SBC application can overcome interoperability problems between SIP user agents. This is achieved by:

� Manipulation of SIP URI user and host parts

� Connection to ITSP SIP trunks on behalf of an IP-PBX - the device can register and utilize user and password to authenticate for the IP-PBX

3.3.6.2.2 SIP Terminations

� SIP REFER Handling (Call Transfer)

SIP UAs may support different versions of the REFER standard and some may not support REFER. This results in interoperability problems. Special handling may be enabled for specific IP Groups that do not support REFER. For such IP Groups, when the OpenTouch SBC receives a REFER request, instead of forwarding it to the IP Group, it handles it locally.

� Interworking of SIP PRACK Requests

Inconsistent support for SIP reliable provisional responses (18x) - when connecting to different SIP networks - causes interoperability problems. While some endpoints do not support PRACK (RFC 3262), others require it.

� Handling of SIP 3xx Redirect Responses

The OpenTouch SBC can handle SIP 3xx responses on behalf of the dialog-initiating UA, and retry the request (e.g., INVITE) using one or more alternative URIs included in the 3xx response. The new request includes SIP headers from the initial request. These include headers such as Diversion, History-Info, P-Asserted-Id, and Priority. The source and destination URIs can be manipulated using the regular manipulation mechanism.

� Interworking of Session Timer Mismatches

The SIP standard provides a signaling keep-alive mechanism using Re-INVITES and UPDATES. In certain setups, keep-alive may be required by some SIP devices, while for others it may not be supported. The OpenTouch SBC resolves this type of mismatch by performing the keep-alive process on behalf of devices that do not support it.

� Interworking of SIP Early Media

o Early Media

Early media can arrive in provisional responses to an INVITE request. This feature determines whether an IP Group can accept early media. The OpenTouch SBC forwards the request for early media for IP Groups that support this capability; otherwise, the OpenTouch SBC terminates it. The OpenTouch SBC also refers to this parameter for features that require early media, such as playing ringback tones.

o Multiple 18x Support

Determines whether multiple 18x responses (including 180 Ringing, 181 Call is Being Forwarded, 182 Call Queued, and 183 Session Progress) are forwarded to the caller.

� Interworking of Re-INVITE

o Method



This feature enables communication between endpoints that generate Re-INVITE requests and those that do not support receipt of Re-INVITEs. The OpenTouch SBC does not forward Re-INVITE requests to IP Groups that do not support it. In such cases, the OpenTouch SBC sends a SIP response to the Re-INVITE request, which can be either a success or a failure depending on whether the OpenTouch SBC can bridge the media between the endpoints. The OpenTouch SBC can handle Re-INVITEs with or without an SDP body.

o Interworking of Re-INVITE SDP

This feature enables communication between endpoints that do not support Re-INVITE requests without SDP and those that require it. The OpenTouch SBC generates an SDP offer and inserts it into the incoming Re-INVITE request if it does not contain an SDP, and only then forwards it to the destination endpoint.

� Interworking of SIP UPDATE Requests

Enable communications between endpoints that generate UPDATE requests and those that do not support receipt of UPDATE requests. The OpenTouch SBC does not forward UPDATE requests to IP Groups that do not support it. In such cases, the OpenTouch SBC sends a SIP response to the UPDATE request, which can be either a success or a failure depending on whether the OpenTouch SBC can bridge the media between the endpoints.

� Interworking Re-INVITE to UPDATE Requests

Enable communications between endpoints that do not support Re-INVITE requests but do support the UPDATE method, or vice versa. The OpenTouch SBC translates the Re-INVITE request to UPDATE request, or vice versa.

Note that if a Re-INVITE request arrives without SDP, the OpenTouch SBC generates SDP and inserts it into the outgoing UPDATE request.

� Interworking of Delayed Offer

Enable communications between endpoints that send INVITEs without SDP (delayed media) and endpoints that do not support receipt of INVITEs without SDP. The OpenTouch SBC creates an SDP and adds it to INVITEs that arrive without SDP.

3.3.6.2.3 SIP Header Manipulation

The device provides enhanced SIP header manipulation, including insertion, removal and/or modification of SIP headers and parameters. This manipulation is configured in the Message Manipulations table (MessageManipulations parameter). The feature enables normalization of SIP messaging fields between communicating network segments. For example, it allows service providers to design their own policies on the SIP messaging fields that must be present before a SIP call enters their network. Similarly, enterprises and small businesses may have policies for information that can enter or leave their networks for policy or security reasons from a Service Provider. The manipulations can also be implemented to resolve incompatibilities between SIP devices inside the enterprise network.

SIP messaging manipulation supports:

� Addition of new headers

� Removal of headers ('Black list')

� Modification of header components - value, header value (e.g., URI value of the P-Asserted-Identity header can be copied to the From header), call parameter values



� Deletion of SIP body (e.g., if a message body isn’t supported in the destination network, the body is removed)

� Translating one SIP response code to another

� Topology hiding (generally present in SIP headers such as Via, Record Route, Route and Service-Route)

� Configurable identity hiding (information related to identity of subscribers for example, P-Asserted-Identity, Referred-By, Identity and Identity-Info)

� Apply conditions per rule - the condition can be on parts of the message or call parameters

� Multiple manipulation rules on the same SIP message

3.3.6.2.4 Restricting and Prioritizing the Codec List

The SBC Allowed Coders (coders restriction) feature determines the coders that can be used for a specific SBC leg. This provides greater control over bandwidth by enforcing use of specific coders (allowed coders groups) while preventing use of other coders.

Coders not listed in the Allowed Coders Group are removed from the SDP offer. Only coders common to the SDP offer and the Allowed Coders Group are therefore used.

In addition to restricting use of coders, the device can prioritize the coders listed in the SDP offer. This feature is referred to as Coder Preference. This is performed on both SBC legs.

3.3.6.2.5 Media Anchoring

To direct the RTP to flow through the device (for NAT traversal, firewall and security), all IP address fields in the SDP are modified:

� Origin: IP address, session and version ID

� Session connection attribute ('c=' field)

� Media connection attribute ('c=' field)

� Media port number

� RTCP media attribute IP address and port (if the parameter EnableRTCPAttribute is set to 1)

3.3.6.3 Security

3.3.6.3.1 IP Firewall to Allow Incoming Traffic

The device provides an internal firewall, allowing the security administrator to define network traffic filtering rules. You can add up to 50 ordered firewall rules.

The access list provides the following firewall rules:

� Block traffic from known malicious sources

� Only allow traffic from known friendly sources and block all others

� Mix allowed and blocked network sources

� Limit traffic to a predefined rate (blocking the excess)

� Limit traffic to specific protocols and specific port ranges on the device

For each packet received on the network interface, the table is scanned from the top down until a matching rule is found. This rule can either deny (block) or permit (allow) the packet. When a rule in



the table is located, subsequent rules further down the table are ignored. If the end of the table is reached without a match, the packet is accepted.

3.3.6.3.2 Configuring RTP Base UDP Port

You can configure the range of UDP ports for RTP, RTCP and T.38. The UDP port range can be configured using media realms in the Media Realm table, allowing you to assign different port ranges (media realms) to different interfaces.

3.3.6.3.3 VoIP Firewall

The device provides a firewall for VoIP:

• SIP signaling:

� Deep and stateful inspection of all SIP signaling packets

� SIP dialog initiations may be rejected based on values of incoming SIP INVITE message and other Layer-3 characteristics

� Packets not belonging to an authorized SIP dialog are discarded

• RTP:

� Opening pinholes (ports) in the device's firewall based on Offer-Answer SDP negotiations

� Deep packet inspection of all RTP packets

� Late rouge detection - if a SIP session was gracefully terminated and someone tries to 'ride on it' with rouge traffic from the already terminated RTP and SIP context, the VoIP Firewall prevents this from occurring

� Disconnects the call (after a user-defined time) if the RTP connection is broken

� Black/White lists for both Layer-3 firewall and SIP classification

3.3.6.3.4 Topology Hiding

The device intrinsically supports topology hiding, limiting the amount of topology information displayed to external parties. For example, IP addresses of ITSP equipment (e.g. proxies, gateways and application servers) can be hidden from outside parties.

The device's topology hiding is provided by implementing back-to-back user agent (B2BUA) leg routing:

• Strips all incoming SIP Via header fields and creates a new Via value for the outgoing message

• Each leg has its own Route/Record Route set

• Modifies SIP To, From, and Request-URI host names (must be configured using the Message Manipulations table)

• Generates a new SIP Call-ID header value (different between legs)

• Changes the SIP Contact header to the device's own address

• Layer-3 topology hiding by modifying source IP address in the SIP IP header

3.3.6.3.5 Registration Security

The device provides flexibility in controlling user's registration:



• Limiting Number of Registrations: You can limit the number of users that can register with the device. This limitation can be applied per source IP Group and/or SRD. By default, no limitation exists for registered users.

• Blocking Incoming Calls from Unregistered Users: You can block incoming calls (INVITE requests) from unregistered users (pertaining to USER-type IP Groups). By default, calls from unregistered users are not blocked. This is configured using the SRD parameter. When a call is rejected, the device sends a SIP 500 'Server Internal Error' response to the remote end.

3.3.6.3.6 SIP Authentication

The device can function as an authentication server for SIP SBC message requests, based on HTTP authentication DIGEST with MD5. Alternatively, such requests can be authenticated by an external, third-party server.

Note: In ALE environment authentication of remote users is not done in the SBC.

3.3.6.3.7 SIP Message Policy Rules

You can configure SIP message policies for blocking (blacklisting) unwanted incoming SIP messages and allowing (whitelisting) receipt of wanted messages. This feature allows you to define legal and illegal characteristics of a SIP message. The message policy can apply globally (default) or per signaling domain.

The feature is helpful against VoIP fuzzing (known also as 'robustness testing') which sends different types of packets to its 'victims' for finding bugs and vulnerabilities. For example, the attacker might try sending a SIP message containing either an over-sized parameter or too many occurrences of a parameter.

SIP message security rules are configured in the new Message Policy table (MessagePolicy).

Each policy can be defined with:

• Maximum message length

• Maximum SIP header length

• Maximum message body length

• Maximum number of headers

• Maximum number of bodies

• Option to send a 400 "Bad Request" response if a message request is rejected

• Blacklist and whitelist for defined SIP methods (e.g., INVITE)

• Blacklist and whitelist for defined SIP bodies

3.3.6.3.8 Robust Receipt of Media Streams

This mechanism filters out unwanted RTP streams that are sent to the same port number on the device. These multiple RTP streams can result from traces of previous calls, call control errors and deliberate attacks. When more than one RTP stream reaches the device on the same port number, the device accepts only one and rejects the rest.



3.3.6.3.9 Encryption : SIP TLS and SRTP

3.3.6.3.9.1 SIP TLS

SIP session can be encrypted using TLS.

MTLS can also be used if mutual authentication is required to open the TLS connection.

The OpenTouch SBC can be a client or a server TLS, according to use case.

Gateway from TLS to UDP/TCP is supported

3.3.6.3.9.2 SRTP

The OpenTouch SBC supports SRTP according to RFC 3711. This allows encrypted media between the OpenTouch SBC and a SIP terminal.

Key exchange mechanism for SRTP is performed according to RFC 4568.

Gateway from SRTP to RTP is supported.

3.3.6.4 Quality of Experience

3.3.6.4.1 Quality of Service Parameters

The device allows you to specify DiffServ (Differentiated Services) values for four predefined service classes:

• Premium Media Service Class – used for RTP Media traffic

• Premium Control Service Class – used for Call Control traffic

• Gold Service Class – used for streaming applications

• Bronze Service Class – used for OAMP applications

Layer-3 QoS parameters enable setting the values of the DiffServ field in the IP Header of the frames related to a specific service class. Layer-2 QoS parameters enable setting the values for the three priority bits in the VLAN tag (IEEE 802.1p standard) according to the value of the DiffServ field found in the packet IP header.

3.3.6.4.2 Configuring Admission Control by Number of Concurrent Calls or Call Rate

The Admission Control page allows you to define up to 100 rules for limiting the number of concurrent calls (SIP dialogs). These call limits can be applied per SRD, IP Group, SIP request type (e.g., INVITEs), SIP dialog direction (e.g., inbound), and/or per user (identified by its registered contact). The feature can be useful for implementing SLA policies.

SIP dialog limits can be defined per SIP request type and direction. These relate to requests that initiate SIP dialogs and not to subsequent requests that can be of different type and direction. SIP dialog-initiating request types can include SIP INVITEs, REGISTER, and/or SUBSCRIBE, or it can be configured to include the total number of all dialogs.

The feature also provides support for SIP-dialog rate control using the 'token bucket' mechanism. This is a control mechanism that dictates the rate of SIP-dialog setups based on the presence of tokens in the bucket – a logical container that holds aggregate SIP dialogs to be accepted or transmitted. Tokens in the bucket are removed ('cashed in') for capability to set up a dialog. A flow can therefore set up dialogs up to its peak burst rate if there are adequate tokens in the bucket and if the burst threshold is configured appropriately.


3.3.6.4.3 Monitoring VoIP Quality of Service: Generating Call Detail Records

Call Detail Records (CDRs) contain vital statistical information on calls made from the device. CDRs are generated at the end and optionally at thethey're sent to a Syslog server. The destination IP address for CDR logs is defined by the CDRSyslogServerIP parameter.

Also refer to chapter “Generating Call Detail Records

3.3.7 OpenTouch SBC Non-Functional

3.3.7.1 Deployment

Two deployment models can be adoptedtraffic.

1) OpenTouch SBC connected directly to the Internet, bypassing the data firewall, so does not

benefit from the additional security layer

2) OpenTouch SBC connected behind the data firewall , and managing only Multimedia traffic.

Figure 7: Deployment

3.3.7.2 High Availability

The High Availability feature allows SIP and RTP (SRTP) sessions to be in the HA pair of servers fails.

The feature provides full redundancy between two

In HA mode, one of the LAN interfaces (Ethernet Group) on each device, referred to as the Maintenance interface, is used for Ethernebe connected to each other through their Maintenance interface on the same broadcast domain. This connection can be:


Monitoring VoIP Quality of Service: Generating Call Detail Records

Call Detail Records (CDRs) contain vital statistical information on calls made from the device. CDRs are generated at the end and optionally at the beginning of each call. After they are generated, they're sent to a Syslog server. The destination IP address for CDR logs is defined by the

Generating Call Detail Records”

Functionality Aspects

adopted. In both, the OpenTouch SBC only manages SIP and RTP

OpenTouch SBC connected directly to the Internet, bypassing the data firewall, so does not

benefit from the additional security layer from firewall at IP level

OpenTouch SBC connected behind the data firewall , and managing only Multimedia traffic.

The High Availability feature allows SIP and RTP (SRTP) sessions to be preserved if the main server

The feature provides full redundancy between two SBC devices.

In HA mode, one of the LAN interfaces (Ethernet Group) on each device, referred to as the interface, is used for Ethernet connectivity between the two devices. The devices must

be connected to each other through their Maintenance interface on the same broadcast domain. This


Call Detail Records (CDRs) contain vital statistical information on calls made from the device. CDRs beginning of each call. After they are generated,

they're sent to a Syslog server. The destination IP address for CDR logs is defined by the

SBC only manages SIP and RTP

OpenTouch SBC connected directly to the Internet, bypassing the data firewall, so does not

OpenTouch SBC connected behind the data firewall , and managing only Multimedia traffic.

preserved if the main server

In HA mode, one of the LAN interfaces (Ethernet Group) on each device, referred to as the t connectivity between the two devices. The devices must

be connected to each other through their Maintenance interface on the same broadcast domain. This



• A direct connection (i.e., port to port). In this setup, however, the physical port group used for this connection can only be used for the Maintenance interface.

–OR-

• Indirect connection through a switch. In this setup, the physical port group used for this connection can also be used for other interfaces (i.e., OAMP, Media, and/or Control) in addition to the Maintenance interface.

Each device has its own Maintenance interface with a unique address. Each device is familiar with the remote device's Maintenance address.

Under normal operation, one device is in 'Active' state while the second is in 'Redundant' state. In the Active device, all logical interfaces are active (i.e., Media, Control, OAMP, Maintenance, etc.). In the redundant device, only the Maintenance interface is active (used for connectivity with the Active device). Management is therefore performed only through the Active device.

If a major functional failure occurs in the Active device, the redundant device becomes active and activates all its logical interfaces exactly as was configured in the Active device.

The HA system can be set to Revertive mode which allows specifying one of the two devices as the favorite or prioritized device. When operating in Revertive mode, each device is configured with a priority level between 1 and 10 (where 1 is the lowest). When the device set with a higher priority recovers from a failure, it first becomes the redundant device and then issues an automatic switchover to again become the active device (otherwise it remains the redundant device after recovery).

If you increase the priority of the redundant device to a level higher than that of the active device and then reset the redundant device, a switchover occurs to the redundant device which becomes the active device.

If both devices are configured with the same priority level, Revertive mode is irrelevant.

When Revertive mode is disabled, a switchover is performed only if the active device fails.

3.3.7.3 Survivability (Stand Alone Survivability)

The device's Stand-Alone Survivability (SAS) feature ensures telephony communication continuity (survivability) for enterprises using hosted IP services (such as IP Centrex) or IP-PBX if these entities should fail. When in survivability mode, the SBC serves as proxy to allow calls between registered users.

3.3.7.4 Configuration Management

3.3.7.4.1 GUI

The device's embedded Web server provides FCAPS (fault management, configuration, accounting, performance and security) functionality. The Web interface allows you to remotely configure the device for quick-and-easy deployment, including loading software (.cmp), configuration (.ini) and auxiliary files. The Web interface provides real-time, online monitoring of the device, including display of alarms and their severity. In addition, the Web interface displays performance statistics of voice calls and various traffic parameters.

The Web interface provides a user-friendly, graphical user interface (GUI) accessed using any standard Web browser (e.g., Microsoft Internet Explorer®). Access to the Web interface is controlled by security mechanisms such as login user name and password, read-write privileges, and limited access to specific IP addresses.



3.3.7.4.2 CLI

Telnet and SSH are available for reconfiguration of the IP address in order to connect to the OpenTouch SBC. The Web-based management tool should be used for management.

3.3.7.4.3 Offline Configuration

The ini file is a text-based file (created using Notepad, for example) that can contain any number of parameters settings. The ini file can be loaded to the device using the Web interface.

When loaded to the device, the configuration settings of the ini file are saved to the device's non-volatile memory. If a parameter is excluded from the loaded ini file, the following occurs :

• Default values are assigned to excluded parameters thereby overriding values previously defined for these parameters (Maintenance � Software Update � Configuration File)

• Current settings are retained (incremental) for excluded parameters ( Maintenance �

Software Update � Load Auxiliary Files)

You can save a copy/backup of the device's current configuration settings as an ini file to a folder on your PC.

You can restore the device's configuration by loading the previously saved ini file or by simply loading a newly created ini file.

3.3.7.5 Fault Management

3.3.7.6 Alarms through GUI

Viewing the following alarm types is supported:

• Active alarms

• Alarm history

Active Alarms Page

Figure 8: Fault Management - Active Alarms Page

For each alarm this information is provided:

• Severity: severity level of the alarm:

� Critical - alarm displayed in red

� Major - alarm displayed in orange

� Minor - alarm displayed in yellow

• Source: unit from which the alarm was raised

• Description: brief explanation of the alarm

• Date: date and time that the alarm was generated



3.3.7.6.1 SNMP

Availability pending in future releases

3.3.7.7 Performance Management

3.3.7.7.1 Viewing Quality of Experience

The Quality of Experience page provides statistical information on calls per SRD or IP Group. The statistics can be further filtered to display incoming and/or outgoing call direction and type of SIP dialog (INVITE, SUBSCRIBE, or all).

The page shows three pie charts:

• Dialog Success Ratio: displays the SIP call and subscribe (SUBSCRIBE) dialog success-failed ratio.

• Dialog Failed Attempts: displays failed call attempts. This includes the number of calls and subscribes which were successfully and abnormally terminated.

• Dialog Termination Ratio: displays call termination by reason (e.g., No Answer).

Quality of Experience Graph

Figure 9: QoE Graph

3.3.7.7.2 Viewing Average Call Duration

The Average Call Duration page displays information about a specific SRD or IP Group. This page includes two graphs:

� Upper graph: displays the number of calls (INVITEs).

� Lower graph: displays the average call duration.



Figure 10: Average Call Duration Graph

3.3.7.7.3 Generating Call Detail Records

3.3.7.7.3.1 CDR Fields for SBC Signaling

The CDR fields for SBC signaling are listed in the table below. The signaling CDRs are published for each SBC leg.

CDR Fields for SBC Signaling

CDR Field Name Description

SBCReportType Report Type (call start, connect, or end)

EPTyp Endpoint type

SIPCallId Unique ID of call

SessionId Unique Session ID

Orig Call originator ('LCL' for local; 'RMT' for remote)

SourceIp Source IP address

SourcePort Source UDP port

DestIp Destination IP address

DestPort Destination UDP port

TransportType Transport type (UDP, TCP, or TLS)

SrcURI Source URI




SrcURIBeforeMap Source URI before manipulation

DstURI Destination URI

DstURIBeforeMap Destination URI before manipulation

Durat Call duration

TrmSd Termination side (local or remote)

TrmReason Termination reason

TrmReasonCategory Termination reason category

SetupTime Call setup time

ConnectTime Call connect time

ReleaseTime Call release time

RedirectReason Redirect reason

RedirectURINum Redirection URI

RedirectURINumBeforeMap Redirect URI number before manipulation

TxSigIPDiffServ Signaling IP DiffServ

IPGroup IP Group description

SrdId SRD name

SIPInterfaceId SIP Interface ID

ProxySetId Proxy Set ID

IpProfileId IP Profile ID

MediaRealm Media Realm name

DirectMedia Direct media or traversing SBC (yes or no)

3.3.7.7.3.2 CDR Fields for SBC Media

The CDR fields for SBC media are listed in the table below. The media CDRs are published for each active media stream, thereby allowing multiple media CDRs where each has a unique call ID corresponding to the signaling CDR.

CDR Fields for SBC Media


MediaReportType Report type (media start, update, or end)

SIPCallId Unique call ID




Cid Channel CID

MediaType Media type (audio, video, or text)

Coder Coder name

PacketInterval Coder packet interval

LocalRtpIp Local RTP IP address

LocalRtpPort Local RTP port

RemoteRtpIp Remote RTP IP address

RemoteRtpPort Remote RTP port

InPackets Number of received packets

OutPackets Number of sent packets

LocalPackLoss Local packet loss

RemotePackLoss Remote packet loss

RTPdelay RTP delay

RTPjitter RTP jitter

TxRTPssrc Tx RTP SSRC

RxRTPssrc Local RTP SSRC

LocalRFactor Local conversation quality

RemoteRFactor Remote conversation quality

LocalMosCQ Local MOS for conversation

RemoteMosCQ Remote MOS for conversation

TxRTPIPDiffServ Media IP DiffServ

Limit: SBC media CDRs are filled using information received from RTCP., MOS and VoIP transmission quality rating (R-Factor) are not provided, as this requires extracting data from the RTP flow which is not offered in this 1.0 release..

3.3.7.8 Maintenance

For Save and Restore, System Snapshot captures a complete OpenTouch SBC state, including:

� Installed OpenTouch SBC software

� Current configuration

� Auxiliary files

� Software Feature Key



The device automatically takes a first snapshot when initial installation is performed. You may take up to 10 additional snapshots if required. You can restore the OpenTouch SBC to a previous snapshot.



4 Security of configuration and management

4.1 Authentication

4.1.1 Communication server authentication

To improve Communication Server security, management accounts can be protected by a reliable authentication mechanism based on a Radius server. This process offers the great advantage of centralizing the password database for the entire OmniPCX Enterprise network. Specific entries for OmniPCX Enterprise system accounts must be added to the RADIUS user database.

Centralization of all user account passwords is the main reason for having RADIUS client in OXE.The following services use authentication to access OXE.

� TELNET, FTP (unsecured connection)

� SSH, SFTP (secured connection)

� Applications like 8770

Each time a user needs to access one of the above services an authentication is needed. When a RADIUS server is configured the authentication request is sent to RADIUS server. Each of the above access services use a PAM (Pluggable Authentication Module) mechanism to authenticate and establish a session.

Before the OXE release R10.1 there was a need to create a Local RADIUS user for every external

RADIUS user declared in the RADIUS server. The Local RADIUS user was mapped to

mtcl, root,adfexc or swinst .

To allow a better serviceability without compromise the security authentication, a new feature removes this need to create a Local RADIUS user for every corporate user in OXE. Once the authentication is granted by the RADIUS server the OXE will open a session for the user with a default “mtcl” profile.

Corporate Identities Authentication

Corporate identities present in the RADIUS user database (for instance Jim Smith, Mr. Dupont, etc.) can be used for authentication in place of OmniPCX Enterprise system account identities (mtcl, root, swinst, etc.). If the user is authorized to access the system the user name is mapped to its corresponding existing system account (mtcl, swinst, root). System logs corresponding to user actions contain corporate identities and allow modification traceability. Authorization rights and identity mapping are managed at Communication Server level.

4.1.2 OmniVista 8770 authentication

A password policy management is used to secure passwords for specific user accounts (strength and aging).

Password policy and password aging entail the following:

� Verification of the length of the password (can be configured between 2 to 512 digits)

� Verification of the content of the password which must not be based on trivial user information (name, e-mail, etc.)



� Verification of the password expiration time (can be configured between 1 to 24855 days) and warnings (requesting a prompt change of password) sent to the user

� Locking the user account when it exceeds the maximum number of login attempts (can be configured between 1 to 32767 attempts)

� Definition of type of password encryption

� Storage of the last {n} password(s) in the history and restrict the usage of last {n} password(s) if needed (can be configured between 0 to 24 passwords)

Administration accounts on the OmniVista 8770 station can have their security level improved with Radius authentication.

4.1.3 OmniTouch 8400 ICS authentication

Alcatel-Lucent OmniTouch 8400 Instant Communications Suite is composed of different services:

• Telephony service

• Messaging service

• One Number service

• Teamwork service

OmniTouch 8400 ICS administrators and end-users can be authenticated via an external Radius or LDAP (LDAPS) server. the SSO (Single Signed On) mechanism is also available with NTLM.

4.2 Securing management exchanges

4.2.1 Secured SNMP

Simple Network Management Protocol (SNMP) is a protocol which provides configuration, interrogation and alarm notification for devices that can be configured on IP networks.

The SNMP protocol has evolved with increased security needs:

• SNMP v1: Community Name and information are sent in the clear

• SNMP v2c: Community Name is ciphered, but all information is sent in the clear

• SNMP v3: Community Name and information are ciphered

All these versions are supported.

4.2.2 Secured shell (SSH)

Provided this is selected at initial installation, exchanges between machines on the network can be encrypted using SSH. Transmission via SSH offers the advantage of encryption upon initialization. Passwords are not sent non-encrypted (i.e., "in the clear") over the network.

SSH V2 is implemented in:

• Alcatel-Lucent OmniPCX Enterprise Communication Server

• OmniVista 8770

When SSH security is enabled, exchanges are encrypted between:

• Alcatel-Lucent OmniPCX Enterprise Communication Server systems in an ABC network



• Alcatel-Lucent OmniPCX Enterprise Communication Server systems and the OmniVista 8770

This means that SSH security must be enabled on all nodes of the ABC network. Administration stations that may connect to the Com Server must support SSH secure exchanges.

The standard Unix/Linux commands are replaced by secure commands:

• ssh (secured shell) replaces telnet

• ssh (secured shell) replaces rsh (remote shell)

• scp (secured copy) replaces rcp (remote copy)

• sftp (secured file transfer protocol) replaces ftp (file transfer protocol)

Prior to R10.1 release SSH service in OXE could be started only after configuring a trusted hosts file. When OXE was isolated, incoming network connections were allowed only from these trusted hosts managed in OXE.

From the new release R10.1, this limitation is removed and the SSH service can be started even if the OXE is not isolated with a trusted hosts file. Once SSH is enabled, the OXE will allow only secure incoming connections like SSH, SFTP, SCP.

Notes:

• Only the encrypted form is used. For authentication, the trusted host’s mechanism is used.

• Before using the SSH feature to secure communications, all Alcatel-Lucent OmniPCX Enterprise Communication Servers in the ABC network must be version 6.0 or higher.

• For the validation testing of the SSH feature, the tools PuTTY and PSFTP were used with a Windows client; OpenSSH (including SFTP) was used with a Linux/SUN/SOLARIS client.

4.2.3 Secured HTTP (HTTP over SSL)

Security in the http layer has become essential in products such as the Alcatel-Lucent OmniPCX Enterprise Communication Server to complete the security offer introduced by the SSH protocol.

All the applicative exchanges between a client station and the communication server via a web interface are encrypted. The encrypted http packets between any device and the Communication server avoid transferring data such as profiles and passwords in the clear.

The SSL protocol works on Port 443 in TCP.

The web server used to host the https function is APACHE.

4.2.4 Secured legacy remote management

To secure remote maintenance and management accesses from the public PSTN network to the OmniPCX Enterprise, Alcatel-Lucent uses an interface named RMA or eRMA (embedded on IP Media Gateway-Common hardware), which separates the internal network and the external network in order to authenticate remote users.

Through RMA, the administrator can access the two Communication Servers (main and standby), as well as the Communication Server applications.



An automatic call to a remote maintenance center is possible for event alarms. According to the event alarms and configuration, two alarm centers can be called.

The remote access is secured in three ways:

• User authentication based on login and password

o 16 user accounts may be configured, with different user rights (RMA configuration right, reset, etc.)

o After five failed attempts, RMA is unavailable from the outside for 15 minutes

• Callback from the RMA system to identify the call origin:

o The RMA can disconnect, and then dial a predefined number

o The RMA can ask for the number to dial back, before disconnecting and calling back the remote user

• Traceability of actions: whether the connection is set up or not, a history record is created with the date, time, login used, and the called back external number

RMA configuration example to open a "character mode" session:



5 Communication security

5.1 Protection against theft of service (Toll fraud)

5.1.1 Transfer protection

The Alcatel-Lucent OmniPCX Enterprise Communication Server allows an internal user to perform a transfer between two external incoming or outgoing calls (in a standard configuration, this feature is not active). It is possible to restrict transfers to authorized people only. For example, a user may be allowed to transfer an incoming call to an outgoing call, but not an outgoing call to another outgoing calls.

5.1.2 Forwarding protection

A dedicated COS restriction (barring category) allows forwarded calls to be regulated. Rerouted calls are associated with a specific restriction or barring table. For example, a user may be allowed to make an international call, but not to forward a call to an international number or a public cellular number.

5.1.3 Protection on internal phones

Internal call control is based on the following features:

• Call COS (class of service) restriction (barring) according to the extension

• Speed dialing numbers

• Phone lock when user is away

• PIN code for private calls with/without call restrictions (barring)

5.1.4 External call restriction

When a user tries to access a public or private external line, it is possible for the system to monitor dialing by the user and block the call according to user predefined rights. The first digits dialed are checked. If they correspond to an authorized number, the number is sent; otherwise, the user only gets the busy tone or a voice guide. External numbers of up to 20 digits may also be analyzed. Each station has four classes of service restrictions, according to the installation status (day, night, forwarding 1, forwarding 2).

The attendant can transfer a trunk to an extension after the user dials the outgoing prefix or outgoing prefix and the country code, so that the user may make outgoing calls to specific destinations on a one-at-a-time basis. The cost of the call is charged to the user.

5.1.5 Restricted access to a phone set

When it is setup on the set, a user secret code (PIN code) is requested:

• When dialing an external number

• When trying to access telephone facilities (e.g. forward, …)

Pin code policy:

After a defined number of consecutive errors in the PIN code:



• All telephone features using the secret code are denied on this extension

• On UA sets with display, the message: “password forbidden” appears

• Substitution (DISA or by extension) on this extension is denied

• An incident is generated for the extension

The secret code is "unlocked" by the administrator or after a timer (of a duration that can be configured).

The number of error attempts can be 0 to 7, where 0 means there is no control over the number of attempts.

5.1.6 Out of service option

Users can put their deskphone in a specific “out of service” state where it will be necessary to enter its extension number and its PIN code to be able to perform any operation. If the user is not physically present in its office, this mechanism ensures that nobody can use the deskphone and spoof user’s identity.

5.1.7 Discrimination calendar for external calls

A weekly calendar is available to forbid external calls by the system entity. For each day of the week, up to 4 system status changes can be configured.

5.1.8 DISA (direct inward system access) protection

DISA allows remote access to internal company communications or telephone services for teleworkers or mobile workers. This can include call cost management features, such as least cost routing or breakout. The DISA service must be protected against hackers. The Alcatel-Lucent OmniPCX Enterprise Communication Server offers two levels of protection:

• Password control

• Caller line identification with automatic substitution

5.1.9 Control

In a standard configuration, the Alcatel-Lucent OmniPCX Enterprise Communication Server offers a password control feature. If an incorrect password is entered (three attempts per call), the Alcatel-Lucent OmniPCX Enterprise Communication Server stops the call and locks access for a temporary programmable time (five minutes minimum). Repeated attempts during the locked period will double the delay through an iterative mechanism without limit. The Alcatel-Lucent OmniPCX Enterprise Communication Server generates alarms in real time according to each event. The DISA access can be unlocked:

• After the programmed time

• By dialing a prefix number from a phone with specific rights

5.1.10 Calling line identification

The Alcatel-Lucent OmniPCX Enterprise Communication Server identifies the calling line or device by analyzing the CLIP provided by ISDN, cellular, or other public network features. If the line or device is authorized, the caller may be automatically substituted for the office phone.



5.1.11 Call monitoring feature

This accounting feature is an option with the OmniVista 4760 and OmniVista 8770.

The feature can display an alarm and provide an e-mail notification when a threshold is exceeded.

The thresholds can be based on the following profiles:

• Accounting: number, cost and call duration, or a variation of this data

• Performance 1: Duration of exceeding threshold, rate of abandon on called numbers and on attendant groups

• Voice over IP Performance 1: VoIP sent/received volume and out of range records (tickets)

These thresholds can apply to different call types: incoming, outgoing, outgoing private calls, DISA (direct incoming system access) calls 1 and subscription.

When the cumulative counters exceed these thresholds for the period and the object, an e-mail is sent to one or more addresses, or an alarm is generated.

Example:

"Cost control" profile that can be applied to an item in the organization map (a set, a cost center, a department, a trunk, etc.):

When the monthly telephone cost exceeds 10,000 Euro (approximately $13,399.40 USD), or the daily cost exceeds 100 Euro (approximately $134.01), etc., an e-mail is sent to the user Jeanne Doe

Note: Thresholds on Performance, VoIP Performance and DISA are not available for the OmniPCX Office - Performance and VoIP Performance are only available if the corresponding licenses are implemented in the OmniPCX Enterprise

5.2 IP Touch security The security of voice over IP communications is generally considered less secure than in a TDM (Time Division Multiplexing) environment.

Voice flows over a shared network are susceptible of being intercepted and listened to by anybody with access to the LAN, with the help of "freeware" tools. A package of measures at the infrastructure level of the network allows the essential limitation of interception risks (switched LAN environment, VLAN voice segmentation, management of ACLs between VLANS, protection against ARP spoofing or flooding), but the only way of being certain that voice flows are well protected is end-to-end encryption: even if they are intercepted they will prove inaudible.

1 Thresholds on Performance, VoIP Performance and DISA are not available for the OmniPCX Office - Performance and VoIP Performance are only available if the corresponding licenses are implemented in the OmniPCX Enterprise



This allows a level of confidentiality superior to that found in a TDM environment (without special equipment).

In order to have a sustainable encryption solution, it is equally necessary to secure the phases preceding the establishment of voice flows. To this end, encryption and the integrity of the signal between the communication server and IP telephones/Media Gateways must be established.

The authentication of the different elements comprising the IP telephony solution must be a prerequisite to the establishment of secure communications. If not, there is a risk of a certain number of attacks of a "man in the middle" type which puts the confidentiality of the message in danger through the interception of private information.

The initialization of IP terminals must be secure in order to avoid a binary (downloaded from a rogue server) being executed on the set. To this end, IP phones initialize in a secure way by validating the signature of downloaded files.

Alcatel-Lucent has a partnership with Thales, a major security player in the domain of Defense and Enterprises. This partnership in its endeavour to provide clients with vital reliable security solutions has produced a high performance encryption solution responding to the demands of voice communications: real time (delay and commutation time) and a high level of security.

The solution allows the encryption of all communication flows linked to voice at the moment they cross through the LAN and even WAN. It does not encrypt TDM flows for example on a T2 junction or on a link to an analogue post, even if the IP section of the communication is encrypted.

The equipment compatible with encryption is as follows:

• The range of communications servers (IPAS, IPRS, IPCS) and passive communication servers (PCS)

• The Media Gateways IP range (Common Hardware or Crystal)

• The IP Touch range (Alcatel-Lucent 8 series)

• IP Desktop Softphone application (software emulation of Alcatel-Lucent IP Touch 4068 Phone set)

• MyIC client (softphone)

• OmniTouch 8400 ICS servers (application servers and media servers)

This solution strongly depends on standards in order to guarantee sustainability and future evolutions in regards to SIP environments, for example:

� The encryption of the signaling call control by IPSec ESP (RFC 2406) in transport mode with AES encryption in block mode (AES CBC). The signal keys are negotiated between terminals and Com Server with the help of IKE (Internet Key Exchange – RFC 2409) based on a calculated PSK (Pre Shared Key)

� Voice encryption by SRTP (RFC 3711) protocol with AES encryption in counter mode. The symmetrical voice keys are derived from receipts from when the Com Server crossed the encryption signal.

Alcatel-Lucent and Thales have decided to separate communication and encryption functions at Communication Server and Media Gateway level to guarantee the solution’s flawless security.

The advantage of this approach is to avoid deactivation, either accidental or intentional, of the encryption without the user being made aware of it.



Thus, an IP Media Gateway equipped with a module cannot be de-securitized without being taken apart.

The great benefit is that deploying this IP Touch Security solution on an existing Alcatel-Lucent OmniPCX Enterprise Communication Server does not require the re-engineering of the IP telephony solution.

The IP Touch Security solution supports large capacity configurations: up to 15,000 Alcatel-Lucent 8 series sets and 240 Media Gateways. System start-up is optimized to reduce start-up time. A system with 15,000 IP phones restarts in approximately 10 minutes.

The high availability of IPT solution is the same with or without dedicated encryption appliances.

The implementation of the IP Touch Security solution does not affect the Com Server high availability, as the SSM module has a dedicated processor to perform hardware encryption and therefore does not use any resources from the Communication Server where main task is Call Handling.

Alcatel-Lucent has chosen hardware-based encryption for the com Servers and Media Gateways because this hardware encryption does not add any delay to the scale generally found in VoIP (dozens of ms). SSM uses a dedicated processor for encryption that means adding encryption does not add any burden to the Com Server processor signaling where the only dedicated task is the Call Handling.

There is no bandwidth overhead when using SRTP instead of RTP. Packets exchanged during a call have the same size, because the optional fields introduced by SRTP protocol are not used in IPT Security feature, as compared to RTP.

Concerning signaling Call Control encryption, there are supplementary messages exchanged between security modules and IP Touch sets for IPSec negotiation, mainly at system initialization. In all cases, the signaling part of a communication can be considered non-significant when compared to the volume of voice packets.

5.2.1 Encryption architecture

The Alcatel-Lucent IP Touch Security solution provides:

• The capability to encrypt voice and call control signaling flows (confidentiality)

• Integrity of call control signaling (ensuring that messages have not been modified)

• Secure download of binaries and configuration files in IP Touch sets and IP Media Gateways

A Server Security Module (SSM) protects:

• The Communications Servers (Main and Standby)

SoftMSM (embedded in IP Media Gateway) protects:

• The IP Media Gateways (Common Hardware or Crystal)

MGSec (Signaling encryption only) protects:

• The IP Media Gateways (Common Hardware)

A Media Security Module (MSM) protects:

• The Passive Communication Servers (PCS)

• The IP Media Gateways (Common Hardware or Crystal) managed by a PCS



• The OmniTouch 8400 ICS: application & media servers, OmniTouch 8440 MS

• The IP-DR link Voice Logger

An Embedded Security on:

• IP Touch sets

End-to-end communication encryption is supported by an OmniPCX Enterprise configuration comprised of networked nodes. The link between OmniPCX Enterprise nodes is an ABC IP hybrid link.

• Inter-node signaling is encrypted using IPSec

• Voice media is encrypted with SRTP

• Voice Media keys used for encryption are generated by the Com Server managing the called party.



5.2.2 Security modules

The Server Security Module (SSM) and the Media Security Module (MSM) are cryptographic components placed between the "not secured/encrypted" LAN and the "secure/clear" connection to Alcatel-Lucent OmniPCX Enterprise Communication Server components.

• SSM : protects the Com Server

• MSM : protects the Media Gateways

Although the physical aspects of the SSM and MSM are almost the same, they differ in the functions they perform.

Note 1: IP touch security modules are based on the Mistral platform from Thales (VPN encryption), which is itself based on a military design.

The SSMs and MSMs are available in rack-mounted models.

Characteristics Rack-mounted model

SSM-RM/MSM-RM



Characteristics Rack-mounted model

SSM-RM/MSM-RM

Dimensions (depth, width, height) 215mm x 371mm x 43.6mm (19” standard rack mountable)

Ethernet ports (10/100 Mbps) 4 clear and 1 encrypted

Server Security Module (SSM)

The SSM is the central component of the IP Touch Security solution. It is connected by a "crossed" RJ45 patch cord to the Com Server on its "clear" port and to the "unsecure" network on its "encrypted" port.

The SSM negotiates and establishes encrypted signaling sessions with IP phones, Media Gateways (through MSM) and Media Gateways secured with MGSec (see: MGSec) or SoftMSM (see: Signaling and voice encryption on IP media gateway): SoftMSM).

Additionally, the SSM also establishes encrypted media sessions when the media server is protected (Alcatel-Lucent 4645 Voice Media System, IPMG) by this component.

It is transparent to QoS tagging (802.1p/DiffServ) from the Media Gateways or Com Server. It reacts as a bridge from an IP point of view (no routing).

It also manages QoS based on layer 3 tagging, to prioritize telephony traffic (whether media or call control signaling) over non real time traffics.

SSM module installation has no impact on Com Server redundancy operation. There is one SSM module on Main CS and another SSM module on Standby CS. The both SSM modules are active. If an SSM failure occurs on Main CS or if the Main CS fails there is an automatic and transparent takeover performed by the Standby CS and its own SSM module, in order to perform encryption.

Media Security Module (MSM)

The Media Gateway is connected to the "clear" port of MSM through a "crossed" RJ45 patch cord.

The MSM is in charge of encryption for Media Gateway signaling traffic to the Com Server.

It also encrypts media traffic (to other MSMs, to IP Phones, …) using per session keys.

Call control signaling encryption and integrity

IP Touch phones and secured Media Gateways are controlled through a "stimuli" protocol called NOE over IP.

Call Control signaling (from the Com Server to IP Touch phones and from the Com Server to secured Media Gateways is protected using IPSec ESP (transport mode) with AES encryption algorithm (CBC).

Symmetric keys are negotiated between IP Touch phones or a secured Media Gateway and SSM and are changed regularly.

Call Control signaling is protected both in confidentiality and integrity. Integrity is checked using HMAC SHA1 signature of the flow. Integrity means that the message has not been changed between the Com server and IP Touch phones or a secured Media Gateway by a Man In the Middle (MIM) attack. HMAC-SHA1 is used for integrity to the phones. For integrity between SSM and MSMs, AESXCBC is used.

Media encryption



Media (voice) is encrypted using SRTP with AES (counter mode) encryption algorithm.

The benefit of SRTP is that it introduces no bandwidth overhead on WAN compared to un-encrypted traffic. It will not add any additional complexity to "network level" services (QoS, trouble shooting, firewalling) configuration.

Symmetric keys are used and they change at every RTP session. They are sent by the Com Server to end points through encrypted signaling sessions.

Transparent modem (and transparent fax) encryption is also supported (with the straight constraints on delay).

A call between two IP Touch phones registered in two different Alcatel-Lucent OmniPCX Enterprise Communication Server can be encrypted if the two nodes are secured. Encryption within the network is also preformed between a Media Gateway on one node and the IP Touch phones or between two Media Gateways.

Fax relay (T38) is supported, not on SRTP but on IPSec (T38 fax does not use RTP).

Notes:

• Voice media is encrypted, but existing "authorized" devices used to log voice calls (voice loggers) are still compatible with IP Touch Security, except for those capturing packets at the IP level between the components of the IP Touch security solution.

• Audio conferences, whether 3 parties or N parties, are also encrypted, if the conference bridge is located in an IPMG protected by an MSM or by SoftMSM.

Telephone user information

The majority of telephone users are not concerned whether their communications are encrypted or not. Typically, it is an assumed IT manager task to make sure that their communications are secured and not at risk.

Visible information

For demanding users, encryption can take place between the parties if all the parties are able to do encryption (i.e. IP Touch sets, secured IPMG). On each set signaling is encrypted (IPSec). Voice communications are also encrypted (SRTP).

Note 2: This icon is visible on IP Touch phones with a display (not Alcatel-Lucent IP Touch 4018 Phone).

The padlock icon is displayed when encryption (signaling and media) is in operation (with either IP Touch Security or a Security module) for the concerned communication.

If a legacy IP Phone (no encryption capability) enters the conference the padlock icon disappears indicating that encryption is no longer ensured. Signaling remains encrypted on IP Touch but not on legacy IP Phones. Partial encryption remains (voice traffic from IP Touch to IP Touch is encrypted but voice traffic between legacy and IP Touch is in clear mode).

When the non-encrypted user, i.e. the legacy IP Phone (no encryption capability) leaves the conference, the padlock icon reappears, indicating that encryption is now ensured.

In this way, the user can control that the communication is encrypted end to end:

• Only for a communication to another IP Touch phone (this can be verified if both users see the encryption icon)



• Which is on the same campus or which uses a hybrid IP link (through the WAN, the call can overflow via the PSTN, and then call is not on IP from end to end)

Note 3: In the context of end to end encryption, it is recommended not to use Bluetooth handsets or headsets, as these are not encrypted and can be intercepted.

There is no display when communications from IP Touch Phones are not encrypted (media) for instance to TDM end points that are not protected by an MSM.

Note 4: Users cannot decide whether they want a communication to be encrypted or not.

Encryption is decided by the Com Server:

• By default between IP Touch phones

• Depending on the encryption capabilities of end points for all other types of communications (to Media Gateways for instance)

Encryption (Voice and signaling) once configured on SSM applies to all IP Touch phones. IP Media Gateways flows (Signaling and Media) on central area are encrypted. IP Media Gateways flows (Signaling and Media) on remote sites can be either encrypted or not depending on the configuration of a SoftMSM or the implementation of a MSM module (PCS survivability). Another option named MGSec provides Signaling encryption only for IP Media Gateways with a few users on remote areas.

All IP Touch phones on a secured system benefit from encryption. It is sometimes requested that encryption be provided for a small number of telephones, but voice encryption is merely the most apparent aspect of the IP Touch Security feature. Security begins when the IP Touch is initialized, so there is mutual authentication of IP Touch sets and SSM modules, based on the Pre Shared Keys mechanism. This mutual authentication is designed to prevent the possibility of a rogue IP phone trying to connect to the Communication Server.

To ensure a good level of security, all IP Touch sets should take advantage of this mechanism. IP Touch phones may be de-secured only when going in survivability mode without security.

5.2.3 MGSec

In order to provide economic but secure communications for small remote branch offices, the Alcatel-Lucent OmniPCX Enterprise Communication Server provides an "MGSec service" with the GD board. This "MGSec service" is not aimed at replacing the "hard MSM" module but is a complement to address a segment of the market not willing to purchase a hardware security module:

• The MGSec service is only used to protect the IP signaling link (IP Link) between the OmniPCX Enterprise (through the SSM) and the IPMG with authentication and integrity to protect the availability of IPMG against MIM attacks. Additionally, the IP link is also encrypted to protect against sniffing.

• The MGSec does not provide encryption of voice through SRTP

• MGsec is available on Common hardware only, and for small capacity only. It is not available on crystal hardware

• MGsec can only be used in a secured system (with SSM modules)

• The "Firewalling" capabilities of the hard SSM are not supported by MGSec (blocking or opening IP addresses and ports)

• The MGSec has the same initialization process as the hard MSM module

• The MGSec service uses SHA-1 as an integrity method with SSM



• On a site equipped with MGSec, IP Touch phones failover to PCS (without hard MSM) deactivates security: there is no signaling encryption between IP Touch and PCS

5.2.4 Signaling and voice encryption on IP media gateway): SoftMSM

In order to secure the Media Gateway communications (voice and signaling) , it was necessary to insert an MSM box between the GD/GA or INTIP and the LAN network.

The OmniPCX Enterprise is equipped with a powerful Gateway board INT-IP3/GD-3 (for Crystal and Common Hardware) where a "software" encryption solution can be deployed to avoid adding MSM hardware cost.

This "soft MSM" is used:

• To protect the IP signaling link (IP Link) between the Com Server (through the SSM-RM, mandatory) and the Media Gateway, with authentication and integrity, in order to protect the availability of MG against MIM attacks. Additionally the IP link is also encrypted to protect against sniffing

• To encrypt voice though SRTP

This security module uses SHA-1 as an integrity method with SSM-RM box (in front of Com Server).

It has the same initialization process has the hard MSM.

Hard MSM (MSM RM) are still required in the following contexts, even when there are INT-IP3/GD-3 in the IPMG:

• To protect application SIP and RTP flows (UM, My Teamwork, A4645)

• When encryption is required on PCS.

• For some specific cases where INT-IP3 can not replace INTIP (for instance IOIP).



5.2.5 IP Touch security in an ABC network

PreShared Keys (PSK) are loaded into all the SSMs of the network using the Customization Center. These PSKs are unique for each ABC network.

All the nodes in an ABC network must be secured. Each node is equipped with SSM on Com Servers and Media Gateways secured with MSMs or MGSec or SoftMSM:

• The ABC protocol between the nodes is encrypted through SSMs (using IPSec in transport mode), including all the traffic between Com Servers (ABC-M, ABC- R, ABC-F)

• The H.323 protocol is not encrypted between nodes

• RTP between nodes is encrypted (using SRTP) except for the Media Gateways secured by MGSec

5.2.6 Encryption compatibilities

Free seating:

When moved to another place, if the IP Touch set is managed by a different CS, one must ensure that the lanpbx.cfg file downloaded is the same has the one handled by the initial CS (in terms of



SSM signature). If it is not, the IP Touch set will not start. In case of network encryption, IPT Security feature activated on different nodes, our recommendation is to use the same lanpbx.cfg file on all the nodes of the network. This way we can ensure that if a set is move from a node to another one, there will not be any problem with the signature of the lanpbx.cfg file downloaded.

IP attendant 4059:

Signaling and voice flows to desk phone are encrypted. However, signals from CS to the 4059 application on the PC via the ABC-A protocol is not.

Voice Messaging 4645:

4645 Voice Mail traffic can be encrypted using a MSM module

DECT: A voice communication between a DECT set and a secured IP Touch is encrypted on the IP part (from IP Touch and up to the MSM module protecting the IPMG).

Conference:

When doing an internal conference encryption takes place between the parties if all the parties are all able to do encryption (i.e. IP Touch sets, secured IPMG). On each set signaling is encrypted (IPSec). Voice communications are also encrypted (SRTP). An icon showing a locker on IP Touch display tells that encryption is turned on for the involved communication.

Wi-Fi:

Alcatel-Lucent OmniTouch 8118 WLAN Handset (OT81X8) can communicate with a secure IP Touch set but only in clear mode. Nevertheless, WPA2 encryption can take place between the Mobile IP Touch set and up to the centralized WLAN switch. For the ICS (Instant Communication Suite) OmniTouch 8440 MS, once the media server is protected by an MSM module, the RTP traffic between the IP Touch and the OmniTouch 8440 MS media server is encrypted using SRTP. SIP signaling traffic between Media server and Com Server is encrypted using IPSec

5.2.7 SIP/TLS support

For the IP communication solution has opted to put SIP at the core to be able to control all the different kind of components:

• Endpoints

• Trunks to carrier systems

IP Touch Security features now support Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP) to secure SIP communications.

Although this is used for SIP Trunks (Public SIP Trunks), it can be used for high-end IP phones using SIP protocol.

It is an enhancement of the current IP Touch Security features which includes the SSM-RM security module in front of the OmniPCX Enterprise Communication Server. The objective is to ensure compatibility with the installed base.

This improvement is to protect the SIP signaling link between the OmniPCX Enterprise Com Server (through the mandatory SSM-RM module) and:

• Alcatel-Lucent IP Touch 4028/4038/4068 phone Extended Edition NOE/SIP encapsulated (General Avaibility MLE Offer H1/2013)

• Carrier and Service Provider Networks (Public SIP Trunking)



Principles of the IP Touch Security feature to support IP Touch sets configured as encapsulated NOE/SIP:

• The SIP messages exchanged between the IP Touch set and the OmniPCX Enterprise CS are secured using TLS protocol (instead of IPSec for IP Touch sets configured as native NOE).

• The SSM-RM module can manage IPSec protocol and TLS protocol at the same time. IP Media Gateways will continue to use IPSec protocol to secure Signaling Call Control.

• TLS protocol will apply globally to all the Alcatel-Lucent IP Touch 4028/4038/4068 phone Extended Edition sets connected to a secure OmniPCX Enterprise node configured as encapsulated NOE/SIP .

The solution provides an end-to-end encryption (using SRTP protocol) on the same OmniPCX Enterprise node between:

• Two IP Touch sets with encapsulated NOE/SIP

• An IP Touch set with encapsulated NOE/SIP and a secure IP Media Gateway (with MSM-RM or SoftMSM)

• An IP Touch set with encapsulated NOE/SIP and a secure OmniTouch 8400 ICS server (with MSM-RM) for voice messaging or voice conference access

With the release 10.1, in a network configuration (multi nodes) the encryption based on SIP/TLS and SRTP is allowed when a SIP end-point is involved. Signaling encryption of IP hybrid links remains unchanged, i.e. IPsec.

IP touch security solution can also provide a protection for the following SIP Applications. Protection means that communications are ciphered with encryption algorithms.

• Voice mail (only support of ICS(NGVM 8440), local storage and AVST). It’s declared as external voice mail inside OXE.

• My Teamwork. It’s declared as network member inside OXE.

• Automatic Attendant.

The goal of this feature is to enable ciphering of RTP flow between equipments managed by OXE

and a non TLS SIP external application (which doesn’t cipher).



Interception by unauthorized personal inside or outside the society becomes very difficult when encryption is used. Man in the middle attack, recording of communication or identity usurpation becomes so difficult to realize that they are not worth doing.

5.3 Verticals certification Telephony networks must be compliant with the security requirements of other major industries. Two major business sectors with specific security standards are:

• The Payment Card Industry

• The Health Insurance Industry

5.3.1 Payment card industry data security standard

The Payment Card Industry Data Security Standard (PCI DSS) is a widely accepted set of policies and procedures intended to optimize the security of credit, debit and cash card transactions and protect cardholders against misuse of their personal information.

The PCI DSS was created jointly in 2004 by four major credit-card companies: Visa, MasterCard, Discover and American Express.

The PCI DSS specifies the requirements for six major objectives:

Control objectives PCI DSS requirements

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect cardholder data

2. Do not use vendor supplied defaults for system passwords and other security parameters

Protect Cardholder Data 3. Protect stored cardholder data

4. Encrypt transmission of cardholder data across networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software on all systems commonly affected by malware

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need-to-know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security

PCI DSS for all merchants and service providers requires appropriate measures to protect any systems that store, process and/or transmit cardholder data.



IP Touch security can help our customers to be compliant (part of Requirement n°4) with this certification because all VoIP communications over the LAN containing personal and confidential data can be transmitted with IPsec encryption.

In face-to-face and e-commerce environments, IP Touch Security technology can help significantly reduce fraudulent actions.

5.3.2 Health insurance portability and accountability

Health Insurance Portability and Accountability (HIPAA) is a US law designed to provide privacy standards to protect patient medical records and other health information provided to health plans, doctors, hospitals and other health care providers like insurance companies.

HIPAA requires that organizations ensure the confidentiality, integrity, and availability of electronically protected health information, protect against reasonably anticipated threats and hazards, and protect against unauthorized uses or disclosures of the protected information.

All personal medical information that is stored or transmitted electronically is subject to HIPAA regulations.

One of the best practices for keeping your VoIP implementation compliant with HIPAA is the encryption of communications and control packets via IPSec between two IP Phones.

The IP Touch security solution actively participates in the HIPAA privacy requirements by protecting medical and confidential information exchanged over the LAN using IP Phones. All the communications are protected and encrypted by IPsec.



6 Antivirus software

6.1 Antivirus software and the OmniPCX Enterprise

The Communication Server that is the heart of our ToIP solution runs on a Linux platform. Currently, installation of a third party application such as an antivirus product directly on top of this platform is forbidden by Alcatel-Lucent. This is for several reasons:

• This Linux platform is especially customized by Alcatel-Lucent to run real-time application and at the same time, hardened to ensure a high level of security by reducing the number of installed packages and services. The Communication Server must be considered as an embedded system, on which only application developed or customized by Alcatel-Lucent can be executed.

• The Communication Server is not accessed directly by human users and thus cannot be considered as a vector of contamination for viruses, even though internally, the Communication Server makes use of some IP flows known to be able to carry viral loads: FTP, HTTP, SMTP, IMAP

Antivirus use could have dangerous side effects on the performances of mission critical, real time functions handled by the Communications Server.

At the difference of Windows platform where anti-virus support and update is mandatory, running an antivirus on Linux depends on the mission of the application. The following discusses the different ways that worms or viruses use to thrive and how OmniPCX Enterprise is protected.

6.2 OmniVista 8770-specific recommendations for anti-virus

Compatibility:

The OmniVista 8770 applications (server and client) operate correctly in the presence of MacAfee and Norton anti-virus systems.

Other anti-virus programs:

Any other anti-virus system can be deployed on a PC hosting the OmniVista 8770 server or clients. In the event of an incompatibility being detected, we recommend that you contact the OmniVista 8770 support department.

END OF DOCUMENT

Alcatel-Lucent Enterprise Communication Solutions 2013...

Documents

Transcript of Alcatel-Lucent Enterprise Communication Solutions 2013...