Jonathan Rosenberg, PhD, the chief technology officer Dynamicsoft, a telecommunications infrastructure vendor based in Parsippany, NJ, is co-author of the Session Initiation Protocol standard, one of the underpinnings of Voice over Internet Protocol telephony. He was recently named as a member of the Internet Architecture Board, the technical body tasked with providing oversight of the architecture, protocols and procedures used by the Internet. Ellen Muraskin, eWeek.coms VOIP and Telephony topic center editor, interviewed Rosenberg via e-mail to get his responses to the security concerns raised in Jim Louderbacks recent column, Security Holes Make VOIP a Risky Business.
Isnt the security of a VOIP network a function of the SIP protocol in the first place?
Many of the attacks Jim is concerned about are something that SIP would need to (and does) protect against. For example, preventing an attacker from eavesdropping on a call is something that SIP itself provides. Preventing someone from hijacking my calls is something that SIP provides. Preventing someone from sending a flood of packets to a SIP server is not something SIP itself can stop, since the attack is not attempting to manipulate any aspect of SIP operation.
What is the best defense against a flood of packets, i.e., a denial-of-service attack?
This is prevented by purchasing hardened servers that have been thoroughly tested for such vulnerabilities, and keeping the products up to date with the latest version. It is hard to stop attacks that merely flood a server with packets in an attempt to disrupt service. Those are best handled by firewalls and intrusion detection systems.
Many IT departments think that the firewall is the one and only answer, but this is not true. Attacks can easily come from the inside (for example, through a Trojan horse that reaches a computer inside the network). Or, they can come from the outside, but be undetectable as an attack. Thus, the network needs to be protected in all places, and that means using SIPs security features, as well.
Is carrier-to-carrier handoff a true problem yet at this point? I havent seen any cases, myself where calls traverse multiple VOIP carriers, unless they gateway out and back in first.
Its not yet a problem in the consumer space (that is, calls where the consumer actually has a VOIP phone). Inter-carrier handoff is quite popular for so-called toll bypass applications, where the end users are on the traditional phone network, and the call traverses multiple SIP carriers in the core of the network. However, inter-carrier calling in the consumer space is coming soon (this year, I think).
Whos on the line
?”> “Anyone with network access can listen in on conversations.” True or false, vis a vis SIP VOIP?
SIP has the ability to secure the media in the call, so that even if an attacker was handed each and every packet on a silver platter, there is nothing they could do to decrypt it. This is done using Secure RTP (SRTP), which encrypts and authenticates each media packet. Now, the problem is that these techniques are not in widespread usage, in large part because operators and enterprises havent been demanding them. Without any kind of security technique in place to prevent this attack, it can be possible, depending on the type of access network. If the caller and/or called party are on a LAN of some sort that broadcasts traffic (such as an Ethernet hub), the media packets to/from that user will be sent in the clear over that LAN. An attacker with a sniffing tool could then extract them in listen in.
What about switched Ethernet?
This makes such attacks much harder to launch, but not impossible. One could insert a tap into the switch and extract traffic. This is a more difficult attack to launch, but its possible. The best way to prevent against such eavesdropping attacks is to enable the SIP security mechanisms that can prevent this (namely, SRTP).
Switched Ethernet is more common in the enterprise these days, but hubs (where everyone sees all the packets on the LAN) are common in homes and smaller enterprises due to their lower cost.
What can prevent someone from spoofing the IP address of your phone? Would this spoof your caller ID with it? Is this a true vulnerability? What makes voice less vulnerable than email in this regard?
IP address spoofing can be prevented by techniques known as ingress source filtering, which detect packets with out-of-place source IP addresses. That technique has nothing to do with VOIP and is in common usage, though it needs more deployment.
That said, spoofing an IP address doesnt, in and of itself, cause a direct attack in SIP. If I send a SIP call setup message and spoof my source address, the called partys phone will ring, but the call wont be able to complete. Of course, I can call you and hang up when you answer without spoofing my source IP address, and achieve the same effect.
You cannot equate source IP address spoofing with faking caller ID. They are different things. If SIPs security mechanisms are enabled, it will be impossible for you, using a spoofed source IP address or otherwise, to insert a fake caller ID. Indeed, with those security techniques in place, if you fake a source IP address in a call setup message, the call wont even be able to pass the first SIP proxy. If SIPs security mechanisms are not used, then it is possible to fake my caller ID, yes, just as I can generate fake FROM addresses in email. Many VOIP systems I know of do, in fact, use SIPs security mechanisms to make sure that caller ID is properly authenticated.
Indeed, with those security mechanisms properly enabled, caller ID becomes more secure than the telephone network. In the telephone network, I could still tap into a cable under the street, insert a box that receives the messages, and generate fake caller IDs. However, that attack would not be possible when SIPs security features are enabled.
So what are some of those SIP security mechanisms?
Without going into too much detail, the core of it is something we call “sips”. Just like “https” means secure http (i.e., secure web), “sips” means secure SIP. When you make a call using sips, all call signaling traffic flows over SSL/TLS, just like secure web traffic. That brings many security properties.
VOIP Caller ID
?”>
Is a Spam bombardment a true threat to an IP voice server?
Spam (a different problem than denial-of-service) is hard to stop. As I discussed above, unless I fundamentally limit who can call me (which is the approach in closed networks), its hard to discern the intent of the caller when a call is received. Some of the techniques in use for email can work for VOIP spam (black/white listing, for example), and others dont (content analysis).
SIP does indeed provide authentication, so that if my SIP provider receives a call, it can know for sure that the caller is indeed who they say they are. The problem is, with spam, thats not enough. Even if I can authenticate the caller – that is, determine his or her identity – that doesnt tell me anything about whether that person is a spammer or not. Being able to verify who you are (which SIP can do) is not the same as verifying whether or not you have good or bad intentions in sending me this call. Unfortunately, the latter problem – determining whether someones intentions are good or bad – is not one that is easily solved by some feature in the SIP protocol. In essence, what is my basis for “trusting” that this caller is a good person? There is no easy one. Thats the trust problem here.
Spam generally doesnt disrupt service, though, in that its not seeking to crash the server or stop you from getting calls (in fact, the aim is to allow you to get calls – from spammers!).
Are such spam attacks in the VOIP world truly anonymous — as opposed to traceable crank phone calls ?
If SIPs security techniques are used, they are traceable. However, traceability doesnt always help. For example, if I receive a spam call from spammer@spammers.iq (.iq is Iraq), I can verify that this caller is , in fact, coming from Iraq, but there is probably little I can do to go after them.
To summarize, SIP itself has a wealth of security features built in for providing authentication, confidentiality, and integrity of communications. It even has techniques that can prevent your SIP provider from listening in on your call – that is, you dont even need to trust your provider (these techniques are harder to deploy, however). These techniques, when enabled, surpass the security of even the PSTN.
However, the problem is that many of these techniques are not deployed, are not demanded by operators or enterprises, and as a result, often not even implemented by vendors. In my experience, it is only after these networks suffer an attack that these network providers wake up, and start demanding these features to be delivered by their vendors.