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