Toward ubiquitous IP Telephony deployments

Dr. Saverio Niccolini Research Staff Member Network Laboratories, NEC Europe Ltd. ([email protected])

Background

• Inside the researchers’ community there is a raising interest for IP Telephony and its deployments – demonstrated by several actors’ efforts in the area

• TERENA IP Telephony Cookbook • TERENA Task Force on Voice, Video and Collaboration • Internet2 SIP.edu deployment • other deployments and projects around the globe 2 TNC2005 - POZNAN - JUNE 2005

Question

• Have VoIP/IPTel technologies reached the level of maturity?

• Are they ready for their introduction in the production environment of the National Research Networks (NRENs) and research institutes on a large scale?

– I will try to show you

• state of the art • challenges • recommendations 3 TNC2005 - POZNAN - JUNE 2005

State of the art

• • • TERENA TF-VVC has developed a “SURVEY on IP Telephony deployments” – NRENs participating to TF-VVC will distribute shortly (I hope) such a Survey to individual institutions with IP Telephony deployments in place or planned – I will collect the results and produce the output Why? Need to understand the state of the art – differences from U.S.A. and Europe • Internet2 SIP.edu deployment is focused on email identities • European deployments are looking with interest also to E.164 numbering • I am not going to say which is the best approach (a mixed one is going to be investigated in the TF-VVC with Recommendations on how to interconnect different deployments) Interested?

– Have a look at the TF-VVC work (this is only one of the activity areas) • Face-to-face meeting today after the conference 4 TNC2005 - POZNAN - JUNE 2005

State of the art

• Briefly looking at the state of the art – common protocol for IP Telephony deployments is SIP – H.323 is related mainly to GDS but linking to PSTN is not ubiquitous – no solution so far on how to link SIP and H.323 to exploit good H.323 MCU functionalities and not to trash the work done so far (SIP NREN hierarchy, or SIP.e(d)u is being discussed but still only an idea) – massive usage of good open-source / free software • SER (SIP Express Router) • Asterisk • X-lite clients 5 TNC2005 - POZNAN - JUNE 2005

Challenges in ubiquitous IP Telephony

• Major factors limiting ubiquitous deployments – limited adoption of SRV records in DNS • this inhibits the convergence of e-mail and VoIP identities – ENUM has some administrative introduction and scalability problems • this inhibits the convergence of URI identities and E.164 numbers – Need for more interoperability tests among multiple sites • this limits interoperability and leave issues unsolved – Network layer issues are almost ignored • IP Telephony is not working with NATs/FWs there) – only small number of institutions implements NAT and/or Firewalls traversal methods » limits the introduction of IP Telephony – Lot of institutions have public address space and ignore NAT/FW traversal methods » limits mobility scenarios where user connect from hot-spots and from home networks where NAT and FW are presents – Security issues are completely ignored (but the problems are out • SPAM over Internet Telephony, SPIT • Denial of Service, DoS, attacks 6 TNC2005 - POZNAN - JUNE 2005

Recommendations: features of a IP Telephony deployment

• Adoption of SRV records in DNS – if a user is reachable at • mailto:[email protected]

• sip:[email protected]

– using SRV records you can reach him at the same address regardless of the application • mailto:[email protected]

• sip:[email protected]

– How?

• make sip request for domain.com point to sip-proxy.dmain.com

• ENUM can make your SIP users being reachable at their telephone number – 0049-621-456789 can be mapped to sip:[email protected] using NAPTR records inside DNS – it is not yet the golden solution (administrative and scalability problems) • but it is well suited for small-medium scale deployment – just one number to remember 7 TNC2005 - POZNAN - JUNE 2005

Recommendations: network layer and security of IP Telephony

• IP Telephony on top of public networks without firewalls – the deployment and the introduction is easy – it constitutes a big risk in terms of security • • NATs (Network Address Translators) – “light” security device • topology hiding • basic firewall functionality – number of NATs is growing (broadband at home, etc.) • reducing number of IP addresses – shortage of address in the IPv4 world – With IPv6 we would not need NATs anymore • even if it is probable that you will still be using NATs as light security mean FWs (Firewalls) – security device – numbers of FWs is growing (including personal FWs) – FWs rules get more restrictive 8 TNC2005 - POZNAN - JUNE 2005

Recommendations: network layer and security of IP Telephony

• IP Telephony deployments built on top of a network with NAT/FW are more secure (servers and clients are more protected) – Examples: • NEC Network Laboratories at Heidelberg (Germany) • EIVD University of Applied Science of Vaud Canton in Yverdon (Switzerland) Server Internal Network DMZ NAT Router and FW Internet SIP (SER) server Asterisk VoIP to PSTN Gateway Internal Network DMZ NAT Router and FW Internal Network Mobile Users 9 TNC2005 - POZNAN - JUNE 2005

Problems: SIP with NATs/FWs

• SIP signaling – SIP signaling and media transport is done peer-to-peer • SIP proxy does not communicate back to SIP client on NAT’ed channel • Pinhole in NAT/FW will timeout on inactivity – typically less than 1 minute – if this occurs, client can not receive incoming call • Media – Media ports are negotiated per call • IP address and port sent in SIP INVITE / 200 OK (SDP) is private – not globally routable • Media must be initiated in Private  Public direction • RTCP (RTP port + 1) fails through firewall because of NAPT function (port translation) • Pinhole in NAT/FW will timeout on inactivity (silence suppression) – typically less than 1 minute » if this occurs, client can not receive media 10 TNC2005 - POZNAN - JUNE 2005

Recommendations: network layer and security of IP Telephony

• Needs of implementing NAT/FW traversal methods – if the institution has no NAT/FW in place it is still a good practice to implement NAT/FW traversal methods avoiding problems in mobility scenarios where NAT/FW are present (hot-spots, broadband at home) TNC2005 - POZNAN - JUNE 2005 11

Solutions to NAT Traversal

• STUN • TURN • ICE • B2BUA • All these solutions require UA to support symmetric signaling and media

TNC2005 - POZNAN - JUNE 2005 12

Solutions to NAT Traversal: STUN

Private Public [A,b] STUN Server X,y A,b S,t STUN Client

NAT

• IETF RFC 3489 “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) ” – discover public IP address (and port mapping rules) of NAT between client and Internet – does not work with Symmetric NATs used by most corporate environments – does not work if both clients are behind the same NAT – requires a STUN client in the SIP UA • best SIP UA have STUN support (Xten software, Zyxel WiFi phone) – requires additional deployment of a STUN server placed in the public space (normally co-located with the SIP Proxy server) • open-source stund server works perfectly with Xten products, Zyxel WiFi phone 13 TNC2005 - POZNAN - JUNE 2005

