[VOIPSA Best Practices] LAST CALL for comment on Best Practicesdocument structure - #2 or #4?

[dan_york at Mitel.com]

Oliver,

> 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>

I believe Eugene Nechamkin 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.

> - 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 
> the list of all solved problems should be printed with references to 
threat taxonomy document.

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.

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:

  - Threat Taxonomy outlining threats to and vulnerabilities in VoIP
  - Tools that can be used to test those threats/vulnerabilities
  - Best Practices you can use to guard/defend against those threats (and 
tools)

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.

> - How the “Securing Call Control” of #2 will be treated ? BP following 
the VoIP protocol used ?

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.  :-)

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.

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.

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..

> I vote for #2 !

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.

Thanks,
Dan
-- 
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel Corp.     http://www.mitel.com
dan_york at mitel.com +1-613-592-2122
PGP key (F7E3C3B4) available for 
secure communication
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://voipsa.org/pipermail/bestpractices_voipsa.org/attachments/20070117/a63bb3db/attachment.htm>