VoIP Security Best Practice Vol. III Configuration Guide for Secure VoIP Systems. VoIP Security Best Practice. Vol. III. (Version: 1.

Transcription

1 VoIP Security Best Practice Vol. III (Version: 1.3) NEC Corporation

2 Contents 1. Introduction Abstract Audience Author Acknowledgements Guideline and Configuration for VoIP Infrastructure Devices UNIVERGE SV Terminal authentication Terminal authentication mechanism Configuration Encryption and terminal authentication The encryption key agreement mechanisms SIP complete encryption and partial encryption Encryption configuration IP Phone Terminal DtermIP (SIP) Terminal Authentication Configuration Encryption Configuration Registrar Destination configuration UTerm (NETerm60) Terminal authentication configuration Encryption configuration Registrar Destination configuration DtermSP Terminal Authentication Configuration Encryption Configuration The Other Equipments MG(BRI)-SIP Encryption configuration Guideline and Configuration for Firewall and IP Network Infrastructure Firewall Juniper NetScreen firewall Checkpoint Firewall IP Network Infrastructure Device...22 i

3 3.2.1 Layer 2 Switch Configuration (VLAN-based Logical Separation) Cisco Catalyst Switch Series UNIVERGE QX Switch Series UNIVERGE CX Switch Series BF210/24 Switch Layer 2 switch (802.1X authentication) Router or Layer 3 Switch (RFC2827-based ingress filtering) Guideline and Configuration for User Access Infrastructure Remote Access from the Internet IPsec-based Remote Access SSL-based remote access Wireless LAN Controller...30 ii

4 1. Introduction 1.1 Abstract Network security is one of the top concerns for every organization these days. An increasing number of regulations have been issued in most regions. Security breaches might cause damage to an organization s reputation and/or loss of business opportunities if occurred. Although IP telephony solutions allow for a new way of office communication while reducing network costs, it does however add complexity onto the development and maintenance of corporate networks because of the unique natures of such systems and the coexistence of data and voice traffic. The purpose of this UNIVERGE VoIP Security Best Practice series is to provide the basic guidelines for deploying and maintaining highly secure UNIVERGE IP telephony systems. This document is the third volume of a series of Security Best Practice for designing and implementing secure IP telephony systems. Its primary goal is providing device configuration information in accordance with the principles provided in the first volume and the security models provided in the second volume. 1.2 Audience UNIVERGE VoIP Security Best Practice is intended for network and system managers. Although this document is essentially technical, it can be read without understanding network and system details. Unlike other volumes, this volume contains some of configuration examples of the UNIVERGE SV7000 and network equipments. In order to understand this volume completely, the extra knowledge about these equipments will be needed. The security practice is composed of many volumes to provide proper information as it relates to your specific needs or purposes. Use the first and second volume in order to better understand the security overview. While you can use volumes two and three if your interest is focused on integrating secure VoIP systems. Since comprehensive security for a corporate network includes too many aspects to cover, in this series, we focus on basic issues that are specific to IP telephony systems. For example, we presume that your organization already has a security policy. NEC does not recommend deploying any security technologies or devices without first establishing a security policy. 1

5 1.3 Author Teruharu Serada is the primary author of this white paper. Mr. Serada works within UNIVERGE product and solution planning as a network security technology expert within the UNIVERGE Solutions Promotion Division. 1.4 Acknowledgements Special thanks to Mr. Sam Safa and Mr. Richard Sitters for their technical and grammatical refinement of our manuscript. 2

6 2. Guideline and Configuration for VoIP Infrastructure Devices The security mechanisms and configuration example of each device in VoIP infrastructure (described at second volume) is described in this section. 2.1 UNIVERGE SV7000 NEC s SV7000 (IP-PBX) has the two following security-related functions: Terminal Authentication Mitigate from malicious users attacks Communication encryption Provide Communication Confidentiality Terminal authentication Terminal authentication mechanism It is possible for IP-PBX to mitigate the possibility of the attacks, by authenticating the terminal. The terminal is authenticated by SV7000 and the telephone number is used as identifier. The authentication mechanism is so-called challenge-response authentication and based on HTTP digest authentication defined by RFC2617. This authentication is NOT mutual, i.e. only the terminal is authenticated, and the SV7000 is not. This actually implies that the terminal is not 100% sure of the identity of the voice server. When mutual authentication is needed between SV7000 and the terminal, the one-time password authentication (described at section 2.1.2) should be used. The goal of the HTTP digest mechanism is the authentication of the SIP terminal during a call setup. This authentication is based on a simple challenge-response mechanism where the SIP server (in this case the SV7000) challenges the terminal to give the right answer to a question. If the answer is correct the terminal is authenticated. The terminal is challenged by the SIP server (SV7000) sending a so called nonce. The response to this nonce should contain a hash (MD5 checksum) of the terminal s username, password and the given nonce value itself (to prevent the replay attack). Since the MD5 checksum is returned to the SV7000 (not the actual username and password), the message cannot be intercepted by an attacker to reveal the real username and password of the terminal. As a result, the message cannot be intercepted for a replay attack as the hash is also over the nonce value itself. Figure 2-1 shows the authentication flow process. 3

7 IP phone IP address: Number: REGISTER sip: :5060 SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK23e1b7207 To: From: IP address: SV7000 SP SIP/ Unauthorized Via: SIP/2.0/UDP :5060;branch=z9hG4bK23e1b7207 From: To: Challenge WWW-Authenticate: Digest realm= sipserver0171, nonce= 4341aa99bf7765d9ad6879ab1d7f296d, opaque= c64dd3e7c54c5060a2130b31c34f2c6f, stale=false, algorithm=md5, qop= auth REGISTER sip: :5060 SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKbfadbfcc1 To: From: Authorization: Response Digest response= c7675fc de737e6edb060f354,nc= ,username= , realm= sipserver0171,nonce= 4341aa99bf7765d9ad6879ab1d7f296d,algorithm=MD5, opaque= c64dd3e7c54c5060a2130b31c34f2c6f, qop=auth,cnonce= , uri= sip: :5060, X-termresponse= f3f96c53a763d014bdd2b2aba6545d9c SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bKbfadbfcc1 From: To: Figure 2-1 Terminal Authentication Flow Configuration The default password, used in the terminal authentication, is same as the STN number, configured by AISTL command on the SV7000. When a password change is needed, an ASPW command is used to. The LSPW command can also be used to list all registered passwords. It is strongly recommended that the default password (same as the STN) is changed. Terminal authentication is enabled using the ASPTN/ASPTL command. Terminal authentication is enabled by default. While not recommended for security reasons, it can be disabled under the TERMINAL tab. The SV7000 can also confirm the terminal s MAC address for every call by checking the tuples (phone number, IP address, MAC address) registered with the system during the authentication process. The SV7000 can confirm the MAC address and the caller s terminal number and protect the call from a terminal which is not registered with the SV7000 yet. MAC address confirmation is a function enabled on the system by default for security reasons. While not recommended by NEC, it is a configurable parameter that can be changed using the ASSDN/ASSDL command(s). 4

8 2.1.2 Encryption and terminal authentication VoIP communication (SIP signal message and RTP media stream) can be encrypted when using terminals that support encryption. Table 2-1 below shows the product firmware versions that support VoIP encryption: Table 2-2 Encryption-supported equipment and versions Available equipment MG(BRI) SIP card MG(PRI) SIP card DtermIP(SIP mode, a.k.a ITN) NETerm60 (a.k.a UTerm) DtermSP30 (only in SIP mode) IP PAD Available firmware version SP3826 Issue 1.0 or later SP3884 Issue 5.0A or later or later or later (I version) or later PA-32IPDA/SP-3835 Issue 3.0 or later SV7000 can simultaneously communicate with terminals that support encryption and ones that do not. Encrypted SIP communications are established between SV7000 and encryption-supporting terminals, while SIP communications between SV7000 and encryption-non-supporting terminals are not encrypted. The encryption-supporting terminals and encryption-unsupported terminals can communicate using RTP; however the RTP communication is not encrypted (Figure 2-2).If both terminals support encryption, then the RTP stream between the terminals is encrypted (SRTP, AES encryption bit key). Note that the encryption of the signaling stream is proprietary in current versions. This means that if either one terminal does not support this proprietary SIP encryption scheme, no media encryption is possible. UNIVERGE SV7000 SIP (plain text) Encryption-non-supporting Terminal (ex. MH210) SIP (encrypted) MG (BRI) RTP (not encrypted) SIP (encrypted) RTP (not encrypted) SRTP All traffics to PSTN is NOT encrypted. Figure 2-2 VoIP encryption Encryption-supporting Terminal (ex. NETerm60) 5

9 The encryption key agreement mechanisms The key agreement mechanisms for SIP encryption are shown in Figure 2-3. These mechanisms are based on NEC proprietary implementation. Terminal Authentication SV7000 The Terminal Pass is shared by both SV7000 and the terminal in their first communication. (This procedure is normally executed only once.) One-Time Password Negotiation Request Terminal Pass Terminals (DtermIP, NETerm) One-Time Password Terminal Registration SV7000 Encryption key is generated by using Terminal Pass Registration Request Authentication Challenge SIP REGISTER message Encryption key for SIP Signaling Terminals (DtermIP, NETerm) Encryption key is generated by using Terminal Pass Mutual authentication Figure 2-3 SIP Key Encryption & Distribution Mechanism The key agreement mechanisms for SIP encryption consists of these steps: Step 1. Step 2. Step 3. Step 4. Users configure the One-time Password (OTP) to SV7000 and terminals. Configuring such OTP passwords is dependent on the terminal s implementation as described later under One-time password configuration. When the SV7000 and the terminals are configured with SIP server, they can communicate and exchange Terminal Pass (shared credential) using SIP. Terminal Pass for each terminal are stored in the SV7000 and identified by the terminals MAC addresses. Terminals have only one Terminal Pass per SV7000. The SV7000 administrators can confirm which terminals share the Terminal Pass using the ASCEL command. The Terminal Pass in both SV7000 and the terminals are not lost even when power is turned off. When a terminal sends the SIP REGISTRATION request to the SV7000, the key agreement is negotiated securely using Terminal Pass. This key is used for SIP encryption. SIP communication between SV7000 and the terminal is encrypted using the keys exchanged in Step 3. This encryption key is valid until the terminal is turned off or restarted. However, such keys are updated periodically (once a day). 6

10 One-Time Password configuration OTP OTP One-Time password One-Time password Terminal Pass Agreement Terminal Pass OTP Terminal Pass is shared Terminal Pass - Terminal Pass is different for every terminal (identified by MAC address). - Terminal Pass is not deleted when terminal/sv7000 is turned off. OTP SIP Encryption Key Agreement RTP Encryption Key Generation Terminal Pass Terminal Pass OTP SIP encryption key is shared SIP encryption key Terminal Pass - SIP encryption key is shared when the terminal sends SIP Registration Message. - Terminal key is used to securely exchange the key. - SIP encryption key is valid while the terminal is is on-line. OTP RTP encryption key is sent over encrypted SIP message SIP encryption key Terminal Pass OTP SIP encryption key RTP encryption key OTP SIP encryption key - RTP encryption key is generated by SV7000 and sent to the terminal. - RTP encryption key is valid during the call. Figure 2-4 Keys and Encryption for SV7000 & Terminals Figure 2-4 shows keys and credentials used in encrypted VoIP communication. RTP encryption is implemented in conformity with SRTP specification described in RFC3711. RTP encryption key is provided by the SV7000 in encrypted SIP messages. The RTP encryption key is generated at the SV7000, sent to the terminal in SIP message and used by the terminal. The encryption algorithm is AES and with 128-bits key length. Figure 2-5 shows authentication and SIP encryption key agreement flow. Mutual authentication and SIP encryption key agreement is done using a 4-way handshake. Both server and client authentication use a challenge-response method. Mutual authentication ensures that neither the terminal's identity, nor the SV7000's identity can be forged by an attacker. Both parties are completely sure they are communicating with the correct counterparts. SIP encryption is based on NEC proprietary implementation. This implies that when two terminals are involved, both need to support this NEC proprietary implementation in order for the RTP media to be encrypted (SRTP) and the conversation to be secured. If either of the two terminals does not support this proprietary mechanism, no SRTP is supported, thus the conversation is not encrypted/secured. 7

11 IP phone IP address: Number: Server-auth Challenge IP address: SV7000 SP REGISTER sip: :5060 SIP/2.0 X-Server-Authenticate: Digest realm= sipterm0001, nonce= 270b7ab701415ba62eb1d13d94cda9e5, opaque= ET54LxmXl8s8A6zYbywf-s8M00p4MDYU, stale=false, algorithm=md5, qop= auth Server-auth Response Client-auth Challenge SIP/ Unauthorized WWW-Authenticate: Digest realm= sipserver0019, nonce= fadb376f721d9c18e983aaa960, opaque= 6ece8afae0ac7b0f52c8783ca5bd2ed8, stale=false, algorithm=md5, qop= auth X-Server-Authorization: Digest realm= sipterm0001, nonce= 270b7ab701415ba62eb1d13d94cda9e5, opaque= ET54LxmXl8s8A6zYbywf-s8M00p4MDYU, qop= auth, algorithm=md5, cnonce= 33bd0af5, nc= ,uri= sip: :5060, X-termname= 693bc0a10 REGISTER sip: :5060 SIP/2.0 Authorization: Digest realm= sipserver0019, nonce= fadb376f721d9c18e983aaa960, opaque= 6ece8afae0ac7b0f52c8783ca5bd2ed8, qop=auth, algorithm=md5, cnonce= 0D155040, nc= , uri= sip: :5060, username= SIP/ OK Client-auth Response Encrypted Encrypted Figure 2-5 Authentication Flow (VoIP encryption enabled) 8

12 SIP complete encryption and partial encryption RTP encryption is in conformity with SRTP specification and its mechanism is unique. While SIP encryption has two encryption mechanisms complete and partial, each mechanism uses the same encryption algorithm (AES, 128 bit key length). The difference between them lies in which fields are encrypted. Although TLS (Transport Layer Security, defined by RFC2246) recommends securing the SIP standard (defined by RFC3261) connection, NEC s SIP implementation has proprietary encryption mechanism. This is because NEC s SIP communication uses UDP only as the transport layer protocol. Complete encryption Complete SIP message encryption format is shown in Figure 2-6 below. In this case, the whole UDP payload is encrypted. Even if malicious users capture the packet and analyze it, they cannot analyze which application protocol is used. UDP header SIP header CRLF SIP data (including SDP) To be encrypted Figure 2-6 SIP Complete Encryption Partial encryption When complete encryption is used, the port numbers in SDP used by RTP communication are also encrypted. If there is any NAT or firewall between SV7000 and the terminals, NAT or firewall can t treat the SIP communication and cannot manage the opened/closed ports. To solve this problem, partial encryption mechanism is provided. If the SV7000 is configured to use partial encryption, only NEC original parameters in SIP data field are encrypted. SDP and SIP headers are not encrypted. SIP partial encryption will encrypt the keys that will be used for the media encryption. So, any intruders/attackers will not be able to read the media encryption keys. As a result, the privacy of voice call is preserved. SIP partial encryption message format is shown in Figure

13 UDP header SIP header CRLF SDP SIP data Figure 2-7 NEC original parameters To be encrypted SIP Partial Encryption 10

14 Encryption configuration One-Time Password (OTP) configuration ASCEL command is used to set the One-Time Password in the SV7000. Figure 2-8 shows the Windows MAT tools captured screen image when ASCEL command is issued. When the administrator sets the One-Time Password, its validity period must also be set. The administrator can set its validity to be indefinite; however, this is NOT recommended due to security reasons. The periods of validity (AVAILABLE PERIOD) should be set. The administrator not only sets the one-time password but lists the terminal s MAC address sharing the Terminal Pass, by issuing the ASCEL command. The terminals listed above can have Terminal Pass stored in their configuration, even after the power is turned off. Figure 2-8 One-Time Password Configuration 11

15 Encryption configuration As described in section , there are two mechanisms for SIP encryption. You can select the type of SIP encryption desired using the ASYDL command in the SV7000 configuration as illustrated bellow: ASYDL system data SYS1 INDEX 831 bit 3 SIP communication is encrypted completely. (0/1 = complete encryption/partial encryption) bit 4 Terminal authentication (0/1 = Terminal authentication is disabled/enabled) List 2-1 SV7000 Encryption Configuration Bit 4 should always be set to 1 (Terminal authentication is enabled). The parameter for SIP encryption method is INDEX 831 with possible values, 18 (complete encryption) or 10 (partial encryption). Figure 2-9 SV7000 Encryption Configuration (Left: Complete Encryption, Right: Partial Encryption) 12

16 2.2 IP Phone Terminal This section describes the IP phone configuration for secure VoIP system. These configurations are applicable for SIP-enabled device, since SIP is supposedly used in this practice as the call signaling protocol DtermIP (SIP) DtermIP (SIP mode) also supports VoIP encryption. It also supports the terminal authentication mechanism Terminal Authentication Configuration Configuration Menu 2. SIP Settings 1. User 1. User ID User ID (Input the terminal phone number as the identifier) 2. Password Password (Input the password set to SV7000) List 2-2 DtermIP Terminal Authentication Configuration This configuration is not mandatory. If the User ID and password are not set or entered incorrectly, then a prompt for the correct User ID and password is displayed Encryption Configuration Configuration Menu 2. SIP Settings 6. Encryption 1. Authentication Mode 2. Enabled 2. One Time Password One Time Password (Input the one-time password set to SV7000) List 2-3 DtermIP Encryption Configuration In order to stop VoIP encryption, set Authentication Mode to 1. Disabled. 13

17 Registrar Destination configuration If the SV7000 is behind a NAT device (router/firewall), then the IP address, being specified by the client as the SIP server, is different from the SV7000 SP (Signaling Processor) s IP address. (Figure 2-10) SIP server address : SIP server address : NAT box SIP server address : Destination IP address is translated by NAT. Figure 2-10 SV7000 Access via NAT device The registrar destination configuration is used in this case. NAT address is set as the SIP server address, and SV7000 SP s address is set as the registrar destination. Configuration Menu 2. SIP Settings 2. Server Address & URI 1. 1st Server (Input NAT s IP address) 5. RegistrarDestination 1. 1st Server (Input the SV7000 SP s IP address) List 2-4 DtermIP Registrar Destination Configuration Note that the extra configuration is not needed when the terminals are behind the NAT. 14

18 2.2.2 UTerm (NETerm60) Uterm (sold as NEterm 60 in Japan) is an encryption-supporting terminal. also supports the terminal authentication mechanism. It Terminal authentication configuration ** Detailed configuration can be obtained from the corresponding manuals ** Encryption configuration Admin Main Menu 8. Authentication 1. Mode Authentication Mode On 2. OneTimePassword OnetimePassword (Input the one-time password set to SV7000) List 2-5 NETerm/UTerm encryption configuration In order to stop VoIP encryption, set Authentication Mode to off. 15

19 Registrar Destination configuration In the case of SV7000 access via NAT (Figure 2-10), both SV7000 SP s address and NAT address must be specified. The UTerm user can specify the SIP server s address by using function keys, but they cannot specify registrar destination address. The VTConfig program must be used in this case. Figure 2-11 VTConfig Interface Registrar Destination configuration is shown in Figure VTConfig uses SIP, SDP and RTP as the communication protocol. If there is any firewall in between NETerm/UTerm and the PC running VTConfig, the firewall must be configured to allow such communication DtermSP30 DtermSP30 also supports VoIP encryption Terminal Authentication Configuration If the user DtermSP30 first or do not configure the authentication information, then the user is prompted to enter the login name and the password. (Figure 2-12) Figure 2-12 DtermSP30 Login Prompt 16

20 The user can enter the login mane and the password every time he/she uses the DtermSP30. These values can be set statically in the DtermSP30 in order to login automatically as soon as the DtermSP30 is launched (this feature is called as Autologin ). In order to configure the Autologin feature, use the following commands: 1. Select the Config setting button. 2. Select the User tab from the dialog box. 3. Check the AutoLogin checkbox and enter the LoginID and Password. (Figure 2-13) Figure 2-13 DtermSP30 Autologin Configuration Encryption Configuration Using DtermSP30Config program, the user can set whether he/she uses the VoIP encryption mechanism or not. If he/she wants to encrypt the communications, put a checkmark in the checkbox as shown in Figure Unlike other terminals, DtermSP30 does not require setting the One-Time Password. This is due to the difference in the key exchange mechanism between the DtermSP30 and the other terminal products. Although the key exchange mechanism is slightly different, the registration message flow and encryption mechanism is completely the same. 17

21 Figure 2-14 DtermSP30 Encryption Configuration 18

22 2.3 The Other Equipments MG(BRI)-SIP Encryption configuration MG(BRI)-SIP supports VoIP encryption. By setting a One-Time Password, VoIP encryption is enabled. To set one-time password, use the set one_time_password command as shown below (List 2-6). -<Configuration mode>main menu- Standard --- input: 1 Custom --- input: 2 Quit --- [Q/q] Input: 2 MG-BRI>set one_time_password One Time Password: input the one-time password set to SV7000 MG-BRI>save config ** Don t power off in progress ** Do you need save? [Y/N]:Y List 2-6 MG(BRI)-SIP One-Time Password Configuration You can confirm that the One-Time Password is set on the MG(BRI)-SIP by issuing the show one_time_password command as shown below (List 2-7). Please note that the assigned One-Time Password is deleted from the configuration setting when the first registration is completed. MG-BRI>show one_time_password One Time Password: List 2-7 MG(BRI)-SIP One-Time Password Confirmation 19

23 3. Guideline and Configuration for Firewall and IP Network Infrastructure The security mechanisms and configuration example of each device in network infrastructure (described in the second volume) is described in this section. 3.1 Firewall VoIP communication may be inspected and controlled by a firewall, since such systems are built on an existing IP network infrastructure. The firewall can be implemented in various ways such as an application level gateway, termination point for all TCP and UDP connection, and/or as a traffic filtering device which inspects and routes all incoming and outgoing packets. When an organization deploys a VoIP system on existing IP network, the firewall function required by the VoIP system can coexist with an existing firewall without violating the organization s security policy. The firewall devices that have stateful packet inspection function are now very widely deployed. If stateful inspection technologies are used with VoIP, it has the responsibility to: Protect from irregular packets which prevents from replay and UDP flood attacks using deep inspection features. Open and close the necessary UDP ports used by an RTP stream. These ports are usually closed and are opened when the firewall need to pass RTP streams. Not all firewall devices will support NEC s SIP implementation. The following firewall products appear to properly handle NEC s SIP communication. Juniper NetScreen firewall Checkpoint firewall-1 In order for the SV7000 and these firewall products to interoperate with VoIP encryption, the system administrator must use SIP Partial Encryption described in chapter If the SIP Complete Encryption is used with these firewalls, the firewalls may not properly handle the NEC SIP communication thus opening/closing the necessary UDP ports. No application gateways will support NEC s SIP implementation at the current state. Ingate s SIParator product has plans to support NEC s SIP implementation but its release date is not fixed yet. 20

24 3.1.1 Juniper NetScreen firewall NetScreen firewall products have not supported NEC s SIP implementation yet. Juniper and NEC have worked closely to support NEC s SIP implementations. Final release dates have NOT been completed Checkpoint Firewall-1 Checkpoint Firewall-1 has not supported NEC s SIP implementation yet. As a result of test with Firewall-1, SV7000 and terminals, some problems were found. Checkpoint and NEC are continuing to work closely in order to fully support NEC s SIP implementation in the near future. The dates to fully support such NEC SIP implementation have NOT been finalized yet. 21

25 3.2 IP Network Infrastructure Device Overview and configuration of the security related functions that are provided by the network devices (multilayer switch, router, etc), is described in this section. The security related functions, of which the network devices are responsible for are following: Network Separation (physical/logical) Ingress Filtering System Availability & Uptime Separation of voice from data traffic can be done via multiple technology methods. One of those methods is using Virtual LAN (VLAN). In this section, only logical separation method using VLAN is described. This method is often used to add a VoIP system and equipments to an existing IP data network and cabling infrastructure Layer 2 Switch Configuration (VLAN-based Logical Separation) In order to mitigate the possibility of Denial-of-Service (DoS) attacks against servers, and achieving Quality of Service (QoS), corporate networks need to be separated into a voice and data networks. In other words, traffic needs to be classified between data and voice. PCs, application and groupware servers are connected to the data network while the IP-PBX, VoIP gateways and IP phones are connected to the voice network. In some cases, some PCs connected to the data network may need to communicate with the IP-PBX and VoIP gateways using an installed Softphone (DtermSP30) application. In other cases, PCs are connected to the network via a layer 2 switch on the IP phone. Under such circumstances, the layer 2 switch must separate voice from data traffic at a single physical entry port into the network. Data network Voice network L2SW Voice and data Data Data Figure 3-1 Network Separation 22

26 IP phone can insert a VLAN tag into the packets it generates while passing packets from a PC without inserting any VLAN tag. This allows the network layer 2 switches to separate voice from data traffic. Traffic separation and/or prioritization - interface separation - QoS parameter (Precedence etc) addition - Queuing Packet from PC (untagged) Packet from IP phone (with VLAN-tag) L2SW PC and IP phone is connected to single port. Figure 3-2 PC and IP Phone Connection Cisco Catalyst Switch Series The following network is considered as an example. the Layer 2 Switch (L2SW). Catalyst is used as FastEthernet NO.24: upper FastEthernet NO.3: PC All packets are VLAN-tagged VLAN-ID: Voice=201, Data=101 Data and voice core FastEthernet NO.1&2: PC and IP-phone PC connected via IP-phone Figure 3-3 Sample Network with Catalyst Switches 23

27 The Catalyst switch in this case should be configured as follow:... interface FastEthernet0/1 description IPphone switchport trunk encapsulation dot1q switchport trunk native vlan 101 switchport trunk allowed vlan 101,201 switchport mode trunk! interface FastEthernet0/2 description IPphone switchport trunk encapsulation dot1q switchport trunk native vlan 101 switchport trunk allowed vlan 101,201 switchport mode trunk! interface FastEthernet0/3 description DataPC switchport access vlan 101 switchport mode access! interface FastEthernet0/4... interface FastEthernet0/24 description Uplink switchport trunk encapsulation dot1q switchport trunk allowed vlan 101,201 switchport mode trunk... List 3-1 Catalyst VLAN-based Network Separation Configuration When a PC and an IP-phone are connected to single port on the Catalyst L2SW and voice & data traffic are separated by configuration that port as a trunk. In the sample configuration above, VLAN-ID for data and voice are 201 and 101 respectively. Since VLAN tag is not attached to data traffic packets, VLAN for data is specified as the native VLAN. Voice and data traffic will be sent to the core network through interface number 0/24 (FastEthernet0/24). VLAN tag is attached to all packets from/to FastEthernet0/24. QoS-related parameters (mls command, priority-queue command and so on) must be configured; such configuration is left out from this example. Please check the proper references for QoS configuration guideline and examples. Please be sure to configure QoS-related parameters in every case. 24

28 UNIVERGE QX Switch Series Figure 3-3 is also considered as a configuration example. QX-S3026C-PW is used as the L2SW. QX switches in this case should be configured as following:... vlan 1 # vlan 101 # vlan 201 #... # interface Ethernet0/1 description IPPhone port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan port trunk pvid vlan 101 # interface Ethernet0/2 description IPPhone port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan port trunk pvid vlan 101 # interface Ethernet0/3 description DataPC port access vlan 101 #... interface Ethernet0/24 description Uplink port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan List 3-2 QX-S VLAN-based network separation configuration The configuration is very similar to Cisco s Catalyst configuration. VLAN-ID for data network is specified as the default VLAN on Ethernet 0/1 and 0/2. The port trunk pvid command is used for specifying the default VLAN. QoS-related parameters (traffic-priority command) must be configured; however, the configuration is left out from this example. Please check the proper references for QoS configuration guideline and examples. Please be sure to configure QoS-related parameters in every case. 25

29 UNIVERGE CX Switch Series Figure 3-3 is also considered as an example. The UNIVERGE CX-FH5248 is used as the L2SW. The CX-FH5248 in this case should be configured as follow:... interface vlan vlan add port 1/52 tagged add port 1/1-3 untagged exit interface vlan vlan add port 1/1-2 tagged add port 1/52 tagged exit List 3-3 CX-FH5248 VLAN-based network separation QoS-related parameters ( config qos enable, class-map, and policy-map commands) must be configured; however, the configuration is left out from this example. Please check the proper references for QoS configuration guideline and examples. Please be sure to configure QoS-related parameters in every case BF210/24 Switch Figure 3-3 is also considered as an example. The BF210/24 is used as the L2SW. The BF210 switch in this case should be configured as following:... # VLAN create vlan default delete 1-24 create vlan VLAN101 tag 101 create vlan VLAN201 tag 201 config vlan VLAN101 add tagged 24 config vlan VLAN101 add untagged 1,2,3 config vlan VLAN201 add tagged 1,2,24... List 3-4 BF210/24 VLAN-based network separation QoS-related parameters ( create access profile command) must be configured; however, the configuration is left out here. Please check the proper references for QoS configuration guideline and examples. Please be sure to configure QoS-related parameters in every case. 26

30 3.2.2 Layer 2 switch (802.1X authentication) Refer to corresponding 802.1X configuration for the different access layer 2 switches. 27

31 3.2.3 Router or Layer 3 Switch (RFC2827-based ingress filtering) To mitigate the possibility of DoS attacks, protection against source IP address spoofing is required. The most effective countermeasures to IP address spoofing is ingress filtering (defined in RFC2827). Consider the following network diagram scenario (Figure 3-4) as an example. Core network Router or L3SW L2SW Ethernet 0/ /24 Ethernet 0/ /24 Client segment: /24 Figure 3-4 Sample Network (Ingress Filtering) In this example, the client segment is connected to the core network through the router or Layer 3 switch (L3SW). Ingress filtering works when the Client s IP packets source IP address is limited to a certain range. In the example above, the address range (IP subnet) is /24. An ingress filtering configuration example using Cisco s IOS is shown below: access-list 101 permit ip any access-list 101 deny ip any any... interface Ethernet 0/0 ip address interface Ethernet0/1 ip address ip access-group 101 in ip accecc-group 102 out List 3-5 Ingress Filtering Sample Configuration 28

32 4. Guideline and Configuration for User Access Infrastructure 4.1 Remote Access from the Internet A remote access system, which implements a secure virtual path, may be deployed to access a VoIP system from a remote site (worker s home, hotels, etc). A softphone (DtermSP30) and/or wireless phone (MH210 & FOMA/WLAN dual mode phone) can work in scenario as long as such secure virtual path is created. Secure virtual paths can be setup using many Virtual Private Network (VPN) technologies. Two of such technologies are described below in brief IPsec-based Remote Access When IPsec-based remote access systems are deployed, all IP-based application can be used securely through the IPsec VPN tunnel. Remote users can use the DtermSP30 as if they are connected to intranet directly. When the DtermSP30 phone is used through such communication medium (the Internet), network bandwidth, delay and jitter should be considered as they may seriously influence the voice communication quality. Based on such network condition, the DtermSP30 may not work very well. Please refer to the corresponding products manuals for proper and accurate configuration SSL-based remote access SSL-based remote access VPN (SSL-VPN) implements secure connectivity without utilizing any PC VPN client software. Unlike IPsec-based remote access, SSL-VPN does not support all IP-based applications. Many SSL-VPN vendors offer various type of SSL-VPN. Not all SSL-VPN products can support the DtermSP30 (softphone) voice application. NEC has tested a variety of such solutions. We found that the NetScreen SA/RA can interoperate with the DtermSP30 without any issues. However, the NetworkConnect must be used instead of the SAM (Secure Application Manager) (both J-SAM and W-SAM) when using the DtermSP30. Moreover, network quality requirements are more critical when compared with IPsec-based remote access VPN solutions. Please refer to the corresponding NetScreen SA/RA product manuals for configuration examples and guidelines. 29

33 VoIP Security Best Practice Vol. III 4.2 Wireless LAN Controller The MH Wireless phones (JustPhone) and WLAN/Cellular dual mode phone (ex. FOMA N900iL in Japan) are connected to the in-house VoIP infrastructure via the WLAN infrastructure. Due to their physical access nature, WLANs are more exposed to security threats than wired LANs. A radio wave from WLAN access point can be transmitted through a wall, a wooden-door and/or a window. To mitigate from the possibility of un-authorized access, communication encryption (layer 2 data) and terminal mutual authentication should be deployed when using a WLAN. Such authentication and encryption can not only mitigate from potential DoS attacks to the VoIP systems, but also prevent malicious terminals from connecting to the in-house WLAN and LAN network. The following encryption and authentication features/algorithms can be used with based WLAN systems. - - Terminal Authentication SSID Authentication Shared Key Authentication (used with WEP Encryption) MAC address-based Access Control 802.1X and EAP Authentication (EAP-MD5, EAP-LEAP, EAP-TLS, EAP-TTLS, PEAP) Communication encryption WEP (Wired Equivalent Privacy) * 64bits Key Length Encryption * 128bits Key Length Encryption WPA / TKIP encryption (with integrity check) WPA2 / AES CBC-MAC Protocol (CCMP) When a WLAN is deployed in a corporate network, 802.1X authentication and dynamic key management mechanism (dynamic WEP, WPA and WPA2) should be used in order to adhere to similar wired LAN security levels. SSID and shared key authentication does not provide reliable authentication since WEP does not provide enough confidentiality due to its poorly designed key management technique. As a result, attackers can easily decrypt encrypted packets. It is recommended (whenever possible) to use WPA2 encryption in order to provide more secure VoIP communications on WLAN networks. NEC s UNIVERGE WL (Wireless LAN Infrastructure solutions) series products supports all the above security features. The MH200 series phones support WEP (64bits and 128bits key length) and WPA2 for encryption, WPA2 is recommended for secure VoIP communications across WLANs and should be configured as such. In case of using WPA2, digital certificate for clients will be installed prior to setting the configuration. Digital certificates must be installed via the Web browser management interface. MH210 configuration [4] WLAN setting [3] Security mode [5] WPA2 EAPTLS List 4-1 MH210 WPA2 Settings 30

34 For additional configuration information on the WLAN Controllers and the MH200, please refer to the corresponding products manuals. Although choosing a non-nec WLAN Infrastructure (UNIVERGE WL) solution is always a possibility, it is important to understand that NEC does not recommend using the MH Series (JustPhone) and/or dual-mode phones with other manufacturer s infrastructure WLAN products. This is due to features implemented on the UNIVERGE WL products that will greatly affect the service quality (throughput, handover time between APs, and so on) of the wireless voice terminals. If you deploy NEC s MH/Dual-Mode series phones with any other WLAN equipment,, please ensure that it at least supports 802.1X and WPA to provide the acceptable level of VoIP security across your wireless LAN. 31