Solutions to FW Traversal

• • • • Open pinholes (statically) – can be a security risk – towards clients • difficult to configure since Internet Telephony protocols negotiate port on a call-by-call basis – towards servers SIP aware FW – dynamically open pinholes per session – firewall just understands signaling and open pinholes consequently Stateful firewall – outgoing traffic open pinholes for corresponding incoming traffic – UA must support symmetric signaling and media Proxy solution – open pinholes just to dedicated host in a DMZ (De-Militarized Zone) • TURN server • B2BUA (already seen) 14 TNC2005 - POZNAN - JUNE 2005

Recommendations: network layer and security of IP Telephony

• What about the deployments previously described?

– usage of STUN (stund) as a NAT traversal method – usage of a B2BUA for the extreme cases (symmetric NATs) with video support • • to be substituted by a better method – open pinholes towards SIP server to be substituted by a better method Internal Network Internal Network SIP (SER) server Asterisk VoIP to PSTN Gateway DMZ NAT Router and FW Internal Network SIP (SER) B2BUA (rtpproxy) STUN (stund) Asterisk VoIP to PSTN Gateway DMZ NAT Router and FW Internal Network Mobile Users TNC2005 - POZNAN - JUNE 2005 15 Mobile Users

Recommendations: security of IP Telephony

• Security issues related to IP Telephony are still 99% ignored (but the problems are there and some solutions are deployable) – Need for encryption to secure the network and prevent lost of sensitive information • Encryption (it complicates the NAT/FW traversal) – SIP signaling encryption » end-to-end (S/MIME) – Media encryption » SRTP – Need for authentication to assert identity • Basic Authentication (deprecated) – end-to-end • • • » hop-by-hop (IPSec, SIPS/TLS) Digest authentication (challenge - response) – end-to-end – today only digest authentication is used but other stronger forms are deployable S/MIME – end-to-end SIPS/TLS – hop-by-hop • • IPSec – hop-by-hop Identity framework (under standardization in IETF) – Denial of Service (DoS) and Intrusion attacks (call cancel, call hijacking, call eavesdropping) (still research topic) • to SIP signaling • • to media transport (RTP/RTCP) to SIP servers • to end clients – SPAM over Internet Telephony (SPIT) (still research topic) • what about of hundreds of calls just with publicity messages, the phone is ringing all day, etc 16 TNC2005 - POZNAN - JUNE 2005

Special thanks

• SWITCH, The Swiss Education and Research Network ( http://www.switch.ch

) – provided ideas about this paper (and material) TNC2005 - POZNAN - JUNE 2005 17

That’s all!

Questions?

TNC2005 - POZNAN - JUNE 2005 18