1 / 10

Secure VoIP: call establishment and media protection

Secure VoIP: call establishment and media protection. Johan Bilien, Erik Eliasson, Joachim Orrblad, Jon-Olov Vatn. Telecommunication Systems Laboratory Royal Institute of Technology (KTH) Stockholm, Sweden. Requirements for secure VoIP. Protecting the signaling

zander
Télécharger la présentation

Secure VoIP: call establishment and media protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure VoIP: call establishment and media protection Johan Bilien, Erik Eliasson, Joachim Orrblad, Jon-Olov Vatn Telecommunication Systems Laboratory Royal Institute of Technology (KTH) Stockholm, Sweden

  2. Requirements for secure VoIP • Protecting the signaling • encryption and integrity protection • hop-by-hop • protection of privacy • Protecting the media • encryption and integrity protection • end-to-end • at network (IPSec ESP) or application layer (SRTP) • Authenticated Key Exchange (AKE) • provides key to protect the media • allows callee policies, such as filtering of spam P P UA UA

  3. AKE for Secure VoIP • Which protocol? • IKE (RFC 2409) • widely deployed and acknowledged • MIKEY (RFC 3830) • specifically designed for protection of multimedia services • MIKEY profile defined for SRTP • How to combine the AKE and the SIP signaling? • “out-of-band”, performed in additional messages, or • integrated, carried in the SIP messages

  4. Performance metrics • Ringing delay (RD) • from sending the INVITE to receiving the ringing notification • includes caller authentication • Media clipping (MC) • media transmission is hindered by ongoing cryptographic processing • Ghost ringing • the caller cancels the call after the callee started ringing INVITE RD 180 Ringing 200 OK RTP MC RTP

  5. IKE and SIP signaling • IKE performed “out of band” • SIP preconditions (RFC 3312) extended for IKE setup INVITE / IPSec required 183 Session in progress IKE UPDATE 200 OK (UPDATE) 200 OK (INVITE)

  6. MIKEY and SIP signaling • MIKEY integrated with SIP / SDP • Without reliable provisional responses • Processing of the MIKEY response in the 200 OK creates media clipping INVITE / MIKEY Init 200 OK / MIKEY Response INVITE / MIKEY Init • With reliable provisional responses • The MIKEY response is sent reliably in a provisional response • The security association is complete before the 200 OK is sent, thus avoiding media clipping 183 / MIKEY Response PRACK 200 OK

  7. Implementation • Signaling protection using TLS • Media protection • SRTP • AKE using MIKEY in the SDP offer-answer • IPSEC – ESP • AKE using MIKEY in a separate MIME payload • proposed MIKEY profile for ESP • No reliable provisional response • Open source (LGPL and GPL)

  8. DIAL OFF HOOK Secure call setup - delays Alice Bob Bob Alice Invite processing • SIP Processing • MIKEY verify, Policy check Callee Transmit Clipping • Create MIKEY Reply • Session key gen. • (Update IPSec DBs) Packetization delay INVITE/MIKEY Init Ringing delay • Create MIKEY Init • SIP processing Caller Transmit Clipping: • SIP Processing • MIKEY verify, policy check • Session key gen. • (Update IPSec DBs) Packetization Delay a1 b1 180 Ringing Alice 200 OK/MIKEY Reply b2 b3 a2 RTP Media a4 a3 RTP Media Caller Reception Clipping

  9. Measurements

  10. Conclusions and future work • In all the measured cases, the ringing delay is not significant for a human person (~ 75 ms) • The key exchange for SRTP results in a short transmit clipping on both sides (~170 ms) • The use of IPSec results in a major media clipping on both sides (~ 800 ms). We believe this to be a Linux IPSec implementation issue. • Adding support for reliable provisional responses, to carry the MIKEY response, would cancel those clippings. • We recommend the use of SRTP for media protection, TLS for signaling protection, and an authenticated key exchange based on MIKEY.

More Related