<br><font size=2 face="sans-serif">Nhut,</font>
<br>
<br><font size=2 face="sans-serif">(Sigh) Yes, you're right. We probably
need a Section 9 called "Emerging Areas of Concern" or something
like that[1] into which we lump SPIT and other miscellaneous things that
don't yet have solid best practices (because they're not yet solid threats,
IMHO) if only so that we can avoid the inevitable questions "Why is
it that in your entire Best Practices document you don't mention SPIT?
How are we to guard against it?" </font>
<br>
<br><font size=2 face="sans-serif">Jozef,</font>
<br>
<br><font size=2 face="sans-serif">- I don't know where fail-over fits.
Section 8, in *my* mind (but I'm just one contributor) was about all the
physical layer stuff that many of us network geeks generally try to ignore
such as backup power, physical security, etc. I was thinking of it
from the "availability" point-of-view in that if you lose power
and don't have your IP-PBX *and* network switches powered by a UPS, your
phones are nice pretty bricks. And you should have them in locked
rooms, etc. I don't know that we'll have all that many Best Practices
in this area.</font>
<br>
<br><font size=2 face="sans-serif">As to fail-over, I'm not sure... is
it in Section 8? Or is it in call control? I'm not sure on
that one... any other opinions?</font>
<br>
<br><font size=2 face="sans-serif">- Yes, caller ID spoofing is something
to be addressed. Probably in Call Control? (Eric Chen, now's probably
a good time to weigh in before we assign everything to you! :-)
As for ENUM, there's probably a large debate on that one, but as
we write the best practice around caller identification the debate can
be waged then.</font>
<br>
<br><font size=2 face="sans-serif">- QoS - Yes, there is definitely a balancing
act between quality and security... although I'm not entirely sure how
we create that as a best practice. Would the best practice be something
like "Install and use quality monitoring equipment" - somewhat
along the lines of what Gary was suggesting earlier?</font>
<br>
<br><font size=2 face="sans-serif">Love all these comments... keep on sending
them in... this is *your* document as much as it is mine or anyone elses.
Let's make sure it's right.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,<br>
Dan</font>
<br>
<br><font size=2 face="sans-serif">[1] Or the section can be called "Issues
Related To VoIP Security That Are Over-Hyped By The Media Because They
Get Attention" (and yes, I know there are probably several members
of the media subscribed to this list)<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Nhut Nguyen" <nnguyen@sta.samsung.com></b></font>
<p><font size=1 face="sans-serif">01/19/2007 12:35 PM</font>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
"Jozef Janitor" <jozjan@cnl.tuke.sk>,
<dan_york@Mitel.com>, <bestpractices@voipsa.org></font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
RE: [VOIPSA Best Practices] Best Practices
document structure set -next question: are these the appropriate areas?</font></table>
<br>
<br>
<br><font size=2 color=#000080 face="Arial">Hi All,</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">Great discussion! </font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">Regarding SPIT I am not sure
if the industry has any good practices yet. I believe this problem is emerging
but solutions are still in the research stage. However, it may be a good
idea to have a stub or a place holder to document emerging practices like
these, or those that address security issues of presence information, for
example!</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">Cheers,</font>
<br><font size=2 color=#000080 face="Arial"><br>
Nhut</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<div align=center>
<br>
<hr></div>
<br><font size=2 face="Tahoma"><b>From:</b> bestpractices-bounces@voipsa.org
[mailto:bestpractices-bounces@voipsa.org] <b>On Behalf Of </b>Jozef Janitor<b><br>
Sent:</b> Friday, January 19, 2007 11:23 AM<b><br>
To:</b> dan_york@Mitel.com; bestpractices@voipsa.org<b><br>
Subject:</b> Re: [VOIPSA Best Practices] Best Practices document structure
set -next question: are these the appropriate areas?</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 color=#1f497d>Does the point #8 describe also the fail-over
procedures? So if my primary call controller broke down then the second
call controller will automatically handle the active calls? This may involve
some clustering techniques.</font>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 color=#1f497d>Also important part of voip security is
the credibility of an incoming calling number (callid). Because in the
PSTN network normally I can’t change my callid, but in the VoIP it’s
usually not a big problem. Maybe this problem could be handled with ENUM.</font>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 color=#1f497d>QoS – this is very important when we are
going to talk about security in voip. We have to consider what level of
security do we need because the encryption of traffic and other security
features are always adding additional delay to the transported voice. If
the value of this additional delay is going to be too high then our call
is maybe for 100% secured but it’s not pleasant to hear.</font>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 color=#1f497d>And SpIT. We know that controlling SPAM
in our emails is very difficult . But controlling SPAM in VoIP will be
even more difficult. So I hope that some pages in this document will also
cover the possibilities of solving the SpIT problem.</font>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 color=#1f497d>All the best,</font>
<br><font size=2 color=#1f497d> Jozef Janitor</font>
<br><font size=2 color=#1f497d> </font><a href=http://www.cnl.tuke.sk/><font size=2 color=blue><u>www.cnl.tuke.sk</u></font></a>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 color=#1f497d> </font>
<br><font size=2 face="Tahoma"><b>From:</b> bestpractices-bounces@voipsa.org
[mailto:bestpractices-bounces@voipsa.org] <b>On Behalf Of </b>dan_york@Mitel.com<b><br>
Sent:</b> Friday, January 19, 2007 11:58 AM<b><br>
To:</b> bestpractices@voipsa.org<b><br>
Subject:</b> [VOIPSA Best Practices] Best Practices document structure
set - next question: are these the appropriate areas?</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Arial"><br>
Best Practices team,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Thank you to those of you who sent in comments either on the list or directly
to me. A special thanks to Eugene Nechamkin who took the time to
write up a counter-proposal. Outside of his contribution, basically all
the feedback was for proposal #2, structuring the document around functional
areas, and so I'm going to say we're going with that.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
Now, the next question - is this list below from the wiki the appropriate
list of areas for VoIP-related best practices?</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
1. </font><font size=3 face="Times New Roman">Securing
Voice and Media stream </font><font size=2 face="Arial"><br>
2. </font><font size=3 face="Times New Roman">Securing
Call Control </font><font size=2 face="Arial"><br>
3. </font><font size=3 face="Times New Roman">Securing
Management Interfaces and APIs </font><font size=2 face="Arial"><br>
4. </font><font size=3 face="Times New Roman">Securing
PSTN Interfaces and Traditional Telephony Issues (i.e. don't forget toll
fraud) </font><font size=2 face="Arial"><br>
5. </font><font size=3 face="Times New Roman">Securing
Servers and Operating Systems </font><font size=2 face="Arial"><br>
6. </font><font size=3 face="Times New Roman">Securing
IP Endpoints (ex. sets, softphones, etc.) </font><font size=2 face="Arial"><br>
7. </font><font size=3 face="Times New Roman">Securing
the TCP/IP network (ex. VLANs, 802.1X, wireless, etc.) </font><font size=2 face="Arial"><br>
8. </font><font size=3 face="Times New Roman">Physical
Security, including backups, power, etc. <br>
</font><font size=2 face="Arial"><br>
Are we missing any major areas? Should these be modified or tweaked?</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
It seems to me to be a complete list, but then again, I wrote it, so of
course it would. Any feedback is welcome.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
Regards,<br>
Dan</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
-- <br>
Dan York, CISSP<br>
Dir of IP Technology, Office of the CTO<br>
Mitel Corp. http://www.mitel.com<br>
dan_york@mitel.com +1-613-592-2122<br>
PGP key (F7E3C3B4) available for <br>
secure communication</font>
<br>