Subject: [stir] STIR vs TERQ

From: <[email-masked]>
Date: Thu, 6 Jun 2013 08:26:18 +0000

Brian,

I was wondering how (whether) this effort would relate with the terq discussions given that a) the issues put forward for example in the FCC document mostly deal with telephone numbers (or name resulting from a number lookup) and b) that CPN/CLI was I think also part of the terq use cases at some point. 

Reading draft-peterson-secure-origin-ps, I would suspect these discussions to include (but not necessarily be limited to) telephone numbers and therefore stir be related to (but distinct from) terq. The former might be interested in the horizontal interface and the latter with the DB/data model in the same way as, say, RFC 4474 could have been related to an enum DB. (Or maybe the latter's been shelved for a time until this one progresses...?) 

One way or another I would have an interest in this but clarification would be appreciated.
Thanks. 

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 05, 2013 9:25 PM
To: DISPATCH list
Subject: [dispatch] New effort on source identity in SIP to reduce robocalling, swatting and vishing

We have started a new effort to reduce robocalling, swatting and vishing in a SIP network following the ideas presented by Henning Schulzrinne in his presentation at IETF 86 Orlando and the recent SIPNOC.  Fundamentally, we plan to minimize the ability to spoof the caller's id.   We have created a new ietf list, [email-masked], where stir stands for "Secure Telephone Identity Revisited".     

Our emphasis in this effort is deployable solutions that can significantly reduce problems in a year or two, not solutions that take a revolution in how service provider and enterprises deploy SIP networks.  For that reason, we are particularly interested in getting active participation by as many SIP service providers as possible, as well as the vendors that serve them.

Some discussion has been ongoing among a group of us, and a meeting was held last week to see if we had enough common vision to initiate an IETF effort we thought would actually get deployed.  So if you get on the list, you will see discussion on specific points already underway. 

If you are interested in working on this effort, or want to stay informed, you can subscribe by visiting:
https://www.ietf.org/mailman/listinfo/stir

We hope to arrange a session in Berlin, details will be forthcoming.

Brian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 6 Jun 2013 09:14:58 -0400

stir is indeed mostly concerned with telephone numbers as the source identity.

Of course there could be relationships between TERQ and stir, since TERQ is intended to encompass a database that has lots of information related to a telephone number.  

One difference is that stir is organized around immediately deployable solutions, where TERQ does not have that emphasis.  We would not want to predicate some important feature of stir on some deployment of TERQ.

It would seem that the solutions we believe will arise will involve cryptographic signatures over header elements in the call signaling, like 4474, although there are proponents of additional capabilities that would involve databases or services that are used when in-band signaling does not maintain the headers needed to determine if the source id is valid.  The credentials for signing need to be available.  TERQ is one place to put them.  The out-of-band database may not be monolithic and the one serving a particular calling or called party might be located via a TERQ database.  However, as above, we would want solutions for these items that are deployable now, and not only when we get TERQ deployment.

Brian

On Jun 6, 2013, at 4:26 AM, [email-masked] wrote:

> _______________________________________________
> stir mailing list
> [email-masked]