![Security in VoIP Systems ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](https://image.slidesharecdn.com/ieeemeetinganacapri-13184086090775-phpapp01-111012035610-phpapp01/85/Ieee-Meeting-Anacapri-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Security in VoIP Systems](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (12)
Viewers also liked
Viewers also liked (19)
Similar to Ieee Meeting Anacapri
Similar to Ieee Meeting Anacapri (20)
Ieee Meeting Anacapri
- 5. Security in VoIP Systems Test Bed
- 7. Security in VoIP Systems QoE vs QoS VoIP PSTN QoE QoE QoS
- 8. The Voice Quality Blanket Struggle Security in VoIP Systems All these factors are related each other and determine the user experience QoE Delay/Jitter
- 12. Security in VoIP Systems Any Questions?
- 13. Security in VoIP Systems Thanks for your attention and enjoy your stay in Capri
Editor's Notes
- PROPOSED METHODOLOGY This methodology has to provide the Telecommunication Engineer with means to plan the necessary changes in the network/VoIP platform, eventually reaching a higher level of security. The SUT has to be simulated accordingly to the procedure, to test the changes effects before doing their actual implementation. This methodology will take in account the right balance between security instruments and the required QoS/QoE for real time operations. To do that both QoS (core network objective point of view) and QoE (End User subjective point of view) have to be considered in a way that should lead to a good balance between network security-efficiency and customer service-satisfaction.
- The idea behind this implementation was to reproduce , on a small scale , most of the issues a VoIP user could expe rience during the life-cicle of the multimedia service he’s getting from the Telco (QoE), and for the carrier the main problems the Management and Engineering team are facing in their day by day work (QoS). We measure, under different WAN connection situations (i.e. Jitter, Delay, Echo, Packet Loss are some of the buttons we modify in order to see how the VoIP infrastructure behaves), VoIP application level parameters. We built an experimental table reporting the test results in terms of QoE and QoS, for the whole set of different WAN/LAN situation simulated in the test bed.
- Service Availability. An attack able to compromise service availability is the most significant VoIP security threats to VoIP networks. It has the potential to quickly impact customers, resulting in lost revenues, system downtime, lost productivity and unplanned maintenance costs. It’s a major concern for service providers providing public services such Emergency call. DoS, viruses and worms DoS, virus and worm-based threats will also use VoIP specific protocols and VoIP application vulnerabilities. Attacks will usually target critical VoIP applications/devices such as end-user phones and soft-clients, call managers, authentication servers and billing applications. Service Integrity . Service integrity threats are focused on compromising VoIP services through toll fraud , identity theft and other fraudulent actions IP TV could record the content of the broadcast and then sell it illegally. A toll fraud can be committed via a VoIP phone that is registered using a stolen or guessed user account and password. Spit has become a major concern in the data security world as millions of unwanted messages are sent around the world. On the contrary of e-mail SPAM, combating SPIT is much more difficult due to the real-time nature of voice services. Eavesdropping on signaling and media paths enables attackers to obtain sensitive business or personal information . Various man-in-the-middle attacks altering the content of the conversation could be launched. Examples of these attacks are insertion and disruption, masquerading, registration hijacking, impersonation and replay. Computational time is the link between the two groups
- Test Cases : Let us consider the Test Case #01 , which is really self-explicative in terms of results. Fixing the Delay of the WAN Network to 0 ms, we could find a theoretical limit for the Packet Loss Ratio (PLR) on an IP Network supporting VoIP services (the validity of which can be took as general for G.711A codec): if the value of PLR goes beyond 2% , it is likely to have troubles with the QoE, as perceived by the End User. In fact, despite no jitter and delay are present during the test, the QoE goes down to the limits of acceptability (MOS=3.1-3.2) for a phone call. This is taking us to one simple but important conclusion: if the IP vector is not able to grant a PLR lower than about 1.2 % , then it cannot bear real time services such as VoIP. We take now a brief look at the results of Test Cases #2 and #3 , in which we tried to simulate a “real life” situation for a general-use IP Network. The measured values of the QoS parameters are in accordance with the experience in real network implementation (i.e. carrier networks). Focusing the attention on QoS, with specific reference to jitter, we notice that a slight increase in the value of jitter causes a significant decrease of QoE , which results in an unacceptable quality when the jitter buffer of the receiver is 20 ms , being just at the bottom boundary for a jitter buffer equal to 60 ms . Example: Take as an example an x-DSL/ATM connection, with a VoIP communication using a G.711A kind of codec: if this is the case then the bandwidth consupmtion, for a sampling time of 20ms , is about 100 kbps ; if you wanna spare bandwidth (50 kbps) you’re gonna use G.729 codec but the drawback is the following: as soon as you loose packets , you’re losing roughly the double of information contents (semantyc wise) you should lose in the case of G.711A Considerations: When the IP vector has enough room in terms of bandwidth the VoIP infrastructure using such a network is able to compensate efficiently for impairements which show up within the network. On the other hand, when the residual available bandwith is <= 10% of the total, then every impairement event becomes highly disruptive in terms of QoE , for the whole set of calls being active on this very line. I.e. a small amount of Jitter can take down the MOS to an unacceptable value (this problem could be partially recovered by an increment of the Jitter buffer, but this intervention is limited to a total maximum of 100 ms; the same should happen for a small value of PLR [ PLR = (lost packtes+late packets)/sent packets ]. Exactly the same result should the RTT Delay increase a little bit (this is very much related to devices’ computational time). When using an IPSec tunnel you have to take in account the additional overhead due to the security encryption, so the bandwidth consumption will be greater of about 30% with respect to an uncrypetd transmission. Limits: Taking in account one parameter at time , the limits being figured out by experimental approach are the following: PLR = 2% (this value refers to G.711A; if you deal with G.729 it has to be significantly lower: < 1 % ) RTT avarage Delay = 400 ms Avarage Jitter = 7 ms (JB = 20ms) | 12 ms (JB = 60ms) | 17 ms (JB = 100ms) If you go beyond one of the above values your QoE will result unacceptable .
- LANForge Ice (by Candela Technologies): Wan impairement simulator Hammer Call Analyzer (by Empirix): MOS-Rfactor & troubleshooting Jperf (by SourceForge): Measure throughput and latency as number of threads grow Can be used to measure performance of any Java code Perfect for measuring the impact of performance optimizations Shows average duration and throughput (invocations per second) IP-Ping SIP Info: The purpose of the INFO message is to carry mid-session information between SIP user agents