This morning I made this video below while out here at IETF…. I’m posting it here because I need to test a video embed inside of a WordPress blog as I’m having a problem doing so:
Thank you for watching. 🙂
Category Archives: IETF
IETF seeks comments on SPIT/voice spam framework…
I wrote previously about new Internet-Drafts out about a “framework” for combating Spam for Internet Telephony, a.k.a. “SPIT”. With the IETF 69 meeting coming up in a few weeks in Chicago, Hannes Tschofenig is really looking for some feedback on these docs so that he can incorporate any feedback before the IETF 69 meeting. We would strongly encourage people to take a look at these docs and send comments directly to Hannes Tschofenig. I have commented… please add your voices. (He’s looking for all kinds of feedback… for instance, I gave some input on an earlier draft that a section needed to have more details added because I didn’t understand it overly well.)
IETF group puts forward framework to combat SPIT (VoIP spam) for discussion
As systems become increasingly interconnected, how do we prevent Spam for Internet Telephony, a.k.a. “SPIT” or “VoIP spam”. As we talked about in this blog and on the Blue Box podcast, SPIT today is not really a huge issue because the PSTN serves as a de facto firewall between companies/entities. But as we move toward increasing interconnection and to the point where a random SIP user could make a SIP connection across the Internet to any other random SIP user, we definitely do have to worry about SPIT and how to prevent it.
Within the IETF, a group has been working on the issue and now has two documents available for review:
- A Framework for Reducing Spam for Internet Telephony
- Requirements for Authorization Policies to tackle Spam for Internet Telephony and Unwanted Traffic
This is the initial release of both documents and the authors are definitely seeking feedback. Speaking of the authors, they include many of the names we have mentioned here in the past involved with VoIP security within the IETF space: Hannes Tschofenig of Nokia Siemens, Henning Shulzrinne of Columbia University, Dan Wing of Cisco, Jonathan Rosenberg of Cisco and David Schwartz of Kayote. (Geoffrey Dawirs of University of Namur and Thomas Froment of Alcatel-Lucent are also authors of one, but I don’t believe we’ve spoken of either of them here before.) They are definitely people who understand the space and have put some thought into it.
I would encourage everyone to take a look at those documents and send in feedback, either to the IETF mailing lists or directly to Hannes Tschofenig (editor of both docs). We have an opportunity here to make sure that interconnected VoIP does NOT become the utter cesspool of spam that email has become. Let’s make sure we do it right!
SIPIt 20 shows the very clear need for SIP security interoperability
Last week, SIPit chair Robert Sparks posted the results of a SIP interoperability survey to the IETF SIP mailing list coming out of the recent SIPit 20 event held in April. For those not familiar with “SIPit” events, they are week-long events sponsored by the SIP Forum held twice a year where vendors bring together their SIP products to test interoperability between their various products and implementations. This particular event, the 20th, was hosted by Alcatel Lucent in Antwerp, Belgium. 67 vendor teams participated, of which 59 completed the web-based survey that generated this data.
The full results of the survey make for interesting reading, but I thought I’d pull out some of the security-related items. First up, SIPS (aka TLS-encrypted SIP):
There was a lot of (understandable) confusion about what to do with sips:. Most implementations that could handle TLS are not yet trying to handle sips:. The few that did try to do something sane with sips: are watching the discussion on the SIP mailing list. In any case, there was not a set of implementors present who felt sips was sufficiently specified and would be unhappy if the definition changed. I also didn’t find anyone who felt an existing deployment would suffer from any change to the definition.
Next up, NAT traversal and STUN/TURN/ICE:
When asked about STUN support, the client implementations replied:
8% I implement all the client requirements of draft-ietf-behave- rfc3489bis
6% I implement some, but not all, of the client requirements of draft-ietf-behave-rfc3498bis
4% I implement all of the client requirements of RFC3489
14% I implement some, but not all, of the client requirements of RFC3489
60% I do not implement STUN as a client
8% OtherThere were several STUN servers and at least two TURN servers. We had more TURN clients this time, and successfully exercised TURN. Three implementations claimed support for ICE, but no interoperability was reported (I suspect there were versioning issues that couldn’t be overcome in the time-scale of the event). There was one ice-tcp implementation present.
And the big one of most interest to me personally (and with my emphasis added):
There were 9 SRTP endpoints (down from 12 at the last event). Only 4 of those used sdes.
Interoperability after key exchange was lower than at SIPit 19.
There was only one RTP over DTLS implementation present.
Anyone doubt that we still have a good bit of work to do??
As I mentioned, the full survey results are definitely worth a read if you are interested in SIP interoperability.