<br><font size=2 face="sans-serif">Oliver,</font>
<br>
<br><font size=2 face="sans-serif">> </font><font size=2 color=#000080 face="Arial">Dan,
I think the #4 is not enough complete on your webpage. The interface list
doesn’t mention the dialog between 2 Call Controllers. <snip></font>
<br>
<br><font size=2 color=#000080 face="Arial">I believe </font><font size=2 face="sans-serif">Eugene
Nechamkin</font><font size=2 color=#000080 face="sans-serif"> meant his
message as a suggestion for a general direction, not necessarily a complete
list.  If we were to decide to organize around interfaces, we would
next need to ensure we had a complete list.  That was my interpretation
of his intent, anyway.</font>
<br>
<br><font size=2 face="sans-serif">> </font><font size=2 color=#000080 face="Arial">-
Where can we found the solution to a threat or the specific testing tool
of this threat? Perhaps it is a little out-subject. But I think in each
part <br>
> the list of all solved problems should be printed with references
to threat taxonomy document.</font>
<br>
<br><font size=2 face="sans-serif">Yes, I completely agree that we should
include that.  If you look on the web page http://wiki.voipsa.org/tiki-index.php?page=Development+Process
just above the document structure area, I suggested info to include for
each best practice and one of those is a cross-link to the relevant threat
taxonomy area.</font>
<br>
<br><font size=2 face="sans-serif">I'd now also expand that to include
references to specific testing tools since, as noted in an earlier message
by list member Dustin Trammell, Dustin and Shawn Merdinger have been working
up a comprehensive list of test tools (that we're not really ready to release
yet, but will do so in conjunction with this BP project).  So in the
end, we'll have this nice little interlinked set of documents:</font>
<br>
<br><font size=2 face="sans-serif">  - Threat Taxonomy outlining threats
to and vulnerabilities in VoIP</font>
<br><font size=2 face="sans-serif">  - Tools that can be used to test
those threats/vulnerabilities</font>
<br><font size=2 face="sans-serif">  - Best Practices you can use
to guard/defend against those threats (and tools)</font>
<br>
<br><font size=2 face="sans-serif">It's a nice story for VOIPSA that, assuming
we execute on all of it, should go far in helping the industry, in my opinion.</font>
<br>
<br><font size=2 face="sans-serif">> </font><font size=2 color=#000080 face="Arial">-
How the “Securing Call Control” of #2 will be treated ? BP following
the VoIP protocol used ?</font>
<br>
<br><font size=2 face="sans-serif">Well, assuming we go with structure
#2, I'm going to leave the precise answer of that to Eric Chen over at
NTT who volunteered as a section leader and said "call control"
would be his first preference for a section. So since he stepped forward
and was the first one to ask (hint, hint), I'll say he's the man for call
control.  And, not wanting to step on section leaders toes, I'll defer
to him.  :-)</font>
<br>
<br><font size=2 face="sans-serif">I will give the general guidance that
our intent is to create *vendor-neutral* best practices.  Which in
my mind means general statements (ex. "Call control signaling should
be encrypted, ideally using TLS.") which could apply across all VoIP
protocols.  So a customer could take that BP statement and, one would
hope, be able to read enough in our document to be able to ask their vendor
questions like "Do you encrypt call signaling?" and "Do
you use TLS to encrypt it? If not, why not?"  Or something like
that.  The point is that we should stick to the vendor-neutral aspects
and leave it to the vendors to explain their individual protocols.</font>
<br>
<br><font size=2 face="sans-serif">The exception would be things like SIP,
which are truly "industry standard" and so there is, in my opinion,
a case to be made for including best practices for securing SIP inside
our BP document.</font>
<br>
<br><font size=2 face="sans-serif">I'd also note that assuming we go with
#2, we also have to flesh out exactly what we throw in the bucket marked
"Call Control".  Is endpoint authentication in there as
well?  Perhaps, but then again maybe it's in the endpoint section...
there's a number of nuances like that that we still have to sort out.  But
that's the *next* debate..</font>
<br>
<br><font size=2 face="sans-serif">> </font><font size=2 color=#000080 face="Arial">I
vote for #2 !</font>
<br>
<br><font size=2 face="sans-serif">Thanks.  I've had several other
direct replies voting for #2.  At this point it's definitely heading
toward a near-consensus on #2, so if you have a different opinion, now
is definitely the time to say so.  Otherwise, about 24 hours from
now I'm going to declare #2 the way forward and start structuring things
around that.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,<br>
Dan</font>
<br><font size=2 face="sans-serif">-- <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>