Lately, I’ve been going through a lot of SIP RFCs and drafts, trying to get an overview of the security suggested in all of these documents. The quality of this work, seen from a developer’s perspective, is quite poor. Sometimes it seems like authors think, “oh, we need to add that security stuff, so let’s add a few keywords like TLS and S/MIME here and there“. We need to get better in reviewing the drafts from a security perspective. Here are  some thoughts on instructions to RFC authors:

  • S/MIME: If you refer to S/MIME, make it very clear which certificates that are going to be used and how the certificate verification process should happen – which part of the SIP message should match with which part of the certificate? And which certificate should be used to encrypt?
  • TLS: If you refer to TLS, you need to be very clear on why – is this to provide authentication, confidentiality or something else? Does the solution require mutual authentication or just server authentication? If authentication is part of your solution, make it very clear how you verify the certificate with the message, down to SIP header fields and X.509v3/PKIX fields.
  • SIPS: If you suggest usage of SIPS, make it very clear on what this adds and how the message flow is supposed to look like. Is SIPS used in the request uri, the Contact or somewhere else? What is the effect? Make sure you really understand SIPS before this is added. Or even better, just avoid SIPS and let it fade away.
  • Certificate matching: If you refer to a certificate SubjAltName, make very clear if it’s a URI or a dnsName field that is required and preferences if there are multiple SubjAltNames in addition to the certificate subject.
The worst documenst so far are the RFCs related to SIP subscriptions. They suggest using S/MIME for encryption, but does not explain how. Now, if I subscribe to the presence status of sip:bob@example.com, my SUBSCRIBE request will end up at the presence server for the domain example.com. Should the user agent somehow find the certificate for sip:example.com to encrypt the message? Should we use the certificate of sip:bob@example.com – which would require the presence server to have the private key belonging to Bob? The RFCs doesn’t help at all.
RFC 3857 states the following on the topic of eavesdropping on SUBSCRIBE/NOTIFY requests:

“To prevent that, watchers MAY use the sips URI scheme when subscribing to a watcherinfo resource.  Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 of RFC 3261).”

This means that a UA should be able to SUBSCRIBE over a TLS connection, and get NOTIFY over – what? Remember that this was written before SIP Outbound was standardized. For a developer this means that the subscriber is required to have a TLS certificate and accept incoming connections on the TLS port if the Contact in the SUBSCRIBE is a SIPS uri. The RFC should discuss this in more detail.

Nine years after RFC 3261 we have a larger toolbox, including GRUUs, SIP Outbound, SIP Domain certificates, DNSsec and much more. It’s time we restart the work with a SIP security architecture and provide something that developers can implement and that users will clearly feel is a better and more trustworthy solution. The IETF mantra is “rough consensus and running code”. RFCs should make it easy to produce running code. The SIP RFCs fails do this on the topic of SIP security.

/Olle

 

 

 

SIP over dual stacks - IPv4 and IPv6

Stay Connected - learn more about SIP & IPv6

Yesterday I found an Internet Draft called Testing Eyeball Happiness that gives examples on how to test dual stack deployments. There is a known issue with applications that retrieves multiple IP addresses from the same host name in DNS and , following current RFCs, test them sequentially with a preference for IPv6 addresses. The timeouts when things go bad with one flow are far longer than what the user accepts. Let’s say that Bob (you know him) use his SIP phone to place a call to Alice. Bob’s phone calls an outbound proxy, that wants to forward to another domain. This domain announces both IPv4 and IPv6 addresses in DNS for their proxy. Now, Bob’s proxy actually has an IPv6 address, but is not connected to the Internet with IPv6. The proxy will try connecting to Alice’s domain SIP proxy over IPv6 for quite a long time before it recognizes that there’s no connectivity. Hopefully it will then try another address, but the question is if the user is waiting for that to happen. In telephony, loosing seconds is a catastrophe, especially between requesting a call and getting the first ringing signal. Remember – this is not about media, this is only about signaling. Without signaling, we’ll never get into any media issues.

