Fourth International Conference on Networking and Services

VPN Analysis and New Perspective for Securing Voice

over VPN Networks

Wafaa Bou Diab Samir Tohme Carole Bassil

Université de Versailles Université de Versailles Université Saint Joseph, Lebanon
Saint-Quentin en Yvelines, France Saint-Quentin en Yvelines, France [email protected]
[email protected] [email protected]

ABSTRACT unsecured IP network. A VPN is composed of two fundamental

Security and privacy become mandatory requirements for VoIP components: Security Services and a tunnel for carrying private
communications that needs security services such as traffic.
confidentiality, integrity, authentication, non-replay and non- VPNs use encryption techniques to prevent the interception and
repudiation. The available solutions are generic and do not respect analysis of datagrams while they are in the public network. There
voice specificities and constraints. Thus, QoS of the voice is are different connectivity models of VPN: Remote-Access VPN is
affected by delay, jitter, and packet loss. New security solutions a User-to-Lan connection, Site-to-site Intranet VPN connects
must take into account the real-time constraint of voice service branch offices to the headquarters and Extranet VPN connects
and their mechanisms should address possible attacks and companies with their business partners.
overhead associated with it. Nowadays, VPNs (Virtual Private
Networks) is considered the strongest security solutions for The introduction of security mechanism such as IPSec VPN
communications over IP networks. Most VPN solutions are impacts directly on speech quality and channel capacity of the
implemented to tunnel data traffic while the trend toward a network. Supporting real time traffic over VPN degrades the
converged data and voice network, however, places new demands performance and quality of service like latency (end-to-end
on VPNs to support real time traffic. delay), jitter (variation of delay), and packet loss and reduces the
effective bandwidth. In this paper we compare different VPN
In this paper we compare the VPN security protocols presenting technologies and present our proposed solution that provides
their advantage and drawbacks. Then we present our new solution security for voice traffic and guarantees performance and quality
to secure voice over IPSec VPNs while guaranteeing the of services
performance and quality of services, without reducing the
effective bandwidth. We use the AVISPA model to analyze the The paper is organized as follows: in Section 2 after a short
security vulnerabilities of exchange messages to initiate session introduction to the basics of VPN protocols, we compare the
and establish VPN. different VPN technologies and their associated security protocols
presenting the strengths and weaknesses of each technology.
Keywords Section 3 describes existing voice over IP security solutions. Our
VoIP, SIP, VPN, IPSec, Security, Voice over VPN. proposed VPN solution for securing voice over IP is presented in
section 4. Finally, section 5 presents our conclusions about this
work.
1. INTRODUCTION
Voice over IP (VoIP) is one of the fastest growing Internet
applications today and supporting reliable real-time service is one
2. VPN PROTOCOLS
of its major concerns for widely deployment in IP-based Virtual private Networks are commonly created at the Link Layer,
networks. The problem of offering security to VoIP is that the Network Layer, or the Session Layer. Each of the protocols
security does not come for free and, security and efficiency are brings strengths and weaknesses to the VPN solution.
conflicting requirements, for instance introducing security layer
will affect the performance and QoS of voice traffic. 2.1 Link layer
Link layer VPNs were designed to extend Remote Access
The key for securing VOIP is to use security mechanisms like Services over the Internet. They can provide flow control thus
those deployed in data networks (firewalls, encryption, etc.) to optimizing transmission by cutting down on dropped packets. The
emulate the security level currently enjoyed by PSTN network main disadvantage is that they are targeted at the Microsoft client
users without affecting the performance and the quality of voice. space, but not on other operating systems clients. The common
Various security requirements have to be met to secure VoIP Link Layer protocols are PPTP and L2TP.
transmission: Authentication, Privacy and Confidentiality,
Integrity, Non repudiation, Non replay and Resource availability.
2.1.1 PPTP
Regarding Virtual Private Network (VPN), it is considered The Point-to-Point Tunneling Protocol PPTP [RFC2637] tunnels
actually as the strongest security solution for communications PPP traffic within IP packets, using a modified version the
between users and corresponding node inside the intranet over Generic Routing Encapsulation (GRE). PPTP uses the same types

0-7695-3094-X/08 $25.00 © 2008 IEEE 73

