Voice over Mesh Protocol (VoMP)

VoMP was designed and first prototyped in May-June 2012 as part of the first New America Foundation contract to integrate Serval security into the OpenBTS base station. It was integrated into release 0.90 “Shiny” of the Serval Mesh app for Android as part of the 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. It does not concern itself with number resolution, directory services or proxies, since that is handled by the 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?

SIPS is a secure variant of the Session Initiation Protocol (SIP) in widespread use for Internet telephony (VoIP). It essentially uses Transport Layer Security (TLS) to protect each hop of the forwarded SIP request, so all intermediate proxies must be trusted.

Early suggestions for implementing secure calls in OpenBTS involved configuring Asterisk to use SIPS+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 main/tcptls.c (version 1.8.14.1), line 206.

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 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 VoMP channel driver for Asterisk was written in time to avoid it.


Login