Category: SIP

The Publishing of RFC 8496 Concludes the 10-year Saga of P-Charge-Info

Rfc 8496 p charge info

October 31, 2018, was a special day for me. Not because it was Halloween, but because after 10 years a small little document I co-authored about the "P-Charge-Info" header for SIP-based Voice-over-IP (VoIP) was published as informational RFC 8496. You can see it at either:

Ultimately, all this document does is register the Session Initiation Protocol (SIP) Header Field of "P-Charge-Info" within the "SIP Parameters" registry maintained by IANA at:

But the story of getting that registration to happen is a long one!

In the beginning...

The short version is this. Back in around 2007 or so, I was working for Voxeo and we were using the "P-Charge-Info" header in our large SIP-based application server to pass along billing information. Essentially, when someone made a call on our system, we wanted to pass a billing identifier that was often different from the source phone number (i.e. "CallerID"). This quote from RFC 8496 was pretty much Voxeo's use case:

As another example, a hosted telephony provider or hosted voice application provider may have a large SIP network with customers distributed over a very large geographic area using local market PSTN numbers but with only a very few actual PSTN interconnection points.

The customers may all have local phone numbers yet outgoing calls are actually routed across a SIP network and out specific PSTN gateways or across specific SIP connections to other SIP service providers. The hosted provider may want to pass a billing identifier to its SIP service providers either for the purpose of simplicity in billing or to obtain better rates from the SIP service providers.

While we at Voxeo were already using P-Charge-Info extensively, we wanted to use the P-Charge-Info header with more SIP service providers, and needed some form of documentation for how to use the header. We also were concerned about the profileration of more P-headers and wanted to register "P-Charge-Info" with IANA so that more people might find and use that header rather than inventing their own. (We were happy with P-Charge-Info and didn't want to have to support more SIP headers related to charging identifiers.)

So I began the process of submitting an Internet Draft way back in February 2008 documenting P-Charge-Info and requesting its addition to the IANA registry.

Almost immediately Tolga Asveren, then at Sonus Networks, contacted me to let me know they were using P-Charge-Info in the SIP equipment they were selling. He had some great suggestions, supplied some additional text, and was interested in working on the document with me. So I published a -01 draft 3 days after the first draft, and Tolga and I began our 10-year journey through the process of getting this document published.

Square pegs in round holes - slamming ISDN info into a SIP header

Along the way, others approached us from traditional PSTN telecom companies indicating that they were interested in using P-Charge-Info as a way of passing the "ISUP Charge Number" that was part of ISDN signaling. Though it was not something that either Tolga or I worked directly with, we were okay adding this in, and so two new parameters got added:

  • Numbering Plan Indicator (NPI)
  • Nature of Address (NOA)

... along with a substantial amount of new text.

A 2011 version of the document can show what this was all about.

Lost in limbo

Meanwhile, the document had gotten caught up in the need to wait while RFC 3427 was replaced by RFC 5727, which defined the whole SIP Header Field registration process.

And then I wound up leaving Voxeo to join the Internet Society (my current employer). And so my attention was no longer focused on VoIP and so this draft was truly a "back burner" kind of thing that I just worked on in random moments.

And unfortunately, it turned out that slamming legacy PSTN signalling into a SIP header caused a whole number of challenges, both with getting agreement - and also with some of the internal IETF processes. It turned out that to do this registration, we were going to have to do some other registrations - and more.

I also published a version that changed some of the parameters values in a way that was not backwards-compatible, which caused some friction.

By 2015, both Tolga and I were ready to ... just... let... it... die...

Returning from the dead - and returning to the SIP roots

And then in early 2017, Henning Schulzrinne and Richard Shockey contacted me to let us know that the US FCC was interested in the status of P-Charge-Info. The FCC had some billing issues between carriers where the carriers were in some cases already using P-Charge-Info, but the carriers really wanted an actual RFC versus an expired draft. There was also some potential interest in having the header around as one of many different tools in the FCC's efforts to combat robo-calling / spam phone calls.

So Tolga and I worked with Henning and the IETF area directors to come up with a plan to resuscitate the document. In doing so, we stripped out all the legacy PSTN signaling. Specifically we removed the NPI and NOA parameters, and all the mentions of the ISUP Charge Number.

We returned it to the simplicity of the original document way back in 2008.

The original goal had been to simply document existing usage of the P-Charge-Info header, as it was being used by various SIP providers and vendors. We returned it to that root.

Success!

After a number of further drafts, an expert review by Adam Roach, and more feedback from Area Director Ben Campbell, the draft finally entered the RFC Editor queue by way of the Independent Series Editor (ISE). Many thanks are due to Ben to sponsoring the draft. He, Jean Mahoney, and Adam were all critical in helping get it across the finish line. Thanks, too, to Henning and Richard who provided the spark for us to revive the document.

It would not have happened, either, if Tolga had not taken the lead over the past year in making edits, answering all the questions from people, proposing solutions and continually asking how to move the draft forward. I may have been the one editing the XML and submitting the new draft versions, but he was the one driving the text revisions.

It's great to see the document finally published as Informational RFC 8496. Looking back on the journey, there were:

  • 16 revisions of draft-york-sipping-p-charge-info (2008-2012)
  • 6 revisions of draft-york-dispatch-p-charge-info (2012-2015)
  • 9 revisions of draft-york-p-charge-info (2017-2018)

Now, granted, some of those were a simple "update to keep the document from being 'expired'", but still it was all a great amount of work.

I learned a HUGE amount along the way. When the journey began in 2008, I didn't really understand much about IETF processes. Now I do - and now understand how we could have done this quite differently along the way.

Thanks to everyone who provided feedback and support over the years.

P-Charge-Info is finally registered in that IANA registry! :-)

