As the CTO of a network security company, I’ve watched the NAC market evolve from its infancy. I believe that NAC promises to further secure IP Telephony environments and that it's this kind of micro-application (e.g. VoIP, peer-to-peer policies, IRC and IM governance, etc) that forms the foundational business benefit of implementing NAC.

To that end, Mirage Networks released a set of IP Telephony rules in 2005, and continually qualify the product via Avaya's DevConnect program. We encourage IT staffs that currently have, or have plans for, IP Telephony implementations to ask their prospective NAC vendors how they plan to integrate into IP Telephony environments. Some starting discussion points:

1. What does "A" mean in NAC? If the NAC solution begins and ends with “Admission” versus “Access”, it’s likely going to be useless beyond the tangential. A NAC solution focused on policy enforcement throughout an endpoint's network lifecycle is much better suited to securing IP telephony environments.

2. Do no harm to your voice network. The nature of real time streaming protocols is well-documented elsewhere. However, it is worth noting the danger of latency injection when evaluating NAC solutions.

3. Keep it simple. Is there a general purpose OS device in the IPTel Segment? Is there an endpoint attempting to enter a stream without sending control packets? Is an unauthorized TFTP server attempting to send configuration data to your phones? There are basic but high value, course-grained policies, spanning pre and post admission, which can be brought to bear to further secure IP Telephony infrastructure without requiring back flips or wide scale OS dependant agent deployments.

A recent white paper, “NAC and Internet Protocol Telephony: Securing Enterprise Voice-Over-IP Environments” provides further detail: http://miragenetworks.com/products/white_papers.asp

-Grant Hartline, CTO, Mirage Networks