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% Other

There 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.

2 thoughts on “SIPIt 20 shows the very clear need for SIP security interoperability

  1. Pingback: Voice of VOIPSA » Blog Archive » Ready or not… here come the IRC-controlled SIP/VoIP attack bots!

  2. Hans Persson

    There were 9 SRTP endpoints (down from 12 at the last event). Only 4 of those used sdes.

    Strange. I performed interop tests with our SRTP/sdescriptions implementation with 6 other vendors, so there must have been at least 7 sdes implementations there.

Comments are closed.