I ran across this paper from Duncan Blake at Unify Square a few weeks back. I think it presents an interesting argument about the use of voice VLANs in the enterprise as a security measure. This is not the first time that I have seen this discussed. I have talked about the same subject myself with coworkers at my previous employer. While this document doesn’t really go into the network considerations of voice VLANs it does make me think about the merit of both the network and security measures of voice VLAN’s when moving to a PC based VoIP network.
Lets take a look at some of the reasons that you would use voice VLANs beyond just security in a IP hardphone deployment.
Quality of Service – The number one reason IPT vendors advocate the use of voice VLAN’s. Traffic separation to ensure quality.
IP addressing – In a large IPT deployments IP addressing could be a major concern when deploying hundreds of new IP phone devices on the LAN. Rather than readdress whole segments of the network voice VLAN’s are sometimes the simpler answer allowing the use of a private IP address scheme and extending the network.
Security –Included for completeness but really the last on the list.
With the following in mind when moving to a PC based VoIP environment where can the PC make up where Voice VLANs left off. Firstly QoS has to be addressed. No argument that QoS is a requirement over low bandwidth WAN connections and in high traffic areas such as a datacenter but at the desktop and local switch closet I start to have some doubts over the value this method offers.
Seeing as we now have data and voice on the same VLAN some might propose we allow the PC to do 802.1Q tagging to extend the existence of voice VLAN’s to the PC. This idea does have some merit when working with standard G. codecs like G.711 where tolerance to jitter and packet loss is low. With the ability to take advantage of PC hardware more vendors are taking advantage of more flexible intelligent codecs such as RTaudio(Microsoft), SILK (Skype) and iLBC (various, freeware).
RTAudio -http://www.microsoft.com/downloads/details.aspx?FamilyID=5d79b584-79c9-42a8-90c4-4ab3f03d19c4&displaylang=en
SILK -http://www.wirevolution.com/2009/01/13/skypes-new-super-wideband-codec/
iLBC -http://ilbcfreeware.org/
While not all of the mentioned codec's can do wideband they do prove that intelligence in the codec is an industry direction and the current G. standards are not the preferred PC codec. What this equates to is less reliance on the network to provide and secure quality.
But wait we haven’t totally dealt with QoS. Marking and classifying is a big part of using a voice VLAN and QoS. Trusting the PC to correctly categorize and intelligently mark VoIP packets is a question most will ask. Well here are a few points. The first one will only be relevant in a Windows environment but using Group Policy’s to ensure that computers are correctly marking packets to match a DSCP architecture is a pretty easy answer. The biggest question here is convincing network people that it can be done correctly is only something each organization can answer. The second would be to mark, classify and queue at bottlenecks on the enterprise network. Unfortunately you aren’t going to get this on the internet so if you have a large remote community this isn’t going to be much help so it’s back to more intelligence in the endpoint.
Moving back to my original discussion about VLAN’s our next area is IP addressing. Well, we already have PC’s on the network so unless adding VoIP to PC’s means more PC’s it’s kind of a moot point. I would be surprised to hear someone say “we added VoIP which meant we needed more PC’s.” Upgrading PC’s, sounds more likely.
The last point is security and at the heart of Duncan’s paper. It’s been proven time and time again the value of VLAN’s as a security measure is nonexistent. A kiddie with a program can defeat this which really makes its value pretty low from a security perspective. Getting access to a switch port for a non-employee of an enterprise is more of a challenge than a voice VLAN from a security aspect.
Although Duncan mentions OCS I think the industry as a whole is recognizing that VoIP needs to be more secure and layering on security as an upgrade or an overlay is a poor approach. I am not going to argue one vendor versus another’s approach but if your deployment of IPT or Unified Communications isn’t using secure media (SRTP and SRTCP) and secure signaling (SIP/TLS as an example) the question is, why? It also makes the discussion of using a VLAN to provide security much less tangible. Is the effort of configuration worth it, if it can be so easily defeated by someone with network access when your media and signaling is already secure? It’s not.
So when you sit down and write your next Unified Communications RFP for enterprise X, think of the following points-
Is security a part of the initial configuration or an overlay?
What codecs will you use for a solid call quality on uncontrolled networks?
How reliant should VoIP be on your enterprise network to ensure call quality whether it is PC based or not?
Comments welcomed.
VoIPNorm
Good post and a topic that many of us have been dealing with long before OCS made its appearance on the PC.
ReplyDeleteOne part I think is over looked (and understandbly so, this is not a networking forum) but having seperate policies such as VLAN/IP addressing or DSCP markings are used outside of just QoS at ingress/egress points in the network.
Having a very clear and defined network policy for your voice traffic allows you flexibility and many options when dealing with things like virus control, use of ACL's and other security tools to ensure your voice traffic (and signaling) is not subject to disruption.
Again good topic, good questions and ulimately every enterprise will likely answer differently, but should acknowledge there are other network/security implications here.
Hi,
ReplyDeleteGreat points about ensuring VoIP quality during virus outbreaks. Feel free to expand on your reasons for using Voice VLAN's, certainly wanted to have an open forum for people to offer up their own opinions.
So with nearly every vendor offering a PC based VoIP endpoint, what would you suggest is a solution to to capture this traffic?
The concept of a Voice VLAN is certainly directed more at physical phones and not applicable as much to any softphone.
ReplyDeleteEnsuring QoS or even more important availability to a softphone is an issue that extands beyond just networking discussion. The bigger problem is within the platform itself. While Win7 has made steps to provide more QoS "like" CPU capabilities, reality is problems within the platform and software continue to be a challenge to providing the same degree of reliablity as "traditional" voice (hard phone, tdm, however you want to define it).
The point I try to get across to others when dealing with this topic is if you ignore those other areas, you are not looking at the big picture and will run into real issues. Ensuring things like backup software, virus scan activity, disk I/O, etc. become more disruptive to softphone service than say WAN QoS.
While I know certain communciation products are touted as making "voice an application" the reality is it is still a unique application and needs to be dealt with and understood as such.
I really like the points you made about priority at the CPU level. Certainly this is where the desktop team will have a heavy influence in product selection and updates to the desktop enviroment. I think this goes back to my previous post somewhat as well. The team element in product selection and deployment in UC is critical. All the IT departments should be aware of the fact that all play a part in the success of UC and buying segemented peices and jamming them together without a true UC strategy is weak at best.
ReplyDeleteThanks for your comments.