Audio Recording: My SIPNOC 2014 Talk – "Is It Time For TLS For SIP?"

Is it time to use Transport Layer Security (TLS... essentially what we used to call "SSL") to add a layer of trust and security to Voice-over-IP (VoIP) that uses the Session Initiation Protocol (SIP)?

Way back in June 2014, I gave a talk on this topic at the SIP Network Operators Conference (SIPNOC) in Herndon, Virginia. I recorded the audio of the session... but then lost track of the recording. I recently found it and, since much of it is (sadly) still relevant, I decided to release the recording as one of my The Dan York Report audio podcast episodes:

The slides that go with the presentation are available on SlideShare:

You'll see in the slide deck that I also provide some tutorials around DANE and DNSSEC along the way.

Coincidentally, I learned on Facebook over the weekend that my friend Olle Johansson was speaking on this exact topic at the FOSDEM 2016 conference in Brussels this weekend. His slides about SIP & TLS are also available on SlideShare, and he has more recent information - and also the conclusion that we need to use "SIP Outbound" for any of this to work:

Olle's last slide about what we need to do hits on the key points - and I agree with his conclusions.

Let's look at how we can get more TLS used within SIP to bring about a more secure and trusted VoIP infrastructure!

Join Me On VUC Today At Noon US EDT To Talk IPv6, IoT, WebRTC and more…

Today at 12 noon US Eastern (in about 3.5 hours), I'll be part of a panel on the VoIP Users Conference (VUC) talking about IPv6, WebRTC, the Internet of Things (IoT) and much, much more... you should be able to watch it live at live.vuc.me or embedded here:

VUC host Randy Resnick had a scheduled guest be unable to attend and so he asked a group of us to come on for what he is calling a "VUC Vision" session. I will be on there, as will, I believe, Tim Panton and a number of others. I expect the discussion should range over good variety of topics. It should be a good time... you're welcome to join in the discussion.

It's probably best to also join the IRC backchannel where links are shared, questions are answered and other comments occur. You also can visit the Google+ event page for the VUC session today where there may be additional links and info.

