Speaking of Standards

The IETF announced today that the IAB, ISOC, MIT and W3C are jointly hosting a workshop at MIT on December 8 and 9 on the topic of Internet privacy. A website is up at:

http://www.iab.org/about/workshops/privacy/

And the announcement started out with this text:

The Internet Architecture Board (IAB), World Wide Web Consortium (W3C), Internet Society (ISOC) and Massachusetts Institute of Technology (MIT) will hold a joint Internet privacy workshop on 8 and 9 December 2010 at MIT, Cambridge, Massachusetts on the question:

“How Can Technology Help to Improve Privacy on the Internet?”

Information about who we are, what we own, what we have experienced, how we behave, where we are located, and how we can be reached are among the most personal pieces of information about us. This information is increasingly being made more easily available electronically via the Internet, often without the consent of the subject.

The question for the workshop therefore is: How can we ensure that architectures and technologies for the Internet, including the World Wide Web, are developed in ways that respects users‚ intentions about their privacy?

This workshop aims to explore the experience and approaches taken by developers of Internet including Web technology, when designing privacy into these protocols and architectures. Engineers know that many design considerations need to be taken into account when developing solutions. Balancing between the conflicting goals of openness, privacy, economics, and security is often difficult…

It sounds like a great event and if you are interested in participating, information is available on the event web site.

Given my background in security, I’ve been asked a number of times… why didn’t the IETF or someone just mandate ONE way to secure audio or video sent via RTP? After all, RTP by itself does not have any real security built-in and while Secure RTP (SRTP) is increasingly used, it’s not universal.

I’m obviously not alone in being asked this question, and Colin Perkins and Magnus Westerlund at the IETF wrote up an Internet-Draft that was recently approved to be an Informational RFC on just this topic:

Why RTP Does Not Mandate a Single Security Mechanism
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory

From the introduction:

The Real-time Transport Protocol (RTP) [RFC3550] is widely used for voice over IP, Internet television, video conferencing, and various other real-time and streaming media applications. Despite this, the base RTP specification provides very limited options for media security, and defines no standard key exchange mechanism. Rather, a number of extensions are defined to provide confidentiality and authentication of RTP media streams and RTCP control messages, and to exchange security keys. This memo outlines why it is appropriate that multiple extension mechanisms are defined, rather than mandating a single security and keying mechanism.

The document goes on to list where RTP is use and issues with various security mechanisms (including SRTP). If you ever wondered why everyone doesn’t just use SRTP… this short document may be well worth the read.

Long-time readers will know that I have a fascination with the ideas behind P2PSIP, which I explained once before in a post “P2PSIP and pushing voice down into local clouds”. While it has very little directly to do with my work here at Voxeo, I’ve continued to help a team of folks with the IETF who are working on an Internet-Draft providing an overview of the security concerns related to P2PSIP.

Given the upcoming IETF 75 meeting, I published an updated version of the Internet-Draft last week. It is available at:

http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements

Those of you interested in SIP, P2P networks or security in general may find it of interest. Here’s the abstract:

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

My particular contribution in this revision was writing a new section on “Interconnection to other networks“. Many, if not most, P2PSIP networks will want to interconnect with the legacy PSTN or with other SIP networks. This section takes a look at what the security ramifications are and what an implementor of a P2PSIP network should consider.

Comments and feedback about this draft are of course welcome. At IETF75 in Stockholm I know that members of the author team will be asking the P2PSIP Working Group to accept this as a “working group document” (another step on the path to becoming a RFC) and there will undoubtedly be further revisions of the document.

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

Technorati Tags: sip, p2p, p2psip, security, ietf, standards

If you aren’t thinking about the security of your VoIP systems, you should be, because the tools to attack those systems keep getting better. Over on the Voice of VOIPSA blog, I recently wrote about the release of a new suite of security test tools that make some of the attacks now “point-and-click”.

For a variety of reasons, many of these attacks are against SIP or unencrypted RTP, so they are definitely good to understand.

P.S. Note that VOIPSA (VoIP Security Alliance) does have a lengthy list of VoIP security tools already… this new suite is just one more to be added to the list.

Technorati Tags: sip, sip security, voip, voip security, security, voipsa

As I mentioned previously, the “RUCUS” BOF about voice spam at IETF 71 in Philadelphia is one of great interest to us. Unfortunately BOF co-chair Hannes Tschofenig ran into a problem with his domain and had to move the page to a new URL: http://www.shingou.info/bof-rucus.html

If you saved the URL or sent it on to someone, you’ll need to update to using the new URL. If you didn’t visit the RUCUS page before, please do check it out – and feel free to join the RUCUS mailing list. Of course, if you can, please do join us in person in Philadelphia!

