Differences

This shows you the differences between two versions of the page.

Link to this comparison view

content:tech:vomp [15/05/2013 15:48]
127.0.0.1 external edit
content:tech:vomp [28/05/2013 15:13] (current)
Andrew Bettison add text taken from NAF1 final report
Line 2: Line 2:
  
 VoMP was designed and first prototyped in May-June 2012 as part of the [[:content:activity:naf1|first New America Foundation contract]] to integrate Serval security into the OpenBTS base station.  It was integrated into [[content:servalmesh:releases:version_0_90|release 0.90 “Shiny”]] of the Serval Mesh app for Android as part of the [[content:activity:shuttleworth1|first Shuttleworth Foundation grant]]. VoMP was designed and first prototyped in May-June 2012 as part of the [[:content:activity:naf1|first New America Foundation contract]] to integrate Serval security into the OpenBTS base station.  It was integrated into [[content:servalmesh:releases:version_0_90|release 0.90 “Shiny”]] of the Serval Mesh app for Android as part of the [[content:activity:shuttleworth1|first Shuttleworth Foundation grant]].
 +
 +VoMP is superior to SSIP+zRTP for mesh telephony in all respects.  It is simpler because it does not have to perform encryption, identification or authentication, since that is built into [[MDP|MDP]].  It does not concern itself with number resolution, directory services or proxies, since that is handled by the [[DNA|DNA]] protocol.  By contrast with SIP/RTP, which assumes stable virtual circuits over static routes, VoMP is suitable for an unreliable datagram service with unstable routing, because its session negotiation protocol and audio codec encapsulation are idempotent and redundant.
  
 ==== Why not SIPS? ==== ==== Why not SIPS? ====
Line 7: Line 9:
 SIPS is a secure variant of the [[http://en.wikipedia.org/wiki/Session_Initiation_Protocol|Session Initiation Protocol (SIP)]] in widespread use for Internet telephony (VoIP).  It essentially uses [[http://en.wikipedia.org/wiki/Transport_Layer_Security|Transport Layer Security (TLS)]] to protect each hop of the forwarded SIP request, so all intermediate proxies must be trusted. SIPS is a secure variant of the [[http://en.wikipedia.org/wiki/Session_Initiation_Protocol|Session Initiation Protocol (SIP)]] in widespread use for Internet telephony (VoIP).  It essentially uses [[http://en.wikipedia.org/wiki/Transport_Layer_Security|Transport Layer Security (TLS)]] to protect each hop of the forwarded SIP request, so all intermediate proxies must be trusted.
  
-When we were looking at implementing secure calls for OpenBTS it was suggested that we simply configure Asterisk to use SIPS+[[http://en.wikipedia.org/wiki/ZRTP|ZRTP]]. This would have been relatively easy to set up, however there are a few problems.+Early suggestions for implementing secure calls in OpenBTS involved configuring Asterisk to use SIPS+[[http://en.wikipedia.org/wiki/ZRTP|ZRTP]]. This would have been relatively easy to set up, however there are a few problems.
  
 When Asterisk checks the TLS certificates it either validates the certificate (checking the chain of trust and so on) and then checks that the common name attribute on the certificate matches the hostname of the peer, or it will do none of these checks.  This code is in [[http://svnview.digium.com/svn/asterisk/tags/1.8.14.1/main/tcptls.c?view=markup|main/tcptls.c (version 1.8.14.1)]], line 206. When Asterisk checks the TLS certificates it either validates the certificate (checking the chain of trust and so on) and then checks that the common name attribute on the certificate matches the hostname of the peer, or it will do none of these checks.  This code is in [[http://svnview.digium.com/svn/asterisk/tags/1.8.14.1/main/tcptls.c?view=markup|main/tcptls.c (version 1.8.14.1)]], line 206.
Line 13: Line 15:
 This is unworkable in a set-up where there is limited or no infrastructure, because there is not likely to be a DNS server present, nor even any static IP assignments that would allow a ''/etc/hosts'' based setup.  This situation would force the administrator to disable the certificate checks completely which would allow a trivial man in the middle attack. This is unworkable in a set-up where there is limited or no infrastructure, because there is not likely to be a DNS server present, nor even any static IP assignments that would allow a ''/etc/hosts'' based setup.  This situation would force the administrator to disable the certificate checks completely which would allow a trivial man in the middle attack.
  
-It would have been possible to modify Asterisk to have a third way where it validates the certificate and checks the chain of trust but does not look at the common name.  We decided against this approach as the VOMP channel driver was written in time to avoid it.+It would have been possible to modify Asterisk to be able to validate the certificate and check the chain of trust without looking up the common name.  We decided against this approach as the [[https://github.com/servalproject/app_servaldna|VoMP channel driver for Asterisk]] was written in time to avoid it.

Login