If you won't be at your computer, you can also call in via:

  • sip:200901@login.zipdx.com
  • +1 (646) 475-2098
  • Skype:vuc.me

The session will of course be recorded so you can listen/watch later.

Vuc vision 20141003


If you found this post interesting or useful, please consider either:


How Do We Define ‘SIP’ For Telecom In 2014?

Sip question"What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?"

A friend asked me that question and my response was:

It depends.

and even more unfortunately:

I don't know.

It turns out to be a challenging question to answer... and it led me to ask:

  • How do we define what "SIP" is for telecommunications in 2014?
  • How do we help vendors move their products/services to be based on SIP?
  • As we talk about "turning off the PSTN" and "moving all telecom to IP", how can we make it easier for companies to switch to using SIP?

The reality is that being "SIP-compliant" does turn out to depend upon where in the larger SIP interconnection ecosystem the vendor is located.

Is the vendor:

  1. a SIP client, in terms of a "hard" phone, a softphone, or other application that is seeking to connect to a SIP server?
  2. a SIP server seeking to connect to a SIP "service provider" to have connectivity out to the PSTN and other SIP networks?
  3. a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
  4. a middlebox such as a firewall or session border controller (SBC) seeking to be in the middle of a SIP communication stream?
  5. an application that interacts with SIP systems in some way? (ex. call recording, IVR, networking monitoring)

To be "SIP-compliant" really means you need to figure out what amount of "SIP" you need to implement to play your part in the larger picture. Particularly when the SIP "architecture" we describe isn't the pretty little picture we use:

Sip architecture

but rather a much more complex reality:

Sip architecture reality

Unfortunately, the "Session Initiation Protocol" (SIP) is no longer just good old RFC 3261 and a few friends. RFC 3261 provided a radical new way to do telecommunications... it was "HTTP for voice"... it was simple, easy and pretty amazing. If you have a moment, go back and read RFC 3261. It's a remarkable document and set of ideas.

However, there were two factors that started to complicate "SIP":

  • the "Internet" community kept thinking of new and innovative ways that they could do more with SIP-based telecommunications; and
  • the traditional telecom companies/vendors kept wanting to bring across more and more legacy PSTN functionality into the world of SIP, typically without changing that PSTN functionality so that they wouldn't have to change their business models or processes.

This combination set SIP up to slowly become more and more of an accretion of various hacks and kludges designed to either enable SIP to unleash new possibilities and/or to take over key functionality from the PSTN.

But in doing so it became so much harder to define what "SIP" was.

Back around 2008/2009, Jonathan Rosenberg tried with his "Hitchiker's Guide to SIP" that was published as RFC 5411 in February 2009:

http://tools.ietf.org/html/rfc5411

Now consider that this contained about 26 pages worth of documents to be referenced... and this was back in 2009! In the 5 years since, the "Realtime Applications and Infrastructure (RAI)" area of the IETF has been extremely busy and a similar document today would be be MUCH longer.

But does such a long list really help?

Going back to to my list of different roles within the SIP ecosystem, do we need more narrower lists for each role? A SIP client connecting to an IP-PBX may not need to implement all of the same specifications as a SIP service provider connecting to the PSTN.

What is the minimum set of SIP specifications for each role?

SIPconnect sipforumThe good news is that for the second role I mention, the SIP server to SIP service provider, the SIP Forum has done some outstanding work with their SIPconnect initiative. You can find more info at:

http://www.sipforum.org/sipconnect

You can download the SIPconnect 1.1 technical specification and see the great amount of work they have done. The idea is that ultimately any "SIPconnect-compliant" IP-PBX or other SIP server can connect to any "SIPconnect-compliant" SIP service provider. It should "just work" with a minimum amount of testing. The goal is to allow the more rapid deployment of SIP-based IP-PBXs and making this part of the interconnection puzzle work that much better.