DOI 10.1109/ICNS.2008.8
of authentication as PPP. These protocols rely on password client and host on a session by session basis, allowing monitoring
strength which is one means to accomplish authentication and and access control based on user authentication. The main
security. disadvantage is that session layer VPNs proxy all traffic, thus they
are slower than lower layer VPNs. Their more sophisticated
2.1.2 L2TP access control is more complicated to set-up manage and maintain
than address based access control schemes. The common Session
The Layer 2 Tunneling Protocol L2TP [RFC2661] combines layer protocol is SSL/TLS.
features of PPTP with Layer 2 Forwarding (L2F) protocol.
Tunneling using L2TP is accomplished through multiple levels of
encapsulation: L2TP, UDP, IPSec, IP and Data-Link, where IPSec 2.3.1 SSL / TLS
provides the encryption for L2TP tunnels. SSL/TLS VPN [RFC 2246] based on the Secure Sockets Layer
(SSL) Protocol provides data encryption and authentication for
2.2 Network layer http traffic. It can also be used for securing RTP traffic (see
The only network layer protocol used in VPNs is IPSec. section 4). SSL uses the primary secure transport mechanism
SSL/HTTPS built-in for secure connections from web browsers to
2.2.1 IPSec web servers. On the majority of web browsers, consultation of the
certificates lists sent back is not activated by default, so a serious
IPSec VPN [RFC 2401] is designed to provide security between problem is provoked by the security of SSL based on these
two gateways, firewalls and routers, or between a client and certificates.
gateway. IPSec provides two different modes: Transport Mode,
applicable only for host-to-host security, provides protection for Table 1: Advantages and Drawbacks of VPN solutions
the payload of IP packet, while Tunnel Mode provides security
between two networks by protecting the entire IP packet. Both
intranet and extranet VPNs are enabled through this mode. ADVANTAGES DRAWBACKS
• Low overhead. • Security and firewall problems.
• No requirement for PKI. • Support only one tunnel at a time
• Support of more PPTP connections in for each user.
PPTP
VPN server. • No additional authentication.
• Compatible with NAT if NAT translate • Access control based upon packet
Figure 1. IPSec in transport and tunnel mode PPTP. filtering.
IPSec provides two security protocols. First, Authentication • Used on IP and non-IP networks. • Slow performance.
Header (AH) protects the source and destination addresses of the • Supports multiple protocols. • Support of few L2TP connections in
IP header using a hash function with a secret key. Second, • Additional authentication facilities VPN server.
Encapsulated Security Payload (ESP) provides authentication,
(e.g. RADIUS) and tokens (one-time
integrity and confidentiality and allows for encryption of the data
L2TP

codes and smart cards).

payload, guaranteeing data confidentiality and integrity [RFC
• Multiple simultaneous tunnels for
2406].
each user.
Internet Key Exchange (IKE) protocol [RFC 2409] sets up IPSec • NAT compatibility in case of
parameters and exchanges encryption keys in order to create a supporting IPSec NAT traversal.
new security association. IKE authenticates the users by using • Flexibility. • Complexity,
either shared secret or public key cryptography. To support • No changes to individual user • Identifying the device not the user.
asymmetric user authentication methods, many enhancements are computers. • No routing capability built-in.
used e.g. Extended Authentication (XAUTH) and Hybrid
• Secured key exchange and strong data • No supporting of protocols other
authentication. XAUTH [12] inserts a login/password
protection. than IP.
authentication after Main Mode and before IPSec parameter
• Supporting a variety of encryption
IPSec

negotiation (Quick Mode) to securely authenticate the remote • Reducing the global performances.
user. XAUTH is secured by IKE main mode that needs a pre- algorithms and checking the integrity • Offering no mechanism of QoS.
shared key or a certificate. Hybrid authentication authenticates of the transmitted data. • Giving access to the whole network
only the server with a certificate or public key, and the client only • Optimal solution for gate-to-gate VPNs. or subnet.
by the legacy methods protected by ISAKMP SA [RFC 2408]. • Suited for long-lived connections.
• NATs compatibility and NAT-Traversal
IKEv2 [RFC 2409] includes features like XAUTH / Hybrid type support.
of legacy authentication support, using encapsulated EAP protocol
[RFC 2284]. This legacy authentication is similar to Hybrid auth. • No need of VPN client software. • Securing the application payload
IKEv2 uses a method similar to IKE shared secret authentication • Secured key exchange and strong data only and leaves out the transport
for the parties to prove to each other that they have the secret protection. and network layer headers as
derived from the EAP key-generating run. • Allowing access to specific resources cleartext.
SSL/TLS

