Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security

Security In Voice Over IP Converged Networks 113

dotslash writes: "This article at Internet Telephony Magazine has a very interesting analysis of security issues created by converging data and telephony networks with VoIP: "When the phenomenon of "convergence" between telephony and Internet started, it also brought closer the world of the phreaker and the hacker. VoIP brings all this to the next level. Unfortunately, the security inherent in VoIP solutions is equivalent to that of the early Internet: Non-existent.""
This discussion has been archived. No new comments can be posted.

Security In Voice Over IP Converged Networks

Comments Filter:
  • SIP and security. (Score:4, Informative)

    by muonzoo ( 106581 ) on Thursday August 15, 2002 @06:45PM (#4079519)
    Many of the current VoIP deployments today are not using the security features that you might expect to see. In large, this is because the standard itself is maturing and the manner in which security will be implemented is still under investigation. In the case of SIP [ietf.org], the article points out that although the payload (voice) might be encrypted, the signalling isn't. This is not entirely true. One thing that SIP permits is to tunnel SIP as a payload within SIP. The external session serves only as a routing mechanism for the fully encrypted 'real' signaling session contained within. These mechanisms are just completing peer review and implementors are just wrapping their heads around it all. One thing is for sure; unlike protocols that have preceeded them, SIP and it's designers are taking security very seriously. How else could they consider using SIP as an integral part of 3GPP and/or it's use for inter-carrier peering.

    Sure, the protocol itself may have exposure issues, and problems with NAT/PAT devices, but there are companies on the market that are addressing these issues as they arise.

  • by Martin Blank ( 154261 ) on Thursday August 15, 2002 @06:48PM (#4079526) Homepage Journal
    I've been using Vonage's service for a couple of months now, and except for some minor issues when I'm doing file transfers, the signal is clear, and definitely worth it. I've lowered my phone bill by about $25 a month (I pay about $40 for the service), and will soon be removing a couple of additional things so that they balance out. In addition, a few family members are considering moving to Vonage.

    Now security is a bit of a concern, but since most people who would want to intercept my calls would likely try either the analog line first or else try to intercept the cordless phone signal, I'm not worried too much. If they can get in, they can listen to me get pestered by friends for solutions, or hear about how my nephew across the country is doing well in school. If I had something really pressing, I'd look for another solution, but for now I'm content to wait for the service to provide support through a firmware update, and if they don't and I need it then I'll look for something else.
  • by apankrat ( 314147 ) on Thursday August 15, 2002 @06:50PM (#4079535) Homepage
    Few of them being:

    * it's transport layer protocol, not an IP one. By default it runs on top of TCP, while majority of VOIP protocols do not require TCP's reliability. Needless to say that this is voids no good by any means.

    * it requires reliable carrier for key establishment/renegotiation. Hence dropped and out-of-order packets will effectively break session. This means that you cant just stick SSL between V and IP layers.

    You still can run SSL over unreliable layer (such as UDP or IP itself), but this will require certain protocol 'fixup' effort, which might end up be no less effort than building VoIP security from the scratch.

    The simpliest solution along the lines of your suggestion would be to use IPsec and classical VPNs. Throw in IKE and you get yourself PKI-based system. It'd be somewhat pain in the arse to configure, but as a quick and dirty solution is will suffice.
  • by FuzzyDaddy ( 584528 ) on Thursday August 15, 2002 @07:04PM (#4079598) Journal
    Also having worked in the field for a while, here's some numbers:

    Regular phone networks encode data at 64 kbps (that's bits per second, not bytes) - 8000 samples/seconds, 8 bits per sample.

    Cell phones use more extreme compression, and can transmit at less than 16 kbps. Ever noticed how they sound worse, though?

    Any stream has a built in delay - you have to buffer up enough sound in a packet before you send it off. So a 1 ms delay means 1000 packets a seconds, which is inefficient for voice. Buffering in voice calls is usually tens of milliseconds.

    Delays of under 100 ms are usually not noticable. Delays of 500 ms will bug the crap out of you.

    And, of course, there is the speed of light limitation, (5 milliseconds for 1000 miles - once you route that through a fiber optic cable, it can be a few times that, depending on the dielectric constant of the fiber.).

  • by Bill Currie ( 487 ) on Thursday August 15, 2002 @07:19PM (#4079672) Homepage
    A 1ms delay for a packet does not equate to 1000 packets per second. It just means that your (eg) 20ms packet (50 packets per second seems reasnable) comes out 21ms after the first sample went in rather than 20ms.

    As an example, look at ppp: your ping time over a 56k modem to your ppp server is going to be around 100ms but it takes about 250ms for a 1500 byte packet to get transfered which is why modem users often see around 200-300ms ping times when playing online games (depending on the size of the packets). Even with that 100ms delay, you will still get about 4 packets per second even though 350*4=1400 (or 325*4=1300 if you're going to split the ping).

  • by cfulmer ( 3166 ) on Thursday August 15, 2002 @11:17PM (#4080674) Journal
    Finally, something I know about! This is what I do for a living.

    The fact of the matter is that most of the large emerging packet telephony networks are not being deployed in enterprises, but in the carrier networks -- telephone companies around the world are replacing their old circuit-switched back-haul networks for packet-switched networks, either ATM or IP. These are private networks which are not open to the general public, and so do not have the same risks as, say running VoIP on the internet would. Sure, the telcos still need to watch out for attackers... it's just that you've raised the bar far enough that 'script kiddies' would have a tough time.

    The article also has an over-simplified view of the effort needed to tap an IP phone call. Even if the user were able to mirror any port on the network onto his computer, he still has the extremely hard task of figuring out which port(s) he needs to monitor -- they typically change on a per-call basis, and the user would actually have to mirror two ports (one for each direction of speech) in order to get the entire call. Now, it can be done, but it's difficult. And, it's made even harder because the signalling path (the communication link that handles setting up calls) is usually encrypted, so it becomes impossible to distinguish among calls.

  • some considerations (Score:2, Informative)

    by jsailor ( 255868 ) on Friday August 16, 2002 @12:19AM (#4080871)

    1. almost all VoIP installations are run on switched networks and phone calls are inherently unicast so only source, destination, and possibly a router can see the traffic. Yes, conference calls can be multicast - but most aren't and switches prune non-multicast group member from the broadcast domain anyway

    2. Almost all VoIP installations place voice traffic on a separate VLAN. This VLAN is ususally well protected through routers and the like. Also it's easy to enhance security for the VLAN with basic switch/LAN security techniques (tying MAC addresses to specific ports, traffic filters, even 802.1x)

    3. Securing the call setup servers, gateways and other devices is relatively easy - any decent VoIP installation would protect these and distribute them so there's no single point of failure.

    4. VoIP can be run of VPN's the main issue is the added latency of the encryption/decryption process.

    5. VoIP over the wide area is no less secure than standard long distance.

  • by afidel ( 530433 ) on Friday August 16, 2002 @01:16AM (#4081053)
    That said, I really don't see VoIP on a large scale taking off for a while.

    Then you are crazy. The amount of money that can be saved by rerouting interoffice calls over the corporate wan is staggering. Because business class SLA's on PRI's for voice are so expensive many businesses are still paying rates close to what consumers were 10 years ago, not the great low rates we are used to today. In the case of our large (180 person) satelite office nearly 80% of our long distance traffic (measured in minutes) was back to one of the companies two major north american campuses or to our manufacturer in taiwan, when we decided to move to VoIP it was determined that the equipment would pay for itself in about 9 months, not a bad ROI at all!

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...