So if you are a vendor of a SIP server, whether you call it an IP-PBX, a call server, or whatever... or you are a SIP service provider seeking to connect to SIP servers at your customers - in either case you have SIPconnect that you can use to be "SIP-compliant".

But what about the other roles?

What if a vendor has multiple products?

What if a service provider or enterprise is just trying to get "SIP" products to work together? What should they specify beyond the vague statement that a product should support "SIP"?

Now, there are other organizations that have attempted to answer this question. The 3GPP has a list of SIP specifications and the GSMA seems to have similar documents. The ITU-T has many recommendations but since they rename everything it's hard to understand what really links back to SIP - and many of the ITU recommendations are only available to members and so you can't easily view them.

Which brings me back to these questions:

  • Do we need a new IETF document that aims to update RFC 5411 with a newer list and perhaps "profiles" of what would be needed for different roles?
  • Is this something the SIP Forum or some other organization should take on?
  • Has someone else already created a concise list/document/specification and I just haven't yet found it?

And perhaps the even larger question:

  • Do you believe this is an issue that we collectively should be working on as an industry to help make the deployment of SIP easier?

What do you think? How do we define SIP in 2014? What should we do? I'd love to hear your comments either in response to this post here on this blog or out on social media where this is posted. (Thanks!)


An audio commentary on this post is also available:


If you found this post interesting or useful, please consider either:


VoiceOps – Mitigating SIP Threats With SBC Policies, Auto-Blacklisting

Voice Ops mailing listThere’s a good discussion going on right now (September 2014) in the VoiceOps mailing list about how you can mitigate SIP threats by configuring the policies and settings on your session border controller (SBC).  It started out with a detailed question from Robert Nystrom asking about how to configure an Acme Packet SBC in the most secure manner and asking about how best to configure access control lists (ACLs).  Several answers can be seen in the VoiceOps archive from folks such as Ryan Delgrosso, Mark Lindsey, Jim Gast and Patrick McNeil, offering commentary and suggestions about how best to proceed.

If you are not already subscribed, the VoiceOps mailing list is a great resource.  As stated on the subscription page:

This list is for discussions related to managing voice networks, both traditional and IP.

The VOIP Operators’ Group (VOG) charter is to facilitate the creation, maintenance, and operations of Voice over Internet Protocol (VOIP) related networks, products, and services.

Similar to the North American Network Operators’ Group (NANOG), The Voice Operators’ Group seeks to assist in the creation of a robust, stable and growing VOIP ecosystem.

While the topics are definitely not all about security, I would encourage you to join the list if you do anything with the operation of VoIP networks – or if you are just curious to learn more about such networks.

SIPNOC 2014 Begins Today In Virginia – I am speaking about TLS and SIP (and DANE)

SIP Forum SIPNOC 2014 OverviewToday I'm back at the Hyatt Dulles in Herndon, Virginia, for the fourth SIP Network Operators Conference (SIPNOC) event. These SIPNOC sessions are great because they bring together the people actually operating the SIP-based networks that make up our telecommunications infrastructure. SIPNOC continues to be THE best place I've found to interact with the people actually taking SIP standards and making them happen in the "real world".

I've been to all four SIPNOCs - and I continue to find them outstanding events, not only because of the excellent technical content, but also because of the people.

In many cases, these are the "phone guys" (and gals) who have found their way to IP. The "Bellheads" of the age-old "Bellhead vs Nethead" debate. The "telcos". The people who have been doing telecom for decades... and are now evolving to IP.

In other cases, the people here are the new contenders. The cable companies are here - and they are strongly challenging the legacy telcos, and they are creating entirely new IP-based infrastructures. The "Internet Telephony Service Providers (ITSPs)" and "SIP Trunking" providers are here, too... companies that are reimagining what telecom can be in an IP space. Newer vendors... newer application providers... etc.

It's a wonderful mix of people.

