VOTER User‘s Guide - support-kb. · PDF fileUser’s Guide for VOTER, the...

Version 0.1.7 | MAY 2018

This User’s Guide leads you through necessary steps for running and analyzing test cases of VOTER, the EUROCONTROL VoIP in ATM Test Suite.

It also helps you with more advanced functionalities like running distributed test cases, configuring IPsec or synchronizing the

system clock against NTP servers.

This document was developed for EUROCONTROL by Spirent under contract no. 10-110903-C Nov 2010. ©2018 The European Organisation for the Safety of Air Navigation (EUROCONTROL). All rights reserved. This document is published by EUROCONTROL for information purposes. This document may be copied in whole or in part, provided that EUROCONTROL is mentioned as the source and to the extent justified by non-commercial use (not for sale). The information contained in this document may not be modified without prior written permission from EUROCONTROL. The use of the document is at the user’s sole risk and responsibility. EUROCONTROL makes no warranty, either implied or express, for the information contained in this document, neither does it assume any legal liability or responsibility for the accuracy, completeness or usefulness of this information.

VOTER User‘s Guide

0/21 User’s Guide for VOTER, the EUROCONTROL VoIP in ATM Test Suite | 2018-05-03

CONTENT

Document Change Record ........................................................................................................... 1 0 Scope ...................................................................................................................................... 2 1 Requirements .......................................................................................................................... 2 2 Download ................................................................................................................................. 2 3 Installation ............................................................................................................................... 3 3.1 TTworkbench .................................................................................................................... 4 3.2 VoIP in ATM Test Suite ..................................................................................................... 4 4 Running the Test Cases .......................................................................................................... 6 4.1 Analysis ............................................................................................................................ 7 4.1.1 Test Case Filtering .................................................................................................. 7 4.1.2 Filtering of Log Events in the Graphical Logging View ............................................. 8 4.1.3 Filtering of Log Events in the Textual Logging View ................................................ 8 4.2 Saving Configurations and Test Results............................................................................ 9 5 Configuration ........................................................................................................................... 9 5.1 Detailed Overview of the Module Parameters ................................................................. 10 5.2 Configuration for Running SNMP Supervision Test Cases .............................................. 10 5.3 Configuration for Running Interoperability Test Cases .................................................... 10 5.4 Configuration for Running Network Performance Test Cases ......................................... 10 6 Details ................................................................................................................................... 14 6.1 Core Language Editor (CL Editor) ................................................................................... 14 6.2 TTthree (TTCN-3 Compiler) ............................................................................................ 15 6.3 TTman (Test Execution Management) ............................................................................ 15 6.4 TTmex (Distributed Test Platform) .................................................................................. 15 6.4.1 Configuration of the Distributed Performance Measurement Tests ........................ 15 6.4.2 Execution of the Distributed Performance Measurement Tests ............................. 16 7 NTP Time Synchronization .................................................................................................... 16 7.1 How to Install and Run NTP Daemon .............................................................................. 16 7.1.1 Installing NTP Daemon on Windows ..................................................................... 16 7.1.2 Installing NTP Daemon on Linux ........................................................................... 17 7.2 Checking if NTP is Properly Synchronized ...................................................................... 18 8 IPsec Policy Settings ............................................................................................................. 19 8.1 Transport Mode ............................................................................................................... 19 8.1.1 Create an IPsec Negotiation Policy on Computer “A” ............................................ 19 8.1.2 Assign the Policy ................................................................................................... 20 8.1.3 Create an IPsec Negotiation Policy on Computer “B” ............................................ 21 8.1.4 Rule Enforcement on Computer “A” ...................................................................... 21 8.1.5 Rule Enforcement on Computer “B” ...................................................................... 22 8.2 Tunnel Mode ................................................................................................................... 22 9 Appendix ................................................................................................................................ 23

User’s Guide for VOTER, the EUROCONTROL VoIP in ATM Test Suite | 2018-05-03 1/23

DOCUMENT CHANGE RECORD Edition Number Edition Date Reason for Change Pages Affected

0.1.0 2011-07-27 Initial version All

0.1.1 2012-01-24 Name change All

0.1.2 2013-06-03 Insert optional steps 4, 6

0.1.3 2013-12-03 Screenshots and content 5, 6, 8, 9, 21

0.1.4 2013-12-19 Added sections 5.2, 5.3, 5.4

All

0.1.5 2017-03-21 Screenshots and content All

0.1.6 2017-11-15 Content update, added module parameter 2, 3, 10

0.1.7 2018-05-03 Content update, added Interop Test Enviroment example

3, 13

2/23 © 2018 EUROCONTROL – All rights reserved

For a successful proceeding please follow the instructions step by step!

If you need any assistance please contact Spirent’s customer care department: Mr. Dirk Borowski, Manager Support Services Phone: +49 30 726 19 19 0 Email: [email protected]

0 SCOPE VOTER provides a conformance test suite for VoIP components in Air Traffic Management (ATM) systems using SIP/SDP. The test purpose of the VOTER 3 test suite is specified in “VOTER 3.0.3. Baseline Specification”. The test purpose of the VOTER 4 test suite is specified in “VOTER 4 Baseline Specification”. The objective of the present document is to provide important usage and reference information to effectively use VOTER Test Suite. This manual is designed for all users of VOTER. To use VOTER efficiently, you should be familiar with Air Traffic Management (ATM) systems and TTCN-3.

1 REQUIREMENTS Operating Systems: Microsoft Windows 7/8/10 Linux (GTK2, x86-32, x86-64) Java 2 Platform: Version 8 JDK or JRE

Download at www.oracle.com/technetwork/java/javase/downloads/index.html. We strongly recommend using the above Java JDK. With the OpenJDK / IcedTea for Linux the TTworkbench license will not work correctly!

Memory: 2 GB (8 GB recommended)

License File Before you start download, please make sure you have a valid license file. Otherwise please contact our sales team at [email protected].

mailto:[email protected]

http://www.oracle.com/technetwork/java/javase/downloads/index.html



2 DOWNLOAD Please go to Spirent’s Customer Service Center at https://support.spirent.com and download these products: TTworkbench the test platform required to run the test cases TTsuite-VOTER the adaptation and project settings required to connect to DUT VOTER Binaries the runnable jar files of the test suite

Step 1

In case you are not registered yet, go to https://support.spirent.com/SpirentSignUpPage and fill in the registration form. The support team will check your data and notify you about your approval.

Step 2

Login at Spirent’s CSC and click on the download app tab on the left side.

Step 3

Select the product line TTworkbench and filter for categories and operating system. Download the purchased TTworkbench version and the TTplugin TTmex. More information can be found in the Knowledge Base Article SOL13477: https://support.spirent.com/SpirentCSC/SC_KnowledgeView?id=SOL13477

Step 4

Select the release type Controlled Release. Click on folder TTsuites for TTworkbench, download the TTsuite-VOTER and VOTER Binaries and save them in your preferred directory. More information can be found in the Knowledge Base Article SOL13545: https://support.spirent.com/SpirentCSC/SC_KnowledgeView?id=SOL13545

Step 5

Save the license file in your preferred directory.

Step 6

Optional: If you need to execute the test cases *_COS1, please download a jpcap installer from a reliable source or install Wireshark (https://www.wireshark.org/).

https://support.spirent.com/

https://support.spirent.com/SpirentSignUpPage

https://support.spirent.com/SpirentCSC/SC_KnowledgeView?id=SOL13477

https://support.spirent.com/SpirentCSC/SC_KnowledgeView?id=SOL13545

https://www.wireshark.org/


3 INSTALLATION 3.1 TTworkbench

Step 1

Windows Platform: Double click on TTworkbench-xxx-installer.exe (to be found on desktop or selected directory). Linux Platform: Use command line java -jar TTworkbench-xxx-installer.jar

Step 2

Follow the pop up installation wizard. On request, browse for the valid license file, already saved in your favored directory.

VOTER Test Suite and TTworkbench require a valid license file for execution.

Step 3

Start TTworkbench from created desktop icon or menu entry.

Step 4

Start a new workspace by accepting the default workspace location on request or choose an existing one.

3.2 VOTER Test Suite

Step 5

In the TTworkbench menu, click on menu item Help Install New Software...


Step 6

Click Add… Archive.

Choose the downloaded installation file TTsuite-VOTER_xxx_archived-site.zip. Click Select All Next Next.

Accept the terms of license agreements. Finish and confirm to restart TTworkbench.

Step 7

After restart, import the installed test suite. Close the welcome tab. In the project view, just click on the right mouse button, go to menu: File Import TTCN-3 TTCN-3 Test Solution Projects. Select the installed Test Suite and click Finish.

Step 8

Unzip the VOTER_xxx.zip file. Copy the ttcn3build folder. Open the VOTER folder in the Package Explorer (TTCN-3 Development Perspective). Paste the ttcn3build folder into the root of the VOTER folder. Further details about installation you can find in the integrated Users Guide. Click on: Help Help Contents Spirent TTworkbench Users Guide.

Step 9 (Optional)

If you need to execute the test cases *_COS1, please install jpcap or Wireshark with the downloaded installer.


4 RUNNING THE TEST CASES Step 1

Open the VOTER_xxx folder in the Package Explorer (TTCN-3 Development Perspective).

Step 2

Open the folder Testcases and double click on one test campaign loader file xxx.clf (with the icon ).

(The perspective will automatically switch into the TTCN-3 Execution Management.)

Step 3

Start your IUT.

Step 4

Click on test campaign name to edit the parameters in the Parameters View (below Management View).

For configuration details please refer to “Chapter 5. Parameterization”.

Parameters are configured with default value. Please use MBS (Message Building System) to change the values.

Step 5

Execution Select one test case by single click and press the Execute tests button or start the execution with double click.

Further details please find under Help Help Contents Spirent TTsuite-VOTER.


4.1 Analysis When you click on the TTCN-3 Graphical Logging tab you see the results of the execution as a graphical output. A single click on a “send” message arrow provides further details of the TTCN-3 template representation in the Test Data View. Double click on “send” and “receive” arrows for a coding in the Dump View. A single click on a “match” or “mismatch” box shows you the received message compared to the expected TTCN-3 template. Mismatched values are marked red.

4.1.1 Test Case Filtering

To filter the displaying of test cases based on their verdicts in the Management View, in the menu of the Management View select Verdict Filter as shown in the following figure.

Result Analyser

Graphical Online Logging

Management View

Test Parametrization


Following dialog will pop up and the verdicts can be chosen.

4.1.2 Filtering of Log Events in the Graphical Logging View

The Graphical Logging View provides the filtering of logs, in order to limit the displayed symbols. Pressing the filter button will popup a selection menu, where to filter the logging events and to enable or disable the filter mechanism.

4.1.3 Filtering of Log Events in the Textual Logging View

The Textual Logging View provides a set of mechanisms for filtering the logs, in order to limit the amount of log output. Following criteria can be used for the filters:

• Component name • Log event type

In addition to the previously mentioned filtering criteria, the Textual Logging View provides the possibility to filter the displayed events by their textual content. The text filter can be enabled or disabled by using the view's menu, as shown in the following figure.


4.2 Saving Configurations and Test Results

The current executed run of test cases can be saved in a *.tlz file. Press the export button and select “Export Log” in the Management View.

The generated *.tlz file (with the icon ) contains the current configuration (CLF) and the executed log traces.

This file can be imported for reviewing. Press the import button and select Import Log.

To run configured test cases again, please press the import button and select Import Session.

In order to generate a test report, use this button. Further details about execution and savings you can find in the integrated Users Guide, Chapter “Using TTworkbench TTman”. Click Help Help Contents Spirent TTworkbench Users Guide.

5 CONFIGURATION TTCN-3 allows to extract test suite information that is available in parameters the user can configure at runtime. This information is referred to as module parameters in TTCN-3, or more generally as PIXIT (Partial Protocol Implementation Extra Information for Testing). A detailed description of all available module parameters will be provided in the following section.

If the test adapter parameters need to be configured, e.g. for the correct port mapping, please refer to the TTworkbench User's Guide, Chapter 8.2.1.6. "Setting the Test Adapter".

The delivered configuration of the test suite enables SIP message transport via UDP. Changing the transport protocol to TCP, please replace the UDP port plugin with the TCP port plugin (see TTworkbench User's Guide, Chapter 8.2.1.6. "Setting the Test Adapter").

Additionally, the module parameter PX_SIP_TRANSPORT has to be set to e_TCP.


Please configure your VoIP in ATM Test Suite according to the protocol and your local settings. You can use our MBS (Message Building System) to ease it up. In the Parameters View of the Execution Management you find different parameters to change the settings for your individual test configuration. Please right click your mouse over the Parameters View to open the Message Building System.

You can access the single parameter and the attributes of single fields. After finishing, just click OK to save the change. The changed parameters are called by the test system during runtime. You can run your test campaign with the new configuration at once without recompilation of your test cases.

5.1 Detailed Overview of the Module Parameters The module parameters are structured according to the tested interfaces and some general settings valid for all tests. For a detailed description of the module parameter groups see the following list:

• General_Settings: contains general settings, valid for all the tested interfaces o PX_EXEC_OPTIONAL: Allows to skip optional test cases if set to false. o PX_ETS_ACTION_BOX_TIMER: Timer value (in milliseconds) the dialog box

waits for user input, before it closes automatically. o PX_WG67_Version_header: Define WG67-Version header field contents to be

included in all messages sent by the Tester (e.g. radio.02, phone.02) o PX_WG67_Version_header_opt: Define WG67-Version header field contents to

be optionally included in all messages sent by the Tester (e.g. recorder.02) o SIP_General_Settings: contains all the SIP related settings, valid for all the

tested interfaces sipTransport: contains configurations for the used transport protocol sipRegistration: contains configuration for SIP registration sipHeaderFields: contains certain SIP header values

• invalidHeaderValues: contains certain invalid SIP header values sipTimers: contains SIP timer values

• Radio_Interface_Settings: contains general radio configurations for GRS and VCS • GRS_Radio_Interface: contains the configuration for testing GRS Radio interface


o Tester_Configuration: contains the configuration of the tester in VCS Radio role. Including user name, domain, IP address and SIP and RTP port numbers of the computer, where the test suite will be executed, as well as the default codec and the codec list supported by the tester.

o SUT_Configuration: Configuration of GRS SUT. Including user name, domain, IP address and SIP and RTP port numbers of the GRS SUT, as well as the default codec and the codec list supported by the GRS SUT and certain RTP Radio parameters.

• VCS_Radio_Interface: contains the configuration for testing VCS Radio interface o Tester_Configuration: Configuration of tester in GRS Radio role. Including user

name, domain, IP address and SIP and RTP port numbers of the computer, where the test suite will be executed, as well as the default codec and the codec list supported by the tester and certain RTP Radio parameters.

o SUT_Configuration: Configuration of VCS Radio SUT. Including user name, domain, IP address and SIP and RTP port numbers of the VCS Radio SUT, as well as the default codec and the codec list supported by the VCS Radio SUT and certain RTP Radio parameters.

• VCS_Telephony_Interface: contains the configuration for testing VCS Telephone interface o Tester_Configuration: Configuration of tester in VCS Telephone role. Including

user name, domain, IP address and SIP and RTP port numbers of the computer where the test suite will be executed, as well as the default codec and the codec list supported by the tester.

o SUT_Configuration: Configuration of VCS Telephone SUT. Including user name, domain, IP address and SIP and RTP port numbers of the VCS Telephone SUT, as well as the default codec and the codec list supported by the VCS Telephone SUT.

o PIXITS: contains extra configuration for the telephone tests • REC_Recorder_Interface: contains the configuration for testing the Recorder interface

o Tester_Configuration: Configuration of tester in User Terminal role for Recorder tests. Including user name, domain, IP address and SIP, RTP and RTSP port numbers of the computer, where the test suite will be executed.

o SUT_Configuration: Configuration of Recorder SUT. Including user name, domain, IP address and SIP, RTP and RTSP port numbers of the Recorder SUT.

o PIXITS: contains extra configuration for the recorder tests

The description for each single module parameter can be viewed in the Parameters View of the TTCN-3 Execution Management.

5.2 Configuration for Running SNMP Supervision Test Cases The following module parameters must be setup before running any SNMP Supervision test cases:


px_SNMP_GRS_AGENT_IP_ADDR The SNMP IP Address for the GRS Agent

px_SNMP_GRS_AGENT_PORT The SNMP Port for the GRS Agent

px_SNMP_VCS_MANAGER_IP_ADDR The SNMP IP Address for the VCS Manager

px_SNMP_VCS_MANAGER_PORT The SNMP port for the VCS Manager

px_SNMP_VCS_MANAGER_TRAP_IP_ADDR The Trap IP Address for the VCS Manager

px_SNMP_VCS_MANAGER_TRAP_PORT The Trap Port for the VCS Manager In adition, the SNMP user information has to be configured. At a minimum the following information for the first user has to be configured: px_SNMP_USERS Groups all the settings required for the authentication and

encryption when using SNMPv3. - userName The user name to be used during testing. - contextName The context ID to be used during testing. - authentication algorithm

The authentication algorithm to be used during testing. One of: noAuthentication, HMAC_MD5_96, HMAC_SHA_96.

passphrase The password to be used for authentication during testing. - encryption algorithm The encryption algorithm to be used during testing. One of:

noEncryption, DES. passphrase

The password to be used for encryption during testing.

If no authentication is used during testing, then “noAuthentication” has to be selected as the authentication algorithm. Otherwise the appropriate authentication algorithm and passphrase have to be selected. If no encryption is used during testing, then “noEncryption” has to be selected as the encryption algorithm. Otherwise the appropriate encryption algorithm and passphrase have to be selected. If no security is used, only the first SNMP User has to be configured (the one with index 0). If security is used, then the first user will be used during engine ID discovery and the second user (with index 1) has to be configured with the desired security parameters.

5.3 Configuration for Running Interoperability Test Cases The interoperability test cases may be run in online mode or offline mode. In order to switch between the two modes, the module parameter “PX_LIVE_CAPTURE” has to be set. Online mode: Set “PX_LIVE_CAPTURE” to “true”, the traffic will be captured from the network in real time. Two aditional module parameters have to be configured:

• PX_INTERFACE_NUMBER: represents the interface index from which the traffic will be captured.

• PX_SHOW_USER_INFO: if set to true will display user indication or not on the screen.


Offline mode: Set “PX_LIVE_CAPTURE” to “false”, the traffic will be read from a .pcap file that was previously generated. The .pcap files must match the name of the test cases and they must be located inside the folder “logs”. In addition to the above described module parameters, the IP addresses and ports for the devices involved in the test cases have to be configurated. Example: SUT_GRS_Radio_UA → generalSIP → addrInfo → ipAddress/ portNumber, SUT_GRS_Radio_UA → generalRTP → addrInfo → ipAddress/ portNumber, etc. Interop Test Enviroment Example:

5.4 Configuration for Running Network Performance Test Cases For the network performance test cases, the same parameters as in the case of interoperability test cases have to be configured. Please see section 5.3 for more details. If online mode is desired, set “PX_LIVE_CAPTURE” to “true”. The traffic is captured in real time. If offline mode is desired, set “PX_LIVE_CAPTURE” to “false”. The traffic is read from a .pcap file, which must have the same name as the test case and must be located inside the “logs” folder.


6 DETAILS 6.1 Core Language Editor (CL Editor) The following is only appliable if TTCN-3 source is available. The standard VOTER package does not include the source code. Each TTCN-3 file can be opened by double clicking and is visible and editable in the CL Editor. As shown in Step 1 of “4. Running My First Test Case” you find the TTCN-3 source code (*.ttcn3) in folder ttcn3.

After opening the files, the source code will be syntactically checked and highlighted. In addition, an outline will be generated automatically and the go-to-declaration feature will be enabled.

TTCN-3 Compiler/ Validate Buttons

Project View TTCN-3

CL Editor

Outline


6.2 TTthree (TTCN-3 Compiler) For recompiling all TTCN-3 files, please open the main module (with the icon ) in the CL Editor by double click. Press the Rebuild button . After recompilation follow Step 2 of “4. Running My First Test Case”. NOTE! Compilation is only necessary if some test cases are changed or some new one is created. Otherwise, the generated *.jar files (in ttcn3build folder) from TTCN-3 source are already available for execution.

6.3 TTman (Test Execution Management) In order to execute test cases and configure parameters, the CLF has to be loaded into the Test Execution Management.

In the folder Testcases, you will find all the CLF files (with the icon ). There is a CLF file for each interface to be tested.

Each CLF contains all the test cases for the appropriate interface, organized in specific group structures. NOTE! You are able to execute all test cases only if you have purchased the test suite. With your evaluation license file you may only run some test cases for evaluation. Further details you can find in the integrated Users Guide, Chapters “Using TTworkbench CL Editor”, “Using TTworkbench TTthree” and “Using TTworkbench TTman”. Click on Help Help Contents Spirent TTworkbench User’s Guide.

6.4 TTmex (Distributed Test Platform) 6.4.1 Configuration of the Distributed Performance Measurement Tests

After the installation of the TTmex as a plugin (see 3.2. Distributed Test Node Setup of the TTmex User’s Guide) you have to do the test configuration.

Provided that you have two computers A and B and you want to deploy and execute the test cases which exist on the computer A (your master daemon) on the computer B (your daemon).

On the computer A in the CCF file define the computer B as container under the container list. Be aware to add all ttplugins and taconfig file of the project to the Deploy Files. After the specification of component distribution in the TCDL file (see 7.4.2. The Test Component Distribution Language of the TTmex User’s Guide) you can now start the TTmex daemon.

Now you have to start the daemons on computers A and B (see 3.2. Distributed Test Node Setup of the TTmex User’s Guide). Note that you have to change the value of NS_HOST variable in the startDaemon file on the computer B with the IP address of the computer A where the naming server is running.

Start the master daemon on the computer A and the normal daemon (startDaemon file) on the computer B. Before running the test cases you have also to modify the IP addresses in the taconfig.xml which exist on the computer A to point on the computer B.


6.4.2 Execution of the Distributed Performance Measurement Tests

Now you are ready to execute the test cases. On the computer A change to the TTmex perspective (see 4. TTmex Perspective) and connect to the naming server. To execute the test cases just right click on the TTmex script (the file with the .mex suffix) and select the “Execute TTmex script”. Now the test cases will be deployed and executed on the computer B.

It could take some minutes to load all the plugins on the computer B. On the computer A a TLZ file will be produced where you can see the execution result of the test cases (see 7.6.1. Viewing Logs with TTman of the TTworkbench User’s Guide).

For detailed information please consult the document “Spirent TTmex User's Guide” by clicking on Help Help Contents Spirent TTmex User’s Guide.

7 NTP TIME SYNCHRONIZATION In order to obtain valid results when running distributed test cases, the computers involved need to synchronize their clock against some reference NTP servers. The following section gives an overview on how to install and run a NTP daemon and how to ensure that the system time is synchronized against some reference NTP server.

7.1 How to Install and Run NTP Daemon The next section describes how to install and run an NTP daemon on a Windows machine (NT / 2000 / XP / Server 2003 / Vista / Windows 7 / Server 2008) and on a Linux machine. Once running, the NTP daemon will ensure proper time synchronization between the system clock and the reference NTP server.

7.1.1 Installing NTP Daemon on Windows

A windows version for an NTP daemon can be downloaded from the following link: http://www.meinberg.de/english/sw/ntp.htm#ntp_nt_stable. Please follow the instruction described on the web page. On the Configuration Options page (see the next figure) select the appropriate country (e.g. Germany).

http://www.meinberg.de/english/sw/ntp.htm#ntp_nt_stable


Continue with the next steps of the installation. Just accept all the default values. Now the NTP daemon should be running. It will always start automatically when Windows starts. The status of the service can be checked under Control Panel Administrative Tools Services as shown in the following figure:

7.1.2 Installing NTP Daemon on Linux

An NTP daemon is available on all major Linux distributions. Before starting the daemon, the configuration file has to be modified. The configuration file can be found under /etc/ntp.conf. To add new NTP servers, just edit the configuration file:

server 0.europe.pool.ntp.org server 1.europe.pool.ntp.org server 2.europe.pool.ntp.org server 3.europe.pool.ntp.org A list of available NTP server may be obtain here: http://www.pool.ntp.org/zone/europe. Before starting the NTP daemon, check that the time on the local computer is not extremely out of sync. If the time on the local server is very different from that of its primary time server your NTP daemon will eventually terminate itself, leaving an error message in the /var/log/messages file. You should run the ntpdate -u command to force your server to become instantly synchronized withits NTP servers before starting the NTP daemon for the first time. The ntpdate command doesn't run continuously in the background, you will still have to run the ntpd daemon to get continuous NTP updates.

http://www.pool.ntp.org/zone/europe


To get NTP configured to start at boot time, use the line:

# chkconfig ntpd on

To start, stop and restart NTP after booting, follow these examples:

# service ntpd start # service ntpd stop # service ntpd restart

7.2 Checking if NTP is Properly Synchronized On both Linux and Windows, the NTP daemon needs around 10 minutes to be properly synchronized with the NTP servers. After 10 minutes from the boot up, you may assume that the system clock of the computer is properly NTP synchronized. To check the accuracy of the synchronization, someone may use the ntpq tool.

The table above summarizes the status of the NTP daemon. Each line is dedicated to an NTP server from the configuration file. If the first character of a line is not blank then it contains a qualifier for the corresponding reference time source. Immediately after the daemon has been started all qualifiers are blank. The NTP daemon needs several polling cycles to check the available time sources and declare one of them as the reference it synchronizes to. An asterisk * in the first column marks the reference time source which is currently preferred by the NTP daemon, the + character marks high quality candidates for the reference time which could be used if the currently selected reference time source should become unavailable.


The column st reflects the stratum number of the reference time source. In the example above, the local clock has stratum 12, the remote time server at 172.16.3.103 has stratum 1 which is the best you can see across the network, and the local radio clock has stratum 0, so the radio clock is currently being preferred. Every time a when count reaches the poll number in the same line, the NTP daemon queries the time from the corresponding time source and resets the when count to 0. The query results of each polling cycle are filtered and used as a measure for the clock's quality and reachability. The column reach shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized. The value must be interpreted as an 8 bit shift register whose content is for historical reasons displayed as octal values. If the NTP daemon has just been started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers is 0, 1, 3, 7, 17, 37, 77, 177 and 377. The maximum value 377 means that the eight last queries were completed successfully. The columns delay, offset and jitter show some timing values which are derived from the query results. In some versions of ntpq the last column is labeled disp (for dispersion) instead of jitter. All values are in in milliseconds. The delay value is derived from the roundtrip time of the queries. The offset value shows the difference between the reference time and the system clock. This is the most important value. The jitter value indicates the magnitude of jitter between several time queries.

8 IPSEC POLICY SETTINGS The following guideline provides step by step instructions for the configuration of IPsec settings on Windows 7 and Windows 2008 to achieve a secure SIP communication between two computers, which is done by using cryptographic security mechanisms. Either the transport mode or the tunnel mode is used to transform the original IP packet into a protected packet. To begin with this let's say that you want to use IPsec for the communication between SIP ports (In this paper we use 5060 as a standard port for SIP communication) on machines "A" and "B".

8.1 Transport Mode In this mode only the payload of the original IP packet is protected (encrypted and authenticated) by using AH (Authentication Header) and ESP (Encapsulating Security Payload). But the IP header is neither modified nor encrypted.

8.1.1 Create an IPsec Negotiation Policy on Computer “A”

1. On computer "A" click Start Control Panel Administrative Tools, and then click Local Security Policy. Or just type "gpedit" on Windows command prompt and then click computerconfiguration/Windowssettings/securitysettings and Local Security Policy. Please note that you must have admin rights to use this program.


2. Right-click the IP Security Policies on Local Computer node, and then click Create IP Security Policy.

3. On the Welcome screen of the IP Security Policy Wizard, click Next.

4. In the Name box, type "SecureSIP". In the Description field, type "Policy to encrypt SIP". Click Next.

5. If you do NOT have machines earlier than Windows Vista in your environment, please ensure that ‘Activate the default response rule’ is not selected and go to step 7. Click Next.

6. In the Default Response Rule Authentication Method, choose the option: "Use a certificate from this certification authority (CA)" and choose your certificate.

7. In the Completing the IP Security Policy Wizard dialog box, ensure that "Edit properties" is selected, and click Finish.

8. In the SecureSIP Properties dialog box, click Add.

9. In the Welcome to the Create IP Security Rule Wizard, click Next.

10. In the Tunnel EndPoint dialog box, select "This rule does not specify a tunnel". Click Next.

11. In the Network Type dialog box, click "All network connections" and Next.

12. In the IP Filter List dialog box, click Add.

13. A new dialog box called IP Filter List appears. Type "Secure5060SIP", and then Add.

14. On the Welcome screen of the IP Filter Wizard, click Next.

15. In the Description text box, type "5060 IPsec Filter". Click Next.

16. In the IP Traffic Source dialog box, click "My IP Address", and then click Next.

17. In the IP Traffic Destination dialog box, select "A Specific IP Address/Subnet", type the IP address of the computer "B" and click Next.

18. In the IP Protocol Type dialog box, select "UDP" in the drop-down list, and click Next.

19. In the Protocol Port dialog box, select "From this port", type 5060 in the text box, select "To This port", type "5060" in the text box. Click Next.

20. On the Completing the IP Filter Wizard screen, click Finish and OK.

21. In the IP Filter list, select "Secure5060SIP" and click Next.

22. In the Filter Action dialog box, click Add.

23. In the Filter Action Wizard dialog box, click Next.

24. In the Filter Action Name dialog box, type "Secure5060Filter" and click Next.

25. In the Filter Action General Options dialog box, select "Negotiate Security" and click Next.

26. In the Communicating with computers that do not support IPsec dialog box, select "Do not allow unsecured communications" and click Next.

27. In the IP Traffic Security dialog box, select "Integrity and encryption". Click Next.

28. On the Completing the IP Security Filter Action Wizard screen, click Finish.

29. In the Filter Action dialog box, select "Secure5060Filter", and click Next.


30. In the Authentication Method dialog box, select "Use a certificate from this certification authority (CA)" and choose your certificate. Click Next.

31. On the Completing the Security Rule Wizard screen click Finish.

32. In the Secure5060 Properties dialog box click OK.

8.1.2 Assign the Policy

Since you already have the policy created this is still not active until you activate it, so to do it, you need to: 1. On Computer "A", click Start Control Panel Administrative Tools, and click

Local Security Policy. 2. Go to the IP Security Policies on Local Computer node. In the right window, right-click

the Secure5060Policy and select Assign. You are done! You configure IPsec under the 5060 port; now let's see how you need to configure the clients in order to be able to communicate between them.

8.1.3 Create an IPsec Negotiation Policy on Computer “B”

On computer "B", the process is similar to the one that was presented before, so you can execute the steps 1 through 32 and then you will be able to connect, or you can export the policy from computer "A" and import it on computer "B", with this procedure:

1. In the Local Security Policy Microsoft Management Console (MMC) console, right-click IP Security Policies on Local Computer, click All Tasks, and then Export Policies.

2. In the Save As dialog box, type "C:\IPSecPolicy\IPsecurityPolicy5060.ipsec", and click Save. Save that IPsec policy on a USB key! Import the security policy to the computer "B".

3. On the computer "B", open the local security policy. To do this, click Start Control Panel Administrative Tools Local Security Policy.

4. Navigate to Computer Configuration/Windows Settings/IP Security Policies on Local Computer.

5. Right-click IP Security Policies on Local Computer, click All Tasks, and then Import Policies.

6. It is recommended to read the IP Security Import warning. When finished click Yes.

7. In the Open dialog box, navigate to the USB key (where you should have the file), and then double-click "IPsecurityPolicy5060.ipsec".

8. Don't forget to assign the policy on computer "B" as you did it for the computer "A".

8.1.4 Rule Enforcement on Computer “A”

Now we are almost finished to have the SIP communication protected under Ipsec! Another thing is the enforcement, for that you need to use the Advanced Windows Firewall and configure a Security Association with this procedure: Configure a Security Association rule in the Windows Firewall with Advanced Security MMC:

1. On Computer "A", click Start Control Panel Administrative Tools, and then click Windows Firewall with Advanced Security.


2. Select and then right-click Connection Security Rules, and then click New Rule.

3. In the New Connection Security Rule Wizard, select "Server-to-server", and then click Next.

4. In the Endpoints dialog box, select for endpoint 1 "these IP addresses" and add the IP address of the computer "A", select for endpoint 2 "these IP addresses" and add the IP address of the computer "B", and then click Next.

5. In the Requirements dialog box, select "Require authentication for inbound and outbound und connections", and then click Next.

6. In the Authentication Method dialog box, either select directly "computer certificate" or select Advanced and then select "computer certificate". Choose your certificate, and click Next.

7. On the Profile page, verify that the Domain, Private, and Public options are selected, and click Next.

8. In the Name box, type "SecureSIPAuthenticationRule", and then click Finish.

9. After having defined the new authentication rule, select and then right-click SecureSIPAuthenticationRule, select properties. In the dialog box select protocol and ports. Select UDP as protocol type, under port for endpoint 1 select specific ports and type "5060" in the textbox, under port for endpoint 2 select specific ports and type "5060" in the textbox. Click Apply and then OK.

8.1.5 Rule Enforcement on Computer “B”

Perform steps 1 through 9 on Computer "B". For the step 4 select for endpoint 1 "these IP addresses" and add the IP address of the computer "B", select for endpoint 2 "these IP addresses" and add the IP address of the computer "A", and then click Next. Now you are done and can enjoy the IPsec connection between computer "A" and "B".

8.2 Tunnel Mode Tunnel mode helps protect an entire IP packet by treating it as an AH or ESP payload. With tunnel mode, an IP packet is encapsulated with an AH or an ESP header and an additional IP header. The IP addresses of the outer IP header are the tunnel endpoints, and the IP addresses of the encapsulated IP header are the original source and final destination addresses. Please be aware that Windows supports IPsec tunneling for situations where both tunnel endpoints have static IP addresses. This is primarily useful in gateway-to-gateway implementations. For configuring a rule between computer "A" and computer "B" you have just to go through the steps described in 6.4.1.1 and 6.4.1.3 with just these two following steps:

1. On the computer "A" under the IP Security Policies on Local Computer double-click on your defined policy. In the dialog box click the Tunnel Setting tab, select The tunnel endpoint is specified by this IP Address box, and then type the IP address of the computer "B".

2. On the computer "B" under the IP Security Policies on Local Computer double-click on your defined policy. In the dialog box click the Tunnel Setting tab, click The tunnel endpoint is specified by this IP Address box, and then type the IP address of the computer "A".


For more information please have a look at following references:

Davies, Joseph; Microsoft Corporation, 2008

Security: http://technet.microsoft.com/en-gb/library/cc730971%28WS.10%29.aspx

Security: http://technet.microsoft.com/en-gb/library/cc748991%28WS.10%29.aspx

http://support.microsoft.com/kb/816514/en-us (Tunnel mode)

http://technet.microsoft.com/en-gb/library/cc787704%28WS.10%29.aspx

9 APPENDIX Acronyms CL Editor Core Language Editor CLF Campaign Loader File IUT Implementation Under Test MBS Message Building System OS Operating System SUT System Under Test TLZ Test Logging Zip File

Notes This document is subject to change without notice.

Spirent Communications Michaelkirchstraße 17/18, 10179 Berlin, Germany Phone +49 30 726 19 19 0 Email [email protected] Fax +49 30 726 19 19 20 Internet www.spirent.com/EUROCONTROL-VOTER

© Spirent Communications, Inc. All of the company names and/or brand names and/or product names and/or logos referred to in this document, in particular the name “Spirent” and its logo device, are either registered trademarks or trademarks pending registration in accordance with relevant national laws. All rights reserved. Specifications subject to change without notice.



http://support.microsoft.com/kb/816514/en-us



http://www.spirent.com/EUROCONTROL-VOTER

VOTER User‘s Guide - support-kb. · PDF fileUser’s Guide for VOTER, the...

Documents

Transcript of VOTER User‘s Guide - support-kb. · PDF fileUser’s Guide for VOTER, the...