inside networks. • Working only with web-based

2.3 Session layer applications.
Session layer VPNs provide more detailed control of data flow • Requiring more firewall
than lower layer VPNs. They work with variety of authentication configuration than IPSec.
and encryption mechanisms and establish a virtual circuit between • More trouble deflecting denial-of-
service attacks.

74
2.4 Comparing Different VPN Technologies analysis. Combined with the firewall implementations, IPSec
Table 1 compares the different types of VPN and presents the makes VoIP more secure than a standard phone line.
advantages and drawbacks of each VPN solution. The security The use of a SSL VPN connection can retain the order and
services offered by VPN technologies are reported in table 2. regularity of the data streams over the public network better than
Both IPSec and SSL negotiate per-session keys, and use best-effort UDP delivery, actually resulting in better call quality.
cryptography to prevent eavesdropping and forgery. IPSec with A SSL VPN connection still uses SSL to communicate, but
mutual certificate authentication is more secure than SSL with one requires a standalone client program. This connection provides
way server certificate authentication which is more vulnerable to enhancements such as on-demand transparent connection which is
denial-of-service attacks than IPSec. Encryption and desirable for the very mobile user who wishes to use VoIP from
Authentication algorithms and protocols for data traffic over a the road and might benefit from custom features.
VPN tunnel are presented with user authentication protocols in IPSEC VPN traffic delivery will be more deterministic, but has
table 3. heavier client requirements, and may have trouble traversing some
Table 2: Different VPN Security services networks. SSL VPNs may provide a better VoIP experience, and
Terminal Auth. User Auth Confidentiality Integrity may be easier to use on some networks than IPSEC VPNs, but
PPTP No Yes Yes No this will be highly dependent on the environment.
L2TP Yes Yes Yes Yes
IPSec Yes No Yes Yes 3.2 Comparing VoIP security solutions
SSL/TLS Yes No Yes Yes The major question when supporting end-to-end security is what
layer should provide this, network layer or some higher layer? For
Table 3: Encryption and Authentication protocols and reliable data transfers, the major alternatives are either IPSec
algorithms (network layer) or TLS (transport/application layer). For real-time
Terminal Auth. User Auth. Encryption UDP traffic, the main alternative is SRTP (transport /application
layer). Although operating at different layers, SRTP and IPSec
PAP, SPAP, MS-CHAP, CHAP. MPPE / RC4 provide similar services like encapsulation format, cryptographic
PPTP

_ EAP-TLS, digital certificates EAP-TLS, MS- transforms (using AES-CM and HMAC-SHA1) and session key
for mutual authentication. CHAP. generation. Moreover, SRTP and IPSec mechanisms offer data
IPSec ESP Computer PAP, CHAP, MS-CHAP, EAP-TLS IPSec/ESP (DES, origin authentication, while user identity is authenticated by
Certificates digital certificates, Certificate 3DES, AES) means of digital certificates or digital signature.
L2TP

Authority and Pre-shared Key