All here talking about telecom in the age of the Internet... sponsored by the SIP Forum.

As I mentioned in a post yesterday on the Deploy360 blog, I will be speaking today at SIPNOC 2014 about TLS for SIP. The abstract for my talk is:

With concerns about large-scale pervasive monitoring on the Internet, many groups are encouraging the increased use of Transport Layer Security (TLS, what we used to call “SSL”). While SIP has had TLS support for quite some time, it is often not used. This session will look at concerns of using TLS with SIP and discuss opportunities for providing higher security for SIP-based communication. The session will also outline some newer innovations such as the DANE protocol that when coupled with DNSSEC can provide a higher level of trust for TLS encryption.

This relates largely to the "TLS for Applications" work we are doing within Deploy360, as well as our advocacy for the use of the DANE protocol to add a layer of trust to TLS/SSL certificates.

As I note in that Deploy360 post, I'm delighted to see on the SIPNOC agenda that speaking before me will be Carl Klatsky from Comcast providing a case study of the lessons they have learned so far in moving to IPv6!

It's kind of fun to scan my list of presentations and look back at what I've spoken about at the past SIPNOC events:

SIPNOC 2011 (employed at Voxeo)
1. SIP Adoption and Network Security
2. Lessons Learned in Large-Scale SIP Interoperability
SIPNOC 2012 (employed at Voxeo)
1. SIP and IPv6 – Can They Get Along?
2. Panel Discussion: SIP Adoption and Network Security
3. BOF: SIP and IPv6
SIPNOC 2013 (employed at Internet Society)
1.IPv6 And SIP – Myth or Reality?
2. Who are You Really Calling? How DNSSEC Can Help
3. Panel Discussion: Anatomy of a VoIP DMZ (moderator)
SIPNOC 2014 (employed at Internet Society)
1. Is It Time For TLS For SIP? (also includes some DNSSEC/DANE)

It's nice to have someone else talking about IPv6 this year!

Of course, you'll also find me in the VoIP security BOF tonight... and listening to the other sessions. Unfortunately I have something else happening tomorrow evening back in New Hampshire and so I'm only here at SIPNOC today and will be flying back tomorrow. The SIPNOC event continues all day tomorrow and half a day on Thursday.

Sessions are underway now... here is photo proof:

Sipnoc2014 start

Unless you happen to be located in the DC area, it would be very hard for anyone to join into this year's SIPNOC event... but if you work with SIP or VoIP networks, I would strongly encourage you to put SIPNOC 2015 on your calendar for next year!


If you found this post interesting or useful, please consider either:


Speaking At SIPNOC 2014 On June 10 About TLS For SIP/VoIP/UC

SIPNOC 2014 logoWhat advantages does Transport Layer Security (TLS, what we used to call “SSL”) bring to voice-over-IP (VoIP) that uses the Session Initiation Protocol (SIP)? What is the state of TLS usage within SIP and VoIP? Why isn’t it being used more?

Tomorrow, June 10, 2014, I’ll be speaking at the SIP Network Operators Conference (SIPNOC) 2014 event down in Herndon, Virginia, on the topic of “Is It Time For TLS For SIP?“. I’ll be discussing why we need more TLS usage in SIP-based communication, including what we think of as “VoIP” and also “Unified Communications (UC)”. The abstract for my talk is:

With concerns about large-scale pervasive monitoring on the Internet, many groups are encouraging the increased use of Transport Layer Security (TLS, what we used to call “SSL”). While SIP has had TLS support for quite some time, it is often not used. This session will look at concerns of using TLS with SIP and discuss opportunities for providing higher security for SIP-based communication. The session will also outline some newer innovations such as the DANE protocol that when coupled with DNSSEC can provide a higher level of trust for TLS encryption.

As you can tell, my focus will be around the “TLS for Applications” topic area we have here on Deploy360, as well as some discussion around DANE and what it can bring in terms of increased security.

