[VOIPSEC] Assessing Skype's network impact

Mon Dec 19 07:44:32 CST 2005

> I wasn't aware that Skype used so much bandwidth! "33K to 46Kbps" IS
> a lot for a voice call, and as you say, this would eat up bandwidth.

At 33 Kbps, you'll find that more than half of that is header overhead.
33 Kbps is the typical results you expect to see from a compression
codec.  MAC, IP, UDP, and RTP headers are fairly bloated when used to
push compressed voice around the network.

> I have found that codecs like G.711 (which is 64kbps) can only manage
> about 2 concurrent calls before audio quality takes a severe nose
dive.

Since G.711 is the least complex codec, it's not the codec, it's the
size of the internet pipe that needs to be considered.  The rule of
thumb I always use is 4000 simultaneous G.711 calls on a Gig-E
connection (keeping it under 50% utilization).  For residential
broadband, it's more about when rate limiting kicks in.  In a cable
environment with QoS, we routinely run 12 G.711 flows through a DOCSIS
cable modem for multi-dwelling unit applications and the limit ends up
being the number of discrete flows a DOCSIS cable modem chip can handle
(16) rather than bandwidth limitations on the network.

Geoff

----------------------------------------------------------------------

Message: 1
Date: Mon, 19 Dec 2005 11:59:00 -0000
From: "Chris Sutton" <chris at c4l.co.uk>
Subject: Re: [VOIPSEC] [CAnet - news] Assessing Skype's network impact
To: <Voipsec at voipsa.org>
Message-ID: <025001c60493$997a98d0$6700a8c0 at office.toastedmedia.net>
Content-Type: text/plain;	charset="us-ascii"

Hi Robert,

Thanks for the informative article. I'm always interested to read about
companies testing Skype.

I wasn't aware that Skype used so much bandwidth! "33K to 46Kbps" IS a
lot for a voice call, and as you say, this would eat up bandwidth. Of
course this is only a problem due to the limited upload stream on your
office ADSL line. Nevertheless, such a high bitrate would still cause
problems.

The G.729 codec in fact uses only 6.4 - 11.8kbps bandwidth per call, and
is a much better demonstration to customers of VoIP potential (there's
nothing like a dropped call/low audio quality to send a customer
running, screaming out the door!) I have found that codecs like G.711
(which is 64kbps) can only manage about 2 concurrent calls before audio
quality takes a severe nose dive.

In my opinion it is this kind of limitation - like having a lack of PBX
redundancy - that will make VoIP unmarketable as a business solution let
alone as a replacement to POTS. I would even go as far as say that this
will be more important than security to most companies (at least until
VoIP becomes more widespread anyway)

Sorry, just had to get that off my chest!!

Regards,

Chris

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Voipsec-request at voipsa.org
Sent: 17 December 2005 12:00
To: Voipsec at voipsa.org
Subject: Voipsec Digest, Vol 12, Issue 17

Send Voipsec mailing list submissions to
	Voipsec at voipsa.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
or, via email, send a message with subject or body 'help' to
	Voipsec-request at voipsa.org

You can reach the person managing the list at
	Voipsec-owner at voipsa.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Voipsec digest..."

Today's Topics:

   1. Fwd: [CAnet - news] Assessing Skype's network impact
      (Robert Moskowitz)

----------------------------------------------------------------------

Message: 1
Date: Fri, 16 Dec 2005 10:29:38 -0500
From: Robert Moskowitz <rgm at icsalabs.com>
Subject: [VOIPSEC] Fwd: [CAnet - news] Assessing Skype's network
	impact
To: voipsec at voipsa.org
Message-ID: <7.0.0.16.2.20051216102846.03c14af8 at icsalabs.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Just another data point or two.