for mutual authentication. IPSec can be used between SIP proxy servers, securing a trunk of
ESP/AH HMAC-MD5, IKE Digital certificates, shared ESP (DES-CBC, many communication channels with a single set of encryption
keys. TLS and SRTP could be used between servers and
IPSec

with digital certificate secret passwords for mutual 3DES-SHA1, AES

or pre-shared key. authentication. and Blowfish). endpoints, where encryption on the server side is off-loaded onto
hardware, allowing the server to handle a greater number of
Digital certificate HTTP Digital certificates, Sub- 3DES, RC4-MD5 secure channels. Alternatively, TLS and SRTP could be used
Basic Authentication, authentication (login page Public-key
SSL

throughout the entire VoIP system. This alternative lowers the

SecurID. protects username/password encyption number of security protocols which minimizes the complexity of
the overall solution. IPSec implemented throughout a VoIP
From what is stated in section 2.1 and in the above tables, we system requires security associations to be setup on all nodes.
conclude that the network layer VPN including IPSec is the This may make the implementation of a large system complicated,
strongest VPN solution on behalf of security. Complexity, unless an automated method of configuring IPSec, based on
performance and compatibility problems of IPSec make it less options set in the VoIP application on clients, are employed.
suitable for media traffic. Therefore, IPSec VPN needs many SRTP without IPSec would leave the session initiation protocols
enhancements to support security for VoIP. unencrypted unless TLS or S/MIME was also implemented.

3. VOIP SECURITY 4. PROPOSED SECURITY SOLUTION

Voice over IP enables easier and cheaper communication with FOR VOICE OVER VPN
greater flexibility, but it is less secure than the traditional TDM
network and introduces significant risks and vulnerabilities. 4.1 Solutions for Voice over IPSec Weakness
Security solutions are used with protocol enhancements to carry
and secure VoIP network such as SRTP (Secure Real-time 4.1.1 Encryption
Transport Protocol) and transport and network layers protection The solution to the bottlenecking at the routers due to the
such as that offered by VPNs. encryption issues is to handle encryption/decryption mechanisms
at the endpoints. This can be feasible with smart-phones support
3.1 VoIP security using VPN VoIP application and IPSec such as SIP-based IP phones. In
Several VPNs solutions such as IPSec and SSL/TLS are used to addition, this solution protects voice traffic from inside attacker.
protect both VoIP signaling and media traffic. IPSec VPNs
provide VoIP encryption by using techniques such as AES 4.1.2 QoS prioritizing
Standard [6], authentication and key exchange, guaranteeing Without a way for the crypto-engine to prioritize packets, the
mobility and security. IPSec helps reduce the threat of man in the engine will still be susceptible to DoS attacks. One solution is to
middle attacks, packet sniffers, and many types of voice traffic schedule the packets with QoS in mind prior to the encryption

75
phase. QoS prioritizing can be done after the encryption process mainly used at the receiving endpoint to reconstruct the original
by preserving the ToS bits from the original IP header in the new headers. A method is used to associate the SCID and the next hop
IPSec header. in the routing table, and also to set up a correspondence between
the header compression tables in the session.
4.2 Proposed Solution
Our proposed solution for securing VoIP is based on IPSec VPN A packet, in addition to link layer framing, has IP header of 20
that supports an additional level of security and performs bytes, UDP header of 8 bytes, and RTP header of 12 bytes
scalability and performance evaluation for voice conversations. resulting in a total of 40 bytes. With IPv6, the IP header is 40
The IPSEC tunnel is used to protect all traffic between two end- bytes for a total of 60 bytes. Incorporation of network-layer
users, not only the VoIP call. Using IPSec tunnel to protect encryption mechanism nearly doubles IP operational overhead,
multimedia traffic is outside the scope of this paper. IPSec adds ESP header of 20 bytes and IP new header thus, the IP
header is a total of 80 bytes with IPv4. In our solution, using
Confidentiality and Authentication are provided by applying ESP cRTP reduces the IPSec inner header to 2 or 4 bytes while IPHC
security mechanism only, since this authentication is very similar reduces the outer header to 2 bytes; therefore, a total of 6 bytes
to AH and using AH will increase processing time and delay. ESP compressed header.
supports various encryption and authentication algorithms (e.g.
AES-CBC, 3DES-CBC and HMAC-SHA1). Advanced 4.2.1 Initiating session
Encryption Standard (AES) is the simplest, most flexible, efficient In order to provide a secure voice call between two
and secured symmetric algorithm, providing the voice and communicating entities, VoIP session is established by the SIP
signaling systems much higher security level than DES, while server. Establishing a VPN tunnel between end-users necessitate
computational power is 3 to 10 times less than 3DES. ESP to know the current location of the callee, that may be outside its
Authentication uses a hash function with a secret key, the default office or couldn’t replay, then unnecessary time will be spent to
authentication algorithm is HMAC-MD5 negotiated within a establish a useless VPN. Moreover, even full encryption of the
security association established between sender and receiver. SIP message would provide the best protection. This cannot be
Integrity in connectionless mode is obtained by calculating an done, because Proxy must be able to read some of the headers,
Integrity Check Value ICV. The algorithm used is based on a one- such as Route. Furthermore, in order to build VPN tunnel and
way hash function like MD5 or SHA1. User authentication before the IKE session starts, the IKE session initiator must know
provided by IKEv2 protocol using, either shared secret or public both parties IP addresses that are known after the normal SIP
key cryptography with XAUTH and Hybrid auth. setup signaling INVITE and 200 OK.
IPSec protocols add unacceptable latency and jitter that To solve these problems, we propose to initiate the session using
significantly degrade voice quality by adding overhead to voice SIP protocol before establishing the VPN and to exchange IPSec
packets. The solution is to use header compression schemes that parameters in the SIP messages. This allows the establishment of
reduce packet header size and packet transit time for low speed IPSEC tunnels between persons who do not know each others’ IP
transmission (RFCs 2407 and 2508). The IP header compression addresses before the call. Moreover, there are no extra round-trips
and the encryption protocols are performed at the User Agent by a needed for the key exchange. SIP messages and thus IPSec
small mobile device due to the advances in microelectronics. parameters are secured with S/MIME protocol that encrypts SIP
message body and some of the headers.
Compressed RTP (cRTP) and IPSec are incompatible standards.
ESP is an obstacle to compression because it forces cRTP to To reduce the number of round trips needed for the session setup
compress only the outer (unencrypted) packet headers. To solve and for the key exchange, IPSec parameters should be exchanged
this problem, we suggest performing cRTP at the network layer to in one round trip in a similar way as in the case of SRTP/MIKEY.
reduce the inner IPSec header (RTP/UDP/IP header) then using In this solution, all IPSEC parameters are transported in a MIKEY
ESP protocol to encrypt the whole voice packet including the message carried as a MIME payload in SIP [4]. With the use of a
cRTP header. Next, the new IP and ESP headers are inserted, as MIKEY message, two IPSEC SA and two IPSEC policy entries
illustrated in Figure 3. Finally, we perform IPHC compression are set in each client host, one SA and policy for the outgoing and
scheme at link layer to reduce the outer IPSec header (IP/ESP). the other for the incoming traffic in each end; this enables IPSEC
transport mode for all traffic between the two hosts, which is done
by setting of "use_ipsec" in the configure file of SIP user agent.
However, it should be possible to select the protected traffic based
on the information in the SDP. The SDP with the media
description is carried in a MIME message with Content-type
application/SDP. The MIKEY message for IPSec is carried in a
MIME message with Content-Type application/MIKEY. SIP
defines end-to-end authentication by using S/MIME, while user
authentication is achieved with IKEv2.
Figure 3. Packet format using cRTP and ESP. In the IKEv2 authentication exchange, the initiator indicates the
Packets compression with IPHC should flow across multiple desire to use the extended authentication XAUTH by leaving out
compression-enabled links, without requiring a compression/ its AUTH payload. The responder uses its AUTH payload and
decompression cycle at each transit router. Thus, a collection of possibly certificate to authenticate itself, and also starts EAP
shared information and session context ID (SCID) is used to route session. The initiator, in this phase, defers the CHILD_SA
compressed packet between endpoints. Such information is formation-related messages until EAP exchange succeeds. To
prevent attack against key-generating EAP methods, the protocol

76
uses a method similar to IKE shared secret authentication for the and IPSEC to protect the conversation between the users. During
parties to prove to each other that they have the secret derived the call, the IKE Quick Mode will renegotiate new keys and
from the EAP run. establish a new SA with Perfect Forward Secrecy PFS.
4.2.2 Architecture
In our proposed solution, VoIP session is established by the SIP
server before IPSec VPN tunnel is built for end-to-end security of
media traffic. The encryption/decryption mechanisms are handled
at the endpoints to prevent the bottleneck at the routers and the
attacks from inside the intranet and to help support mobility when
users may like to roam in the middle of a conversation. Mobility
has not been addressed in the current paper.
The QoS prioritizing can be done by providing the encryption
procedure to preserve ToS bits from the original IP header in the
new IPSec header. The standard voice codec considered is G711
that generates 160 bytes of voice payload per frame. Figure 4
shows the proposed VPN security architecture for voice over IP as
described below, while Figure 5 illustrates the exchanged SIP Figure 5. Exchanged messages.
messages and IPSec parameters during session setup.
5. Security Analysis with AVISPA
Automated Validation of Internet Security Protocols and
Applications (AVISPA) is a push-button tool for building and
analyzing security protocols [15]. We constructed a formal model
in HLPSL (High Level Protocol Specification Language) [16],
and used automated AVISPA model checker to carry out formal
analysis of the security vulnerabilities of exchange IKEv2
parameters into SIP messages.

Figure 4. Architecture of proposed solution. In our analysis, the diameter SIP/IKEv2 application allows a
diameter client to request authentication and authorization
We assume that Alice is inside an intranet and would like to information to a diameter server for SIP based on IP multimedia
initiate a phone call over the internet with Bob located in another services. The IKEv2 authentication based on digital signatures
intranet. Alice’s and Bob’s User Agents (UAs) can be either performs mutual authentication and key exchange prior to setting
hardware SIP phones or PC based soft-phones. The proposed up an IPSec connection.
architecture adopts SIP proxy server in each intranet for initiation
session and authentication terminals and users. We model a successful run of the protocol: In the first attempt, the
authentication fails and the credentials of the User Agent Clients
In order to establish the connection, Alice sends an INVITE are requested (together with a challenge) by the Diameter Server.
message to the SIP proxy server 1 inside its intranet. The INVITE The users exchange nonce values and perform a Diffie-Hellman
message is generated by user agent with multipart payload exchange, establishing an initial security association IKE-SA. In
carrying the media description and the MIKEY message for the second attempt, the client sends his credentials to the Server
IPSec. Proxy1 forwards the INVITE request to the redirect server for authorization and authentication. This exchange authenticates
that retrieves the current user IP address as contact information, the previous messages, exchanges the user identities, and
thus, the proxy can forward the request to the user. establishes the first child security association CHILD-SA used to
secure the subsequent IPSec tunnel. The credentials are sent via
On behalf of Alice, SIP proxy1 makes a DNS lookup to determine
the HTTP Digest schema, which can safely be modeled in HLPSL
the proxy server of domain 2 and then forwards the INVITE
by using a hash function. We assume that the SIP server and the
request to SIP Proxy2 which looks for the position of Bob with
Diameter client are located in the same node, so that the SIP
the help of a Location Server, usually a DNS. DNS replies that server is able to receive and process SIP requests and responses.
Bob is logged in domain 2.The redirect server knows this through These rely on the AAA infrastructure to authenticate the SIP
a static configuration set up by Bob with a SIP REGISTER request and authorize the usage of particular SIP services.
message. Alice sends an ACK message to the Redirect Server and
then resends the INVITE request to Bob directly at domain 2 Our implementation is described as the following: Alice
which returns an ACK message to Alice. Finally, Alice sends an (respectively Bob) generates a nonce Na and a Diffie-Hellman
ACK message to Bob when receives Bob’s 200 response message half key KEa (respectively KEb). In addition, SA1 contains
for request success. Alice's cryptosuite offers and Bob's preference for the
establishment of the IKE-SA, similarly SA2 for the establishment
After a successful initiation of SIP session, an end-to-end VPN of the CHILD-SA. These parameters are exchanged into SIP
tunnel is established between the two endpoints using ESP in messages and sent to Bob through the proxy servers. This helps in
tunnel mode that protects the entire inner IP packet. This will exchanging IKE parameters without knowing both parties IP
guarantee an end-to-end security between the sending and addresses. Furthermore, Alice and Bob are authenticated and
receiving hosts. Then VPN will be ready to tunnel the voice traffic authorized by diameter server.

77
We model a successful run of the protocol and verify the secrecy parameters into SIP messages for initiating session and
and authentication using OFMC back-end [15]. The analysis establishing VPN tunnel.
results show that the messages are exchanged safely and the
security goals are met. We use the animation tool SPAN (Security Experiments with other VoIP security solutions to compare the
Protocol Animator for Avispa) [14] that helps design and animate bandwidth consumption, latency, jitter and packet loss are part of
HLPSL specifications, i.e. interactively produce Message our future work. Moreover, we are extending our proposed
Sequence Charts (MSC) which can be seen as an “Alice & Bob” solution to a global security solution for voice and multimedia
trace of an HLPSL specification. The results are shown in Figure communications over mobile VPN networks that support mobility
6 describing the building with SPAN of a possible execution in real-time applications.
(MSC drawing) of SIP_IKE exchanged messages to initiate
session and establish VPN tunnel. 7. REFERENCES
[1] A. Passito. Evaluating Voice Speech Quality in 802.11b
Networks with VPN/IPSec. Proceedings of the XIII IEEE
International Conference on Networks, 2005.
[2] A. Steffen, D. Kaufmann, and A. Stricker. SIP Security.
Security Group Zürcher Hochschule Winterthur, 2004.
[3] B. Hartpence. Curricular Response to the Real Time Data
And VoIP Tidal Wave. The Consortium for Computing
Sciences in Colleges, 2007.
[4] B. Springer and L. Kilmartin. Performance evaluation of
the Internet Key Exchange Protocol under dynamic VoIP
network conditions. ISSC Limerick, Jul 2003.
[5] D.R.Kuhn, T.J.Walsh, and S.Fries, Security Considerations
for Voice over IP Systems. NIST Gaithersburg, Jan 2005.
[6] Federal Information. Advanced Encryption Standard (AES).
Processing Standards Publication 197, Nov 2001.
[7] J. Orrblad, “Alternatives to MIKEY/SRTP to secure VoIP”,
Master Thesis, KTH, Stockholm, March 2005.
[8] M. Saarinen. Legacy User Authentication with IPSEC.
Helsinki, Finland, Feb 2004.
[9] N. Lindqvist. SIP Session Initiation Protocol. Seminar on
Instant Messaging and Presence Architectures in the
Internet, 2005.
[10] Nascimento, A. Passito, E. Mota, and L Carvalho. Can I
add a Secure VoIP call? Proceedings of the IEEE
International Symposium on a World of Wireless, Mobile
and Multimedia Networks, 2006.
[11] Passito. Performance evaluation of VoIP traffic using
IPSecurity protocol. Proceedings of I Workshop on
Computer Science and Information Systems, Brazil 2004.
[12] R. Barbieri, D. Bruschi, and E. Rosti. Voice over IPSec:
Figure 6: Basic animation of SIP/IKEv2 specification. Analysis and Solutions. 18th Annual Computer Security
Applications Conference San Diego California, Dec 2002.
[13] S. Huang, Z. Liu, and J. Chen. SIP-Based Mobile VPN for
6. Conclusion and Future Work Real-Time Applications. Hsinchu, Taiwan 2005.
Within this paper, different VPN solutions are presented that solve [14] Y. Glouche and T. Genet. SPAN – a Security Protocol
the security aspects and trust the communication between user and ANimator for AVISPA – User Manual. IRISA / Université
private network over internet. Moreover, we defined the de Rennes 1, 2006. 20 pages.
implemented security mechanisms for real time traffic. Some of [15] A. Armando, et al. The AVISPA Tool for the automated
these security mechanisms leave the end-to-end communication validation of internet security protocols and applications.
unsecured. IPSec VPNs is the best solution for real time traffic on 17th International Conference on Computer Aided
behalf of security, but solution that provides best security may not Verification, CAV’2005, Edinburgh, Scotland, 2005.
provide best performance and may affect the QoS like latency, Springer.
jitter, packet loss and synchronization etc... For example, IPsec [16] Y. Chevalier, et al. A high level protocol specification
provides different security protocols introducing more complexity language for industrial security-sensitive protocols. In
and resource usage. We propose a new VoIP over VPN security Proceedings of Workshop on Specification and Automated
solution that adopts IPSec tunneling protocol in combination with Processing of Security Requirements (SAPS), Linz, Austria,
cRTP and IPHC compressions technologies and uses SIP to 2004.
exchange IPSec parameters. This solution provides security for
voice traffic and guarantees performance and quality of services,
without reducing the effective bandwidth. We use AVISPA model
to analyze the security vulnerabilities of exchange IKEv2

78