HTTP and Happy Eyeballs

We’ve seen this problem on the web. Browsers suddenly told us that large sites was not available. Turned out that the new home router enabled IPv6 tunnels and announced IPv6 prefixes on the LAN, something that the firewall blocked. By disabling IPv6 in the laptop, we could reach the web site again. This caused web sites to stop announcing IPv6 and computer owners to disable IPv6. This was no good for the IPv6 migration so the browser developers started to try to find solutions. The Happy Eyeballs discussion in the IETF is about finding algorithms where the browser connects to all addresses in parallel and selects a candidate that answers quickly. In SIP, we need to implement the same fix, over UDP, TCP and STCP. I’ll try to set up some tests at SIPit to see what the current state is.

A quote from the abstract section of the IETF draft:

In a dual stack network (i.e., one that contains both IPv4 [RFC0791] and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network that uses multiple prefixes allocated by upstream providers that implement BCP 38 Ingress Filtering [RFC2827], the fact that two hosts that need to communicate have addresses using the same architecture does not imply that the network has usable routes connecting them, or that those addresses are useful to the applications in question. In addition, the process of establishing a session using the Sockets API [RFC3493] is generally described in terms of obtaining a list of possible addresses for a peer (which will normally include both IPv4 and IPv6 addresses) using getaddrinfo() and trying them in sequence until one succeeds or all have failed. This naive algorithm, if implemented as described, has the side-effect of making the worst case delay in establishing a session far longer than human patience normally allows. This has the effect of discouraging users from enabling IPv6 in their equipment, or content providers from offering AAAA records for their services.

References:

I’m currently swimming through the deep waters of SIP RFCs in order to get an overview of TLS implementation requirements. Reading RFC 3428 – The SIP Message Extension- I found something I did not know. In section 11, Security Considerations, the RFC states:

In normal usage, most SIP requests are used to setup and modify communication sessions. The actual communication between participants happens in the media sessions, not in the SIP requests themselves. The MESSAGE method changes this assumption; MESSAGE requests normally carry the actual communication between participants as payload. This implies that MESSAGE requests have a greater need for security than most other SIP requests. In particular, UAs that support the MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms.

I have seen quite a few implementations of MESSAGE, but none has been compliant with RFC 3428.

The SIP MESSAGE implements a way to send short messages over SIP, within a dialog or outside of a dialog. MESSAGE requests does not create dialog, thus there’s no “session”. For chat sessions that , MSRP – the message session relay protocol – was developed. I’ll try to write more about that protocol in another blog post.

Having a lot of interesting discussions about Realtime Network Security, with SIP as a focus, these days. We need to get enough people in a large room with enough whiteboards to attack the issue. The SIP RFCs needs many updates in this area to help developers to develop more secure software.

( 11 Oct, 2011) oej.  

Last week I talked at the Voip2Day conference in Madrid, organized by Avanzada7. The talk, named “Watch out!” covers new areas developed in SIP, but not implemented in many devices or servers out there. Solutions for NAT traversal, PSTN trunk registration and new work with the real time web is covered, along with a small update to the list of 10 bullets to remember when implementing a new SIP platform.

Some topics covered:

  • ICE, Interactive Connection Establishment, a complex but working solution to find a working media path between two Sip phones, either directly or using a media relay (A TURN server). Used both for NAT traversal and IPv4/IPv6 dual stack deployments.
  • SIP Outbound, the way to handle NAT traversal for SIP signaling. With SIP outbound, the client sets up multiple IP connections, called flows, to servers while indicating that it’s actually the same device that registers on all these connections. The proxy can then do failover if one connection fails. It’s up to the SIP phone, the user agent, to maintain the connections and re-open them when they fail.
  • GIN – the way SIPconnect sends a registration for a SIP trunk with multiple phone numbers. Before GIN, every vendor used it’s very own hack which raised the cost for service providers that wanted to support multiple vendors.
  • GRUU – Globally Routable User URI’s – a domain-based address for every device that registers for an account. Makes it possible to do more complex operations over domain boundaries. Without a GRUU, many URI’s are unusable since they’re referring to an IP address hidden behind a NAT device.
I feel that ICE and SIP outbound are good candidates on solving the NAT puzzle as well as the IPv6 transition. We need more Open Source implementations as a reference!
The presentation also covers RTCweb briefly. On the conference, there was a live demonstration by Iñaki Bas Castillo and a colleague of a SIP implementation in JavaScript connecting over WebSockets to a SIP proxy. They lacked RTCweb so there was no media in the calls, but it showed that it’s possible to implement SIP in the browser!

The talk is now published on Slideshare and can be viewed online. Enjoy!

/Olle

Realtime communication in web browsersVideo sessions in the browser opens up for a lot of new applications. While this has been working with various plugins, new opportunities will open up when it becomes part of your standard web browser. HTML5 introduced native video in the browser. New standardization are looking into peer2peer multimedia sessions in the browser, not just broadcast. This opens up for a large set of applications, from “click2call” without plugins to video chats like in Facebook and Google+. This is exciting. And all the old SIP architects seems to have jumped onto this project, trying to get things right from start in this second generation effort. (more…)

The very first SIP-compatible software I installed myself was SER, Sip Express Router, from iptel.org, a spinoff from the Fokus research institute in Berlin. During the years I have worked with SER and OpenSER/Kamailio, I’ve become friends with many of the developers and have contributed with documentation and training. The team gathers world leading SIP experts and developers, so it’s a joy to meet them and brainstorm and share experiences. In almost all my installations and platforms, a SIP proxy is at the core of the real time multimedia platform. My choice has always been SER/OpenSER/Kamailio.

Starting as a SIP proxy, moving on as an extensible SIP server

Sip Express Router started as an Open Source SIP Proxy. Today we see Kamailio, based on the common sip-router.org core, as an extensible SIP server. With an embedded presence server, http support and interfaces to python and lua for scripting, it’s a platform that can handle many different roles in a large-scale SIP architecture. IPv4 and IPv6 support from the beginning, security integrated and a very active development team. Everything you need to build a standard-compliant cool network for your organization’s real-time communication. 10 years of success.

Jubilee September 2nd, 2011 where it all started

The 3rd of September marks 10 years since the start. Reason to celebrate, don’t you think?

 

We will celebrate on Friday, September 2nd and into the night. FhG Fokus Research Institute hosts a one-day conference session with all the core people. If you have any interest in SIP and these platforms, make sure you will be there.

The event is organized with sponsorships from FhG Fokus Institute, Asipto, Amooma and TeamForrest. At the same time local events will be organized in Barcelona, Spain and Vienna, Austria.  Read the agenda and register today!

The benefit of open standards is that it put the customers in control. They can use any SIP-compatible phone with any SIP-compatible server. We can place calls between companies. We can freely choose a SIP PSTN-gateway service provider. There are no vendor lock-ins.

To reach this, a lot of work is needed. A lot of testing, code changes, discussions between developers and regular meetings as standards evolve. The SIP Forum, an organization for vendors that sell SIP based services or products, organizes SIPit events where developers meet to run tests, discuss standards and improve their products. The winners here are the customers. A result of SIPit is better interoperability between products, something that expands the market and makes it easier to integrate solutions from different vendors.

As a customer, please ask your vendor if they send teams to SIPit. That’s enough. There are no formal tests involved, no official test results that you can ask for. Participation means that a vendor is interested in interoperability, which is good for you.

Registration for the next SIPit in Monte Carlo, Monaco, is now open. It’s hosted by ETSI, an European Union standardization organization. If you develop SIP products – make sure you register now!

Alec Saunders has written a new manifesto called “Voice 3.0: The emergence of the Voice Web“. It’s very good reading and I agree with most of it. Please read it! What I am missing, which you will see in my comment far down the side, are two things:

  • IPv6 – it’s the glue that will make Voice 3.0 work
  • Security – we need to learn from our mistakes and make Voice 3.0 secure by default

I have written a lot of information about SIP and IPv6 on Edvina’s web site, Twitter and Facebook. Dan York has joined me in this campaign and have a lot of good podcasts, presentations and information on Voxeo’s IPv6 resources page. There’s quite a lot of work we still need to do, but we’re heading in the right direction in the SIP community.

I’m embarrassed

Now is the  time to start working on security. I find it really embarrassing that we have almost no experience of security in VoIP. The protocol has been around for ten years or more and we’re still confused. The hardware vendors claim that the CPUs can’t handle it. Or the DSP’s. Or something else. As we move towards more video we need more CPU power to encrypt. On the other side we have users that doesn’t require any security. They run stuff over the enterprise networks, over home networks and the Internet without bothering with who can listen in, access the log files or access their accounts.

The dark side

This last year, the number of attacks on SIP servers has grown in numbers. I hear not only rumours, but see attacks in progress. I have met a number of people who have lost huge amounts of money on International calls to foreign countries, placed by unknown hackers that figured out that their account (typically “300″) had a very complicated password (typically “300″). The next thing that we’re going to see during summer leave or xmas is someone showing a journalist how easy it is to see that the boss calls the union several times a day, propably to negotiate layoffs. Or calling competition, maybe to sell the company.

Let’s agree on one thing: ALL networks are insecure

I think it’s time to stop ignoring security. I think we have to agree that it makes our architecture much more easy if we assume that ALL networks are insecure. We can not judge, our users surely can not determine if a network is secure or not. They have to be able to connect to any open WiFi network and use the services we produce. Without thinking about anything else than reaching their office, customer, family or the kid back home. Every communication needs to be secure. Period.

If we start there, we’re on the right track. Now we need to work together and figure out where to go. How do we exchange encryption keys? How do we handle identities? Where do we start. Let’s not make the mistake of trying to hook on to a global PKI that doesn’t scale (and has proven not to be secure) like the one used by the web. PGP is interesting, but only scale on a nerd level. It’s too complicated the way we use it today. I would not even try to explain it and make my mother use it. We need to work on this.

Distributed webs of trust

Maybe it’s Facebook, Google+ or LinkedIn that will be the trust platform. Or a combination of them using systems like OpenID, oAuth and SAML 2.0 in various combinations. We need something simple, scalable and secure. That’s not easy to fulfill. Especially in a world filled with engineers with a lot of opinions, experiences and ideas. It’s our responsibility to start working on this. The IETF and other parties are already working hard on other components of Voice 3.0.Let’s get our act together on the security part of the vision for Voice 3.0 too. We need to, step by step, build a trustworthy platform for realtime communication for everyone.

Imagine working at your desk, getting a phone call from your friend Randy. You answer on your IP phone. Being Randy, he suddenly wants to play a new jingle he created while being in the mood the day before. The phone speaker is not a good device for a cool guitar riff – is it? On the same desk you have your PC with a softphone that supports HD voice and really cool loudspeakers. Why not transfer the audio to the PC while still using the phone’s microphone? After that, you want to play a video for Randy. Now you want to add media from your laptop to the call – while the call is still managed by the IP phone.

This is a true multimedia session, that is not that far away. But it’s too complex to manage in the SIP protocol today. I just found out about the SPLICES working group in the IETF that is working on this issue. I also know that the Asterisk development team is working on a new media architecture - something we’ve needed for many years. My presentation about the new media architecture from Astridevcon 3 years ago talks about being able to add streams, have multiple streams of the same kind and remove streams dynamically during a call. SPLICES, when finished, will help us implement it in a really cool way in SIP.

Another mailing list to follow.

Do you know another thing? Randy and I wouldn’t be able to have this call as easily if we did not use SIP over IPv6. Doing a call like the one above over two NATs would be awfully complex…

« Previous PageNext Page »