Slashdot is powered by your submissions, so send in your scoop

 



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:
  • by gatekeep ( 122108 ) on Thursday August 15, 2002 @06:28PM (#4079452)
    Granted, security should be implemented at each layer if possible, but wouldn't VoIP inherit the security of the IP network itself? So far, most VoIP installations I've seen/heard about are either within an office, connecting handsets to a PBX with traditional trunks, or between offices of the same company using their internal WAN. Granted you can still have attacks internally, but in neither of these scenarios is it very easy for the general public to snoop or intercept your phone calls.

    That said, I really don't see VoIP on a large scale taking off for a while. Two things need to occur before that happens;

    - Suitably fast data service has to be ubiquitous. Spotty DSL/Cable coverage won't do it.
    - Said data service has to be less expensive than conventional phone service. This one's a no brainer.
    - Wireless data on a large scale would help as well.

    So far, I don't see these criteria being met in all but niche markets, and that's exactly where VoIP has found itself... for now.
  • by noahbagels ( 177540 ) on Thursday August 15, 2002 @06:40PM (#4079496)
    Sorry for swearing - but everyone reading /. is adult enough to get a dose of reality.

    If you're actually reading this thread - you're wasting your time.

    do you really care if someone can easily tap your phone conversations?.

    More importantly:

    is the value of your conversation worth the energy required for someone to crack your phone call?

    In a security course (both in college, and later in a Cisco class) we heard that the risk is equal to the value divided by the effort required to get at that value.
    Now: I don't believe this quote exactly, but it's point is clear.

    Nobody I know would spend the effort required to tap my personal line just to hear something I might not tell them directly.
    Further: Companies with secrets can use:

    I. Standard Non-Secure Phone Lines

    II. Secure VoIP solutions

    III.Standard VoIP solutions over a VPN
    ... need I go on?
  • by xt ( 225814 ) on Thursday August 15, 2002 @07:08PM (#4079620)
    Only a couple of months ago, we finished a roll-out for IP phones. The client was a bank and security was the top consideration. In essence, whatever worked to secure data, worked to secure VoIP. The problem in general is not with the technology; it is with the "old school" PBX designers and engineers.

    I have met quite a few people, extremely skilled with PBXs, who view data networks as a black box and have almost no knowledge or methodology to work with products that use them, much less secure them.

    When these people grasp the realities of the new, converged, technology, we can expect to see quite a few changes both on VoIP systems' built-in security and fail-safe operation.
  • Re:Simple Answer (Score:3, Insightful)

    by homer_ca ( 144738 ) on Thursday August 15, 2002 @07:13PM (#4079642)
    That's pretty much it. Educate the users so they are aware of the level of privacy. Police, fire, taxis and pilots have for years used (and still use) unencrypted analog 2 way radios. Anybody with a scanner could eavesdrop on them, and they lived with that risk.

    I'm not saying it's a good idea to just forget about security, but people should remember there's nothing sacred about privacy electronic communications. If it's really important to keep something secret, don't say it on an insecure line.
  • by Anonymous Coward on Thursday August 15, 2002 @07:41PM (#4079803)
    I disagree. The SIP protocol, last I read, has the following problems :

    1) No key exchange
    2) What is the trust infrastructure ? Here we
    are on Amazon,demanding server authenticity for
    our 10 dollar book. Yet the SIP call agents
    don't have a trust infrastructure definition
    and they are supposed to route thousands of
    phone calls.
    3) Partial payload encryption. SIP has fields
    which are hop mutable(changeable). "shudder"
    Stating "we use SSL or IPSec" ain't gonna
    cut it.
    4) SIP is the signalling, xGCP is the control
    and RTP is the data. MGCP is a text protocol
    and their is no standard for encryption this
    bad boy protocol AFAIK.

    What the SIP working group really needs is new WG chairs who will stop letting every 2 bit company get a RFC so that their little POS will work. And then they need to define how the heck
    all the protocols work together. SIP is the signalling ? How does it exchange RTP keys ? Ask a SIP WG member that question... duh.

    I think we should disband the IETF WG since it is fundamentally flawed. It has defined a protocol(and perversed beyond reason), and didn't bother to think how it's gonna work with others securely. No trust models, nothing...at least CableLabs specifications define a security model.

    coward76 AT yahoo DOT com
  • by Anonymous Coward on Thursday August 15, 2002 @11:28PM (#4080706)
    The 79XX series IP phones, while capable of being deployed with external power adapters, are really intended to be used with inline power delivered from the switch itself. Many newer switches support inline power, and not just those from Cisco. In this manner you can have UPS backing of all the IP phones by backing up the switch.

    Cisco does also recommend that the IP phones be placed in a seperate VLAN, both for easy administration and QoS treatment and security reasons. This is very easy to accomplish; you can even keep a workstation attached to the phone in the workstation VLAN - the phone will tag its own frames as belonging to the phone VLAN with 802.1q. One can place ACLs/firewalls at centralized layer 3 boundaries between the networks and place intrusion detection devices inside.

    Jason Young, CCIE #8607, MCSE
    jyoung@wantec.com
    http://www.wantec.com
  • by Tmack ( 593755 ) on Friday August 16, 2002 @12:44AM (#4080952) Homepage Journal
    Thats what UPS's are for.

    I work for a VoIP company, doing it with a pure Cisco solution and T1 data lines. The traffic is split at the end router on the customer's site (which has a UPS for itself and the T1 equipment). Their lan plugs into one jack, their phone system (POTS or digital PBX) block into another. The voice traffic goes over the same T1 and DS3's as the data, but on a different "private" network using IPs in the "unroutable" range, until it gets the the voice switch, where it is merged with the national POTS network. The data goes through the same channels, but on publicly accessable IP ranges. All the routers have standard Cisco access security, limiting access via another private network to only machines authed to do so. Also with traffic split in that way, DOS attacks only clog the data line, as the bandwidth for the voice portion is partially reserved.

    As for down-time, the most common cause is the data line itself going down. And being provided by the same company as standard phone service (baby bells), gives the same down-time, or better.
    Also worthy of mention is that standard POTS lines are not the same old analog lines back to the telco as most people believe. They too get digitized along the way and are sent out on T1/DS1 T3/DS3 lines(DS3=28*DS1's, DS1=24*DS0 lines = 672POTS lines/DS3 using TDM/PCM).

    Tm

  • by Anonymous Coward on Friday August 16, 2002 @10:06AM (#4082268)

    That said, I really don't see VoIP on a large scale taking off for a while.
    You are failing to consider large-scale campus and satellite office type situations. Two terrific examples being Enormous State University and Maximegalon Consolidated, Inc.. Each of them is just dying to get VOIP going, just to save on long-distance charges between the disparate campuses where they do business. Flat rates is always preferable to toll-based rates. Especially business rates.

    What amazes me is that most post here that I've read are considering freedom from evesdropping as the only inmportant aspect of security. Far more important in this situation is theft-of-service.

    Some folks have brought up the obvious aspect of this by pointing out that live, unsupervised network jacks are not exactly uncommon on large university campuses, often also in many corporations. Throw unsecured wireless nets in and the networks become very porous indeed. While those ARE potential disabling factors in VOIP security, they aren't the true achilles heel. Those are the issues that are already known from the regular computing-over-IP security regimen. There are well known security regimens to handle tham. Those may or may not exist at any given location, depending on the diligence of the security professionals.

    What few people are considering is something that is built right into VOIP, as an aspect of adapting private-network telephony to the public-network internet: VOIP call signaling is IN-BAND. I'll say it again: Voice-Over-IP signalling is IN-BAND.

    You can encrypt the content of the call all you want, but the information necessary to get the calls through on VOIP has to be accessible to the devices that route the call. Encryption (at current tech) of the signalling will slow down the call enough to impact quality of service.

    If you can eavesdrop on signalling info, you can pretty easily spoof it. Spoof it, and you get a free net-dail-tone. Spammers like open mail relays; hacking/phreaking college students will LOVE open out-bound lines to ANYWHERE.

Without life, Biology itself would be impossible.

Working...