>From: "Bill St.Arnaud" <bill.st.arnaud at canarie.ca>
>To: <news at canarie.ca>
>Date: Fri, 16 Dec 2005 10:14:27 -0500
>Subject: [CAnet - news] Assessing Skype's network impact
>Reply-To: bill.st.arnaud at canarie.ca
>List-Id: CA*net News mailing list <news.canarie.ca>
>
>Assessing Skype's network impact
>
>For more information on this item please visit the CANARIE CA*net 4
Optical
>Internet program web site at
http://www.canarie.ca/canet4/library/list.html
>-------------------------------------------
>
>[Thanks to Harvey Newman for this pointer. Some excerpts from Network
World
>article-- BSA]
>
><http://nwwsubscribe.com/highlights/facepage.asp?k=FOCHIPR&U=http://www
.nwfu
>sion.com&n=15>
>
>
>If you're worried about Skype creating a security problem for your
>network, don't, because the free VoIP service poses little danger to an
>enterprise network. That's a good thing, because it's just about
>impossible to keep Skype out of your network if end users are
determined
>to run it.
>
>That's the conclusion we reached after testing multiple versions of
>Skype for several weeks in our independent test lab.
>
>Skype is inscrutable and mysterious. It uses indecipherable encryption.
>It dynamically morphs traffic characteristics. It can work through
>virtually any network address translation (NAT)-based firewall.
>
>And with more than 4 million online users at any given time, one can
>assume that Skype has permeated many enterprise networks.
>
>We assessed the state of the encryption and security of the Skype
>messages and streams, looking for exposed information that could be
>useful to hackers and susceptible to man-in-the-middle interception and
>diversion tactics. We evaluated the security of Skype Instant Messaging
>and file transfer, along with the internetworking of Skype 1.4 and 2.0
>beta. We also tracked the effect of Skype operations, in terms of CPU
>and memory use, on laptops.
>
>Our testing shows that neither Skype VoIP nor Skype Instant Messaging
>poses any readily exploitable security threat. We also conducted a
dozen
>private interviews with hackers, enterprise network managers and
leading
>network-security-equipment suppliers, none of which could cite one case
>of Skype being exploited for insidious security assaults.
>
>Bandwidth is not a big concern either. A Skype voice call uses 33K to
>46Kbps of bandwidth in each direction. This is not a lot, and is
typical
>of an efficient WAN-oriented VoIP vocoding, such as G.729. Of course,
if
>a few dozen internal users are concurrently running Skype calls, this
>could eat up a T-1's worth of bandwidth.
>
>What should concern IT departments about Skype is not so much the
danger
>to security but the fact that it can't be controlled. Our testing shows
>that:
>
>*
>Skype works through firewalls and symmetric NATs (where a unique
>external IP address is associated with each internal user). We tried a
>number of commercial firewalls, configurations and even IPSs, which
work
>based on many higher-level traffic-analysis techniques, and we could
not
>prevent Skype from successfully establishing quality VoIP phone calls.
>*
>When Skype users download the software, they must consent to the usage
>agreement that includes a provision allowing Skype to commandeer their
>PC and its resources. The big fear is that the PC - ostensibly an
>enterprise node with private company files and communications stored on
>it - could become a Skype SuperNode. A Skype SuperNode is a
commandeered
>PC that plays a kind of proxy role in Skype call setup. We saw no
>evidence of any attempted takeover or use of any of the Skype-loaded
PCs
>or laptops we tested. Conventional wisdom is that a SuperNode takeover
>occurs only on nodes that maintain a long-term presence with the same
>public IP address.
>*
>
>Should Skype be stopped?
>
>We have not found or even heard of any plausible claims of inherent
>security threats or vulnerabilities associated with Skype at this time.
>
>In our research, we found one major U.S.-based global manufacturer that
>has decided to try to exclude Skype from its network. Technically, the
>company could not do so (see the story "Spotting and stopping Skype:
>good luck"), short of subjecting all its users' PCs to periodic scans
to
>detect Skype software. Even then, it would be possible for a user to go
>to work, download Skype, make calls and then uninstall Skype from
inside
>the enterprise network, all in an afternoon. The company has decided to
>arrange for users to make free, Internet-based calls via corporate
>network resources as an alternative to Skype.
>
>How do you identify and stop Skype? There will soon be IPS vendors that
>will work out a way to reliably spot and stop Skype calls in the short
>term. However, as of this writing, there is no vendor we could find
that
>offered a commercial solution that stops Skype calls permanently.
>
>Skype is inscrutable: Skype traffic is encrypted, the User Datagram
>Protocol and TCP ports it uses vary randomly; even the packet lengths
>and VoIP voice sample sizes vary.
>
>
>
>
>
>-------------------------------------
>To SUBSCRIBE:
>send a blank e-mail message to
>news-join at canarie.ca
>
>To UNSUBSCRIBE:
>send a blank email message to
>news-leave at canarie.ca
>-------------------------------------
>
>These news items and comments are mine alone and do not necessarily
reflect
>those  of the CANARIE board or management.
>-----------
>Bill.St.Arnaud at canarie.ca
>www.canarie.ca/~bstarn
>skype: pocketpro
>SkypeIn: +1 614 441-9603
>
>
>_______________________________________________
>news mailing list
>news at canarie.ca
>http://lists.canarie.ca/mailman/listinfo/news

Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of Cybertrust, Inc.
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      rgm at icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

End of Voipsec Digest, Vol 12, Issue 17
***************************************

------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

End of Voipsec Digest, Vol 12, Issue 19
***************************************