Technorati Tags: spit, ietf, spam, rucus, standards, sip

As more systems get connected using VoIP and over time security systems come into use to help prevent voice spam, a.k.a. “SPam for Internet Telephony” or “SPIT”, what happens if you have an application that makes a very large number of outbound calls? For instance, a notification system? Might the traffic from that application not look like the beginning of a flood of SPIT?

Within the IETF there’s been a bit of discussion in the past months about voice spam/SPIT and just recently RFC 5039 from Jonathan Rosenberg and Cullen Jennings was published that specifically addresses the issue of SIP and Spam.

The RFC is an excellent summary of the current thinking about the SPIT problem and potential solutions to address it. If you haven’t read the document, I would *highly* recommend it.

A concern I had, though, was that it did not appear to me that existing documents address the issue of what SPIT could look like at a network level. For instance, if a network administrator monitoring network traffic suddenly saw a large flood of SIP INVITE packets coming into his/her network, it could be:

1. a telemarketer/spammer launching a flood of SIP connections to deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP endpoints.

I could very easily see existing network tools that look at traffic and perform anomaly detection (and potentially source suppression) being modified to suppress large flows of SIP traffic. This last case of legitimate traffic concerned me and so I put together an Internet- Draft talking about the types of legitimate systems that might generate a significant volume of traffic that could resemble SPIT (or a DoS attack).

I put the document out primarily to stimulate discussion. Are these legitimate scenarios being addressed in current thinking about SPIT? If not, my point really is that they need to be considered.

Comments about the document are very definitely welcome. Are there other scenarios I should include? Am I accurate? Am I overstating the case? or what?

Technorati Tags: ietf, security, sip, standards, voip, voip security

Over on the “Voice of VOIPSA” weblog, I posted about an excellent overview of SIP security issues that Hannes Tschofenig presented yesterday at the 3Rd ETSI Security Workshop in France. If you aren’t familiar with the current state of SIP security, I’d highly recommend you take a read through Hannes’ slides.

Technorati Tags: identity, ietf, security, sip, standards, voip, voip security

Have you ever wanted to understand why SIP doesn’t work so well across NAT devices and firewalls? Have you heard of STUN, TURN or ICE but didn’t know what they were or how they worked? Over on my Blue Box podcast site I’ve just uploaded Blue Box Special Edition #22 which explores and explains all these details. In this interview I sat down with Dr. Jonathan Rosenberg, a Cisco fellow and author of a wide range of RFCs and Internet-Drafts related to SIP to talk about SIP and NAT traversal. We explore what the problem is, how ALGs and SBCs attempt to solve the problem and how the IETF has looked to address the issue through first STUN, then TURN and now finally ICE. I think you’ll find it a very educational and informative session.

On a similar note, you may also be interested in Blue Box Special Edition #20 where I sat down with Cullen Jennings to talk about overall security issues with SIP. These two podcasts together give you a solid overview of the current security issues with SIP.

Technorati Tags: blue box, bluebox, dan york, danyork, ietf, sip, standards, voip security, jonathan rosenberg

One of the livelier sessions at the IETF meeting in Vancouver, BC was the segment having to do with SPIT. No I am not talking about what comes out of your mouth but rather the internet telephony version of SPAM. While it’s not a big problem yet, folks in the industry are indeed concerned about it and how to prevent it before it gets to be one.

The problem (or really the good news in this case) is that for the most part SPIT does not really exist yet in the wild. This being the case however we really don’t yet know what it looks like or how to detect it.

Currently some of the work is going into figuring out what SIP header we would transmit SPIT information to clients in. The problem is that at this point I don’t think that it’s clear that we know what SPIT scores need to look like. Is a simple number from 1-100 the right way to measure this? Or do we need a more complex way of delivering multiple scores and information to explain to the user agent what the SPIT detectors have discovered.

All of this however does not yet touch on the MUCH bigger problem of how to detect SPIT. As with e-mail the problem is that much depends on the context and permissions involved in the actual message. You can not simply decide that something is SPIT based on the fact that they place a lot of calls in a short amount of time (as I have heard suggested by some people). An example of a use-case where this does not work is emergency outbound notification. For systems like this platforms NEED to be able to place very large numbers of phone calls in a short amount of time. While some might say that white listing can help with some of these cases I think e-mail has shown that for this most part this does not not work. I don’t want to miss a call telling me that something horrible when on at my child school because I forgot to enter my school’s phone number into my office PBX.

Anyway there is still much work to be done in the space and there are sure to be many more heated discussions at the IETF and elsewhere on this subject.