I had posted on the topic of "Security" some days back. I received some
feedback from Valdis Kletnieks, Lixia Zhang, and Perry Metzger. I am glad to
receive their feedback.
Perry suggested that I come and participate. I thought about that and decided
that I will try to attend the November meeting in Atlanta. This would be the
first time I shall attend. It would help me to receive further feedback on the
IETF working groups that focus on VoIP Security or Security in general that
VoIP can also use. I would like to participate in more than one forum, and then
decide where my interest might be. In addition to the Security Area and its
Working Groups, I am also thinking in terms of the Policy Framework working
group under the Operations and Management Area. This is because I think that a
Security Framework is more useful if it is Policy Based.
There was feedback that Security is frequently a difficult problem. I have also
come to the same realization. To start with I share some VoIP requirements
including the Security ones. They are not mine but I have borrowed them from
information assurance technical framework. I think they are a good starting
point, especially to glean the Security consequences. Please share your
feedback, which of course would be appreciated.
REQUIREMENTS:
The general intuitive requirements for VoIP can be stated simply: VoIP is to
provide a functional replacement for a traditional telephone infrastructure in
a given context. However, in meeting user expectations, more detailed
requirements emerge, some of which may be optional in some circumstances.
These more specific requirements include, but are not limited to, the following
items:
. Acceptable voice quality in real time (<150 ms delay).
. An acceptable addressing scheme, which may or may not map directly to
existing phone number schemes, but which must be translatable to existing phone
networks and legacy systems.
. Access control to allow one to limit calls into or out of the
organization's telephone infrastructure from either a public system or another
enclave on the basis of such factors as calling number, called number, time of
day, and others. This type of access control is what one would expect from a
conventional private branch exchange (PBX), and this functionality should not
be lost in a VoIP implementation. Indeed, this capability may prove to be more
crucial in the VoIP realm than it was in traditional telephony.
. Sufficient auditing and billing functionality to meet mission,
regulatory, and statutory requirements.
. Cost which is equivalent to, or an improvement over, existing phone
technology, when all factors are added in.
. Ability to interface and interoperate with existing secure telephone
technology, such as secure telephone unit (STU) III and secure telephone
equipment (STE).
. Quality of service, including reliability and availability, that is
comparable to that of existing telephone technology.
. Call prioritization and preemption capabilities, including both
prioritization of telephone calls (e.g., "the General's call always goes
through") and prioritization of telephone traffic versus data traffic on the
network to maintain acceptable service levels.
. Emergency 911 geolocation information, as required by law and/or
regulation (and perhaps the ability to disable it for some applications).
. Robustness. A converged network is a single point of failure;
therefore, it must be designed for redundancy, fault tolerance, and graceful
degradation.
. Confidentiality. Sniffing a network is easier than tapping a
traditional phone network, in large part because it requires less precise
physical access. Therefore, some sort of confidentiality mechanism may be
needed to achieve functionality (even basic functionality) equivalent to that
of the traditional phone network.
. Legality. All pertinent legal and regulatory requirements applicable
to the traditional phone network must be met in a VoIP environment. However,
as noted in the previous section, it should not be assumed that the same rules
automatically apply in the same ways in the new environment. Therefore, there
should be a conscious effort to determine the ground rules when using the new
technology.
. Connection to the PSTN must not introduce errors or vulnerabilities to
the PSTN, lest the PSTN decline to allow the connection.
. Feature set (conferencing, call waiting, call forwarding, voice mail,
Caller ID, automatic dial-back, etc.) similar to the standard feature suite one
expects from PSTN service.
. Traffic management and load monitoring capabilities similar to what one
would expect from a typical PBX installation.
With best Regards
Dr. A R Choudhary