The SAFE IP Telephony Blueprint

IPT (IP telephony) is a relatively new technology, at least in production networks (testing and experimentation have gone on for quite a bit longer, of course). Data exchange has had time to develop security protocols that have made it through the standards-development process, but protocols comparable to IPSec in the data arena have not yet been developed for IPT. This is a problem because you could be in a position where there is interest in deploying IPTprovided, of course, that you can do so and deliver ubiquitous telephony service to users and sites that require it, and that it will be (from their perspective) indistinguishable from traditional telephony services. And, of course, you must do it securely, interfacing with a secured data network without creating new security vulnerabilities in that.

Design Fundamentals

The IPT design fundamentals are quite straightforward:

• Security and attack mitigation based on policy

• Quality of service (QoS)

• Reliability, performance, and scalability

• Authentication of users and devices

• Options for HA

• Secure management

The first priority design fundamental is that everything is based on the policy chosen ; this is a part of the implementation of that, and, of course, you can't implement effectively if you don't have a good plan. The next highest is the performance make-or-break factor in IPT: QoS. With those two covered, you can then consider reliability, performance, and scalabilitythe factors that will make this work over a larger network (one which is more than a test lab rollout). Authentication is nothing new, although, again, note that it is of users as well as devices. It is worth considering options for HA, although you might find that HA is not considered "optional" when it comes to voice communications. When it comes to telephony, HA is part of the requirements, with the discussion limited to means and costs (that is what is meant by the term options ). Finally, of course, as with every other SAFE network architecture, secure management (and reporting, though not listed) is fundamental.

Axioms

The SAFE IPT Blueprint has axioms, of course, although not with the depth of the SAFE VPN Blueprint. The first one should hardly surprise you:

• Voice networks are targets.

• Data and voice segmentation are key.

• Telephony devices don't support confidentiality.

• IP phones provide access to the data-voice segments.

• Soft phones require open access.

• Soft phones are especially susceptible to attacks.

• Establishing identity is key.

• Rogue devices pose serious threats.

• Secure and monitor all voice services and segments.

The last axiom is also no surprise; the ones between, however, are unique to the IPT environment (remember, the Enterprise SAFE model included IP phones and call managers). In ordinary telephony, the two networks remain separate, so they cannot (without great effort) cross-contaminate one another. However, with IPT, the two networks converge, so a problem can enter via one to threaten the other (and this can go either way). Therefore, it is key to keep the two as logically separated as possible. Soft phones (an unofficial term for PC-based phones) are especially problematic in this regard because the PC is typically not that well protected (there is no IDS, for instance). Disabling unused ports and the "new device-friendly" features of call managers are especially important in keeping intruders out.