I’ve spoken at SIPNOC events for the past two years (and before that) but my topic has always included IPv6.  This time I won’t be doing that… but to my delight one of the talks before mine tomorrow will be Carl Klatsky from Comcast providing a case study of their work their voice services to IPv6.  Here is his abstract:

Comcast Voice IPv6 Deployment Lessons Learned. Presented by Carl Klatsky, Comcast.

This presentation will review the successes, challenges, and lessons learned in deploying IPv6 support into Comcast’s IMS based SIP voice network, in support of an upcoming IPv6 technical trial. The presentation will review the overall target architecture covering both access and network side elements, and share the lessons learned with the SIP community.

I’m very much looking forward to hearing what Carl has to say!

There are many other great sessions on the SIPNOC 2014 agenda.  Unfortunately I can only be at the event tomorrow and will be missing out on the great content on Wednesday and Thursday.  You can, of course, expect to find me in any of the security-related sessions on Tuesday!

If any of you reading this are at SIPNOC 2014 tomorrow please do feel free to say hello!

P.S. And before anyone asks in the comments, no, there is not a live stream (or recordings) of the SIPNOC sessions.  They try to keep it an informal atmosphere where information can be shared with the conference sessions without that information being immediately public.

 

New Kamailio DNSSEC Module Enables Higher Security For SIP / VoIP

Kamailio LogoIf you are using voice-over-IP (VoIP), and specifically the Session Initiation Protocol (SIP), how do you know if you are really connecting to the correct SIP server when you make a connection?  When you call someone, your SIP server needs to make a connection to the SIP server for the recipient – how is it sure it is reaching the correct server?

As I’ve talked about and written about in the past, one way to help with this is to use DNSSEC to validate that the information received by the SIP server from DNS is in fact accurate.  While DNSSEC support in VoIP systems has been somewhat limited to date, the great Kamailio team has added a module that provides DNSSEC support.  It will be included in the forthcoming Kamailio 4.1 release (whose development was recently frozen, so it should be available soon), but in the meantime it can be added to Kamailio installations using this tutorial:

http://www.kamailio.org/wiki/tutorials/dns/dnssec

The actual module itself can be found at:

http://kamailio.org/docs/modules/devel/modules/dnssec.html

This kind of support for DNSSEC within VoIP is great to see and will lead to more secure communications over IP in the future.  Plus, getting this kind of DNSSEC support out there now will lay the groundwork for potentially using DANE in the future to secure the certificates used in VoIP communications.

Congrats to the Kamailio team and we look forward to learning more about people using this module in the future!

P.S. See our DNSSEC and DNSSEC Basics pages to learn more about how you can get started with DNSSEC.

SIP Forum IPv6 Task Group Call – Weds, Oct 3rd, 19:00 CEST, 1:00pm US Eastern

SIP ForumThe SIP Forum IPv6 Task Group will be having its next conference call today, October 3, 2013, at: 19:00 CEST, 18:00 BST (UK) and 1:00 pm US Eastern (and see other times). Task Group co-chair Andy Hutton sent out this agenda and call-in information:

  1. Status of the draft for developers
  2. Status of mine and Gonzalo’s draft to update RFC 3263
  3. Happy Eyeballs for SIP
    3.1. Connection oriented
    3.2. UDP
  4. IPv6 and related protocols
    4.1. MSRP
    4.2. XCAP/HTTP
    4.3. ICE/turn
    4.4. Other related protocols

Anyone is welcome to join the SIP Forum’s IPv6 mailing list and also to join in the effort.  The group is working to “evaluate current best practices and enable and promote migration to SIP over IPv6.”

It’s great to see the work they are doing because we definitely do need to have IP-based telecommunications working over IPv6!

Can We Create A "Secure Caller ID" For VoIP? (Join Tomorrow’s STIR BOF To Learn More)

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

You can also join the Jabber chat room at:

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?


Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."


If you found this post interesting or useful, please consider either: