An RFC for SIP security! Excellent!
The RFC draft-ietf-speermint-voipthreats-01 was release in July and summarizes several of the threats towards VoIP.
SIP Request Spoofing
Most SIP request spoofing require first a SIP message eavesdropping
but some of the them could be also performed by guessing or
exploiting broken implementations. Threats in this category are:
session teardown - the attacker uses CANCEL/BYE messages in order
to tear down an existing call at SIP layer, it is needed that the
attacker replicates the proper SIP header for the hijacking to be
successful (To, From, Call-ID, CSeq);
Billing fraud - the attacker alters an INVITE request to bill a
call to a victim UE and avoid paying for the phone call.
user ID spoofing - SSPs are responsible for asserting the
legitimacy of user ID; if an SSP fails to achieve the level of
identity assertion that the federation it belongs expects, it may
create an entry point for attackers to conduct user ID spoofing
attacks.
Unwanted requests - the attacker sends requests to interfere with
regular operation, i.e. sends a REGISTER request to hijack calls.
The SPEERMINT architecture as defined in [refs.speermintarch] does
not require registrations between the signaling functions (SF) of
the connected SSPs. Superfluous requests like REGISTERs should be
rejected.
There is also a part of how to spoof messages:
SIP Reply Spoofing
Threats in this category are:
Forged 200 Response - the attacker sends a forged CANCEL request
to terminate a call in progress tricking the terminating UE to
believe that the originating UE actually sent it, and successfully
hijacks a call sending a forged 200 OK message to the originating
UE communicating the address of the rogue UE under the attacker's
control;
Forged 302 Response - the attacker sends a forged "302 Moved
Temporarily" reply instead of a 200 OK, this enables the attack to
hijack the call and to redirect it to any destination UE of his
choosing;
Forged 404 Response - the attacker sends a forged "404 Not Found"
reply instead of a 200 OK, this enables the attack to disrupt the
call establishment;
The RFC has a good overview how to protect yourself against these security issues in the end and elaborates on each of them what to do.
Here is a smaller part of it:
4.13. Encyrption and Integrity Protection of Signalling Messages Encryption of signalling messages can be achieved with TLS or IPSec. Similar to strong identity assertion, a PKI infrastructure is assumed to be in place for TLS (or IPSec) deployment so that SSPs can obtain and trust the keys necessary to decrypt messages and verify signatures sent by other SSPs. 4.14. Encyrption and Integrity Protection of Media Stream The Secure Real-time Transport Protocol (SRTP) [RFC3711] adds security features to plain RTP by mainly providing encryption using AES to prevent eavesdropping. It also uses HMAC-SHA1 and index keeping to enable message authentication/integrity and replay protection required to prevent media hijack attacks. Secure RTCP (SRTCP) provides the same security-related features to RTCP as SRTP does for RTP. SRTCP is described in [RFC3711] as optional. In order to prevent media session teardown, it is recommended to turn this feature on.
A MUST read and “are we covered” for all VoIP Service Providers! Good luck!
