From york@isoc.org Wed Dec 4 06:00:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6DC1AE249 for ; Wed, 4 Dec 2013 06:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm7eA7ovK_jb for ; Wed, 4 Dec 2013 06:00:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB41AE216 for ; Wed, 4 Dec 2013 06:00:47 -0800 (PST) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB065.namprd06.prod.outlook.com (10.242.187.143) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 14:00:43 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.101]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.101]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 14:00:42 +0000 From: Dan York To: "stir@ietf.org List" Thread-Topic: Where are we at right now with STIR? What can be most helpful at the moment? Thread-Index: AQHO8Pk4Nx8UzI0GR0SyWC6YK5+Tdg== Date: Wed, 4 Dec 2013 14:00:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(164054003)(76176001)(15975445006)(85306002)(31966008)(49866001)(47736001)(47446002)(80976001)(74662001)(74502001)(87266001)(51856001)(83322001)(19580395003)(81686001)(19580405001)(76482001)(87936001)(81816001)(83072001)(36756003)(50986001)(74876001)(47976001)(4396001)(2656002)(81342001)(74706001)(74366001)(59766001)(77982001)(77096001)(15202345003)(80022001)(15395725003)(65816001)(53806001)(54356001)(85852002)(46102001)(63696002)(90146001)(76796001)(76786001)(56816005)(81542001)(54316002)(56776001)(69226001)(79102001)(16236675002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CEC49FB84955Cyorkisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: [stir] Where are we at right now with STIR? What can be most helpful at the moment? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:00:50 -0000 --_000_CEC49FB84955Cyorkisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ, Robert ... or really anyone, The STIR list has been quiet lately and I'm just getting my brain back into= IETF thinking after several crazy weeks of travel - and I'm wondering: - what help is needed most right now to move STIR efforts forward? - is it review of the existing documents? - creation of new documents? (and if so, what?) - something else? How can any of us on the list best help? Thanks, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_CEC49FB84955Cyorkisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <30EC9E4CB678D24A8828E8E7BB3FFF05@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Russ, Robert ... or really anyone,

The STIR list has been quiet lately and I'm just getting my brain back= into IETF thinking after several crazy weeks of travel - and I'm wondering= :

- what help is needed most right now to move STIR efforts forward?
- is it review of the existing documents?
- creation of new documents? (and if so, what?)
- something else?

How can any of us on the list best help?

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet = Society
york@isoc.org <mailto:york@isoc.o= rg>   +1-802-735-1624
Jabber: york@jabber.isoc.org <mai= lto:york@jabber.isoc.org>
Skype: danyork   http://twitter= .com/danyork

http://www.internetsociety.org/deplo= y360/ 
--_000_CEC49FB84955Cyorkisocorg_-- From rjsparks@nostrum.com Wed Dec 4 07:22:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64611AE28C for ; Wed, 4 Dec 2013 07:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JTAZutk3aH0 for ; Wed, 4 Dec 2013 07:22:55 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B07421AE273 for ; Wed, 4 Dec 2013 07:22:54 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB4FMpBE085515 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 4 Dec 2013 09:22:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <529F48CB.50209@nostrum.com> Date: Wed, 04 Dec 2013 09:22:51 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: stir@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010505060408080500060308" Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism) Subject: Re: [stir] Where are we at right now with STIR? What can be most helpful at the moment? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:22:57 -0000 This is a multi-part message in MIME format. --------------010505060408080500060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/4/13 8:00 AM, Dan York wrote: > Russ, Robert ... or really anyone, > > The STIR list has been quiet lately Extremely. I hope it was just a seasonal thing. > and I'm just getting my brain back into IETF thinking after several > crazy weeks of travel - and I'm wondering: > > - what help is needed most right now to move STIR efforts forward? > - is it review of the existing documents? > - creation of new documents? (and if so, what?) > - something else? > > How can any of us on the list best help? I think we should LC the problem statement and send it off to the IESG in the next couple of weeks. Have you reviewed the threats document? Do you think it is ready for LC as well? We were working on some structural questions in Vancouver. We should finish those conversations. RjS > > Thanks, > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --------------010505060408080500060308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/4/13 8:00 AM, Dan York wrote:
Russ, Robert ... or really anyone,

The STIR list has been quiet lately
Extremely.

I hope it was just a seasonal thing.


and I'm just getting my brain back into IETF thinking after several crazy weeks of travel - and I'm wondering:

- what help is needed most right now to move STIR efforts forward?
- is it review of the existing documents?
- creation of new documents? (and if so, what?)
- something else?

How can any of us on the list best help?
I think we should LC the problem statement and send it off to the IESG in the next couple of weeks.
Have you reviewed the threats document? Do you think it is ready for LC as well?

We were working on some structural questions in Vancouver. We should finish those conversations.

RjS

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Society
Skype: danyork   http://twitter.com/danyork



_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--------------010505060408080500060308-- From housley@vigilsec.com Wed Dec 4 08:04:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFE81AE2E7 for ; Wed, 4 Dec 2013 08:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqofeWw42Mzu for ; Wed, 4 Dec 2013 08:04:51 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1A1AE2E3 for ; Wed, 4 Dec 2013 08:04:50 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 5E47C9A41BC; Wed, 4 Dec 2013 11:04:38 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id jc9qoCkvWxe0; Wed, 4 Dec 2013 11:04:12 -0500 (EST) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D35C29A41BD; Wed, 4 Dec 2013 11:04:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-11--156054540 From: Russ Housley In-Reply-To: Date: Wed, 4 Dec 2013 11:03:58 -0500 Message-Id: References: To: Dan York X-Mailer: Apple Mail (2.1085) Cc: "stir@ietf.org List" Subject: Re: [stir] Where are we at right now with STIR? What can be most helpful at the moment? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:04:54 -0000 --Apple-Mail-11--156054540 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are waiting for draft-ietf-stir-problem-statement-01 to be posted. = We will begin WG Last Call once it is posted. Russ On Dec 4, 2013, at 9:00 AM, Dan York wrote: > Russ, Robert ... or really anyone, >=20 > The STIR list has been quiet lately and I'm just getting my brain back = into IETF thinking after several crazy weeks of travel - and I'm = wondering: >=20 > - what help is needed most right now to move STIR efforts forward? > - is it review of the existing documents? > - creation of new documents? (and if so, what?) > - something else? >=20 > How can any of us on the list best help? >=20 > Thanks, > Dan >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail-11--156054540 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii We are waiting for draft-ietf-stir-problem-statement-01 to be posted.  We will begin WG Last Call once it is posted.

Russ


On Dec 4, 2013, at 9:00 AM, Dan York wrote:

Russ, Robert ... or really anyone,

The STIR list has been quiet lately and I'm just getting my brain back into IETF thinking after several crazy weeks of travel - and I'm wondering:

- what help is needed most right now to move STIR efforts forward?
- is it review of the existing documents?
- creation of new documents? (and if so, what?)
- something else?

How can any of us on the list best help?

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Society
york@isoc.org <mailto:york@isoc.org>   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--Apple-Mail-11--156054540-- From internet-drafts@ietf.org Fri Dec 6 17:50:56 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26BD1AE12B; Fri, 6 Dec 2013 17:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKrKiqJp1bwX; Fri, 6 Dec 2013 17:50:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A261AD845; Fri, 6 Dec 2013 17:50:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131207015054.32142.60425.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 17:50:54 -0800 Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 01:50:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited Worki= ng Group of the IETF. Title : Secure Telephone Identity Problem Statement Author(s) : Jon Peterson Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-stir-problem-statement-01.txt Pages : 23 Date : 2013-12-06 Abstract: Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-problem-statement-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-problem-statement-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From housley@vigilsec.com Mon Dec 9 11:13:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC32D1AE4CD for ; Mon, 9 Dec 2013 11:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duSHZ2VKYr1w for ; Mon, 9 Dec 2013 11:13:35 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2249B1AE07A for ; Mon, 9 Dec 2013 11:13:35 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 631739A41D4 for ; Mon, 9 Dec 2013 14:13:20 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id SnXtq3xkGbuv for ; Mon, 9 Dec 2013 14:12:59 -0500 (EST) Received: from [192.168.2.110] (pool-96-255-140-248.washdc.fios.verizon.net [96.255.140.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9CE9A9A41D2 for ; Mon, 9 Dec 2013 14:12:59 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2013 14:12:48 -0500 Message-Id: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:13:37 -0000 The authors have posted an updated Internet-Draft on the STIR problem = statement. It can be found here: = http://www.ietf.org/id/draft-ietf-stir-problem-statement-01.txt. Is this document ready for the STIR WG to pass to the IESG, requesting = publication as an Informational RFC? Please provide your input on this = mail list by end-of-business on 23 December 2013. If you have issues or = concerns, please tell us what changes to the document are necessary to = resolve them. Russ= From fmousinh@cisco.com Mon Dec 9 13:53:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F11AE108 for ; Mon, 9 Dec 2013 13:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzNIbFfxqDD1 for ; Mon, 9 Dec 2013 13:53:32 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 62E631AE0D0 for ; Mon, 9 Dec 2013 13:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3186; q=dns/txt; s=iport; t=1386626007; x=1387835607; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7x/3T04NCEAXWguyD2CLqGurSbfyoMQofI5oU5QNOlg=; b=QWKDTaJAedBLxeOAPUkskKS3+AWUD47eN2UZyzOO7s66AIW1xQ27a4xW 7C3ax6vn1r3xcbooxkMBe4i50SWPTGdLgBCDIytv4mpzdvpLixG2vuyUX Yqe/Vkkw/mhqdISr6XwYNaSs6GpmwmU/Ky583LAXCPcbI2Nv84ZnLj2s8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAA87plKtJXG+/2dsb2JhbABQCYMHOE0GuRaBMxZtB4ImAQEEAQEBaxsCAQgsGicLJAECBBMJh3kIBcB4F441F0uEMwOJCo8KgTCQY4JXUoIq X-IronPort-AV: E=Sophos;i="4.93,860,1378857600"; d="scan'208";a="5507698" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 09 Dec 2013 21:53:27 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9LrRge027427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 21:53:27 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 15:53:26 -0600 From: "Fernando Mousinho (fmousinh)" To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt Thread-Index: AQHO8u7fTDzq96V2cUGYojcFgbQGwZpMfRAA Date: Mon, 9 Dec 2013 21:53:26 +0000 Message-ID: References: <20131207015054.32142.60425.idtracker@ietfa.amsl.com> In-Reply-To: <20131207015054.32142.60425.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.117.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:53:35 -0000 Some feedback on this last draft: Section 3, Out-of-Band Identity Verification: We should remove the reference to E164, given some callers may advertise toll-free numbers and other non E164 identities. (I do understand that otherwise we would try to convert numbers to some canonical form). I would also slightly change the last sentence in this same section, as it gives the impression that out-of-band should only be used if inband is not available. Correct me if I=B9m wrong, but we would be ok if some entities only support out-of-band even if technically they could handle inband. Suggested text =B3This approach is needed because the inband technique does not work in all use cases, such as when intermediaries are involved or interworking with PSTN is used.=B2 On 12/6/13, 8:50 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Secure Telephone Identity Revisited >Working Group of the IETF. > > Title : Secure Telephone Identity Problem Statement > Author(s) : Jon Peterson > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-stir-problem-statement-01.txt > Pages : 23 > Date : 2013-12-06 > >Abstract: > Over the past decade, Voice over IP (VoIP) systems based on SIP have > replaced many traditional telephony deployments. Interworking VoIP > systems with the traditional telephone network has reduced the > overall security of calling party number and Caller ID assurances by > granting attackers new and inexpensive tools to impersonate or > obscure calling party numbers when orchestrating bulk commercial > calling schemes, hacking voicemail boxes or even circumventing multi- > factor authentication systems trusted by banks. Despite previous > attempts to provide a secure assurance of the origin of SIP > communications, we still lack of effective standards for identifying > the calling party in a VoIP session. This document examines the > reasons why providing identity for telephone numbers on the Internet > has proven so difficult, and shows how changes in the last decade may > provide us with new strategies for attaching a secure identity to SIP > sessions. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-stir-problem-statement-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-problem-statement-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Mon Dec 9 14:02:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9351AE116 for ; Mon, 9 Dec 2013 14:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJawjGLbvuKX for ; Mon, 9 Dec 2013 14:02:10 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 751F91AE034 for ; Mon, 9 Dec 2013 14:02:09 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "Fernando Mousinho (fmousinh)" , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt Thread-Index: AQHO8u7wNAwJKVeTO0uWI6cUBN8mLppMwCAA//+tMm8= Date: Mon, 9 Dec 2013 22:02:03 +0000 References: <20131207015054.32142.60425.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:02:13 -0000 As a minor matter, as far as I can tell, toll-free numbers, at least in the= US, would be considered E.164, as they do not seem to fall into any of the= Annex A exceptions, such as short codes, and follow the structure of the n= ational numbering plan.=0A= =0A= ________________________________________=0A= From: stir [stir-bounces@ietf.org] on behalf of Fernando Mousinho (fmousinh= ) [fmousinh@cisco.com]=0A= Sent: Monday, December 09, 2013 4:53 PM=0A= To: stir@ietf.org=0A= Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt=0A= =0A= Some feedback on this last draft:=0A= =0A= Section 3, Out-of-Band Identity Verification:=0A= =0A= We should remove the reference to E164, given some callers may advertise=0A= toll-free numbers and other non E164 identities. (I do understand that=0A= otherwise we would try to convert numbers to some canonical form).=0A= =0A= I would also slightly change the last sentence in this same section, as it= =0A= gives the impression that out-of-band should only be used if inband is not= =0A= available. Correct me if I=B9m wrong, but we would be ok if some entities= =0A= only support out-of-band even if technically they could handle inband.=0A= Suggested text =B3This approach is needed because the inband technique does= =0A= not work in all use cases, such as when intermediaries are involved or=0A= interworking with PSTN is used.=B2=0A= =0A= =0A= =0A= =0A= =0A= On 12/6/13, 8:50 PM, "internet-drafts@ietf.org" = =0A= wrote:=0A= =0A= >=0A= >A New Internet-Draft is available from the on-line Internet-Drafts=0A= >directories.=0A= > This draft is a work item of the Secure Telephone Identity Revisited=0A= >Working Group of the IETF.=0A= >=0A= > Title : Secure Telephone Identity Problem Statement=0A= > Author(s) : Jon Peterson=0A= > Henning Schulzrinne=0A= > Hannes Tschofenig=0A= > Filename : draft-ietf-stir-problem-statement-01.txt=0A= > Pages : 23=0A= > Date : 2013-12-06=0A= >=0A= >Abstract:=0A= > Over the past decade, Voice over IP (VoIP) systems based on SIP have=0A= > replaced many traditional telephony deployments. Interworking VoIP=0A= > systems with the traditional telephone network has reduced the=0A= > overall security of calling party number and Caller ID assurances by=0A= > granting attackers new and inexpensive tools to impersonate or=0A= > obscure calling party numbers when orchestrating bulk commercial=0A= > calling schemes, hacking voicemail boxes or even circumventing multi-= =0A= > factor authentication systems trusted by banks. Despite previous=0A= > attempts to provide a secure assurance of the origin of SIP=0A= > communications, we still lack of effective standards for identifying=0A= > the calling party in a VoIP session. This document examines the=0A= > reasons why providing identity for telephone numbers on the Internet=0A= > has proven so difficult, and shows how changes in the last decade may= =0A= > provide us with new strategies for attaching a secure identity to SIP= =0A= > sessions.=0A= >=0A= >=0A= >The IETF datatracker status page for this draft is:=0A= >https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement=0A= >=0A= >There's also a htmlized version available at:=0A= >http://tools.ietf.org/html/draft-ietf-stir-problem-statement-01=0A= >=0A= >A diff from the previous version is available at:=0A= >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-problem-statement-01=0A= >=0A= >=0A= >Please note that it may take a couple of minutes from the time of=0A= >submission=0A= >until the htmlized version and diff are available at tools.ietf.org.=0A= >=0A= >Internet-Drafts are also available by anonymous FTP at:=0A= >ftp://ftp.ietf.org/internet-drafts/=0A= >=0A= >_______________________________________________=0A= >stir mailing list=0A= >stir@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/stir=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From richard@shockey.us Mon Dec 9 18:55:06 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2BA1AE10C for ; Mon, 9 Dec 2013 18:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOCBIU3opC4p for ; Mon, 9 Dec 2013 18:55:05 -0800 (PST) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 2140F1AE107 for ; Mon, 9 Dec 2013 18:55:05 -0800 (PST) Received: (qmail 12152 invoked by uid 0); 10 Dec 2013 02:55:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.mail.unifiedlayer.com with SMTP; 10 Dec 2013 02:55:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=dWlv622en3l06Its39TUvV48Q3xFqMMouQhhdOSiu8E=; b=BuL/TspPktKcwlZkpKIm4PXa73x8XptGcFKk9haBN2mR94xZ4PkPalYvFekq0v9apQuQik6zyIP09H1ZTVFpuEr5Kx6eSAeYLGW8YtgFDQ2n7L2oqzwQjGSkwXjNopdj; Received: from [173.79.179.104] (port=49548 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VqDT0-0003cg-KE; Mon, 09 Dec 2013 19:54:34 -0700 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Fernando Mousinho \(fmousinh\)'" , References: <20131207015054.32142.60425.idtracker@ietfa.amsl.com>, In-Reply-To: Date: Mon, 9 Dec 2013 21:54:32 -0500 Message-ID: <003401cef553$27996ca0$76cc45e0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHAntbWDqdBy1GtLjl2NzzK6AuCuQIKX7jWAWMCDwqaTf0+QA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:55:07 -0000 +1 =20 800 numbers are technically part of the North American Numbering Plan = and are therefore E.164=20 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne Sent: Monday, December 09, 2013 5:02 PM To: Fernando Mousinho (fmousinh); stir@ietf.org Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt As a minor matter, as far as I can tell, toll-free numbers, at least in = the US, would be considered E.164, as they do not seem to fall into any of = the Annex A exceptions, such as short codes, and follow the structure of the national numbering plan. ________________________________________ From: stir [stir-bounces@ietf.org] on behalf of Fernando Mousinho = (fmousinh) [fmousinh@cisco.com] Sent: Monday, December 09, 2013 4:53 PM To: stir@ietf.org Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt Some feedback on this last draft: Section 3, Out-of-Band Identity Verification: We should remove the reference to E164, given some callers may advertise toll-free numbers and other non E164 identities. (I do understand that otherwise we would try to convert numbers to some canonical form). I would also slightly change the last sentence in this same section, as = it gives the impression that out-of-band should only be used if inband is = not available. Correct me if I=B9m wrong, but we would be ok if some = entities only support out-of-band even if technically they could handle inband. Suggested text =B3This approach is needed because the inband technique = does not work in all use cases, such as when intermediaries are involved or interworking with PSTN is used.=B2 On 12/6/13, 8:50 PM, "internet-drafts@ietf.org" = wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Secure Telephone Identity Revisited=20 >Working Group of the IETF. > > Title : Secure Telephone Identity Problem Statement > Author(s) : Jon Peterson > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-stir-problem-statement-01.txt > Pages : 23 > Date : 2013-12-06 > >Abstract: > Over the past decade, Voice over IP (VoIP) systems based on SIP have > replaced many traditional telephony deployments. Interworking VoIP > systems with the traditional telephone network has reduced the > overall security of calling party number and Caller ID assurances by > granting attackers new and inexpensive tools to impersonate or > obscure calling party numbers when orchestrating bulk commercial > calling schemes, hacking voicemail boxes or even circumventing = multi- > factor authentication systems trusted by banks. Despite previous > attempts to provide a secure assurance of the origin of SIP > communications, we still lack of effective standards for identifying > the calling party in a VoIP session. This document examines the > reasons why providing identity for telephone numbers on the Internet > has proven so difficult, and shows how changes in the last decade = may > provide us with new strategies for attaching a secure identity to = SIP > sessions. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-stir-problem-statement-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-problem-statement-01 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From tony@yaanatech.com Mon Dec 9 20:01:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B41AE183 for ; Mon, 9 Dec 2013 20:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqZOBYYP_UNg for ; Mon, 9 Dec 2013 20:01:51 -0800 (PST) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with SMTP id 20ADB1AE187 for ; Mon, 9 Dec 2013 20:01:51 -0800 (PST) Received: from [192.168.88.12] (unknown [175.145.117.172]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 86CDF58090; Tue, 10 Dec 2013 04:03:05 +0000 (UTC) Date: Tue, 10 Dec 2013 11:59:52 +0800 Message-ID: <7qs2st3daut5sryomdp94jnb.1386647992422@email.android.com> Importance: normal From: Tony Rutkowski To: Richard Shockey , 'Henning Schulzrinne' , "'Fernando Mousinho (fmousinh)'" , stir@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_94670303206330" Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Tony Rutkowski List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 04:01:53 -0000 ----_com.android.email_94670303206330 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzIgVGhleSBhcmUgYWRtaW5pc3RyYXRpdmVseSBhbmQgbGVnYWxseSBwYXJ0IG9mIHRoZSBOQU5Q IGFzIHdlbGwuIDotKQoKClNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZQoKLS0tLS0tLS0gT3JpZ2lu YWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tl eS51cz4gCkRhdGU6IDEwLzEyLzIwMTMgIDEwOjU0ICAoR01UKzA4OjAwKSAKVG86ICdIZW5uaW5n IFNjaHVsenJpbm5lJyA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PiwiJ0Zlcm5hbmRvIE1v dXNpbmhvIChmbW91c2luaCknIiA8Zm1vdXNpbmhAY2lzY28uY29tPixzdGlyQGlldGYub3JnIApT dWJqZWN0OiBSZTogW3N0aXJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3Rpci1wcm9ibGVtLXN0 YXRlbWVudC0wMS50eHQgCiAKKzHCoCAKCjgwMCBudW1iZXJzIGFyZSB0ZWNobmljYWxseSBwYXJ0 IG9mIHRoZSBOb3J0aCBBbWVyaWNhbiBOdW1iZXJpbmcgUGxhbiBhbmQKYXJlIHRoZXJlZm9yZcKg IEUuMTY0IAoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogc3RpciBbbWFpbHRvOnN0 aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbm5pbmcgU2NodWx6cmlubmUKU2Vu dDogTW9uZGF5LCBEZWNlbWJlciAwOSwgMjAxMyA1OjAyIFBNClRvOiBGZXJuYW5kbyBNb3VzaW5o byAoZm1vdXNpbmgpOyBzdGlyQGlldGYub3JnClN1YmplY3Q6IFJlOiBbc3Rpcl0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dAoKQXMgYSBtaW5vciBt YXR0ZXIsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0b2xsLWZyZWUgbnVtYmVycywgYXQgbGVhc3Qg aW4gdGhlClVTLCB3b3VsZCBiZSBjb25zaWRlcmVkIEUuMTY0LCBhcyB0aGV5IGRvIG5vdCBzZWVt IHRvIGZhbGwgaW50byBhbnkgb2YgdGhlCkFubmV4IEEgZXhjZXB0aW9ucywgc3VjaCBhcyBzaG9y dCBjb2RlcywgYW5kIGZvbGxvdyB0aGUgc3RydWN0dXJlIG9mIHRoZQpuYXRpb25hbCBudW1iZXJp bmcgcGxhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTog c3RpciBbc3Rpci1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgRmVybmFuZG8gTW91c2lu aG8gKGZtb3VzaW5oKQpbZm1vdXNpbmhAY2lzY28uY29tXQpTZW50OiBNb25kYXksIERlY2VtYmVy IDA5LCAyMDEzIDQ6NTMgUE0KVG86IHN0aXJAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtzdGlyXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0CgpTb21l IGZlZWRiYWNrIG9uIHRoaXMgbGFzdCBkcmFmdDoKClNlY3Rpb24gMywgT3V0LW9mLUJhbmQgSWRl bnRpdHkgVmVyaWZpY2F0aW9uOgoKV2Ugc2hvdWxkIHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRvIEUx NjQsIGdpdmVuIHNvbWUgY2FsbGVycyBtYXkgYWR2ZXJ0aXNlCnRvbGwtZnJlZSBudW1iZXJzIGFu ZCBvdGhlciBub24gRTE2NCBpZGVudGl0aWVzLiAoSSBkbyB1bmRlcnN0YW5kIHRoYXQKb3RoZXJ3 aXNlIHdlIHdvdWxkIHRyeSB0byBjb252ZXJ0IG51bWJlcnMgdG8gc29tZSBjYW5vbmljYWwgZm9y bSkuCgpJIHdvdWxkIGFsc28gc2xpZ2h0bHkgY2hhbmdlIHRoZSBsYXN0IHNlbnRlbmNlIGluIHRo aXMgc2FtZSBzZWN0aW9uLCBhcyBpdApnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IG91dC1vZi1i YW5kIHNob3VsZCBvbmx5IGJlIHVzZWQgaWYgaW5iYW5kIGlzIG5vdAphdmFpbGFibGUuIENvcnJl Y3QgbWUgaWYgScK5bSB3cm9uZywgYnV0IHdlIHdvdWxkIGJlIG9rIGlmIHNvbWUgZW50aXRpZXMg b25seQpzdXBwb3J0IG91dC1vZi1iYW5kIGV2ZW4gaWYgdGVjaG5pY2FsbHkgdGhleSBjb3VsZCBo YW5kbGUgaW5iYW5kLgpTdWdnZXN0ZWQgdGV4dCDCs1RoaXMgYXBwcm9hY2ggaXMgbmVlZGVkIGJl Y2F1c2UgdGhlIGluYmFuZCB0ZWNobmlxdWUgZG9lcwpub3Qgd29yayBpbiBhbGwgdXNlIGNhc2Vz LCBzdWNoIGFzIHdoZW4gaW50ZXJtZWRpYXJpZXMgYXJlIGludm9sdmVkIG9yCmludGVyd29ya2lu ZyB3aXRoIFBTVE4gaXMgdXNlZC7CsgoKCgoKCk9uIDEyLzYvMTMsIDg6NTAgUE0sICJpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Cndyb3RlOgoKPgo+ QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIAo+ZGlyZWN0b3JpZXMuCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgU2VjdXJlIFRlbGVwaG9uZSBJZGVudGl0eSBSZXZpc2l0ZWQgCj5Xb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLgo+Cj7CoMKgwqDCoMKgwqAgVGl0bGXCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IFNl Y3VyZSBUZWxlcGhvbmUgSWRlbnRpdHkgUHJvYmxlbSBTdGF0ZW1lbnQKPsKgwqDCoMKgwqDCoCBB dXRob3IocynCoMKgwqDCoMKgwqAgOiBKb24gUGV0ZXJzb24KPsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEhlbm5pbmcgU2NodWx6cmlubmUKPsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEhhbm5lcyBUc2No b2ZlbmlnCj7CoMKgwqDCoMKgwqAgRmlsZW5hbWXCoMKgwqDCoMKgwqDCoCA6IGRyYWZ0LWlldGYt c3Rpci1wcm9ibGVtLXN0YXRlbWVudC0wMS50eHQKPsKgwqDCoMKgwqDCoCBQYWdlc8KgwqDCoMKg wqDCoMKgwqDCoMKgIDogMjMKPsKgwqDCoMKgwqDCoCBEYXRlwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA6IDIwMTMtMTItMDYKPgo+QWJzdHJhY3Q6Cj7CoMKgIE92ZXIgdGhlIHBhc3QgZGVjYWRlLCBW b2ljZSBvdmVyIElQIChWb0lQKSBzeXN0ZW1zIGJhc2VkIG9uIFNJUCBoYXZlCj7CoMKgIHJlcGxh Y2VkIG1hbnkgdHJhZGl0aW9uYWwgdGVsZXBob255IGRlcGxveW1lbnRzLsKgIEludGVyd29ya2lu ZyBWb0lQCj7CoMKgIHN5c3RlbXMgd2l0aCB0aGUgdHJhZGl0aW9uYWwgdGVsZXBob25lIG5ldHdv cmsgaGFzIHJlZHVjZWQgdGhlCj7CoMKgIG92ZXJhbGwgc2VjdXJpdHkgb2YgY2FsbGluZyBwYXJ0 eSBudW1iZXIgYW5kIENhbGxlciBJRCBhc3N1cmFuY2VzIGJ5Cj7CoMKgIGdyYW50aW5nIGF0dGFj a2VycyBuZXcgYW5kIGluZXhwZW5zaXZlIHRvb2xzIHRvIGltcGVyc29uYXRlIG9yCj7CoMKgIG9i c2N1cmUgY2FsbGluZyBwYXJ0eSBudW1iZXJzIHdoZW4gb3JjaGVzdHJhdGluZyBidWxrIGNvbW1l cmNpYWwKPsKgwqAgY2FsbGluZyBzY2hlbWVzLCBoYWNraW5nIHZvaWNlbWFpbCBib3hlcyBvciBl dmVuIGNpcmN1bXZlbnRpbmcgbXVsdGktCj7CoMKgIGZhY3RvciBhdXRoZW50aWNhdGlvbiBzeXN0 ZW1zIHRydXN0ZWQgYnkgYmFua3MuwqAgRGVzcGl0ZSBwcmV2aW91cwo+wqDCoCBhdHRlbXB0cyB0 byBwcm92aWRlIGEgc2VjdXJlIGFzc3VyYW5jZSBvZiB0aGUgb3JpZ2luIG9mIFNJUAo+wqDCoCBj b21tdW5pY2F0aW9ucywgd2Ugc3RpbGwgbGFjayBvZiBlZmZlY3RpdmUgc3RhbmRhcmRzIGZvciBp ZGVudGlmeWluZwo+wqDCoCB0aGUgY2FsbGluZyBwYXJ0eSBpbiBhIFZvSVAgc2Vzc2lvbi7CoCBU aGlzIGRvY3VtZW50IGV4YW1pbmVzIHRoZQo+wqDCoCByZWFzb25zIHdoeSBwcm92aWRpbmcgaWRl bnRpdHkgZm9yIHRlbGVwaG9uZSBudW1iZXJzIG9uIHRoZSBJbnRlcm5ldAo+wqDCoCBoYXMgcHJv dmVuIHNvIGRpZmZpY3VsdCwgYW5kIHNob3dzIGhvdyBjaGFuZ2VzIGluIHRoZSBsYXN0IGRlY2Fk ZSBtYXkKPsKgwqAgcHJvdmlkZSB1cyB3aXRoIG5ldyBzdHJhdGVnaWVzIGZvciBhdHRhY2hpbmcg YSBzZWN1cmUgaWRlbnRpdHkgdG8gU0lQCj7CoMKgIHNlc3Npb25zLgo+Cj4KPlRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOgo+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50Cj4KPlRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ogo+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAxCj4KPkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoKPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVu dC0wMQo+Cj4KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIAo+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IAo+dG9vbHMuaWV0Zi5vcmcuCj4KPkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoKPmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj5zdGlyIG1haWxpbmcgbGlzdAo+c3RpckBpZXRmLm9yZwo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpzdGlyIG1haWxpbmcgbGlzdApzdGly QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RpcgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpzdGlyIG1haWxpbmcg bGlzdApzdGlyQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3RpcgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3Rp ciBtYWlsaW5nIGxpc3QKc3RpckBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N0aXIK ----_com.android.email_94670303206330 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj4rMiBUaGV5IGFyZSBhZG1p bmlzdHJhdGl2ZWx5IGFuZCBsZWdhbGx5IHBhcnQgb2YgdGhlIE5BTlAgYXMgd2VsbC4gOi0pPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZTwvZGl2PjwvZGl2 Pjxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTog UmljaGFyZCBTaG9ja2V5ICZsdDtyaWNoYXJkQHNob2NrZXkudXMmZ3Q7IDxicj5EYXRlOiAxMC8x Mi8yMDEzICAxMDo1NCAgKEdNVCswODowMCkgPGJyPlRvOiAnSGVubmluZyBTY2h1bHpyaW5uZScg Jmx0O0hlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiZndDssIidGZXJuYW5kbyBNb3VzaW5obyAo Zm1vdXNpbmgpJyIgJmx0O2Ztb3VzaW5oQGNpc2NvLmNvbSZndDssc3RpckBpZXRmLm9yZyA8YnI+ U3ViamVjdDogUmU6IFtzdGlyXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1z dGF0ZW1lbnQtMDEudHh0IDxicj4gPGJyPjxicj4rMSZuYnNwOyA8YnI+PGJyPjgwMCBudW1iZXJz IGFyZSB0ZWNobmljYWxseSBwYXJ0IG9mIHRoZSBOb3J0aCBBbWVyaWNhbiBOdW1iZXJpbmcgUGxh biBhbmQ8YnI+YXJlIHRoZXJlZm9yZSZuYnNwOyBFLjE2NCA8YnI+PGJyPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPkZyb206IHN0aXIgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBIZW5uaW5nIFNjaHVsenJpbm5lPGJyPlNlbnQ6IE1vbmRheSwgRGVjZW1i ZXIgMDksIDIwMTMgNTowMiBQTTxicj5UbzogRmVybmFuZG8gTW91c2luaG8gKGZtb3VzaW5oKTsg c3RpckBpZXRmLm9yZzxicj5TdWJqZWN0OiBSZTogW3N0aXJdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudC0wMS50eHQ8YnI+PGJyPkFzIGEgbWlub3IgbWF0dGVy LCBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgdG9sbC1mcmVlIG51bWJlcnMsIGF0IGxlYXN0IGluIHRo ZTxicj5VUywgd291bGQgYmUgY29uc2lkZXJlZCBFLjE2NCwgYXMgdGhleSBkbyBub3Qgc2VlbSB0 byBmYWxsIGludG8gYW55IG9mIHRoZTxicj5Bbm5leCBBIGV4Y2VwdGlvbnMsIHN1Y2ggYXMgc2hv cnQgY29kZXMsIGFuZCBmb2xsb3cgdGhlIHN0cnVjdHVyZSBvZiB0aGU8YnI+bmF0aW9uYWwgbnVt YmVyaW5nIHBsYW4uPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPkZyb206IHN0aXIgW3N0aXItYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEZl cm5hbmRvIE1vdXNpbmhvIChmbW91c2luaCk8YnI+W2Ztb3VzaW5oQGNpc2NvLmNvbV08YnI+U2Vu dDogTW9uZGF5LCBEZWNlbWJlciAwOSwgMjAxMyA0OjUzIFBNPGJyPlRvOiBzdGlyQGlldGYub3Jn PGJyPlN1YmplY3Q6IFJlOiBbc3Rpcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zdGlyLXByb2Js ZW0tc3RhdGVtZW50LTAxLnR4dDxicj48YnI+U29tZSBmZWVkYmFjayBvbiB0aGlzIGxhc3QgZHJh ZnQ6PGJyPjxicj5TZWN0aW9uIDMsIE91dC1vZi1CYW5kIElkZW50aXR5IFZlcmlmaWNhdGlvbjo8 YnI+PGJyPldlIHNob3VsZCByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byBFMTY0LCBnaXZlbiBzb21l IGNhbGxlcnMgbWF5IGFkdmVydGlzZTxicj50b2xsLWZyZWUgbnVtYmVycyBhbmQgb3RoZXIgbm9u IEUxNjQgaWRlbnRpdGllcy4gKEkgZG8gdW5kZXJzdGFuZCB0aGF0PGJyPm90aGVyd2lzZSB3ZSB3 b3VsZCB0cnkgdG8gY29udmVydCBudW1iZXJzIHRvIHNvbWUgY2Fub25pY2FsIGZvcm0pLjxicj48 YnI+SSB3b3VsZCBhbHNvIHNsaWdodGx5IGNoYW5nZSB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGlz IHNhbWUgc2VjdGlvbiwgYXMgaXQ8YnI+Z2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCBvdXQtb2Yt YmFuZCBzaG91bGQgb25seSBiZSB1c2VkIGlmIGluYmFuZCBpcyBub3Q8YnI+YXZhaWxhYmxlLiBD b3JyZWN0IG1lIGlmIEnCuW0gd3JvbmcsIGJ1dCB3ZSB3b3VsZCBiZSBvayBpZiBzb21lIGVudGl0 aWVzIG9ubHk8YnI+c3VwcG9ydCBvdXQtb2YtYmFuZCBldmVuIGlmIHRlY2huaWNhbGx5IHRoZXkg Y291bGQgaGFuZGxlIGluYmFuZC48YnI+U3VnZ2VzdGVkIHRleHQgwrNUaGlzIGFwcHJvYWNoIGlz IG5lZWRlZCBiZWNhdXNlIHRoZSBpbmJhbmQgdGVjaG5pcXVlIGRvZXM8YnI+bm90IHdvcmsgaW4g YWxsIHVzZSBjYXNlcywgc3VjaCBhcyB3aGVuIGludGVybWVkaWFyaWVzIGFyZSBpbnZvbHZlZCBv cjxicj5pbnRlcndvcmtpbmcgd2l0aCBQU1ROIGlzIHVzZWQuwrI8YnI+PGJyPjxicj48YnI+PGJy Pjxicj5PbiAxMi82LzEzLCA4OjUwIFBNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiAmbHQ7 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnJmd0Ozxicj53cm90ZTo8YnI+PGJyPiZndDs8YnI+Jmd0 O0EgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyA8YnI+Jmd0O2RpcmVjdG9yaWVzLjxicj4mZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIFNlY3VyZSBUZWxlcGhvbmUgSWRlbnRpdHkgUmV2aXNpdGVkIDxicj4m Z3Q7V29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogU2VjdXJlIFRlbGVwaG9uZSBJZGVu dGl0eSBQcm9ibGVtIFN0YXRlbWVudDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEF1dGhvcihzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6 IEpvbiBQZXRlcnNvbjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEhlbm5pbmcgU2NodWx6cmlubmU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBIYW5uZXMgVHNjaG9mZW5pZzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dDxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjM8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRlJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAx My0xMi0wNjxicj4mZ3Q7PGJyPiZndDtBYnN0cmFjdDo8YnI+Jmd0OyZuYnNwOyZuYnNwOyBPdmVy IHRoZSBwYXN0IGRlY2FkZSwgVm9pY2Ugb3ZlciBJUCAoVm9JUCkgc3lzdGVtcyBiYXNlZCBvbiBT SVAgaGF2ZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7IHJlcGxhY2VkIG1hbnkgdHJhZGl0aW9uYWwgdGVs ZXBob255IGRlcGxveW1lbnRzLiZuYnNwOyBJbnRlcndvcmtpbmcgVm9JUDxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7IHN5c3RlbXMgd2l0aCB0aGUgdHJhZGl0aW9uYWwgdGVsZXBob25lIG5ldHdvcmsgaGFz IHJlZHVjZWQgdGhlPGJyPiZndDsmbmJzcDsmbmJzcDsgb3ZlcmFsbCBzZWN1cml0eSBvZiBjYWxs aW5nIHBhcnR5IG51bWJlciBhbmQgQ2FsbGVyIElEIGFzc3VyYW5jZXMgYnk8YnI+Jmd0OyZuYnNw OyZuYnNwOyBncmFudGluZyBhdHRhY2tlcnMgbmV3IGFuZCBpbmV4cGVuc2l2ZSB0b29scyB0byBp bXBlcnNvbmF0ZSBvcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7IG9ic2N1cmUgY2FsbGluZyBwYXJ0eSBu dW1iZXJzIHdoZW4gb3JjaGVzdHJhdGluZyBidWxrIGNvbW1lcmNpYWw8YnI+Jmd0OyZuYnNwOyZu YnNwOyBjYWxsaW5nIHNjaGVtZXMsIGhhY2tpbmcgdm9pY2VtYWlsIGJveGVzIG9yIGV2ZW4gY2ly Y3VtdmVudGluZyBtdWx0aS08YnI+Jmd0OyZuYnNwOyZuYnNwOyBmYWN0b3IgYXV0aGVudGljYXRp b24gc3lzdGVtcyB0cnVzdGVkIGJ5IGJhbmtzLiZuYnNwOyBEZXNwaXRlIHByZXZpb3VzPGJyPiZn dDsmbmJzcDsmbmJzcDsgYXR0ZW1wdHMgdG8gcHJvdmlkZSBhIHNlY3VyZSBhc3N1cmFuY2Ugb2Yg dGhlIG9yaWdpbiBvZiBTSVA8YnI+Jmd0OyZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9ucywgd2Ug c3RpbGwgbGFjayBvZiBlZmZlY3RpdmUgc3RhbmRhcmRzIGZvciBpZGVudGlmeWluZzxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7IHRoZSBjYWxsaW5nIHBhcnR5IGluIGEgVm9JUCBzZXNzaW9uLiZuYnNwOyBU aGlzIGRvY3VtZW50IGV4YW1pbmVzIHRoZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7IHJlYXNvbnMgd2h5 IHByb3ZpZGluZyBpZGVudGl0eSBmb3IgdGVsZXBob25lIG51bWJlcnMgb24gdGhlIEludGVybmV0 PGJyPiZndDsmbmJzcDsmbmJzcDsgaGFzIHByb3ZlbiBzbyBkaWZmaWN1bHQsIGFuZCBzaG93cyBo b3cgY2hhbmdlcyBpbiB0aGUgbGFzdCBkZWNhZGUgbWF5PGJyPiZndDsmbmJzcDsmbmJzcDsgcHJv dmlkZSB1cyB3aXRoIG5ldyBzdHJhdGVnaWVzIGZvciBhdHRhY2hpbmcgYSBzZWN1cmUgaWRlbnRp dHkgdG8gU0lQPGJyPiZndDsmbmJzcDsmbmJzcDsgc2Vzc2lvbnMuPGJyPiZndDs8YnI+Jmd0Ozxi cj4mZ3Q7VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 PGJyPiZndDtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXN0aXIt cHJvYmxlbS1zdGF0ZW1lbnQ8YnI+Jmd0Ozxicj4mZ3Q7VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPiZndDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDE8YnI+Jmd0Ozxicj4mZ3Q7QSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4mZ3Q7aHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVt ZW50LTAxPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgPGJyPiZndDtzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGJy PiZndDt0b29scy5pZXRmLm9yZy48YnI+Jmd0Ozxicj4mZ3Q7SW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4mZ3Q7ZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy88YnI+Jmd0Ozxicj4mZ3Q7X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0O3N0aXIgbWFpbGluZyBsaXN0PGJyPiZn dDtzdGlyQGlldGYub3JnPGJyPiZndDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N0aXI8YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPnN0aXIgbWFpbGluZyBsaXN0PGJyPnN0aXJAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPGJyPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnN0aXIgbWFpbGluZyBsaXN0PGJyPnN0aXJA aWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPGJy Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5z dGlyIG1haWxpbmcgbGlzdDxicj5zdGlyQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3Rpcjxicj48L2JvZHk+ ----_com.android.email_94670303206330-- From philippe.fouquart@orange.com Tue Dec 10 00:42:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78EA1AE236 for ; Tue, 10 Dec 2013 00:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd4DiiMn7HAk for ; Tue, 10 Dec 2013 00:42:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id A19351AE0C4 for ; Tue, 10 Dec 2013 00:42:49 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id A1B4619028F; Tue, 10 Dec 2013 09:42:43 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7C581158059; Tue, 10 Dec 2013 09:42:43 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 09:42:43 +0100 From: To: Tony Rutkowski , Richard Shockey , 'Henning Schulzrinne' , "'Fernando Mousinho (fmousinh)'" , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt Thread-Index: AQHO9VxHTOZ74vF2LEOfWNtKUDpfQJpNG3Ew Date: Tue, 10 Dec 2013 08:42:43 +0000 Message-ID: <6090_1386664963_52A6D403_6090_10177_1_B5939C6860701C49AA39C5DA5189448B110A26B4@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <7qs2st3daut5sryomdp94jnb.1386647992422@email.android.com> In-Reply-To: <7qs2st3daut5sryomdp94jnb.1386647992422@email.android.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.10.70015 Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 08:42:53 -0000 KzMgc2luY2UgdGhpcyBpcyBub3Qgc3BlY2lmaWMgdG8gdGhlIE5BTlAgOikNCg0KUmVnYXJkcywN Cg0KUGhpbGlwcGUgRm91cXVhcnQNCk9yYW5nZSBMYWJzIE5ldHdvcmtzDQorMzMgKDApIDEgNDUg MjkgNTggMTMNCg0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFRvbnkgUnV0a293c2tpDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxMCwgMjAx MyA1OjAwIEFNDQpUbzogUmljaGFyZCBTaG9ja2V5OyAnSGVubmluZyBTY2h1bHpyaW5uZSc7ICdG ZXJuYW5kbyBNb3VzaW5obyAoZm1vdXNpbmgpJzsgc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzdGlyXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDEu dHh0DQoNCisyIFRoZXkgYXJlIGFkbWluaXN0cmF0aXZlbHkgYW5kIGxlZ2FsbHkgcGFydCBvZiB0 aGUgTkFOUCBhcyB3ZWxsLiA6LSkNCg0KDQpTZW50IGZyb20gU2Ftc3VuZyBNb2JpbGUNCg0KDQoN Ci0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0NCkZyb206IFJpY2hhcmQgU2hvY2tl eSA8cmljaGFyZEBzaG9ja2V5LnVzPiANCkRhdGU6IDEwLzEyLzIwMTMgMTA6NTQgKEdNVCswODow MCkgDQpUbzogJ0hlbm5pbmcgU2NodWx6cmlubmUnIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5n b3Y+LCInRmVybmFuZG8gTW91c2luaG8gKGZtb3VzaW5oKSciIDxmbW91c2luaEBjaXNjby5jb20+ LHN0aXJAaWV0Zi5vcmcgDQpTdWJqZWN0OiBSZTogW3N0aXJdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudC0wMS50eHQgDQoNCg0KKzHCoCANCg0KODAwIG51bWJl cnMgYXJlIHRlY2huaWNhbGx5IHBhcnQgb2YgdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJlcmluZyBQ bGFuIGFuZA0KYXJlIHRoZXJlZm9yZcKgIEUuMTY0IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEhlbm5pbmcgU2NodWx6cmlubmUNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDksIDIwMTMg NTowMiBQTQ0KVG86IEZlcm5hbmRvIE1vdXNpbmhvIChmbW91c2luaCk7IHN0aXJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbc3Rpcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0t c3RhdGVtZW50LTAxLnR4dA0KDQpBcyBhIG1pbm9yIG1hdHRlciwgYXMgZmFyIGFzIEkgY2FuIHRl bGwsIHRvbGwtZnJlZSBudW1iZXJzLCBhdCBsZWFzdCBpbiB0aGUNClVTLCB3b3VsZCBiZSBjb25z aWRlcmVkIEUuMTY0LCBhcyB0aGV5IGRvIG5vdCBzZWVtIHRvIGZhbGwgaW50byBhbnkgb2YgdGhl DQpBbm5leCBBIGV4Y2VwdGlvbnMsIHN1Y2ggYXMgc2hvcnQgY29kZXMsIGFuZCBmb2xsb3cgdGhl IHN0cnVjdHVyZSBvZiB0aGUNCm5hdGlvbmFsIG51bWJlcmluZyBwbGFuLg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBzdGlyIFtzdGlyLWJvdW5jZXNA aWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBGZXJuYW5kbyBNb3VzaW5obyAoZm1vdXNpbmgpDQpbZm1v dXNpbmhAY2lzY28uY29tXQ0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwOSwgMjAxMyA0OjUzIFBN DQpUbzogc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzdGlyXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0DQoNClNvbWUgZmVlZGJhY2sgb24g dGhpcyBsYXN0IGRyYWZ0Og0KDQpTZWN0aW9uIDMsIE91dC1vZi1CYW5kIElkZW50aXR5IFZlcmlm aWNhdGlvbjoNCg0KV2Ugc2hvdWxkIHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRvIEUxNjQsIGdpdmVu IHNvbWUgY2FsbGVycyBtYXkgYWR2ZXJ0aXNlDQp0b2xsLWZyZWUgbnVtYmVycyBhbmQgb3RoZXIg bm9uIEUxNjQgaWRlbnRpdGllcy4gKEkgZG8gdW5kZXJzdGFuZCB0aGF0DQpvdGhlcndpc2Ugd2Ug d291bGQgdHJ5IHRvIGNvbnZlcnQgbnVtYmVycyB0byBzb21lIGNhbm9uaWNhbCBmb3JtKS4NCg0K SSB3b3VsZCBhbHNvIHNsaWdodGx5IGNoYW5nZSB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGlzIHNh bWUgc2VjdGlvbiwgYXMgaXQNCmdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgb3V0LW9mLWJhbmQg c2hvdWxkIG9ubHkgYmUgdXNlZCBpZiBpbmJhbmQgaXMgbm90DQphdmFpbGFibGUuIENvcnJlY3Qg bWUgaWYgScK5bSB3cm9uZywgYnV0IHdlIHdvdWxkIGJlIG9rIGlmIHNvbWUgZW50aXRpZXMgb25s eQ0Kc3VwcG9ydCBvdXQtb2YtYmFuZCBldmVuIGlmIHRlY2huaWNhbGx5IHRoZXkgY291bGQgaGFu ZGxlIGluYmFuZC4NClN1Z2dlc3RlZCB0ZXh0IMKzVGhpcyBhcHByb2FjaCBpcyBuZWVkZWQgYmVj YXVzZSB0aGUgaW5iYW5kIHRlY2huaXF1ZSBkb2VzDQpub3Qgd29yayBpbiBhbGwgdXNlIGNhc2Vz LCBzdWNoIGFzIHdoZW4gaW50ZXJtZWRpYXJpZXMgYXJlIGludm9sdmVkIG9yDQppbnRlcndvcmtp bmcgd2l0aCBQU1ROIGlzIHVzZWQuwrINCg0KDQoNCg0KDQpPbiAxMi82LzEzLCA4OjUwIFBNLCAi aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0Kd3Jv dGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgDQo+ZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIFNlY3VyZSBUZWxlcGhvbmUgSWRlbnRpdHkgUmV2aXNpdGVkIA0KPldv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+wqDCoMKgwqDCoMKgIFRpdGxlwqDCoMKgwqDC oMKgwqDCoMKgwqAgOiBTZWN1cmUgVGVsZXBob25lIElkZW50aXR5IFByb2JsZW0gU3RhdGVtZW50 DQo+wqDCoMKgwqDCoMKgIEF1dGhvcihzKcKgwqDCoMKgwqDCoCA6IEpvbiBQZXRlcnNvbg0KPsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEhlbm5pbmcg U2NodWx6cmlubmUNCj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBIYW5uZXMgVHNjaG9mZW5pZw0KPsKgwqDCoMKgwqDCoCBGaWxlbmFtZcKgwqDCoMKg wqDCoMKgIDogZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dA0KPsKgwqDC oMKgwqDCoCBQYWdlc8KgwqDCoMKgwqDCoMKgwqDCoMKgIDogMjMNCj7CoMKgwqDCoMKgwqAgRGF0 ZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAyMDEzLTEyLTA2DQo+DQo+QWJzdHJhY3Q6DQo+wqDC oCBPdmVyIHRoZSBwYXN0IGRlY2FkZSwgVm9pY2Ugb3ZlciBJUCAoVm9JUCkgc3lzdGVtcyBiYXNl ZCBvbiBTSVAgaGF2ZQ0KPsKgwqAgcmVwbGFjZWQgbWFueSB0cmFkaXRpb25hbCB0ZWxlcGhvbnkg ZGVwbG95bWVudHMuwqAgSW50ZXJ3b3JraW5nIFZvSVANCj7CoMKgIHN5c3RlbXMgd2l0aCB0aGUg dHJhZGl0aW9uYWwgdGVsZXBob25lIG5ldHdvcmsgaGFzIHJlZHVjZWQgdGhlDQo+wqDCoCBvdmVy YWxsIHNlY3VyaXR5IG9mIGNhbGxpbmcgcGFydHkgbnVtYmVyIGFuZCBDYWxsZXIgSUQgYXNzdXJh bmNlcyBieQ0KPsKgwqAgZ3JhbnRpbmcgYXR0YWNrZXJzIG5ldyBhbmQgaW5leHBlbnNpdmUgdG9v bHMgdG8gaW1wZXJzb25hdGUgb3INCj7CoMKgIG9ic2N1cmUgY2FsbGluZyBwYXJ0eSBudW1iZXJz IHdoZW4gb3JjaGVzdHJhdGluZyBidWxrIGNvbW1lcmNpYWwNCj7CoMKgIGNhbGxpbmcgc2NoZW1l cywgaGFja2luZyB2b2ljZW1haWwgYm94ZXMgb3IgZXZlbiBjaXJjdW12ZW50aW5nIG11bHRpLQ0K PsKgwqAgZmFjdG9yIGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMgdHJ1c3RlZCBieSBiYW5rcy7CoCBE ZXNwaXRlIHByZXZpb3VzDQo+wqDCoCBhdHRlbXB0cyB0byBwcm92aWRlIGEgc2VjdXJlIGFzc3Vy YW5jZSBvZiB0aGUgb3JpZ2luIG9mIFNJUA0KPsKgwqAgY29tbXVuaWNhdGlvbnMsIHdlIHN0aWxs IGxhY2sgb2YgZWZmZWN0aXZlIHN0YW5kYXJkcyBmb3IgaWRlbnRpZnlpbmcNCj7CoMKgIHRoZSBj YWxsaW5nIHBhcnR5IGluIGEgVm9JUCBzZXNzaW9uLsKgIFRoaXMgZG9jdW1lbnQgZXhhbWluZXMg dGhlDQo+wqDCoCByZWFzb25zIHdoeSBwcm92aWRpbmcgaWRlbnRpdHkgZm9yIHRlbGVwaG9uZSBu dW1iZXJzIG9uIHRoZSBJbnRlcm5ldA0KPsKgwqAgaGFzIHByb3ZlbiBzbyBkaWZmaWN1bHQsIGFu ZCBzaG93cyBob3cgY2hhbmdlcyBpbiB0aGUgbGFzdCBkZWNhZGUgbWF5DQo+wqDCoCBwcm92aWRl IHVzIHdpdGggbmV3IHN0cmF0ZWdpZXMgZm9yIGF0dGFjaGluZyBhIHNlY3VyZSBpZGVudGl0eSB0 byBTSVANCj7CoMKgIHNlc3Npb25zLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudA0KPg0KPlRoZXJlJ3MgYWxzbyBh IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudC0wMQ0KPg0KPkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDENCj4N Cj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiANCj5zdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgDQo+dG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5zdGlyIG1haWxpbmcgbGlzdA0KPnN0aXJAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBs aXN0DQpzdGlyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0aXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz dGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdGlyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From pp3129@att.com Tue Dec 10 05:38:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174931AE06C for ; Tue, 10 Dec 2013 05:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46sLxpThy7pA for ; Tue, 10 Dec 2013 05:38:17 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2DB1ACB4E for ; Tue, 10 Dec 2013 05:38:17 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 34917a25.0.1012132.00-2162.2828300.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 10 Dec 2013 13:38:12 +0000 (UTC) X-MXL-Hash: 52a7194430d75e38-06c0d500d04c6916ff414bab088d70cfc3399353 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBADcANh013216 for ; Tue, 10 Dec 2013 08:38:11 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBADc3K7013180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Dec 2013 08:38:05 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Tue, 10 Dec 2013 13:37:52 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 08:37:52 -0500 From: "PFAUTZ, PENN L" To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt Thread-Index: Ac71rQCFXjZ/VP/1QGm0g7pC3fNlhw== Date: Tue, 10 Dec 2013 13:37:51 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D604A20960@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=KeZlR3kD c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=_DfTuTUdZJYA:10 a=ofMgfj31e3cA:10 a=7rbOGru5kh8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=szWs1IS8dSAA:10 a=48vgC7mUAAAA:8 a=XHa3Cv8s31Nibm] X-AnalysisOut: [YGxFgA:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=wpoJ8-VUmAZy3Bi5:21 a=XTigHn-gQ22-s8yj:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 13:38:20 -0000 A few comments: 1. In the terminology section: Out-of-Band Identity Verification: Out-of-band verification determines whether the E.164 number used by the calling party actually exists, whether the calling entity is entitled to use the number and whether a call has recently been made from this phone number. This approach is needed when the in-band technique does not work due to intermediaries or due to interworking with PSTN networks. Delete the last sentence - not part of a definition 2. Section 4.4 replace "The gateway must verify that Alice can claim the E.164 number she is using before it populates the corresponding calling party number field in telephone network signaling." With "It is desirable that the gateway verify that Alice can claim the E.164 number she is using before it populates the corresponding calling party number field in telephone network signaling." 3. Section 5.1 "Since [5] was written, the whole notion of P- headers intended for use in private SIP domains has also been deprecated, largely because of overwhelming evidence that these headers were being used outside of private contexts and leaking into the public Internet." Reference for this deprecation? Also, who's to say that the majority of applications of the stir work won't= be in private contexts? 4. Section 6.2 "6.2. Failure of Public ENUM At the time [1] was written, the hopes for establishing a certificate authority for telephone numbers on the Internet largely rested on public ENUM deployment. The e164.arpa DNS tree established for ENUM could have grown to include certificates for telephone numbers or at least for number ranges. It is now clear however that public ENUM as originally envisioned has little prospect for adoption. That said, some national authorities for telephone numbers are migrating their provisioning services to the Internet, and issuing credentials that express authority for telephone numbers to secure those services. These new authorities for numbers could provide to the public Internet the necessary signatory authority for securing calling partys' numbers. While these systems are far from universal, the authors of this draft believe that a solution devised for the North American Numbering Plan could have applicability to other country." I'm not sure how to interpret this. Which national authorities are migrati= ng provisioning to the Internet? Not the US AFAICT. On the other hand folks are discussing approaches like using the NPAC (US p= ortability database) as ENUM registry that could support the capabilities needed by stir. If the latter kind of effort is meant a b= etter title might be "Evolution of ENUM." 5. Section 7 Requirements "Generation: Intermediaries as well as end system must be able to generate= the source identity information." What kinds of intermediaries? Have we agreed to this? Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, December 06, 2013 8:51 PM To: i-d-announce@ietf.org Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited Worki= ng Group of the IETF. Title : Secure Telephone Identity Problem Statement Author(s) : Jon Peterson Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-stir-problem-statement-01.txt Pages : 23 Date : 2013-12-06 Abstract: Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-problem-statement-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-problem-statement-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Dec 10 06:18:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B556E1ADF80 for ; Tue, 10 Dec 2013 06:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF-zSvACnlqV for ; Tue, 10 Dec 2013 06:18:39 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id ADE701ADDD2 for ; Tue, 10 Dec 2013 06:18:39 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id e16so3831625qcx.41 for ; Tue, 10 Dec 2013 06:18:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+sE0wcjcsLhUKF5FkytFesG/yU/Ab82qNliPJRBtJjI=; b=ismmltnd+NKUOjJqHjjVCQgsjJtMQVYeyjFi2fTBuey6A2Fc7xPRNBGfgXLrLfViU5 Cy6JtsA/cS7lWI+L7pZcepBj6ZGAeIRf7dmfAaIihnQ1q/q7i1KQy0qwZMM8UvT9Go9B PJXB080RpoKMPKxVc+2+6ws0YfxpFf0oHrpPWdI638yyoKKNK7wWaWT5bmNvFGoappWL eg16F7m2mqA5gU6d6E7YpFSdq3p5hvf2JLARm277RcIDqFnhEnwbhes/Hd1GeIbYS8JN QVYu+/UjTsfGuq2I61yiSr6T5EG/tr0U5rDabv0xMICnY4qwyKC8xdc0Fc8HbZKuEySD vjHQ== X-Gm-Message-State: ALoCoQlSYgAbTyL/LVjiU7Z9F4pHFfQBRifsNeHGEmIWel9P1USFcD3ft3WsJqm5EEa/CdaHoeJr X-Received: by 10.224.171.70 with SMTP id g6mr35947143qaz.80.1386685113452; Tue, 10 Dec 2013 06:18:33 -0800 (PST) Received: from [10.33.192.27] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id x10sm46567883qas.5.2013.12.10.06.18.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 06:18:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Brian Rosen In-Reply-To: <38726EDA2109264987B45E29E758C4D604A20960@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Tue, 10 Dec 2013 09:18:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <971AA8C3-95EF-4D99-8F53-362C51C52FE8@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D604A20960@MISOUT7MSGUSR9N.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1822) Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 14:18:41 -0000 Inline On Dec 10, 2013, at 8:37 AM, PFAUTZ, PENN L wrote: > A few comments: > 1. In the terminology section: > Out-of-Band Identity Verification: > Out-of-band verification > determines whether the E.164 number used by the calling party > actually exists, whether the calling entity is entitled to use = the > number and whether a call has recently been made from this phone > number. This approach is needed when the in-band technique does > not work due to intermediaries or due to interworking with PSTN > networks. >=20 > Delete the last sentence - not part of a definition Move it maybe >=20 > 2. Section 4.4 replace > "The gateway must verify that Alice can claim the > E.164 number she is using before it populates the corresponding > calling party number field in telephone network signaling." >=20 > With > "It is desirable that the gateway verify that Alice can claim the > E.164 number she is using before it populates the corresponding > calling party number field in telephone network signaling.=94 These are all use cases, and they all have statements like this. I=92d = prefer to leave it as is. >=20 > 3. Section 5.1 > "Since [5] was written, the whole notion of P- headers intended for > use in private SIP domains has also been deprecated, largely because > of overwhelming evidence that these headers were being used outside > of private contexts and leaking into the public Internet." >=20 > Reference for this deprecation? RFC5757 > Also, who's to say that the majority of applications of the stir work = won't be in private contexts? Explanation of why P-headers aren=92t allowed any more, not saying = whether stir is used in private contexts >=20 > 4. Section 6.2 > "6.2. Failure of Public ENUM >=20 > At the time [1] was written, the hopes for establishing a = certificate > authority for telephone numbers on the Internet largely rested on > public ENUM deployment. The e164.arpa DNS tree established for ENUM > could have grown to include certificates for telephone numbers or at > least for number ranges. It is now clear however that public ENUM = as > originally envisioned has little prospect for adoption. That said, > some national authorities for telephone numbers are migrating their > provisioning services to the Internet, and issuing credentials that > express authority for telephone numbers to secure those services. > These new authorities for numbers could provide to the public > Internet the necessary signatory authority for securing calling > partys' numbers. While these systems are far from universal, the > authors of this draft believe that a solution devised for the North > American Numbering Plan could have applicability to other country." >=20 > I'm not sure how to interpret this. Which national authorities are = migrating provisioning to the Internet? Not the US AFAICT. > On the other hand folks are discussing approaches like using the NPAC = (US portability database) as ENUM registry that could support > the capabilities needed by stir. If the latter kind of effort is = meant a better title might be "Evolution of ENUM.=94 This is referring to Public ENUM, which clearly failed. To make stir = work in some contexts, at least some aspects of the database have to be = public. There is relevance to private, or infrastructure ENUM, which is = why the text refers to it.=20 >=20 > 5. Section 7 Requirements > "Generation: Intermediaries as well as end system must be able to = generate the source identity information." > What kinds of intermediaries? Have we agreed to this? How about the service provider that serves the end point? I think we also would allow a service provider who delegated the number = to the SP that serves the endpoint the ability to do it. Those are intermediaries in this context Brian= From travis.russell@oracle.com Tue Dec 10 12:32:08 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E51AE071 for ; Tue, 10 Dec 2013 12:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW4zc-Bhzzfq for ; Tue, 10 Dec 2013 12:32:04 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C647E1ADE85 for ; Tue, 10 Dec 2013 12:32:04 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBAKVwgL020469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Dec 2013 20:31:59 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBAKVviY028715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Dec 2013 20:31:58 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBAKVvqJ019655 for ; Tue, 10 Dec 2013 20:31:57 GMT MIME-Version: 1.0 Message-ID: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> Date: Tue, 10 Dec 2013 12:31:54 -0800 (PST) From: Travis Russell Sender: Travis Russell To: stir@ietf.org X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 14.0.4760.0 (x86)] Content-Type: multipart/mixed; boundary="__1386707516828107773abhmp0003.oracle.com" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:32:08 -0000 --__1386707516828107773abhmp0003.oracle.com Content-Type: multipart/alternative; boundary="__1386707516829107774abhmp0003.oracle.com" --__1386707516829107774abhmp0003.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the so-= called Calling Name (CNAM) database. =20 It is my experience that spoofing is simply accomplished via VoIP servers m= odifying the SIP fields. There are a number of ways this has been facilitat= ed - you can call a spoof service where the call is terminated on a VoIP se= rver, and when prompted enter the telephone number you want to appear as th= e calling party (works great - I have tried this myself). The VoIP server t= han re-originates the call and sends it to the called party with the new "s= poofed" identity.=20 =20 I am not familiar with any cases where the spoofed identity was retrieved f= rom a SNAM server (although I may be wrong in this case).=20 =20 In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and possibl= y randomly between numbers. Anonymization facilitates automated illegal te= lemarketing or telephony denial-of-service attacks, as described above, as = it makes it difficult to blacklist numbers. =20 =20 A hacker or fraudster will typically use a "hit list" when doing this, beca= use fraud management systems look for calls to/from unassigned numbers (man= y operators assign "dark numbers" in their number ranges to identify hacker= s looking for assigned numbers). They will try to use assigned numbers of l= egitimate subscribers to alleviate discovery by FMS or network "traps" wher= e dark numbers are assigned. It is the fact that they are using legitimate = subscriber identities that makes it impossible to black list, because you a= re effecting the good subscribers service. =20 QUESTION: How will validation/verification work in the case of number porta= bility where a number once assigned to one operator is now assigned to anot= her operator? Has consideration been given to updates through the number po= rtability process in these cases or is this a mute point? =20 --=20 HYPERLINK "http://www.oracle.com/"Description: Oracle Travis Russell | Technologist, Sr. Mgr Phone: HYPERLINK "tel:+1%209194602172"+1 9194602172 | Mobile: HYPERLINK "te= l:+1%209194121167"+1 9194121167=20 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560=20 HYPERLINK "http://www.oracle.com/commitment"Description: Green Oracle Oracle is committed to developing practices and products that help protect = the environment =20 --__1386707516829107774abhmp0003.oracle.com Content-Type: multipart/related; boundary="__1386707516829107775abhmp0003.oracle.com" --__1386707516829107775abhmp0003.oracle.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Looking at the f= ollowing paragraph:

For numbers where th= e caller has suppressed textual caller identification, number spoofing can = be used to retrieve this information, stored in the so-called Calling Name = (CNAM) database.

 

It is my experience that spoofing is simply accomplished= via VoIP servers modifying the SIP fields. There are a number of ways this= has been facilitated – you can call a spoof service where the call i= s terminated on a VoIP server, and when prompted enter the telephone number= you want to appear as the calling party (works great – I have tried = this myself). The VoIP server than re-originates the call and sends it to t= he called party with the new “spoofed” identity.

 

I am not fa= miliar with any cases where the spoofed identity was retrieved from a SNAM = server (although I may be wrong in this case).

 

In the paragraph immediat= ely after:

For anonymization, the caller= does not necessarily care whether the number is in service, or who it is a= ssigned to, and may switch rapidly and possibly randomly between numbers.&n= bsp; Anonymization facilitates automated illegal telemarketing or telephony= denial-of-service attacks, as described above, as it makes it difficult to= blacklist numbers. 

 

A hacker or fraudster will typically use a = 220;hit list” when doing this, because fraud management systems look = for calls to/from unassigned numbers (many operators assign “dark num= bers” in their number ranges to identify hackers looking for assigned= numbers). They will try to use assigned numbers of legitimate subscribers = to alleviate discovery by FMS or network “traps” where dark num= bers are assigned. It is the fact that they are using legitimate subscriber= identities that makes it impossible to black list, because you are effecti= ng the good subscribers service.

&n= bsp;

QUESTION: How will validation/verificati= on work in the case of number portability where a number once assigned to o= ne operator is now assigned to another operator? Has consideration been giv= en to updates through the number portability process in these cases or is t= his a mute point?

 

<= p class=3DMsoNormal>--
3D"Des=
Travis Russell | Technologist, S= r. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167
Oracle<= span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif";color:#66= 6666'> CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North C= arolina 27560

3D"Descrip=

Oracle is committed to = developing practices and products that help protect the environment<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>=

 

--__1386707516829107775abhmp0003.oracle.com Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="image001.gif" Content-ID: R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9AQP/A wP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPVIDfcOQa6A8yR aO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1nBGRmhl8AWiUJYicC AIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4AAunsqg/dw95KwdfBgzB qKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1ItxK7aKl8lCl8DAfALW1+2rUi3 QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyIqRgMcA8a/z5AZQWXOxEdHxwUgfIg sX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjUmYLnomokcDlS4s0eFzQNqvXDEyzmAwFP yaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpFRxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ 9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvP m8OVEkAIYLYPThSsRIpEQJr1x94QBIT09FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8A BijggAQWaOCBCCao4A+CDDbo4IMQRijhhBQKGAIAOw== --__1386707516829107775abhmp0003.oracle.com Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="image002.gif" Content-ID: R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zPuZu2 lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxjSYdrOp/Q6NPg YqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMqDwFCAAIFPIYDgidr OUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQGBH82TpMicD0pAgQACToD AchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLDLS8MAvf497ruCZ+gOA0gfNt3 AIK0J/JWKVzIsEQIADs= --__1386707516829107775abhmp0003.oracle.com-- --__1386707516829107774abhmp0003.oracle.com-- --__1386707516828107773abhmp0003.oracle.com-- From br@brianrosen.net Tue Dec 10 14:24:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0AB1AE218 for ; Tue, 10 Dec 2013 14:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKF5JyZC6sjK for ; Tue, 10 Dec 2013 14:24:46 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7A1AE20B for ; Tue, 10 Dec 2013 14:24:46 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so4379415qcy.26 for ; Tue, 10 Dec 2013 14:24:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=oKo689z8hN0WYxcKx0UH67nnenK9AbtsyksFxR9/j4o=; b=RA0bH02Ine7OBDeVX9dJwU4fvtV7Okj+r76V8hQo1mZ/o+YgT+jDtj1qrl1bYiTYPa ZvpF2Y0nYkWzgAijFjwFp3fqGQkfsBAEvihw3gqZ40177vT6XXw3npRLAfacOyNfbQTL bvS8ODFx4x5snc6LfSIaUTRni5xTVItFTF6tRVZKb8Gpx9nsCTN3auh8OuoLsogZtOHN t4Rk8VDpKSbbOBVow+kcQ/lcYMzXVUXdTnCXgxCmeqyhiYW4rROiXg0ELU34OufQ7AF5 vvMdXkYjIBmOfurgLn+z5z+ALkg7buHYWqWW3kayyDcyxVLG8jNUY9ytQPgfBTBXsr8D 2/VA== X-Gm-Message-State: ALoCoQk0TIlKn90j9Q8sT+LciF04j6AbDRQVMwmddONpZ2hpfnn0gikIheYX0XHPc/bJXKUZsc+F X-Received: by 10.49.1.10 with SMTP id 10mr48128665qei.6.1386714280804; Tue, 10 Dec 2013 14:24:40 -0800 (PST) Received: from [10.33.192.27] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 4sm51048515qak.11.2013.12.10.14.24.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 14:24:39 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EBB91315-6E8B-49C1-A151-177E27A6AD06" From: Brian Rosen X-Priority: 3 In-Reply-To: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> Date: Tue, 10 Dec 2013 17:24:37 -0500 Message-Id: <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> To: Travis Russell X-Mailer: Apple Mail (2.1822) Cc: "stir@ietf.org List" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:24:50 -0000 --Apple-Mail=_EBB91315-6E8B-49C1-A151-177E27A6AD06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The caller name comes from a database queried by the calling telephone = number. Usually, the display name in the SIP message is not used. = That=92s not always true (enterprise internal PBX for example). = Certainly, if you receive the call from a POTS phone, whatever is in the = SIP signaling for display name is not even available to the called party = or her service provider.=20 The conventional implementation is the database is operated by the = calling service provider. The called service provider dips the database = with the calling party TN obtained in the signaling. =20 If you can spoof the calling party number, you can cause the name to be = any name that is already in the database. The fraud management systems you are referring to sound like the ones = inbound systems call centers use to identify fraudulent inbound callers. = I=92m not aware of any service provider attempting to identify = fraudulent callers on behalf of a typical residential or enterprise = customer. We have most certainly considered number portability in this system. = The credentials will change when numbers port. The old credential will = become invalid (or the coverage of the credential will change if the = credential has more than one TN associated with it). A new credential = will be issued, or an existing credential will get another TN associated = with it. We did agree that we could have some delay of this (or, rather, that we = would not attempt to invalidate cacheing of credentials. If, following = a port, the old holder could spoof the call for some minutes, or even = hours, that would probably be okay. Brian On Dec 10, 2013, at 3:31 PM, Travis Russell = wrote: > Looking at the following paragraph: > For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) database. > =20 > It is my experience that spoofing is simply accomplished via VoIP = servers modifying the SIP fields. There are a number of ways this has = been facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 identity. > =20 > I am not familiar with any cases where the spoofed identity was = retrieved from a SNAM server (although I may be wrong in this case). > =20 > In the paragraph immediately after: > For anonymization, the caller does not necessarily care whether the = number is in service, or who it is assigned to, and may switch rapidly = and possibly randomly between numbers. Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist numbers.=20 > =20 > A hacker or fraudster will typically use a =93hit list=94 when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign =93dark numbers=94 in their number ranges = to identify hackers looking for assigned numbers). They will try to use = assigned numbers of legitimate subscribers to alleviate discovery by FMS = or network =93traps=94 where dark numbers are assigned. It is the fact = that they are using legitimate subscriber identities that makes it = impossible to black list, because you are effecting the good subscribers = service. > =20 > QUESTION: How will validation/verification work in the case of number = portability where a number once assigned to one operator is now assigned = to another operator? Has consideration been given to updates through the = number portability process in these cases or is this a mute point? > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_EBB91315-6E8B-49C1-A151-177E27A6AD06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = caller name comes from a database queried by the calling telephone = number.  Usually, the display name in the SIP message is not used. =  That=92s not always true (enterprise internal PBX for example). =  Certainly, if you receive the call from a POTS phone, whatever is = in the SIP signaling for display name is not even available to the = called party or her service provider. 

The = conventional implementation is the database is operated by the calling = service provider.  The called service provider dips the database = with the calling party TN obtained in the signaling. =  

If you can spoof the calling party = number, you can cause the name to be any name that is already in the = database.

The fraud management systems you are = referring to sound like the ones inbound systems call centers use to = identify fraudulent inbound callers.  I=92m not aware of any = service provider attempting to identify fraudulent callers on behalf of = a typical residential or enterprise = customer.

We have most certainly considered = number portability in this system.  The credentials will change = when numbers port.  The old credential will become invalid (or the = coverage of the credential will change if the credential has more than = one TN associated with it).  A new credential will be issued, or an = existing credential will get another TN associated with = it.

We did agree that we could have some delay = of this (or, rather, that we would not attempt to invalidate cacheing of = credentials.  If, following a port, the old holder could spoof the = call for some minutes, or even hours, that would probably be = okay.

Brian


On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com>= ; wrote:

Looking at the = following paragraph:
For = numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the = so-called Calling Name (CNAM) database.
 
It is = my experience that spoofing is simply accomplished via VoIP servers = modifying the SIP fields. There are a number of ways this has been = facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 = identity.
 
I am not = familiar with any cases where the spoofed identity was retrieved from a = SNAM server (although I may be wrong in this case).
 
In the = paragraph immediately after:
For = anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and = possibly randomly between numbers.  Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist = numbers. 
 
A hacker = or fraudster will typically use a =93hit list=94 when doing this, = because fraud management systems look for calls to/from unassigned = numbers (many operators assign =93dark numbers=94 in their number ranges = to identify hackers looking for assigned numbers). They will try to use = assigned numbers of legitimate subscribers to alleviate discovery by FMS = or network =93traps=94 where dark numbers are assigned. It is the fact = that they are using legitimate subscriber identities that makes it = impossible to black list, because you are effecting the good subscribers = service.
 
QUESTION: = How will validation/verification work in the case of number portability = where a number once assigned to one operator is now assigned to another = operator? Has consideration been given to updates through the number = portability process in these cases or is this a mute = point?
 
-- 
<image001.gif>
Travis Russell | Technologist, Sr. = Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU Product = Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to = developing practices and products that help protect the = environment
 
________________________________= _______________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_EBB91315-6E8B-49C1-A151-177E27A6AD06-- From travis.russell@oracle.com Tue Dec 10 14:38:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91531AE242 for ; Tue, 10 Dec 2013 14:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3gYBDzHfGCe for ; Tue, 10 Dec 2013 14:38:34 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 72FA81AE23D for ; Tue, 10 Dec 2013 14:38:34 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBAMcQ2i029263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Dec 2013 22:38:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBAMcQ3K026471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 22:38:26 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBAMcQs4026466; Tue, 10 Dec 2013 22:38:26 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 10 Dec 2013 14:38:23 -0800 (PST) From: Travis Russell Sender: Travis Russell To: Brian Rosen References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> In-Reply-To: <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 14.0.4760.0 (x86)] Content-Type: multipart/mixed; boundary="__1386715105999103305abhmp0002.oracle.com" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org List" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:38:40 -0000 --__1386715105999103305abhmp0002.oracle.com Content-Type: multipart/alternative; boundary="__1386715105999103306abhmp0002.oracle.com" --__1386715105999103306abhmp0002.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks Brian for the clarifications. The FMS I am referring to are the FSM = used by service providers that look for anomalies in subscriber behaviors. = These systems look at behaviors of inbound and outbound callers, and provid= e alarms/flags to the fraud department when there is an anomaly occurring. = One "trick" used by fraud investigators is to assign dark numbers throughou= t their number ranges. When the dark number is hit several times, it indica= tes a hacker trying to create a hit list. There are a number of variations = to this technique but it is common for fraudsters to spend a fair amount of= time honing their hit lists prior to launching an attack.=20 =20 The FMS also looks for short calls, velocity of calls, etc to identify anom= alies, and there are thresholds in the network that fraudsters eventually d= iscover to ensure they "fly under the radar" of these systems. All of that = said to make the point that fraudsters absolutely care about the numbers be= ing legitimate to prevent detection by the many systems put in place by fra= ud departments.=20 =20 In the case of the calling party name, is it thought that the name display = is critical to this process? My understanding is that the number itself is = the critical element, and the name is just a convenience provided to subscr= ibers. There are many errors in the calling name database so personally I d= on't even pay attention to that anymore. The number on the other hand is ab= solutely important. By the way, in wireless communications, the calling par= ty name is driven by the address book on the device itself, and not CNAM.= =20 =20 I mention this because in the problem statement it sounds like the calling = party name is of equal importance to validation as the number.=20 =20 --=20 HYPERLINK "http://www.oracle.com/"Description: Oracle Travis Russell | Technologist, Sr. Mgr Phone: HYPERLINK "tel:+1%209194602172"+1 9194602172 | Mobile: HYPERLINK "te= l:+1%209194121167"+1 9194121167=20 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560=20 HYPERLINK "http://www.oracle.com/commitment"Description: Green Oracle Oracle is committed to developing practices and products that help protect = the environment =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, December 10, 2013 5:25 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? =20 The caller name comes from a database queried by the calling telephone numb= er. Usually, the display name in the SIP message is not used. That's not = always true (enterprise internal PBX for example). Certainly, if you recei= ve the call from a POTS phone, whatever is in the SIP signaling for display= name is not even available to the called party or her service provider.=20 =20 The conventional implementation is the database is operated by the calling = service provider. The called service provider dips the database with the c= alling party TN obtained in the signaling. =20 =20 If you can spoof the calling party number, you can cause the name to be any= name that is already in the database. =20 The fraud management systems you are referring to sound like the ones inbou= nd systems call centers use to identify fraudulent inbound callers. I'm no= t aware of any service provider attempting to identify fraudulent callers o= n behalf of a typical residential or enterprise customer. =20 We have most certainly considered number portability in this system. The c= redentials will change when numbers port. The old credential will become i= nvalid (or the coverage of the credential will change if the credential has= more than one TN associated with it). A new credential will be issued, or= an existing credential will get another TN associated with it. =20 We did agree that we could have some delay of this (or, rather, that we wou= ld not attempt to invalidate cacheing of credentials. If, following a port= , the old holder could spoof the call for some minutes, or even hours, that= would probably be okay. =20 Brian =20 =20 On Dec 10, 2013, at 3:31 PM, Travis Russell wrote: Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the so-= called Calling Name (CNAM) database. =20 It is my experience that spoofing is simply accomplished via VoIP servers m= odifying the SIP fields. There are a number of ways this has been facilitat= ed - you can call a spoof service where the call is terminated on a VoIP se= rver, and when prompted enter the telephone number you want to appear as th= e calling party (works great - I have tried this myself). The VoIP server t= han re-originates the call and sends it to the called party with the new "s= poofed" identity. =20 I am not familiar with any cases where the spoofed identity was retrieved f= rom a SNAM server (although I may be wrong in this case). =20 In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and possibl= y randomly between numbers. Anonymization facilitates automated illegal te= lemarketing or telephony denial-of-service attacks, as described above, as = it makes it difficult to blacklist numbers.=20 =20 A hacker or fraudster will typically use a "hit list" when doing this, beca= use fraud management systems look for calls to/from unassigned numbers (man= y operators assign "dark numbers" in their number ranges to identify hacker= s looking for assigned numbers). They will try to use assigned numbers of l= egitimate subscribers to alleviate discovery by FMS or network "traps" wher= e dark numbers are assigned. It is the fact that they are using legitimate = subscriber identities that makes it impossible to black list, because you a= re effecting the good subscribers service. =20 QUESTION: How will validation/verification work in the case of number porta= bility where a number once assigned to one operator is now assigned to anot= her operator? Has consideration been given to updates through the number po= rtability process in these cases or is this a mute point? =20 --=20 HYPERLINK "http://www.oracle.com/" Travis Russell | Technologist, Sr. Mgr Phone: HYPERLINK "tel:+1%209194602172"+1 9194602172 | Mobile: HYPERLINK "te= l:+1%209194121167"+1 9194121167=20 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 HYPERLINK "http://www.oracle.com/commitment" Oracle is committed to developing practices and products that help protect = the environment =20 _______________________________________________ stir mailing list HYPERLINK "mailto:stir@ietf.org"stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 --__1386715105999103306abhmp0002.oracle.com Content-Type: multipart/related; boundary="__1386715106000103307abhmp0002.oracle.com" --__1386715106000103307abhmp0002.oracle.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Thanks Br= ian for the clarifications. The FMS I am referring to are the FSM used by s= ervice providers that look for anomalies in subscriber behaviors. These sys= tems look at behaviors of inbound and outbound callers, and provide alarms/= flags to the fraud department when there is an anomaly occurring. One ̶= 0;trick” used by fraud investigators is to assign dark numbers throug= hout their number ranges. When the dark number is hit several times, it ind= icates a hacker trying to create a hit list. There are a number of variatio= ns to this technique but it is common for fraudsters to spend a fair amount= of time honing their hit lists prior to launching an attack.

 

The FMS also looks for short calls, velocity of calls, = etc to identify anomalies, and there are thresholds in the network that fra= udsters eventually discover to ensure they “fly under the radar”= ; of these systems. All of that said to make the point that fraudsters abso= lutely care about the numbers being legitimate to prevent detection by the = many systems put in place by fraud departments.

 

In the case of the calling party name, is it thought that the name disp= lay is critical to this process? My understanding is that the number itself= is the critical element, and the name is just a convenience provided to su= bscribers. There are many errors in the calling name database so personally= I don’t even pay attention to that anymore. The number on the other = hand is absolutely important. By the way, in wireless communications, the c= alling party name is driven by the address book on the device itself, and n= ot CNAM.

 

I mention this because in the probl= em statement it sounds like the calling party name is of equal importance t= o validation as the number.

 

--
3D"Description:
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1= 9194121167
Oracle CGBU Product Mark= eting
5200 Paramount Pkwy | Morrisville, North Carolina 27560

3D"Description:

Oracle is committed to developing = practices and products that help protect the environment

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday= , December 10, 2013 5:25 PM
To: Travis Russell
Cc: stir= @ietf.org List
Subject: Re: [stir] Comments/Queries?

 

The caller name comes from a database queried by the calling telep= hone number.  Usually, the display name in the SIP message is not used= .  That’s not always true (enterprise internal PBX for example).=  Certainly, if you receive the call from a POTS phone, whatever is in= the SIP signaling for display name is not even available to the called par= ty or her service provider. 

<= o:p> 

The conventional implem= entation is the database is operated by the calling service provider.  = ;The called service provider dips the database with the calling party TN ob= tained in the signaling.  

 

If you can spoof th= e calling party number, you can cause the name to be any name that is alrea= dy in the database.

&nbs= p;

The fraud management systems yo= u are referring to sound like the ones inbound systems call centers use to = identify fraudulent inbound callers.  I’m not aware of any servi= ce provider attempting to identify fraudulent callers on behalf of a typica= l residential or enterprise customer.

 

We have most = certainly considered number portability in this system.  The credentia= ls will change when numbers port.  The old credential will become inva= lid (or the coverage of the credential will change if the credential has mo= re than one TN associated with it).  A new credential will be issued, = or an existing credential will get another TN associated with it.

 

We did agree that we could have some delay of this (or, rath= er, that we would not attempt to invalidate cacheing of credentials.  = If, following a port, the old holder could spoof the call for some minutes,= or even hours, that would probably be okay.

 

Brian<= o:p>

 

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> wrote:

<= /div>



Lo= oking at the following paragraph:

For numbers where the caller has suppressed textual caller identifica= tion, number spoofing can be used to retrieve this information, stored in t= he so-called Calling Name (CNAM) database.

=

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>It is my= experience that spoofing is simply accomplished via VoIP servers modifying= the SIP fields. There are a number of ways this has been facilitated ̵= 1; you can call a spoof service where the call is terminated on a VoIP serv= er, and when prompted enter the telephone number you want to appear as the = calling party (works great – I have tried this myself). The VoIP serv= er than re-originates the call and sends it to the called party with the ne= w “spoofed” identity.

 

I am not familia= r with any cases where the spoofed identity was retrieved from a SNAM serve= r (although I may be wrong in this case).

<= p class=3DMsoNormal> 

In the pa= ragraph immediately after:

Fo= r anonymization, the caller does not necessarily care whether the number is= in service, or who it is assigned to, and may switch rapidly and possibly = randomly between numbers.  Anonymization facilitates automated illegal= telemarketing or telephony denial-of-service attacks, as described above, = as it makes it difficult to blacklist numbers. 

<= /div>

 

A hacker or fraudster will typically use a “hit list” when do= ing this, because fraud management systems look for calls to/from unassigne= d numbers (many operators assign “dark numbers” in their number= ranges to identify hackers looking for assigned numbers). They will try to= use assigned numbers of legitimate subscribers to alleviate discovery by F= MS or network “traps” where dark numbers are assigned. It is th= e fact that they are using legitimate subscriber identities that makes it i= mpossible to black list, because you are effecting the good subscribers ser= vice.

 

QUESTION: How will validation/verification wo= rk in the case of number portability where a number once assigned to one op= erator is now assigned to another operator? Has consideration been given to= updates through the number portability process in these cases or is this a= mute point?

 

-- 
<image001.gif>
T= ravis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle<= span class=3Dapple-converted-space> CGBU= Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 275= 60

 

_____= __________________________________________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir

 

--__1386715106000103307abhmp0002.oracle.com Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="image001.gif" Content-ID: R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9AQP/A wP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPVIDfcOQa6A8yR aO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1nBGRmhl8AWiUJYicC AIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4AAunsqg/dw95KwdfBgzB qKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1ItxK7aKl8lCl8DAfALW1+2rUi3 QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyIqRgMcA8a/z5AZQWXOxEdHxwUgfIg sX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjUmYLnomokcDlS4s0eFzQNqvXDEyzmAwFP yaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpFRxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ 9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvP m8OVEkAIYLYPThSsRIpEQJr1x94QBIT09FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8A BijggAQWaOCBCCao4A+CDDbo4IMQRijhhBQKGAIAOw== --__1386715106000103307abhmp0002.oracle.com Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="image002.gif" Content-ID: R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zPuZu2 lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxjSYdrOp/Q6NPg YqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMqDwFCAAIFPIYDgidr OUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQGBH82TpMicD0pAgQACToD AchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLDLS8MAvf497ruCZ+gOA0gfNt3 AIK0J/JWKVzIsEQIADs= --__1386715106000103307abhmp0002.oracle.com-- --__1386715105999103306abhmp0002.oracle.com-- --__1386715105999103305abhmp0002.oracle.com-- From br@brianrosen.net Tue Dec 10 14:46:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06B21AE154 for ; Tue, 10 Dec 2013 14:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH2nTtSoXD0K for ; Tue, 10 Dec 2013 14:46:07 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 651301AE0F3 for ; Tue, 10 Dec 2013 14:46:07 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so4528031qcy.12 for ; Tue, 10 Dec 2013 14:46:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=N1nHi8yaHcii8DseAs9JYDDF0kg1YgMWTLZu0hATJNE=; b=LqGXixW259gmLgLoSjmuNvvmwlkmRcaipoYOuui24i1A6Ievqj8bdD3el/tK40zLC6 ihcCECM6qLRBRkx1+I1c35rgYmWJe0L9JlXcWVcM8oWkJ1oT0VHb6aNg6Y3JvZMw6Ig0 3Spmb7LsiTMm/3cZEAQiwdBfQ4Uwu8MH3LAB7JDNnP9FHUtJL5PCFP/1XtjrNEVo7okx UpcDX4Ko82ykU/AfofeYVQ8+iDRnjhMoofhl1RB+SvQoBlLnslBoPpvfBcNHHyUp/KwV sxrFaypc12ROdldt5rdCKLLybDXBPGihr+/MtmCMDMpkkvIZl6YmH3h01S4NSbSpYs+E WSGQ== X-Gm-Message-State: ALoCoQkK23KP03E8Ql7AOdVqXtilNZ6+bFaW0EZ1ThvAxVvDG8SyF3XfE6+miZBb5uGxrwxTlJdJ X-Received: by 10.224.39.15 with SMTP id d15mr48895011qae.36.1386715561828; Tue, 10 Dec 2013 14:46:01 -0800 (PST) Received: from [10.33.192.27] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id lc1sm746026qeb.5.2013.12.10.14.46.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 14:46:01 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5B4E9C0D-3ECA-46AC-92F3-1C435B9A0955" From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 10 Dec 2013 17:45:58 -0500 Message-Id: References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> To: Travis Russell X-Mailer: Apple Mail (2.1822) Cc: "stir@ietf.org List" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:46:11 -0000 --Apple-Mail=_5B4E9C0D-3ECA-46AC-92F3-1C435B9A0955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What users look at for numbers they have not memorized is name. They = can=92t tell anything from the number. In the IETF work, we have split name and number. We=92ll come up with = the number solution first, and then work on name. The name discussions = are on a separate list (cnit). Most of the bad calls we see are from what I usually call =93pink=94 = service providers. They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number. They don=92t run = FMS systems. I am told that wholesale divisions of major carriers = sometimes are the unwitting origination carrier, because there are many = instances of permitted =93spoofing=94 (call centers calling on behalf of = another enterprise for example) which means they don=92t scrutinize = calling party number on the wholesale side. However, the majority of = the bad calls come from these =93pink=94 carriers. =20 We all agree we need to get the number reliable first. Brian On Dec 10, 2013, at 5:38 PM, Travis Russell = wrote: > Thanks Brian for the clarifications. The FMS I am referring to are the = FSM used by service providers that look for anomalies in subscriber = behaviors. These systems look at behaviors of inbound and outbound = callers, and provide alarms/flags to the fraud department when there is = an anomaly occurring. One =93trick=94 used by fraud investigators is to = assign dark numbers throughout their number ranges. When the dark number = is hit several times, it indicates a hacker trying to create a hit list. = There are a number of variations to this technique but it is common for = fraudsters to spend a fair amount of time honing their hit lists prior = to launching an attack. > =20 > The FMS also looks for short calls, velocity of calls, etc to identify = anomalies, and there are thresholds in the network that fraudsters = eventually discover to ensure they =93fly under the radar=94 of these = systems. All of that said to make the point that fraudsters absolutely = care about the numbers being legitimate to prevent detection by the many = systems put in place by fraud departments. > =20 > In the case of the calling party name, is it thought that the name = display is critical to this process? My understanding is that the number = itself is the critical element, and the name is just a convenience = provided to subscribers. There are many errors in the calling name = database so personally I don=92t even pay attention to that anymore. The = number on the other hand is absolutely important. By the way, in = wireless communications, the calling party name is driven by the address = book on the device itself, and not CNAM. > =20 > I mention this because in the problem statement it sounds like the = calling party name is of equal importance to validation as the number. > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:25 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > The caller name comes from a database queried by the calling telephone = number. Usually, the display name in the SIP message is not used. = That=92s not always true (enterprise internal PBX for example). = Certainly, if you receive the call from a POTS phone, whatever is in the = SIP signaling for display name is not even available to the called party = or her service provider.=20 > =20 > The conventional implementation is the database is operated by the = calling service provider. The called service provider dips the database = with the calling party TN obtained in the signaling. =20 > =20 > If you can spoof the calling party number, you can cause the name to = be any name that is already in the database. > =20 > The fraud management systems you are referring to sound like the ones = inbound systems call centers use to identify fraudulent inbound callers. = I=92m not aware of any service provider attempting to identify = fraudulent callers on behalf of a typical residential or enterprise = customer. > =20 > We have most certainly considered number portability in this system. = The credentials will change when numbers port. The old credential will = become invalid (or the coverage of the credential will change if the = credential has more than one TN associated with it). A new credential = will be issued, or an existing credential will get another TN associated = with it. > =20 > We did agree that we could have some delay of this (or, rather, that = we would not attempt to invalidate cacheing of credentials. If, = following a port, the old holder could spoof the call for some minutes, = or even hours, that would probably be okay. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 3:31 PM, Travis Russell = wrote: >=20 >=20 > Looking at the following paragraph: > For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) database. > =20 > It is my experience that spoofing is simply accomplished via VoIP = servers modifying the SIP fields. There are a number of ways this has = been facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 identity. > =20 > I am not familiar with any cases where the spoofed identity was = retrieved from a SNAM server (although I may be wrong in this case). > =20 > In the paragraph immediately after: > For anonymization, the caller does not necessarily care whether the = number is in service, or who it is assigned to, and may switch rapidly = and possibly randomly between numbers. Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist numbers.=20 > =20 > A hacker or fraudster will typically use a =93hit list=94 when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign =93dark numbers=94 in their number ranges = to identify hackers looking for assigned numbers). They will try to use = assigned numbers of legitimate subscribers to alleviate discovery by FMS = or network =93traps=94 where dark numbers are assigned. It is the fact = that they are using legitimate subscriber identities that makes it = impossible to black list, because you are effecting the good subscribers = service. > =20 > QUESTION: How will validation/verification work in the case of number = portability where a number once assigned to one operator is now assigned = to another operator? Has consideration been given to updates through the = number portability process in these cases or is this a mute point? > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_5B4E9C0D-3ECA-46AC-92F3-1C435B9A0955 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 What = users look at for numbers they have not memorized is name.  They = can=92t tell anything from the number.

In the IETF = work, we have split  name and number.  We=92ll come up with = the number solution first, and then work on name.  The name = discussions are on a separate list (cnit).

Most = of the bad calls we see are from what I usually call =93pink=94 service = providers.  They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number.  They don=92t = run FMS systems.  I am told that wholesale divisions of major = carriers sometimes are the unwitting origination carrier, because there = are many instances of permitted =93spoofing=94 (call centers calling on = behalf of another enterprise for example) which means they don=92t = scrutinize calling party number on the wholesale side.  However, = the majority of the bad calls come from these =93pink=94 carriers. =  

We all agree we need to get the number = reliable = first.

Brian


On Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com>= ; wrote:

Thanks Brian for the clarifications. The FMS I am = referring to are the FSM used by service providers that look for = anomalies in subscriber behaviors. These systems look at behaviors of = inbound and outbound callers, and provide alarms/flags to the fraud = department when there is an anomaly occurring. One =93trick=94 used by = fraud investigators is to assign dark numbers throughout their number = ranges. When the dark number is hit several times, it indicates a hacker = trying to create a hit list. There are a number of variations to this = technique but it is common for fraudsters to spend a fair amount of time = honing their hit lists prior to launching an = attack.
 
The FMS also looks for short calls, velocity of = calls, etc to identify anomalies, and there are thresholds in the = network that fraudsters eventually discover to ensure they =93fly under = the radar=94 of these systems. All of that said to make the point that = fraudsters absolutely care about the numbers being legitimate to prevent = detection by the many systems put in place by fraud = departments.
 
In the case of the calling party name, is it thought = that the name display is critical to this process? My understanding is = that the number itself is the critical element, and the name is just a = convenience provided to subscribers. There are many errors in the = calling name database so personally I don=92t even pay attention to that = anymore. The number on the other hand is absolutely important. By the = way, in wireless communications, the calling party name is driven by the = address book on the device itself, and not = CNAM.
 
I mention this because in the problem statement it = sounds like the calling party name is of equal importance to validation = as the number.
 
-- 
<image001.gif>
Travis Russell | Technologist, = Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU Product = Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560

Oracle is committed to developing practices and products th= at help protect the environment

Oracle is committed to developing practices and = products that help protect the environment
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:25 PM
To: Travis = Russell
Cc: stir@ietf.org = List
Subject: Re: [stir] = Comments/Queries?
 
The caller name = comes from a database queried by the calling telephone number. =  Usually, the display name in the SIP message is not used. =  That=92s not always true (enterprise internal PBX for example). =  Certainly, if you receive the call from a POTS phone, whatever is = in the SIP signaling for display name is not even available to the = called party or her service provider. 
 
The conventional implementation is the database is = operated by the calling service provider.  The called service = provider dips the database with the calling party TN obtained in the = signaling.  
 
If = you can spoof the calling party number, you can cause the name to be any = name that is already in the database.
 
The fraud management systems you are referring to = sound like the ones inbound systems call centers use to identify = fraudulent inbound callers.  I=92m not aware of any service = provider attempting to identify fraudulent callers on behalf of a = typical residential or enterprise = customer.
 
We = have most certainly considered number portability in this system. =  The credentials will change when numbers port.  The old = credential will become invalid (or the coverage of the credential will = change if the credential has more than one TN associated with it). =  A new credential will be issued, or an existing credential will = get another TN associated with it.
 
We did agree that we could have some delay of this = (or, rather, that we would not attempt to invalidate cacheing of = credentials.  If, following a port, the old holder could spoof the = call for some minutes, or even hours, that would probably be = okay.
 
Brian
 
 
On = Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> = wrote:


Looking at = the following paragraph:
For numbers where the caller has suppressed = textual caller identification, number spoofing can be used to retrieve = this information, stored in the so-called Calling Name (CNAM) = database.
 
It is my experience that spoofing is simply = accomplished via VoIP servers modifying the SIP fields. There are a = number of ways this has been facilitated =96 you can call a spoof = service where the call is terminated on a VoIP server, and when prompted = enter the telephone number you want to appear as the calling party = (works great =96 I have tried this myself). The VoIP server than = re-originates the call and sends it to the called party with the new = =93spoofed=94 identity.
 
I am not familiar with any cases where the spoofed = identity was retrieved from a SNAM server (although I may be wrong in = this case).
 
In the paragraph immediately = after:
For = anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and = possibly randomly between numbers.  Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist = numbers. 
 
A hacker or fraudster will typically use a =93hit = list=94 when doing this, because fraud management systems look for calls = to/from unassigned numbers (many operators assign =93dark numbers=94 in = their number ranges to identify hackers looking for assigned numbers). = They will try to use assigned numbers of legitimate subscribers to = alleviate discovery by FMS or network =93traps=94 where dark numbers are = assigned. It is the fact that they are using legitimate subscriber = identities that makes it impossible to black list, because you are = effecting the good subscribers = service.
 
QUESTION: How will validation/verification work in = the case of number portability where a number once assigned to one = operator is now assigned to another operator? Has consideration been = given to updates through the number portability process in these cases = or is this a mute point?
 
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the environment
 
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_5B4E9C0D-3ECA-46AC-92F3-1C435B9A0955-- From jcronin@egh.com Tue Dec 10 18:36:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9622B1ADFD7 for ; Tue, 10 Dec 2013 18:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.617 X-Spam-Level: X-Spam-Status: No, score=0.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q5-OtvS2SIr for ; Tue, 10 Dec 2013 18:36:09 -0800 (PST) Received: from mia.egh.com (50-79-181-89-static.hfc.comcastbusiness.net [50.79.181.89]) by ietfa.amsl.com (Postfix) with ESMTP id 995181AE0EF for ; Tue, 10 Dec 2013 18:36:08 -0800 (PST) Received: from jojo.egh.com (Jojo.egh.com [198.179.132.13]) by mia.egh.com (8.14.5/8.14.5/SuSE Linux 0.8) with ESMTP id rBB2a2VF026097 for ; Tue, 10 Dec 2013 21:36:02 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_21728CF2-A804-4432-8B14-33A5C33EE8F3" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Jonathan Cronin X-Priority: 3 In-Reply-To: Date: Tue, 10 Dec 2013 21:36:02 -0500 Message-Id: <0D3FF8C5-2946-4B73-A358-E9CABC898E41@egh.com> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> To: "stir@ietf.org List" X-Mailer: Apple Mail (2.1822) Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 02:36:12 -0000 --Apple-Mail=_21728CF2-A804-4432-8B14-33A5C33EE8F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 10, 2013, at 5:45 PM, Brian Rosen wrote: > What users look at for numbers they have not memorized is name. They = can=92t tell anything from the number. ... > We all agree we need to get the number reliable first. Let me second this. If the end user can get authenticated reliable = caller identification (which may require more than name) they don=92t care about the calling number. But that=92s for the = future. Jonathan Jonathan Cronin jtcegh@gmail.com 781 861 0670 EGH, Inc. 55 Waltham Street Lexington, MA 02421 --Apple-Mail=_21728CF2-A804-4432-8B14-33A5C33EE8F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 10, 2013, at 5:45 PM, Brian = Rosen <br@brianrosen.net> = wrote:

What users look at for = numbers they have not memorized is name.  They can=92t tell = anything from the = number.

...
We all agree we need to get the number reliable = first.

Let me second this. =  If the end user can get authenticated reliable caller = identification (which may require more than name)
they don=92t = care about the calling number.  But that=92s for the = future.

Jonathan

=

Jonathan Cronin
jtcegh@gmail.com
781 861 = 0670

EGH, Inc.
55 Waltham Street
Lexington, MA = 02421

= --Apple-Mail=_21728CF2-A804-4432-8B14-33A5C33EE8F3-- From travis.russell@oracle.com Wed Dec 11 03:50:42 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C41A1ACC87 for ; Wed, 11 Dec 2013 03:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te7e1Xegdqco for ; Wed, 11 Dec 2013 03:50:37 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25B071AC7EE for ; Wed, 11 Dec 2013 03:50:37 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBBBoSqT001504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 11:50:29 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBBoPJ8009870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 11:50:26 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBBoPoH009858; Wed, 11 Dec 2013 11:50:25 GMT MIME-Version: 1.0 Message-ID: <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> Date: Wed, 11 Dec 2013 03:50:22 -0800 (PST) From: Travis Russell Sender: Travis Russell To: Brian Rosen References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 14.0.4760.0 (x86)] Content-Type: multipart/mixed; boundary="__1386762625403121579abhmp0003.oracle.com" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org List" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:50:42 -0000 --__1386762625403121579abhmp0003.oracle.com Content-Type: multipart/alternative; boundary="__1386762625404121580abhmp0003.oracle.com" --__1386762625404121580abhmp0003.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks Brian, =20 Agreed. But remember most of us use our cell phones these days, and the nam= e comes from your address book based on number.=20 =20 Calling name will be a challenge since the service providers providing CNAM= services to the operators are challenged to get the names right. And if yo= u send a correction to your own name it sometimes does not get fixed perman= ently as the next bulk load reverts back to the old files.=20 =20 I like the label of "pink" service providers. There are also those that off= er spoofing as a service. You call a freephone number, your call is termina= ted on the VoIP switch where you are asked for the number you want to appea= r, and the call re-originated. These come through as legitimate calls to th= e major service providers, and when tracing the call you can only trace as = far back as the spoofing service. Perfectly legitimate companies by the way= , as there is nothing illegal about spoofing your number.=20 =20 I only provide all this info because it is important for all of us to under= stand the problem and how it manifests itself within service provider netwo= rks. --=20 HYPERLINK "http://www.oracle.com/"Description: Oracle Travis Russell | Technologist, Sr. Mgr Phone: HYPERLINK "tel:+1%209194602172"+1 9194602172 | Mobile: HYPERLINK "te= l:+1%209194121167"+1 9194121167=20 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560=20 HYPERLINK "http://www.oracle.com/commitment"Description: Green Oracle Oracle is committed to developing practices and products that help protect = the environment =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, December 10, 2013 5:46 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? =20 What users look at for numbers they have not memorized is name. They can't= tell anything from the number. =20 In the IETF work, we have split name and number. We'll come up with the n= umber solution first, and then work on name. The name discussions are on a= separate list (cnit). =20 Most of the bad calls we see are from what I usually call "pink" service pr= oviders. They aren't actually complicit, but they look the other way as th= eir subscribers spoof name and number. They don't run FMS systems. I am t= old that wholesale divisions of major carriers sometimes are the unwitting = origination carrier, because there are many instances of permitted "spoofin= g" (call centers calling on behalf of another enterprise for example) which= means they don't scrutinize calling party number on the wholesale side. H= owever, the majority of the bad calls come from these "pink" carriers. =20 =20 We all agree we need to get the number reliable first. =20 Brian =20 =20 On Dec 10, 2013, at 5:38 PM, Travis Russell wrote: Thanks Brian for the clarifications. The FMS I am referring to are the FSM = used by service providers that look for anomalies in subscriber behaviors. = These systems look at behaviors of inbound and outbound callers, and provid= e alarms/flags to the fraud department when there is an anomaly occurring. = One "trick" used by fraud investigators is to assign dark numbers throughou= t their number ranges. When the dark number is hit several times, it indica= tes a hacker trying to create a hit list. There are a number of variations = to this technique but it is common for fraudsters to spend a fair amount of= time honing their hit lists prior to launching an attack. =20 The FMS also looks for short calls, velocity of calls, etc to identify anom= alies, and there are thresholds in the network that fraudsters eventually d= iscover to ensure they "fly under the radar" of these systems. All of that = said to make the point that fraudsters absolutely care about the numbers be= ing legitimate to prevent detection by the many systems put in place by fra= ud departments. =20 In the case of the calling party name, is it thought that the name display = is critical to this process? My understanding is that the number itself is = the critical element, and the name is just a convenience provided to subscr= ibers. There are many errors in the calling name database so personally I d= on't even pay attention to that anymore. The number on the other hand is ab= solutely important. By the way, in wireless communications, the calling par= ty name is driven by the address book on the device itself, and not CNAM. =20 I mention this because in the problem statement it sounds like the calling = party name is of equal importance to validation as the number. =20 --=20 HYPERLINK "http://www.oracle.com/" Travis Russell | Technologist, Sr. Mgr Phone: HYPERLINK "tel:+1%209194602172"+1 9194602172 | Mobile: HYPERLINK "te= l:+1%209194121167"+1 9194121167=20 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 HYPERLINK "http://www.oracle.com/commitment" Oracle is committed to developing practices and products that help protect = the environment =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, December 10, 2013 5:25 PM To: Travis Russell Cc: HYPERLINK "mailto:stir@ietf.org"stir@ietf.org List Subject: Re: [stir] Comments/Queries? =20 The caller name comes from a database queried by the calling telephone numb= er. Usually, the display name in the SIP message is not used. That's not = always true (enterprise internal PBX for example). Certainly, if you recei= ve the call from a POTS phone, whatever is in the SIP signaling for display= name is not even available to the called party or her service provider.=20 =20 The conventional implementation is the database is operated by the calling = service provider. The called service provider dips the database with the c= alling party TN obtained in the signaling. =20 =20 If you can spoof the calling party number, you can cause the name to be any= name that is already in the database. =20 The fraud management systems you are referring to sound like the ones inbou= nd systems call centers use to identify fraudulent inbound callers. I'm no= t aware of any service provider attempting to identify fraudulent callers o= n behalf of a typical residential or enterprise customer. =20 We have most certainly considered number portability in this system. The c= redentials will change when numbers port. The old credential will become i= nvalid (or the coverage of the credential will change if the credential has= more than one TN associated with it). A new credential will be issued, or= an existing credential will get another TN associated with it. =20 We did agree that we could have some delay of this (or, rather, that we wou= ld not attempt to invalidate cacheing of credentials. If, following a port= , the old holder could spoof the call for some minutes, or even hours, that= would probably be okay. =20 Brian =20 =20 On Dec 10, 2013, at 3:31 PM, Travis Russell wrote: Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the so-= called Calling Name (CNAM) database. =20 It is my experience that spoofing is simply accomplished via VoIP servers m= odifying the SIP fields. There are a number of ways this has been facilitat= ed - you can call a spoof service where the call is terminated on a VoIP se= rver, and when prompted enter the telephone number you want to appear as th= e calling party (works great - I have tried this myself). The VoIP server t= han re-originates the call and sends it to the called party with the new "s= poofed" identity. =20 I am not familiar with any cases where the spoofed identity was retrieved f= rom a SNAM server (although I may be wrong in this case). =20 In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and possibl= y randomly between numbers. Anonymization facilitates automated illegal te= lemarketing or telephony denial-of-service attacks, as described above, as = it makes it difficult to blacklist numbers.=20 =20 A hacker or fraudster will typically use a "hit list" when doing this, beca= use fraud management systems look for calls to/from unassigned numbers (man= y operators assign "dark numbers" in their number ranges to identify hacker= s looking for assigned numbers). They will try to use assigned numbers of l= egitimate subscribers to alleviate discovery by FMS or network "traps" wher= e dark numbers are assigned. It is the fact that they are using legitimate = subscriber identities that makes it impossible to black list, because you a= re effecting the good subscribers service. =20 QUESTION: How will validation/verification work in the case of number porta= bility where a number once assigned to one operator is now assigned to anot= her operator? Has consideration been given to updates through the number po= rtability process in these cases or is this a mute point? =20 --=20 HYPERLINK "http://www.oracle.com/" Travis Russell | Technologist, Sr. Mgr Phone: HYPERLINK "tel:+1%209194602172"+1 9194602172 | Mobile: HYPERLINK "te= l:+1%209194121167"+1 9194121167=20 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 HYPERLINK "http://www.oracle.com/commitment" Oracle is committed to developing practices and products that help protect = the environment =20 _______________________________________________ stir mailing list HYPERLINK "mailto:stir@ietf.org"stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 --__1386762625404121580abhmp0003.oracle.com Content-Type: multipart/related; boundary="__1386762625404121581abhmp0003.oracle.com" --__1386762625404121581abhmp0003.oracle.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Thanks Br= ian,

 

Agreed. But remember most of us use our = cell phones these days, and the name comes from your address book based on = number.

 =

Calling name will be a challenge sin= ce the service providers providing CNAM services to the operators are chall= enged to get the names right. And if you send a correction to your own name= it sometimes does not get fixed permanently as the next bulk load reverts = back to the old files.

 

I like the label of &= #8220;pink” service providers. There are also those that offer spoofi= ng as a service. You call a freephone number, your call is terminated on th= e VoIP switch where you are asked for the number you want to appear, and th= e call re-originated. These come through as legitimate calls to the major s= ervice providers, and when tracing the call you can only trace as far back = as the spoofing service. Perfectly legitimate companies by the way, as ther= e is nothing illegal about spoofing your number.

 

I only provide all this info because it is important for all of us to = understand the problem and how it manifests itself within service provider = networks.

--
3D"Description:
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1= 9194121167
Oracle CGBU Product Mark= eting
5200 Paramount Pkwy | Morrisville, North Carolina 27560

3D"Description:

Oracle is committed to developing = practices and products that help protect the environment

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday= , December 10, 2013 5:46 PM
To: Travis Russell
Cc: stir= @ietf.org List
Subject: Re: [stir] Comments/Queries?

 

What users look at for numbers they have not memorized is name. &n= bsp;They can’t tell anything from the number.

 

In th= e IETF work, we have split  name and number.  We’ll come up= with the number solution first, and then work on name.  The name disc= ussions are on a separate list (cnit).

 

Most of the = bad calls we see are from what I usually call “pink” service pr= oviders.  They aren’t actually complicit, but they look the othe= r way as their subscribers spoof name and number.  They don’t ru= n FMS systems.  I am told that wholesale divisions of major carriers s= ometimes are the unwitting origination carrier, because there are many inst= ances of permitted “spoofing” (call centers calling on behalf o= f another enterprise for example) which means they don’t scrutinize c= alling party number on the wholesale side.  However, the majority of t= he bad calls come from these “pink” carriers.  =

 

We all agree we need to get the number reliable first.

 

Brian

=  

 

<= div>

On Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com>= ; wrote:



Thanks Brian for the clarifications. Th= e FMS I am referring to are the FSM used by service providers that look for= anomalies in subscriber behaviors. These systems look at behaviors of inbo= und and outbound callers, and provide alarms/flags to the fraud department = when there is an anomaly occurring. One “trick” used by fraud i= nvestigators is to assign dark numbers throughout their number ranges. When= the dark number is hit several times, it indicates a hacker trying to crea= te a hit list. There are a number of variations to this technique but it is= common for fraudsters to spend a fair amount of time honing their hit list= s prior to launching an attack.

 

The FMS also looks for short calls, velocity of calls, etc to iden= tify anomalies, and there are thresholds in the network that fraudsters eve= ntually discover to ensure they “fly under the radar” of these = systems. All of that said to make the point that fraudsters absolutely care= about the numbers being legitimate to prevent detection by the many system= s put in place by fraud departments.

 

In the case of the calling party name, is it thought that the= name display is critical to this process? My understanding is that the num= ber itself is the critical element, and the name is just a convenience prov= ided to subscribers. There are many errors in the calling name database so = personally I don’t even pay attention to that anymore. The number on = the other hand is absolutely important. By the way, in wireless communicati= ons, the calling party name is driven by the address book on the device its= elf, and not CNAM.

 

I me= ntion this because in the problem statement it sounds like the calling part= y name is of equal importance to validation as the number.

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: <= a href=3D"tel:+1%209194121167">+1 9194121167 
Ora= cle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Car= olina 27560

<image002.= gif>

Oracle is committed to devel= oping practices and products that help protect the environment<= /o:p>

&nb= sp;

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 5:25 PM
To: Travis Russell
Cc: st= ir@ietf.org List
Subject:=  Re: [stir] Comments/Queries?

=

 

The caller name comes from a database queried by the calling tele= phone number.  Usually, the display name in the SIP message is not use= d.  That’s not always true (enterprise internal PBX for example)= .  Certainly, if you receive the call from a POTS phone, whatever is i= n the SIP signaling for display name is not even available to the called pa= rty or her service provider. 

 

The conventional implementation is the database is operated by the callin= g service provider.  The called service provider dips the database wit= h the calling party TN obtained in the signaling.  

 

If you can spoof the calling party number, you = can cause the name to be any name that is already in the database.

 

The fraud management systems you are = referring to sound like the ones inbound systems call centers use to identi= fy fraudulent inbound callers.  I’m not aware of any service pro= vider attempting to identify fraudulent callers on behalf of a typical resi= dential or enterprise customer.

 

We have most certainly considered number portability in this system. &nb= sp;The credentials will change when numbers port.  The old credential = will become invalid (or the coverage of the credential will change if the c= redential has more than one TN associated with it).  A new credential = will be issued, or an existing credential will get another TN associated wi= th it.

 =

We did agree that we c= ould have some delay of this (or, rather, that we would not attempt to inva= lidate cacheing of credentials.  If, following a port, the old holder = could spoof the call for some minutes, or even hours, that would probably b= e okay.

 

Brian

<= /div>

 

=

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.r= ussell@oracle.com> wrote:




Looking at the following paragraph:

=

For numbers where the caller has suppressed textual= caller identification, number spoofing can be used to retrieve this inform= ation, stored in the so-called Calling Name (CNAM) database.

 

It is my experience that spoofing is simply= accomplished via VoIP servers modifying the SIP fields. There are a number= of ways this has been facilitated – you can call a spoof service whe= re the call is terminated on a VoIP server, and when prompted enter the tel= ephone number you want to appear as the calling party (works great – = I have tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new “spoofed” identity.

 =

I am not familiar with any ca= ses where the spoofed identity was retrieved from a SNAM server (although I= may be wrong in this case).

 

= In the paragraph immediately after:

<= div>

For anonymization, the caller does not necessarily care w= hether the number is in service, or who it is assigned to, and may switch r= apidly and possibly randomly between numbers.  Anonymization facilitat= es automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist numbers. 

 =

A hacker or fraudster will ty= pically use a “hit list” when doing this, because fraud managem= ent systems look for calls to/from unassigned numbers (many operators assig= n “dark numbers” in their number ranges to identify hackers loo= king for assigned numbers). They will try to use assigned numbers of legiti= mate subscribers to alleviate discovery by FMS or network “traps̶= 1; where dark numbers are assigned. It is the fact that they are using legi= timate subscriber identities that makes it impossible to black list, becaus= e you are effecting the good subscribers service.

 

QUESTION: How will validation/verification work in the= case of number portability where a number once assigned to one operator is= now assigned to another operator? Has consideration been given to updates = through the number portability process in these cases or is this a mute poi= nt?

 <= o:p>

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167=  
O= racle = CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North C= arolina 27560

Oracle is committed to developing practic= es and products that help protect the environment

 

______________________________________________= _
stir mailing list
stir@ietf.org
https://www.ietf.org/mail= man/listinfo/stir

<= /div>

 

--__1386762625404121581abhmp0003.oracle.com Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="image001.gif" Content-ID: R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9AQP/A wP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPVIDfcOQa6A8yR aO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1nBGRmhl8AWiUJYicC AIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4AAunsqg/dw95KwdfBgzB qKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1ItxK7aKl8lCl8DAfALW1+2rUi3 QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyIqRgMcA8a/z5AZQWXOxEdHxwUgfIg sX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjUmYLnomokcDlS4s0eFzQNqvXDEyzmAwFP yaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpFRxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ 9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvP m8OVEkAIYLYPThSsRIpEQJr1x94QBIT09FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8A BijggAQWaOCBCCao4A+CDDbo4IMQRijhhBQKGAIAOw== --__1386762625404121581abhmp0003.oracle.com Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="image002.gif" Content-ID: R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zPuZu2 lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxjSYdrOp/Q6NPg YqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMqDwFCAAIFPIYDgidr OUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQGBH82TpMicD0pAgQACToD AchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLDLS8MAvf497ruCZ+gOA0gfNt3 AIK0J/JWKVzIsEQIADs= --__1386762625404121581abhmp0003.oracle.com-- --__1386762625404121580abhmp0003.oracle.com-- --__1386762625403121579abhmp0003.oracle.com-- From br@brianrosen.net Wed Dec 11 05:46:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CCD1ADE8A for ; Wed, 11 Dec 2013 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XtQSr_Epv3a for ; Wed, 11 Dec 2013 05:46:42 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF201ADEBE for ; Wed, 11 Dec 2013 05:46:42 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id w5so589605qac.14 for ; Wed, 11 Dec 2013 05:46:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=z2qogbGRpWA0gZ7VG9xZI31xCproUjjgTVk6w/Mbobg=; b=S4UpjggdNOn9v4y9Y2aq4SsjOO+Ad72p0uBnbdgjW84TLqJwL4GDyBI2pTA/tb7Osx Db0/x5KIlQN6if3KdfUH/nnp52JEidIx9jCa2CVp/aTGk0r9C+okWxWvrHK03v/+ETwF /W07Tj8LNdiLznT3X6kU09YDXjdkVeyxBkkdM2zRq8psBjvfJcYuqTrnVVb4VeJh6mOI iFKd9ivI0ca0/f5FqAKfXfrkfwjZjnL2nwuuXN8YYVUC0vwmDNw7EHXtLfcpSp0SzZCR Db/ie0Vuy1mlXRH7tO0LDiPCOaE6koWhMi02BXfpzgbgVL6wMFGQxdjYLEMqc417E1RP mmjw== X-Gm-Message-State: ALoCoQkr2MYVTL3tLcfiLhCkplaeAElL50VkJA0gtXttPOYHWoiiN/Su407HAZW6Jc0YIG/8qg5j X-Received: by 10.224.120.10 with SMTP id b10mr2781509qar.64.1386769596468; Wed, 11 Dec 2013 05:46:36 -0800 (PST) Received: from [10.33.192.27] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id o10sm58958837qaa.6.2013.12.11.05.46.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 05:46:35 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A22E6B54-CC51-49F0-B09C-F0ADE822DE60" From: Brian Rosen X-Priority: 3 In-Reply-To: <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> Date: Wed, 11 Dec 2013 08:46:32 -0500 Message-Id: <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> To: Travis Russell X-Mailer: Apple Mail (2.1822) Cc: "stir@ietf.org List" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:46:47 -0000 --Apple-Mail=_A22E6B54-CC51-49F0-B09C-F0ADE822DE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline On Dec 11, 2013, at 6:50 AM, Travis Russell = wrote: > Thanks Brian, > =20 > Agreed. But remember most of us use our cell phones these days, and = the name comes from your address book based on number. Not the problem calls - they aren=92t in your address book. > =20 > Calling name will be a challenge since the service providers providing = CNAM services to the operators are challenged to get the names right. = And if you send a correction to your own name it sometimes does not get = fixed permanently as the next bulk load reverts back to the old files. Yes, there are quite a few challenges. You might go back into the = archive of the knit list (and this list just before we created cnit) = where some solutions were proposed. > =20 > I like the label of =93pink=94 service providers. There are also those = that offer spoofing as a service. You call a freephone number, your call = is terminated on the VoIP switch where you are asked for the number you = want to appear, and the call re-originated. These come through as = legitimate calls to the major service providers, and when tracing the = call you can only trace as far back as the spoofing service. Perfectly = legitimate companies by the way, as there is nothing illegal about = spoofing your number. The mechanisms we are discussing would stop this unless the spoofing = service was authorized to place calls on the numbers it was using. =20 > =20 > I only provide all this info because it is important for all of us to = understand the problem and how it manifests itself within service = provider networks. > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:46 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > What users look at for numbers they have not memorized is name. They = can=92t tell anything from the number. > =20 > In the IETF work, we have split name and number. We=92ll come up = with the number solution first, and then work on name. The name = discussions are on a separate list (cnit). > =20 > Most of the bad calls we see are from what I usually call =93pink=94 = service providers. They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number. They don=92t run = FMS systems. I am told that wholesale divisions of major carriers = sometimes are the unwitting origination carrier, because there are many = instances of permitted =93spoofing=94 (call centers calling on behalf of = another enterprise for example) which means they don=92t scrutinize = calling party number on the wholesale side. However, the majority of = the bad calls come from these =93pink=94 carriers. =20 > =20 > We all agree we need to get the number reliable first. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 5:38 PM, Travis Russell = wrote: >=20 >=20 > Thanks Brian for the clarifications. The FMS I am referring to are the = FSM used by service providers that look for anomalies in subscriber = behaviors. These systems look at behaviors of inbound and outbound = callers, and provide alarms/flags to the fraud department when there is = an anomaly occurring. One =93trick=94 used by fraud investigators is to = assign dark numbers throughout their number ranges. When the dark number = is hit several times, it indicates a hacker trying to create a hit list. = There are a number of variations to this technique but it is common for = fraudsters to spend a fair amount of time honing their hit lists prior = to launching an attack. > =20 > The FMS also looks for short calls, velocity of calls, etc to identify = anomalies, and there are thresholds in the network that fraudsters = eventually discover to ensure they =93fly under the radar=94 of these = systems. All of that said to make the point that fraudsters absolutely = care about the numbers being legitimate to prevent detection by the many = systems put in place by fraud departments. > =20 > In the case of the calling party name, is it thought that the name = display is critical to this process? My understanding is that the number = itself is the critical element, and the name is just a convenience = provided to subscribers. There are many errors in the calling name = database so personally I don=92t even pay attention to that anymore. The = number on the other hand is absolutely important. By the way, in = wireless communications, the calling party name is driven by the address = book on the device itself, and not CNAM. > =20 > I mention this because in the problem statement it sounds like the = calling party name is of equal importance to validation as the number. > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:25 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > The caller name comes from a database queried by the calling telephone = number. Usually, the display name in the SIP message is not used. = That=92s not always true (enterprise internal PBX for example). = Certainly, if you receive the call from a POTS phone, whatever is in the = SIP signaling for display name is not even available to the called party = or her service provider.=20 > =20 > The conventional implementation is the database is operated by the = calling service provider. The called service provider dips the database = with the calling party TN obtained in the signaling. =20 > =20 > If you can spoof the calling party number, you can cause the name to = be any name that is already in the database. > =20 > The fraud management systems you are referring to sound like the ones = inbound systems call centers use to identify fraudulent inbound callers. = I=92m not aware of any service provider attempting to identify = fraudulent callers on behalf of a typical residential or enterprise = customer. > =20 > We have most certainly considered number portability in this system. = The credentials will change when numbers port. The old credential will = become invalid (or the coverage of the credential will change if the = credential has more than one TN associated with it). A new credential = will be issued, or an existing credential will get another TN associated = with it. > =20 > We did agree that we could have some delay of this (or, rather, that = we would not attempt to invalidate cacheing of credentials. If, = following a port, the old holder could spoof the call for some minutes, = or even hours, that would probably be okay. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 3:31 PM, Travis Russell = wrote: >=20 >=20 >=20 > Looking at the following paragraph: > For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) database. > =20 > It is my experience that spoofing is simply accomplished via VoIP = servers modifying the SIP fields. There are a number of ways this has = been facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 identity. > =20 > I am not familiar with any cases where the spoofed identity was = retrieved from a SNAM server (although I may be wrong in this case). > =20 > In the paragraph immediately after: > For anonymization, the caller does not necessarily care whether the = number is in service, or who it is assigned to, and may switch rapidly = and possibly randomly between numbers. Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist numbers.=20 > =20 > A hacker or fraudster will typically use a =93hit list=94 when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign =93dark numbers=94 in their number ranges = to identify hackers looking for assigned numbers). They will try to use = assigned numbers of legitimate subscribers to alleviate discovery by FMS = or network =93traps=94 where dark numbers are assigned. It is the fact = that they are using legitimate subscriber identities that makes it = impossible to black list, because you are effecting the good subscribers = service. > =20 > QUESTION: How will validation/verification work in the case of number = portability where a number once assigned to one operator is now assigned = to another operator? Has consideration been given to updates through the = number portability process in these cases or is this a mute point? > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_A22E6B54-CC51-49F0-B09C-F0ADE822DE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline
On Dec 11, 2013, at 6:50 AM, = Travis Russell <travis.russell@oracle.com>= ; wrote:

Thanks Brian,
 
Agreed. But remember most = of us use our cell phones these days, and the name comes from your = address book based on number.
Not = the problem calls - they aren=92t in your address = book.

 
Calling name will be a challenge since the service = providers providing CNAM services to the operators are challenged to get = the names right. And if you send a correction to your own name it = sometimes does not get fixed permanently as the next bulk load reverts = back to the old files.
Yes, there = are quite a few challenges.  You might go back into the archive of = the knit list (and this list just before we created cnit) where some = solutions were proposed.
 
I like the label of =93pink=94 service providers. = There are also those that offer spoofing as a service. You call a = freephone number, your call is terminated on the VoIP switch where you = are asked for the number you want to appear, and the call re-originated. = These come through as legitimate calls to the major service providers, = and when tracing the call you can only trace as far back as the spoofing = service. Perfectly legitimate companies by the way, as there is nothing = illegal about spoofing your = number.
The mechanisms we are = discussing would stop this unless the spoofing service was authorized to = place calls on the numbers it was using. =  

 
I only provide all this info because it is important = for all of us to understand the problem and how it manifests itself = within service provider networks.
-- 
<image001.gif>
Travis Russell | Technologist, = Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU Product = Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the environment
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:46 PM
To: Travis = Russell
Cc: stir@ietf.org = List
Subject: Re: [stir] = Comments/Queries?
 
What users look = at for numbers they have not memorized is name.  They can=92t tell = anything from the number.
 
In = the IETF work, we have split  name and number.  We=92ll come = up with the number solution first, and then work on name.  The name = discussions are on a separate list = (cnit).
 
Most = of the bad calls we see are from what I usually call =93pink=94 service = providers.  They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number.  They don=92t = run FMS systems.  I am told that wholesale divisions of major = carriers sometimes are the unwitting origination carrier, because there = are many instances of permitted =93spoofing=94 (call centers calling on = behalf of another enterprise for example) which means they don=92t = scrutinize calling party number on the wholesale side.  However, = the majority of the bad calls come from these =93pink=94 carriers. =  
 
We = all agree we need to get the number reliable = first.
 
Brian
 
 
On = Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com> = wrote:


Thanks Brian for the clarifications. The FMS I am = referring to are the FSM used by service providers that look for = anomalies in subscriber behaviors. These systems look at behaviors of = inbound and outbound callers, and provide alarms/flags to the fraud = department when there is an anomaly occurring. One =93trick=94 used by = fraud investigators is to assign dark numbers throughout their number = ranges. When the dark number is hit several times, it indicates a hacker = trying to create a hit list. There are a number of variations to this = technique but it is common for fraudsters to spend a fair amount of time = honing their hit lists prior to launching an = attack.
 
The FMS also looks for = short calls, velocity of calls, etc to identify anomalies, and there are = thresholds in the network that fraudsters eventually discover to ensure = they =93fly under the radar=94 of these systems. All of that said to = make the point that fraudsters absolutely care about the numbers being = legitimate to prevent detection by the many systems put in place by = fraud departments.
 
In the case of the calling party = name, is it thought that the name display is critical to this process? = My understanding is that the number itself is the critical element, and = the name is just a convenience provided to subscribers. There are many = errors in the calling name database so personally I don=92t even pay = attention to that anymore. The number on the other hand is absolutely = important. By the way, in wireless communications, the calling party = name is driven by the address book on the device itself, and not = CNAM.
 
I mention this because in = the problem statement it sounds like the calling party name is of equal = importance to validation as the = number.
 
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the = environment
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:25 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?
 
The caller name comes from a database queried by the = calling telephone number.  Usually, the display name in the SIP = message is not used.  That=92s not always true (enterprise internal = PBX for example).  Certainly, if you receive the call from a POTS = phone, whatever is in the SIP signaling for display name is not even = available to the called party or her service = provider. 
 
The = conventional implementation is the database is operated by the calling = service provider.  The called service provider dips the database = with the calling party TN obtained in the signaling. =  
 
If = you can spoof the calling party number, you can cause the name to be any = name that is already in the database.
 
The fraud management systems you are referring to = sound like the ones inbound systems call centers use to identify = fraudulent inbound callers.  I=92m not aware of any service = provider attempting to identify fraudulent callers on behalf of a = typical residential or enterprise = customer.
 
We = have most certainly considered number portability in this system. =  The credentials will change when numbers port.  The old = credential will become invalid (or the coverage of the credential will = change if the credential has more than one TN associated with it). =  A new credential will be issued, or an existing credential will = get another TN associated with it.
 
We did agree that we could have some delay of this = (or, rather, that we would not attempt to invalidate cacheing of = credentials.  If, following a port, the old holder could spoof the = call for some minutes, or even hours, that would probably be = okay.
 
Brian
 
 
On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> = wrote:



Looking at the following = paragraph:
For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) = database.
 
It is my experience that spoofing is simply = accomplished via VoIP servers modifying the SIP fields. There are a = number of ways this has been facilitated =96 you can call a spoof = service where the call is terminated on a VoIP server, and when prompted = enter the telephone number you want to appear as the calling party = (works great =96 I have tried this myself). The VoIP server than = re-originates the call and sends it to the called party with the new = =93spoofed=94 identity.
 
I am not familiar with any cases where the spoofed = identity was retrieved from a SNAM server (although I may be wrong in = this case).
 
In the paragraph immediately = after:
For = anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and = possibly randomly between numbers.  Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist = numbers. 
 
A hacker or fraudster will typically use a =93hit = list=94 when doing this, because fraud management systems look for calls = to/from unassigned numbers (many operators assign =93dark numbers=94 in = their number ranges to identify hackers looking for assigned numbers). = They will try to use assigned numbers of legitimate subscribers to = alleviate discovery by FMS or network =93traps=94 where dark numbers are = assigned. It is the fact that they are using legitimate subscriber = identities that makes it impossible to black list, because you are = effecting the good subscribers = service.
 
QUESTION: How will validation/verification work in = the case of number portability where a number once assigned to one = operator is now assigned to another operator? Has consideration been = given to updates through the number portability process in these cases = or is this a mute point?
 
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the = environment
 
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
=
= --Apple-Mail=_A22E6B54-CC51-49F0-B09C-F0ADE822DE60-- From michael.hammer@yaanatech.com Wed Dec 11 07:27:10 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6711AD9AC for ; Wed, 11 Dec 2013 07:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8sR97Qx_3es for ; Wed, 11 Dec 2013 07:27:03 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 616B21ADFBC for ; Wed, 11 Dec 2013 07:27:03 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 11 Dec 2013 07:26:57 -0800 From: Michael Hammer To: "br@brianrosen.net" , "travis.russell@oracle.com" Thread-Topic: [stir] Comments/Queries? Thread-Index: AQHO9ebkazRl0V0+qkKf14lDN/A/7ppOh4aAgAAD2YCAAAIeAIAA2ykAgAAgdQD//5TOcA== Date: Wed, 11 Dec 2013 15:26:56 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> In-Reply-To: <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.97] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0040_01CEF65B.83E96150" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:27:10 -0000 ------=_NextPart_000_0040_01CEF65B.83E96150 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0041_01CEF65B.83E96150" ------=_NextPart_001_0041_01CEF65B.83E96150 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit AFAIK, the freephone SPs are authorized to originate the calls on those numbers. So, that is NOT spoofing. Let's not water down the meaning of terms. The goal is to stop someone from using numbers not assigned or delegated to them. Mike From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, December 11, 2013 8:47 AM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? Inline On Dec 11, 2013, at 6:50 AM, Travis Russell wrote: Thanks Brian, Agreed. But remember most of us use our cell phones these days, and the name comes from your address book based on number. Not the problem calls - they aren't in your address book. Calling name will be a challenge since the service providers providing CNAM services to the operators are challenged to get the names right. And if you send a correction to your own name it sometimes does not get fixed permanently as the next bulk load reverts back to the old files. Yes, there are quite a few challenges. You might go back into the archive of the knit list (and this list just before we created cnit) where some solutions were proposed. I like the label of "pink" service providers. There are also those that offer spoofing as a service. You call a freephone number, your call is terminated on the VoIP switch where you are asked for the number you want to appear, and the call re-originated. These come through as legitimate calls to the major service providers, and when tracing the call you can only trace as far back as the spoofing service. Perfectly legitimate companies by the way, as there is nothing illegal about spoofing your number. The mechanisms we are discussing would stop this unless the spoofing service was authorized to place calls on the numbers it was using. I only provide all this info because it is important for all of us to understand the problem and how it manifests itself within service provider networks. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect the environment From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:46 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? What users look at for numbers they have not memorized is name. They can't tell anything from the number. In the IETF work, we have split name and number. We'll come up with the number solution first, and then work on name. The name discussions are on a separate list (cnit). Most of the bad calls we see are from what I usually call "pink" service providers. They aren't actually complicit, but they look the other way as their subscribers spoof name and number. They don't run FMS systems. I am told that wholesale divisions of major carriers sometimes are the unwitting origination carrier, because there are many instances of permitted "spoofing" (call centers calling on behalf of another enterprise for example) which means they don't scrutinize calling party number on the wholesale side. However, the majority of the bad calls come from these "pink" carriers. We all agree we need to get the number reliable first. Brian On Dec 10, 2013, at 5:38 PM, Travis Russell < travis.russell@oracle.com> wrote: Thanks Brian for the clarifications. The FMS I am referring to are the FSM used by service providers that look for anomalies in subscriber behaviors. These systems look at behaviors of inbound and outbound callers, and provide alarms/flags to the fraud department when there is an anomaly occurring. One "trick" used by fraud investigators is to assign dark numbers throughout their number ranges. When the dark number is hit several times, it indicates a hacker trying to create a hit list. There are a number of variations to this technique but it is common for fraudsters to spend a fair amount of time honing their hit lists prior to launching an attack. The FMS also looks for short calls, velocity of calls, etc to identify anomalies, and there are thresholds in the network that fraudsters eventually discover to ensure they "fly under the radar" of these systems. All of that said to make the point that fraudsters absolutely care about the numbers being legitimate to prevent detection by the many systems put in place by fraud departments. In the case of the calling party name, is it thought that the name display is critical to this process? My understanding is that the number itself is the critical element, and the name is just a convenience provided to subscribers. There are many errors in the calling name database so personally I don't even pay attention to that anymore. The number on the other hand is absolutely important. By the way, in wireless communications, the calling party name is driven by the address book on the device itself, and not CNAM. I mention this because in the problem statement it sounds like the calling party name is of equal importance to validation as the number. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect the environment From: Brian Rosen [ mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:25 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? The caller name comes from a database queried by the calling telephone number. Usually, the display name in the SIP message is not used. That's not always true (enterprise internal PBX for example). Certainly, if you receive the call from a POTS phone, whatever is in the SIP signaling for display name is not even available to the called party or her service provider. The conventional implementation is the database is operated by the calling service provider. The called service provider dips the database with the calling party TN obtained in the signaling. If you can spoof the calling party number, you can cause the name to be any name that is already in the database. The fraud management systems you are referring to sound like the ones inbound systems call centers use to identify fraudulent inbound callers. I'm not aware of any service provider attempting to identify fraudulent callers on behalf of a typical residential or enterprise customer. We have most certainly considered number portability in this system. The credentials will change when numbers port. The old credential will become invalid (or the coverage of the credential will change if the credential has more than one TN associated with it). A new credential will be issued, or an existing credential will get another TN associated with it. We did agree that we could have some delay of this (or, rather, that we would not attempt to invalidate cacheing of credentials. If, following a port, the old holder could spoof the call for some minutes, or even hours, that would probably be okay. Brian On Dec 10, 2013, at 3:31 PM, Travis Russell < travis.russell@oracle.com> wrote: Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, number spoofing can be used to retrieve this information, stored in the so-called Calling Name (CNAM) database. It is my experience that spoofing is simply accomplished via VoIP servers modifying the SIP fields. There are a number of ways this has been facilitated - you can call a spoof service where the call is terminated on a VoIP server, and when prompted enter the telephone number you want to appear as the calling party (works great - I have tried this myself). The VoIP server than re-originates the call and sends it to the called party with the new "spoofed" identity. I am not familiar with any cases where the spoofed identity was retrieved from a SNAM server (although I may be wrong in this case). In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number is in service, or who it is assigned to, and may switch rapidly and possibly randomly between numbers. Anonymization facilitates automated illegal telemarketing or telephony denial-of-service attacks, as described above, as it makes it difficult to blacklist numbers. A hacker or fraudster will typically use a "hit list" when doing this, because fraud management systems look for calls to/from unassigned numbers (many operators assign "dark numbers" in their number ranges to identify hackers looking for assigned numbers). They will try to use assigned numbers of legitimate subscribers to alleviate discovery by FMS or network "traps" where dark numbers are assigned. It is the fact that they are using legitimate subscriber identities that makes it impossible to black list, because you are effecting the good subscribers service. QUESTION: How will validation/verification work in the case of number portability where a number once assigned to one operator is now assigned to another operator? Has consideration been given to updates through the number portability process in these cases or is this a mute point? -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect the environment _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_001_0041_01CEF65B.83E96150 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

AFAIK, the freephone SPs are authorized to originate the calls on = those numbers.

So, that is NOT spoofing.  Let’s not water down the = meaning of terms.

 

The goal is to stop someone from using numbers not assigned or = delegated to them.

 

Mike

 

 

From:= = stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, December 11, 2013 8:47 AM
To: = Travis Russell
Cc: stir@ietf.org List
Subject: Re: = [stir] Comments/Queries?

 

Inline

On = Dec 11, 2013, at 6:50 AM, Travis Russell <travis.russell@oracle.com&g= t; wrote:



Thanks Brian,

 

Agreed. But remember most of us use our cell phones these days, and = the name comes from your address book based on = number.

Not the = problem calls - they aren’t in your address = book.



 

Calling name will be a challenge since the service providers = providing CNAM services to the operators are challenged to get the names = right. And if you send a correction to your own name it sometimes does = not get fixed permanently as the next bulk load reverts back to the old = files.

Yes, there = are quite a few challenges.  You might go back into the archive of = the knit list (and this list just before we created cnit) where some = solutions were proposed.

 

I like the label of “pink” service providers. There are = also those that offer spoofing as a service. You call a freephone = number, your call is terminated on the VoIP switch where you are asked = for the number you want to appear, and the call re-originated. These = come through as legitimate calls to the major service providers, and = when tracing the call you can only trace as far back as the spoofing = service. Perfectly legitimate companies by the way, as there is nothing = illegal about spoofing your number.

The mechanisms we are discussing would stop this = unless the spoofing service was authorized to place calls on the numbers = it was using.  



 

I only provide all this info because it is important for all of us to = understand the problem and how it manifests itself within service = provider networks.

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 = 9194602172 | = Mobile: +1 = 9194121167 
O= racle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North = Carolina 27560

Oracle is committed to developing practices and products that help = protect the = environment

 

From:=  Brian Rosen = [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:46 PM
To: Travis = Russell
Cc: stir@ietf.org = List
Subject: Re: [stir] = Comments/Queries?

 

What users look at for numbers they have not memorized = is name.  They can’t tell anything from the = number.

 

In the IETF work, we have split  name and number. =  We’ll come up with the number solution first, and then work = on name.  The name discussions are on a separate list = (cnit).

 

Most of the bad calls we see are from what I usually = call “pink” service providers.  They aren’t = actually complicit, but they look the other way as their subscribers = spoof name and number.  They don’t run FMS systems.  I = am told that wholesale divisions of major carriers sometimes are the = unwitting origination carrier, because there are many instances of = permitted “spoofing” (call centers calling on behalf of = another enterprise for example) which means they don’t scrutinize = calling party number on the wholesale side.  However, the majority = of the bad calls come from these “pink” carriers. =  

 

We all agree we need to get the number reliable = first.

 

Brian

 

 

On Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com> = wrote:




Thanks Brian for the clarifications. The FMS I am referring to are = the FSM used by service providers that look for anomalies in subscriber = behaviors. These systems look at behaviors of inbound and outbound = callers, and provide alarms/flags to the fraud department when there is = an anomaly occurring. One “trick” used by fraud = investigators is to assign dark numbers throughout their number ranges. = When the dark number is hit several times, it indicates a hacker trying = to create a hit list. There are a number of variations to this technique = but it is common for fraudsters to spend a fair amount of time honing = their hit lists prior to launching an = attack.

 

The FMS also looks for short calls, velocity of calls, etc to = identify anomalies, and there are thresholds in the network that = fraudsters eventually discover to ensure they “fly under the = radar” of these systems. All of that said to make the point that = fraudsters absolutely care about the numbers being legitimate to prevent = detection by the many systems put in place by fraud = departments.

 

In the case of the calling party name, is it thought that the name = display is critical to this process? My understanding is that the number = itself is the critical element, and the name is just a convenience = provided to subscribers. There are many errors in the calling name = database so personally I don’t even pay attention to that anymore. = The number on the other hand is absolutely important. By the way, in = wireless communications, the calling party name is driven by the address = book on the device itself, and not = CNAM.

 

I mention this because in the problem statement it sounds like the = calling party name is of equal importance to validation as the = number.

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 = 9194602172 | = Mobile: +1 = 9194121167 
O= racle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North = Carolina 27560

Oracle is committed to developing practices and products that help = protect the = environment

=

 

From:=  Brian Rosen = [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:25 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

The caller name comes from a database queried by the = calling telephone number.  Usually, the display name in the SIP = message is not used.  That’s not always true (enterprise = internal PBX for example).  Certainly, if you receive the call from = a POTS phone, whatever is in the SIP signaling for display name is not = even available to the called party or her service = provider. 

 

The conventional implementation is the database is = operated by the calling service provider.  The called service = provider dips the database with the calling party TN obtained in the = signaling.  

 

If you can spoof the calling party number, you can = cause the name to be any name that is already in the = database.

 

The fraud management systems you are referring to = sound like the ones inbound systems call centers use to identify = fraudulent inbound callers.  I’m not aware of any service = provider attempting to identify fraudulent callers on behalf of a = typical residential or enterprise = customer.

 

We have most certainly considered number portability = in this system.  The credentials will change when numbers port. =  The old credential will become invalid (or the coverage of the = credential will change if the credential has more than one TN associated = with it).  A new credential will be issued, or an existing = credential will get another TN associated with = it.

 

We did agree that we could have some delay of this = (or, rather, that we would not attempt to invalidate cacheing of = credentials.  If, following a port, the old holder could spoof the = call for some minutes, or even hours, that would probably be = okay.

 

Brian

 

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> = wrote:





Looking at = the following paragraph:

For = numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the = so-called Calling Name (CNAM) = database.

 

It is my = experience that spoofing is simply accomplished via VoIP servers = modifying the SIP fields. There are a number of ways this has been = facilitated – you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great – I = have tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new “spoofed” = identity.

 

I am not = familiar with any cases where the spoofed identity was retrieved from a = SNAM server (although I may be wrong in this = case).

 

In the = paragraph immediately = after:

For = anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and = possibly randomly between numbers.  Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist = numbers. 

 

A hacker = or fraudster will typically use a “hit list” when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign “dark numbers” in their = number ranges to identify hackers looking for assigned numbers). They = will try to use assigned numbers of legitimate subscribers to alleviate = discovery by FMS or network “traps” where dark numbers are = assigned. It is the fact that they are using legitimate subscriber = identities that makes it impossible to black list, because you are = effecting the good subscribers = service.

 

QUESTION: = How will validation/verification work in the case of number portability = where a number once assigned to one operator is now assigned to another = operator? Has consideration been given to updates through the number = portability process in these cases or is this a mute = point?

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 = 9194602172 | = Mobile: +1 = 9194121167 
O= racle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North = Carolina 27560

Oracle is committed to developing practices and products that help = protect the = environment

 

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

=

 

------=_NextPart_001_0041_01CEF65B.83E96150-- ------=_NextPart_000_0040_01CEF65B.83E96150 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIx MTE1MjY1NVowIwYJKoZIhvcNAQkEMRYEFEhz76qBdzH/DfiTH5DlkNiWLwqQMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAciqYBWYn60NSMQjAnjlfTI4KblXQ+I1qxgAikr/D T/GJC73XUdooycJjTSJOa+rn6lTkxziaPKQx4Pd966t3F3ggdMU2mliiIBzkWvvUwvLTTg3vCKr+ Gmb4PqqBxpcGkHTYHiY/hpMjeKxpQZDSHyRqBZPPJ9VriJxd2ViNJP3BTl9fgtYKjcDVfYGc8M8v yYquL7UP0cUUPfi3Zf4gm9J7EHSLLNRCJFDRl421OqOPoLHMbA+Ilh8zIMqbr9inN2NQelleVztV hTUcWdFBAn5VzAva+TyYLQCuRYy7GPCPcAQM0xMQ+gOQO1Y5EvirSBs1AeKniJWqMzKXCvM4SQAA AAAAAA== ------=_NextPart_000_0040_01CEF65B.83E96150-- From Pierce.Gorman@sprint.com Wed Dec 11 08:07:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D51ADF69 for ; Wed, 11 Dec 2013 08:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgPOTCP8vo_o for ; Wed, 11 Dec 2013 08:06:56 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2291ADF5E for ; Wed, 11 Dec 2013 08:06:56 -0800 (PST) Received: from mail135-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Wed, 11 Dec 2013 16:06:50 +0000 Received: from mail135-tx2 (localhost [127.0.0.1]) by mail135-tx2-R.bigfish.com (Postfix) with ESMTP id 7C8C3600A2; Wed, 11 Dec 2013 16:06:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz98dI9371Ic85fh1453Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275ch93eR1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h1155h) Received-SPF: pass (mail135-tx2: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=Pierce.Gorman@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail135-tx2 (localhost.localdomain [127.0.0.1]) by mail135-tx2 (MessageSwitch) id 1386778007537911_20253; Wed, 11 Dec 2013 16:06:47 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.252]) by mail135-tx2.bigfish.com (Postfix) with ESMTP id 73D5820046; Wed, 11 Dec 2013 16:06:47 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 11 Dec 2013 16:06:44 +0000 Received: from PLSWEH03.ad.sprint.com (plsweh03.corp.sprint.com [144.226.242.132]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rBBG6hSa011486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 10:06:43 -0600 Received: from pdawm10a.ad.sprint.com ([169.254.2.104]) by PLSWEH03.ad.sprint.com ([144.226.242.132]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 10:06:43 -0600 From: "Gorman, Pierce A [NTK]" To: Michael Hammer , "br@brianrosen.net" , "travis.russell@oracle.com" Thread-Topic: [stir] Comments/Queries? Thread-Index: AQHO9oV7u+TyEbGOsUaF/Fva4Ojak5pPKK4g Date: Wed, 11 Dec 2013 16:06:42 +0000 Message-ID: References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.67] Content-Type: multipart/alternative; boundary="_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197822PDAWM10Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "stir@ietf.org" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:07:05 -0000 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197822PDAWM10Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is the goal to prevent misuse or only to validate calling number where/when= possible and therefore imply when potential misuse may have occurred (beca= use of a lack of validation)? Best regards, Pierce Gorman From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: December 11, 2013 9:27 AM To: br@brianrosen.net; travis.russell@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Comments/Queries? AFAIK, the freephone SPs are authorized to originate the calls on those num= bers. So, that is NOT spoofing. Let's not water down the meaning of terms. The goal is to stop someone from using numbers not assigned or delegated to= them. Mike From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, December 11, 2013 8:47 AM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? Inline On Dec 11, 2013, at 6:50 AM, Travis Russell > wrote: Thanks Brian, Agreed. But remember most of us use our cell phones these days, and the nam= e comes from your address book based on number. Not the problem calls - they aren't in your address book. Calling name will be a challenge since the service providers providing CNAM= services to the operators are challenged to get the names right. And if yo= u send a correction to your own name it sometimes does not get fixed perman= ently as the next bulk load reverts back to the old files. Yes, there are quite a few challenges. You might go back into the archive = of the knit list (and this list just before we created cnit) where some sol= utions were proposed. I like the label of "pink" service providers. There are also those that off= er spoofing as a service. You call a freephone number, your call is termina= ted on the VoIP switch where you are asked for the number you want to appea= r, and the call re-originated. These come through as legitimate calls to th= e major service providers, and when tracing the call you can only trace as = far back as the spoofing service. Perfectly legitimate companies by the way= , as there is nothing illegal about spoofing your number. The mechanisms we are discussing would stop this unless the spoofing servic= e was authorized to place calls on the numbers it was using. I only provide all this info because it is important for all of us to under= stand the problem and how it manifests itself within service provider netwo= rks. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect = the environment From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:46 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? What users look at for numbers they have not memorized is name. They can't= tell anything from the number. In the IETF work, we have split name and number. We'll come up with the n= umber solution first, and then work on name. The name discussions are on a= separate list (cnit). Most of the bad calls we see are from what I usually call "pink" service pr= oviders. They aren't actually complicit, but they look the other way as th= eir subscribers spoof name and number. They don't run FMS systems. I am t= old that wholesale divisions of major carriers sometimes are the unwitting = origination carrier, because there are many instances of permitted "spoofin= g" (call centers calling on behalf of another enterprise for example) which= means they don't scrutinize calling party number on the wholesale side. H= owever, the majority of the bad calls come from these "pink" carriers. We all agree we need to get the number reliable first. Brian On Dec 10, 2013, at 5:38 PM, Travis Russell > wrote: Thanks Brian for the clarifications. The FMS I am referring to are the FSM = used by service providers that look for anomalies in subscriber behaviors. = These systems look at behaviors of inbound and outbound callers, and provid= e alarms/flags to the fraud department when there is an anomaly occurring. = One "trick" used by fraud investigators is to assign dark numbers throughou= t their number ranges. When the dark number is hit several times, it indica= tes a hacker trying to create a hit list. There are a number of variations = to this technique but it is common for fraudsters to spend a fair amount of= time honing their hit lists prior to launching an attack. The FMS also looks for short calls, velocity of calls, etc to identify anom= alies, and there are thresholds in the network that fraudsters eventually d= iscover to ensure they "fly under the radar" of these systems. All of that = said to make the point that fraudsters absolutely care about the numbers be= ing legitimate to prevent detection by the many systems put in place by fra= ud departments. In the case of the calling party name, is it thought that the name display = is critical to this process? My understanding is that the number itself is = the critical element, and the name is just a convenience provided to subscr= ibers. There are many errors in the calling name database so personally I d= on't even pay attention to that anymore. The number on the other hand is ab= solutely important. By the way, in wireless communications, the calling par= ty name is driven by the address book on the device itself, and not CNAM. I mention this because in the problem statement it sounds like the calling = party name is of equal importance to validation as the number. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect = the environment From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:25 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? The caller name comes from a database queried by the calling telephone numb= er. Usually, the display name in the SIP message is not used. That's not = always true (enterprise internal PBX for example). Certainly, if you recei= ve the call from a POTS phone, whatever is in the SIP signaling for display= name is not even available to the called party or her service provider. The conventional implementation is the database is operated by the calling = service provider. The called service provider dips the database with the c= alling party TN obtained in the signaling. If you can spoof the calling party number, you can cause the name to be any= name that is already in the database. The fraud management systems you are referring to sound like the ones inbou= nd systems call centers use to identify fraudulent inbound callers. I'm no= t aware of any service provider attempting to identify fraudulent callers o= n behalf of a typical residential or enterprise customer. We have most certainly considered number portability in this system. The c= redentials will change when numbers port. The old credential will become i= nvalid (or the coverage of the credential will change if the credential has= more than one TN associated with it). A new credential will be issued, or= an existing credential will get another TN associated with it. We did agree that we could have some delay of this (or, rather, that we wou= ld not attempt to invalidate cacheing of credentials. If, following a port= , the old holder could spoof the call for some minutes, or even hours, that= would probably be okay. Brian On Dec 10, 2013, at 3:31 PM, Travis Russell > wrote: Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the so-= called Calling Name (CNAM) database. It is my experience that spoofing is simply accomplished via VoIP servers m= odifying the SIP fields. There are a number of ways this has been facilitat= ed - you can call a spoof service where the call is terminated on a VoIP se= rver, and when prompted enter the telephone number you want to appear as th= e calling party (works great - I have tried this myself). The VoIP server t= han re-originates the call and sends it to the called party with the new "s= poofed" identity. I am not familiar with any cases where the spoofed identity was retrieved f= rom a SNAM server (although I may be wrong in this case). In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and possibl= y randomly between numbers. Anonymization facilitates automated illegal te= lemarketing or telephony denial-of-service attacks, as described above, as = it makes it difficult to blacklist numbers. A hacker or fraudster will typically use a "hit list" when doing this, beca= use fraud management systems look for calls to/from unassigned numbers (man= y operators assign "dark numbers" in their number ranges to identify hacker= s looking for assigned numbers). They will try to use assigned numbers of l= egitimate subscribers to alleviate discovery by FMS or network "traps" wher= e dark numbers are assigned. It is the fact that they are using legitimate = subscriber identities that makes it impossible to black list, because you a= re effecting the good subscribers service. QUESTION: How will validation/verification work in the case of number porta= bility where a number once assigned to one operator is now assigned to anot= her operator? Has consideration been given to updates through the number po= rtability process in these cases or is this a mute point? -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect = the environment _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197822PDAWM10Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is the goal to prevent mi= suse or only to validate calling number where/when possible and therefore i= mply when potential misuse may have occurred (because of a lack of validation)? 

 

 

Best regards,

 

 

Pierce Gorman

 

 

From: Michae= l Hammer [mailto:michael.hammer@yaanatech.com]
Sent: December 11, 2013 9:27 AM
To: br@brianrosen.net; travis.russell@oracle.com
Cc: stir@ietf.org
Subject: Re: [stir] Comments/Queries?

 

AFAIK, the freephone SP= s are authorized to originate the calls on those numbers.

So, that is NOT spoofin= g.  Let’s not water down the meaning of terms.

 

The goal is to stop som= eone from using numbers not assigned or delegated to them.

 

Mike

 

 

From: stir [= mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, December 11, 2013 8:47 AM
To: Travis Russell
Cc: stir@ietf.org List
Subject: Re: [stir] Comments/Queries?

 

Inline

On Dec 11, 2013, at 6:50 AM, Travis Russell <travis.russell@oracle.com> = wrote:

 

Thanks Brian,

 

Agreed. But remember mo= st of us use our cell phones these days, and the name comes from your addre= ss book based on number.

Not the problem calls - they aren’t in your ad= dress book.

 

 

Calling name will be a = challenge since the service providers providing CNAM services to the operat= ors are challenged to get the names right. And if you send a correction to your own name it sometimes does not get fixed permanently = as the next bulk load reverts back to the old files.

Yes, there are quite = a few challenges.  You might go back into the archive of the knit list= (and this list just before we created cnit) where some solutions were prop= osed.

 

I like the label of = 220;pink” service providers. There are also those that offer spoofing= as a service. You call a freephone number, your call is terminated on the VoIP switch where you are asked for the number you want to appear, = and the call re-originated. These come through as legitimate calls to the m= ajor service providers, and when tracing the call you can only trace as far= back as the spoofing service. Perfectly legitimate companies by the way, as there is nothing illegal about spoofin= g your number.

The mechanisms we are discussing would stop this unl= ess the spoofing service was authorized to place calls on the numbers it wa= s using.  

 

 

I only provide all this= info because it is important for all of us to understand the problem and h= ow it manifests itself within service provider networks.

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr<= br> Phone: +1 9194602172=  | Mobile: +1 9194121167  Oracle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 27560

Oracle is committed to d= eveloping practices and products that help protect the environment

 

From: Brian Rosen [mailto:br@brianrosen.net]<= span class=3D"apple-converted-space"> 
Sent: Tuesday, Dec= ember 10, 2013 5:46 PM
To: Travis Russell=
Cc: stir@ietf.org List
Subject: Re: [stir= ] Comments/Queries?

 

What users look at for numbers they have not memoriz= ed is name.  They can’t tell anything from the number.

 

In the IETF work, we have split  name and numbe= r.  We’ll come up with the number solution first, and then work = on name.  The name discussions are on a separate list (cnit).

 

Most of the bad calls we see are from what I usually= call “pink” service providers.  They aren’t actuall= y complicit, but they look the other way as their subscribers spoof name an= d number.  They don’t run FMS systems.  I am told that whol= esale divisions of major carriers sometimes are the unwitting origination carrie= r, because there are many instances of permitted “spoofing” (ca= ll centers calling on behalf of another enterprise for example) which means= they don’t scrutinize calling party number on the wholesale side.  However, the majority of the bad calls come f= rom these “pink” carriers.  

 

We all agree we need to get the number reliable firs= t.

 

Brian

 

 

On Dec 10, 2013, at 5:38 PM, Travis Russell <travi= s.russell@oracle.com> wrote:



Thanks Brian for the cl= arifications. The FMS I am referring to are the FSM used by service provide= rs that look for anomalies in subscriber behaviors. These systems look at behaviors of inbound and outbound callers, and provide ala= rms/flags to the fraud department when there is an anomaly occurring. One &= #8220;trick” used by fraud investigators is to assign dark numbers th= roughout their number ranges. When the dark number is hit several times, it indicates a hacker trying to create a hit = list. There are a number of variations to this technique but it is common f= or fraudsters to spend a fair amount of time honing their hit lists prior t= o launching an attack.

 

The FMS also looks for = short calls, velocity of calls, etc to identify anomalies, and there are th= resholds in the network that fraudsters eventually discover to ensure they “fly under the radar” of these systems. All of = that said to make the point that fraudsters absolutely care about the numbe= rs being legitimate to prevent detection by the many systems put in place b= y fraud departments.

 

In the case of the call= ing party name, is it thought that the name display is critical to this pro= cess? My understanding is that the number itself is the critical element, and the name is just a convenience provided to subscribe= rs. There are many errors in the calling name database so personally I don&= #8217;t even pay attention to that anymore. The number on the other hand is= absolutely important. By the way, in wireless communications, the calling party name is driven by the address b= ook on the device itself, and not CNAM.

 

I mention this because = in the problem statement it sounds like the calling party name is of equal = importance to validation as the number.

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr<= br> Phone: +1 9194602172=  | Mobile: +1 9194121167  Oracle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 27560

Oracle is committed to d= eveloping practices and products that help protect the environment

 

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: Tuesday, Dec= ember 10, 2013 5:25 PM
To: Travis Russell=
Cc: stir@ietf.org List
Subject: Re: [stir= ] Comments/Queries?

 

The caller name comes from a database queried by the= calling telephone number.  Usually, the display name in the SIP messa= ge is not used.  That’s not always true (enterprise internal PBX= for example).  Certainly, if you receive the call from a POTS phone, whatever is in the SIP signaling for display name is no= t even available to the called party or her service provider. 

 

The conventional implementation is the database is o= perated by the calling service provider.  The called service provider = dips the database with the calling party TN obtained in the signaling. &nbs= p;

 

If you can spoof the calling party number, you can c= ause the name to be any name that is already in the database.

 

The fraud management systems you are referring to so= und like the ones inbound systems call centers use to identify fraudulent i= nbound callers.  I’m not aware of any service provider attemptin= g to identify fraudulent callers on behalf of a typical residential or enterprise customer.

 

We have most certainly considered number portability= in this system.  The credentials will change when numbers port.  = ;The old credential will become invalid (or the coverage of the credential = will change if the credential has more than one TN associated with it).  A new credential will be issued, or an e= xisting credential will get another TN associated with it.

 

We did agree that we could have some delay of this (= or, rather, that we would not attempt to invalidate cacheing of credentials= .  If, following a port, the old holder could spoof the call for some = minutes, or even hours, that would probably be okay.

 

Brian

 

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travi= s.russell@oracle.com> wrote:




Looking at the following paragraph:

For numbers where the caller has suppr= essed textual caller identification, number spoofing can be used to retriev= e this information, stored in the so-called Calling Name (CNAM) database.

 

It is my experience that spoofing is s= imply accomplished via VoIP servers modifying the SIP fields. There are a n= umber of ways this has been facilitated – you can call a spoof service where the call is terminated on a VoIP server, and when prom= pted enter the telephone number you want to appear as the calling party (wo= rks great – I have tried this myself). The VoIP server than re-origin= ates the call and sends it to the called party with the new “spoofed” identity.

 

I am not familiar with any cases where= the spoofed identity was retrieved from a SNAM server (although I may be w= rong in this case).

 

In the paragraph immediately after:

For anonymization, the caller does not= necessarily care whether the number is in service, or who it is assigned t= o, and may switch rapidly and possibly randomly between numbers.  Anonymization facilitates automated illegal telemarketing o= r telephony denial-of-service attacks, as described above, as it makes it d= ifficult to blacklist numbers. 

 

A hacker or fraudster will typically u= se a “hit list” when doing this, because fraud management syste= ms look for calls to/from unassigned numbers (many operators assign “dark numbers” in their number ranges to identify hackers look= ing for assigned numbers). They will try to use assigned numbers of legitim= ate subscribers to alleviate discovery by FMS or network “traps”= ; where dark numbers are assigned. It is the fact that they are using legitimate subscriber identities that makes it impossible to bla= ck list, because you are effecting the good subscribers service.

 

QUESTION: How will validation/verifica= tion work in the case of number portability where a number once assigned to= one operator is now assigned to another operator? Has consideration been given to updates through the number portability process in these case= s or is this a mute point?

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172=  | Mobile: +1 9194121167  Oracle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 27560

Oracle is committed to d= eveloping practices and products that help protect the environment

 

_____________________________________= __________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197822PDAWM10Aadsprin_-- From br@brianrosen.net Wed Dec 11 08:21:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F6F1ADC03 for ; Wed, 11 Dec 2013 08:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R07XVZ8VlpWF for ; Wed, 11 Dec 2013 08:21:38 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50E1A1F5D for ; Wed, 11 Dec 2013 08:21:38 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id e16so5211005qcx.17 for ; Wed, 11 Dec 2013 08:21:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vnlLdsDxSUnqD8x9+Av4QVjqcbFtRyGBltsT9oT8OhA=; b=l96pxkaBK9d7pJ91sjv/fTcSAGjPqkHNtcmPzTJrfRZDtQ+AMfalpRdCwpDCR6i25x gx89OY6gQQW3Xzxr1GAEDf+nmi3hG2wz9e+Q3FtaX8Pg4q7Ae+sFZm/I6vQTLcXcCJ/U ABNx+dLtoAZq+ygw+Aj2uCmRHwSs57K3kmWlJDvuEI+nhd5ux+WVOj6Ibmu+SvLAUt6d ALX2CDAG70FGmRPFNrUreweIs0o3oIXGV11hb8p1ptq2lmhQuRYCeVeA3cOsn2482oXb p9XcJxNpOXCPYJQdvUHDWVQakp8NCAjb+xkBi/GVexl4ktJzNINOQeZTyuijB5WJLT6z eOVg== X-Gm-Message-State: ALoCoQm0VGbTz3O1LH7RjBVdYcqp9w4Y6Ed9S9WZxDigc/P9Y8D71QqzYpkv846AwHDvHaHNb8Hf X-Received: by 10.224.2.69 with SMTP id 5mr4140758qai.19.1386778892610; Wed, 11 Dec 2013 08:21:32 -0800 (PST) Received: from [10.33.192.27] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id z16sm45512126qab.3.2013.12.11.08.21.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 08:21:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7177E511-224F-4078-ACCB-82B65A0C9571" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Brian Rosen In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> Date: Wed, 11 Dec 2013 11:21:29 -0500 Message-Id: <43D67C87-A678-4C96-84F9-87A0F69E4E06@brianrosen.net> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1822) Cc: "stir@ietf.org" , "travis.russell@oracle.com" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:21:43 -0000 --Apple-Mail=_7177E511-224F-4078-ACCB-82B65A0C9571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think he was talking about services that let you show any number you = want as calling party TN. That would NOT be allowed with stir. Brian On Dec 11, 2013, at 10:26 AM, Michael Hammer = wrote: > AFAIK, the freephone SPs are authorized to originate the calls on = those numbers. > So, that is NOT spoofing. Let=92s not water down the meaning of = terms. > =20 > The goal is to stop someone from using numbers not assigned or = delegated to them. > =20 > Mike > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Wednesday, December 11, 2013 8:47 AM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > Inline > On Dec 11, 2013, at 6:50 AM, Travis Russell = wrote: >=20 >=20 > Thanks Brian, > =20 > Agreed. But remember most of us use our cell phones these days, and = the name comes from your address book based on number. > Not the problem calls - they aren=92t in your address book. >=20 >=20 > =20 > Calling name will be a challenge since the service providers providing = CNAM services to the operators are challenged to get the names right. = And if you send a correction to your own name it sometimes does not get = fixed permanently as the next bulk load reverts back to the old files. > Yes, there are quite a few challenges. You might go back into the = archive of the knit list (and this list just before we created cnit) = where some solutions were proposed. >=20 > =20 > I like the label of =93pink=94 service providers. There are also those = that offer spoofing as a service. You call a freephone number, your call = is terminated on the VoIP switch where you are asked for the number you = want to appear, and the call re-originated. These come through as = legitimate calls to the major service providers, and when tracing the = call you can only trace as far back as the spoofing service. Perfectly = legitimate companies by the way, as there is nothing illegal about = spoofing your number. > The mechanisms we are discussing would stop this unless the spoofing = service was authorized to place calls on the numbers it was using. =20 >=20 >=20 > =20 > I only provide all this info because it is important for all of us to = understand the problem and how it manifests itself within service = provider networks. > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:46 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > What users look at for numbers they have not memorized is name. They = can=92t tell anything from the number. > =20 > In the IETF work, we have split name and number. We=92ll come up = with the number solution first, and then work on name. The name = discussions are on a separate list (cnit). > =20 > Most of the bad calls we see are from what I usually call =93pink=94 = service providers. They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number. They don=92t run = FMS systems. I am told that wholesale divisions of major carriers = sometimes are the unwitting origination carrier, because there are many = instances of permitted =93spoofing=94 (call centers calling on behalf of = another enterprise for example) which means they don=92t scrutinize = calling party number on the wholesale side. However, the majority of = the bad calls come from these =93pink=94 carriers. =20 > =20 > We all agree we need to get the number reliable first. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 5:38 PM, Travis Russell = wrote: >=20 >=20 >=20 > Thanks Brian for the clarifications. The FMS I am referring to are the = FSM used by service providers that look for anomalies in subscriber = behaviors. These systems look at behaviors of inbound and outbound = callers, and provide alarms/flags to the fraud department when there is = an anomaly occurring. One =93trick=94 used by fraud investigators is to = assign dark numbers throughout their number ranges. When the dark number = is hit several times, it indicates a hacker trying to create a hit list. = There are a number of variations to this technique but it is common for = fraudsters to spend a fair amount of time honing their hit lists prior = to launching an attack. > =20 > The FMS also looks for short calls, velocity of calls, etc to identify = anomalies, and there are thresholds in the network that fraudsters = eventually discover to ensure they =93fly under the radar=94 of these = systems. All of that said to make the point that fraudsters absolutely = care about the numbers being legitimate to prevent detection by the many = systems put in place by fraud departments. > =20 > In the case of the calling party name, is it thought that the name = display is critical to this process? My understanding is that the number = itself is the critical element, and the name is just a convenience = provided to subscribers. There are many errors in the calling name = database so personally I don=92t even pay attention to that anymore. The = number on the other hand is absolutely important. By the way, in = wireless communications, the calling party name is driven by the address = book on the device itself, and not CNAM. > =20 > I mention this because in the problem statement it sounds like the = calling party name is of equal importance to validation as the number. > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:25 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > The caller name comes from a database queried by the calling telephone = number. Usually, the display name in the SIP message is not used. = That=92s not always true (enterprise internal PBX for example). = Certainly, if you receive the call from a POTS phone, whatever is in the = SIP signaling for display name is not even available to the called party = or her service provider.=20 > =20 > The conventional implementation is the database is operated by the = calling service provider. The called service provider dips the database = with the calling party TN obtained in the signaling. =20 > =20 > If you can spoof the calling party number, you can cause the name to = be any name that is already in the database. > =20 > The fraud management systems you are referring to sound like the ones = inbound systems call centers use to identify fraudulent inbound callers. = I=92m not aware of any service provider attempting to identify = fraudulent callers on behalf of a typical residential or enterprise = customer. > =20 > We have most certainly considered number portability in this system. = The credentials will change when numbers port. The old credential will = become invalid (or the coverage of the credential will change if the = credential has more than one TN associated with it). A new credential = will be issued, or an existing credential will get another TN associated = with it. > =20 > We did agree that we could have some delay of this (or, rather, that = we would not attempt to invalidate cacheing of credentials. If, = following a port, the old holder could spoof the call for some minutes, = or even hours, that would probably be okay. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 3:31 PM, Travis Russell = wrote: >=20 >=20 >=20 >=20 > Looking at the following paragraph: > For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) database. > =20 > It is my experience that spoofing is simply accomplished via VoIP = servers modifying the SIP fields. There are a number of ways this has = been facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 identity. > =20 > I am not familiar with any cases where the spoofed identity was = retrieved from a SNAM server (although I may be wrong in this case). > =20 > In the paragraph immediately after: > For anonymization, the caller does not necessarily care whether the = number is in service, or who it is assigned to, and may switch rapidly = and possibly randomly between numbers. Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist numbers.=20 > =20 > A hacker or fraudster will typically use a =93hit list=94 when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign =93dark numbers=94 in their number ranges = to identify hackers looking for assigned numbers). They will try to use = assigned numbers of legitimate subscribers to alleviate discovery by FMS = or network =93traps=94 where dark numbers are assigned. It is the fact = that they are using legitimate subscriber identities that makes it = impossible to black list, because you are effecting the good subscribers = service. > =20 > QUESTION: How will validation/verification work in the case of number = portability where a number once assigned to one operator is now assigned = to another operator? Has consideration been given to updates through the = number portability process in these cases or is this a mute point? > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_7177E511-224F-4078-ACCB-82B65A0C9571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think he was talking about services that let you show any number you = want as calling party TN.  That would NOT be allowed with = stir.

Brian

On Dec 11, = 2013, at 10:26 AM, Michael Hammer <michael.hammer@yaanatech.com<= /a>> wrote:

AFAIK, the freephone SPs are authorized to originate = the calls on those numbers.
So, that is NOT spoofing.  = Let=92s not water down the meaning of terms.
 
The goal is to stop = someone from using numbers not assigned or delegated to = them.
 
Mike
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, December 11, = 2013 8:47 AM
To: Travis = Russell
Cc: stir@ietf.org = List
Subject: Re: [stir] = Comments/Queries?
 
Inline
On = Dec 11, 2013, at 6:50 AM, Travis Russell <travis.russell@oracle.com> = wrote:


Thanks Brian,
 
Agreed. But remember most of us = use our cell phones these days, and the name comes from your address = book based on number.
Not the problem calls - they aren=92t in your = address book.


 
Calling name will be a = challenge since the service providers providing CNAM services to the = operators are challenged to get the names right. And if you send a = correction to your own name it sometimes does not get fixed permanently = as the next bulk load reverts back to the old = files.
Yes, = there are quite a few challenges.  You might go back into the = archive of the knit list (and this list just before we created cnit) = where some solutions were = proposed.

 
I like the label of =93pink=94 = service providers. There are also those that offer spoofing as a = service. You call a freephone number, your call is terminated on the = VoIP switch where you are asked for the number you want to appear, and = the call re-originated. These come through as legitimate calls to the = major service providers, and when tracing the call you can only trace as = far back as the spoofing service. Perfectly legitimate companies by the = way, as there is nothing illegal about spoofing your = number.
The = mechanisms we are discussing would stop this unless the spoofing service = was authorized to place calls on the numbers it was using. =  


 
I only provide all this = info because it is important for all of us to understand the problem and = how it manifests itself within service provider = networks.
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the = environment
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:46 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?
 
What users look at for numbers they have not = memorized is name.  They can=92t tell anything from the = number.
 
In = the IETF work, we have split  name and number.  We=92ll come = up with the number solution first, and then work on name.  The name = discussions are on a separate list = (cnit).
 
Most = of the bad calls we see are from what I usually call =93pink=94 service = providers.  They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number.  They don=92t = run FMS systems.  I am told that wholesale divisions of major = carriers sometimes are the unwitting origination carrier, because there = are many instances of permitted =93spoofing=94 (call centers calling on = behalf of another enterprise for example) which means they don=92t = scrutinize calling party number on the wholesale side.  However, = the majority of the bad calls come from these =93pink=94 carriers. =  
 
We = all agree we need to get the number reliable = first.
 
Brian
 
 
On Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com> = wrote:



Thanks Brian for the = clarifications. The FMS I am referring to are the FSM used by service = providers that look for anomalies in subscriber behaviors. These systems = look at behaviors of inbound and outbound callers, and provide = alarms/flags to the fraud department when there is an anomaly occurring. = One =93trick=94 used by fraud investigators is to assign dark numbers = throughout their number ranges. When the dark number is hit several = times, it indicates a hacker trying to create a hit list. There are a = number of variations to this technique but it is common for fraudsters = to spend a fair amount of time honing their hit lists prior to launching = an attack.
 
The FMS also looks for short = calls, velocity of calls, etc to identify anomalies, and there are = thresholds in the network that fraudsters eventually discover to ensure = they =93fly under the radar=94 of these systems. All of that said to = make the point that fraudsters absolutely care about the numbers being = legitimate to prevent detection by the many systems put in place by = fraud departments.
 
In the case of the calling party = name, is it thought that the name display is critical to this process? = My understanding is that the number itself is the critical element, and = the name is just a convenience provided to subscribers. There are many = errors in the calling name database so personally I don=92t even pay = attention to that anymore. The number on the other hand is absolutely = important. By the way, in wireless communications, the calling party = name is driven by the address book on the device itself, and not = CNAM.
 
I mention this because in = the problem statement it sounds like the calling party name is of equal = importance to validation as the = number.
 
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the = environment
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:25 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?
 
The caller name comes from a database queried by the = calling telephone number.  Usually, the display name in the SIP = message is not used.  That=92s not always true (enterprise internal = PBX for example).  Certainly, if you receive the call from a POTS = phone, whatever is in the SIP signaling for display name is not even = available to the called party or her service = provider. 
 
The = conventional implementation is the database is operated by the calling = service provider.  The called service provider dips the database = with the calling party TN obtained in the signaling. =  
 
If = you can spoof the calling party number, you can cause the name to be any = name that is already in the database.
 
The fraud management systems you are referring to = sound like the ones inbound systems call centers use to identify = fraudulent inbound callers.  I=92m not aware of any service = provider attempting to identify fraudulent callers on behalf of a = typical residential or enterprise = customer.
 
We = have most certainly considered number portability in this system. =  The credentials will change when numbers port.  The old = credential will become invalid (or the coverage of the credential will = change if the credential has more than one TN associated with it). =  A new credential will be issued, or an existing credential will = get another TN associated with it.
 
We did agree that we could have some delay of this = (or, rather, that we would not attempt to invalidate cacheing of = credentials.  If, following a port, the old holder could spoof the = call for some minutes, or even hours, that would probably be = okay.
 
Brian
 
 
On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> = wrote:




Looking at the following = paragraph:
For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) = database.
 
It is my experience that spoofing is simply = accomplished via VoIP servers modifying the SIP fields. There are a = number of ways this has been facilitated =96 you can call a spoof = service where the call is terminated on a VoIP server, and when prompted = enter the telephone number you want to appear as the calling party = (works great =96 I have tried this myself). The VoIP server than = re-originates the call and sends it to the called party with the new = =93spoofed=94 identity.
 
I am not familiar with any cases where the spoofed = identity was retrieved from a SNAM server (although I may be wrong in = this case).
 
In the paragraph immediately = after:
For = anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and = possibly randomly between numbers.  Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist = numbers. 
 
A hacker or fraudster will typically use a =93hit = list=94 when doing this, because fraud management systems look for calls = to/from unassigned numbers (many operators assign =93dark numbers=94 in = their number ranges to identify hackers looking for assigned numbers). = They will try to use assigned numbers of legitimate subscribers to = alleviate discovery by FMS or network =93traps=94 where dark numbers are = assigned. It is the fact that they are using legitimate subscriber = identities that makes it impossible to black list, because you are = effecting the good subscribers = service.
 
QUESTION: How will validation/verification work in = the case of number portability where a number once assigned to one = operator is now assigned to another operator? Has consideration been = given to updates through the number portability process in these cases = or is this a mute point?
 
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the = environment
 
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_7177E511-224F-4078-ACCB-82B65A0C9571-- From br@brianrosen.net Wed Dec 11 08:22:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2743D1ADF7B for ; Wed, 11 Dec 2013 08:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cimD4MZxiLFo for ; Wed, 11 Dec 2013 08:22:48 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6ACB1A1F5D for ; Wed, 11 Dec 2013 08:22:47 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id e16so5313080qcx.31 for ; Wed, 11 Dec 2013 08:22:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ouGkTmDx7poGfTYuAAMPmGP8d36OTfq/k4OUAUomf+E=; b=LoKU2c2nsiYd3JpTjNeNqID22fx/bNkAzlgwzuac6v+JAKPUkpNJ+fV9eNNlxwQtwt EI4HCs9XBK9WDe1qXn4E8zTFyUw8qbCUwZMRfhbTflsxmP4caBY7XzxzH3S7w5ixFO3k TWWiLUSgjqJfslwgig+TCUdwwKCyLBUXdLMHpMnKhcVGQmS5If4mTfyaAFiraKU0NrBI +CKrTKCiLw66+ChhWJDFu1v6OsgF/k+M1ZQELqZFFyYW35XKjmVa0J/sW8aFCahAl6sP eBWLy5teu8tNteWGS+FwkkRgFkOFpyx+K696y+ohe30rwOh486ljeO0RcmCMMo7k/WSI BFrQ== X-Gm-Message-State: ALoCoQm4JN5fMHKr85f2HNsuzV/xQWFSvp+ma9DbqovpuMe4Rf4lPL0rZlSynfYWMvw474oCdutP X-Received: by 10.49.131.69 with SMTP id ok5mr3929298qeb.77.1386778962085; Wed, 11 Dec 2013 08:22:42 -0800 (PST) Received: from [10.33.192.27] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id u17sm53906995qeb.4.2013.12.11.08.22.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 08:22:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9A392DBC-D91D-47BC-AD95-028E52F4DAE8" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Brian Rosen In-Reply-To: Date: Wed, 11 Dec 2013 11:22:39 -0500 Message-Id: <393B2F03-E77A-432B-9C9E-34E1C0FB4D13@brianrosen.net> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> To: "Gorman, Pierce A [NTK]" X-Mailer: Apple Mail (2.1822) Cc: "stir@ietf.org" , Michael Hammer , "travis.russell@oracle.com" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:22:53 -0000 --Apple-Mail=_9A392DBC-D91D-47BC-AD95-028E52F4DAE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, although you recognize that we also have to deal with phase in, and = situations such as PSTN-PSTN that we can=92t realistically affect. Brian On Dec 11, 2013, at 11:06 AM, Gorman, Pierce A [NTK] = wrote: > Is the goal to prevent misuse or only to validate calling number = where/when possible and therefore imply when potential misuse may have = occurred (because of a lack of validation)?=20 > =20 > =20 > Best regards, > =20 > =20 > Pierce Gorman > =20 > =20 > From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 > Sent: December 11, 2013 9:27 AM > To: br@brianrosen.net; travis.russell@oracle.com > Cc: stir@ietf.org > Subject: Re: [stir] Comments/Queries? > =20 > AFAIK, the freephone SPs are authorized to originate the calls on = those numbers. > So, that is NOT spoofing. Let=92s not water down the meaning of = terms. > =20 > The goal is to stop someone from using numbers not assigned or = delegated to them. > =20 > Mike > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Wednesday, December 11, 2013 8:47 AM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > Inline > On Dec 11, 2013, at 6:50 AM, Travis Russell = wrote: > =20 > Thanks Brian, > =20 > Agreed. But remember most of us use our cell phones these days, and = the name comes from your address book based on number. > Not the problem calls - they aren=92t in your address book. > =20 > =20 > Calling name will be a challenge since the service providers providing = CNAM services to the operators are challenged to get the names right. = And if you send a correction to your own name it sometimes does not get = fixed permanently as the next bulk load reverts back to the old files. > Yes, there are quite a few challenges. You might go back into the = archive of the knit list (and this list just before we created cnit) = where some solutions were proposed. >=20 > =20 > I like the label of =93pink=94 service providers. There are also those = that offer spoofing as a service. You call a freephone number, your call = is terminated on the VoIP switch where you are asked for the number you = want to appear, and the call re-originated. These come through as = legitimate calls to the major service providers, and when tracing the = call you can only trace as far back as the spoofing service. Perfectly = legitimate companies by the way, as there is nothing illegal about = spoofing your number. > The mechanisms we are discussing would stop this unless the spoofing = service was authorized to place calls on the numbers it was using. =20 > =20 > =20 > I only provide all this info because it is important for all of us to = understand the problem and how it manifests itself within service = provider networks. > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:46 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > What users look at for numbers they have not memorized is name. They = can=92t tell anything from the number. > =20 > In the IETF work, we have split name and number. We=92ll come up = with the number solution first, and then work on name. The name = discussions are on a separate list (cnit). > =20 > Most of the bad calls we see are from what I usually call =93pink=94 = service providers. They aren=92t actually complicit, but they look the = other way as their subscribers spoof name and number. They don=92t run = FMS systems. I am told that wholesale divisions of major carriers = sometimes are the unwitting origination carrier, because there are many = instances of permitted =93spoofing=94 (call centers calling on behalf of = another enterprise for example) which means they don=92t scrutinize = calling party number on the wholesale side. However, the majority of = the bad calls come from these =93pink=94 carriers. =20 > =20 > We all agree we need to get the number reliable first. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 5:38 PM, Travis Russell = wrote: >=20 >=20 >=20 > Thanks Brian for the clarifications. The FMS I am referring to are the = FSM used by service providers that look for anomalies in subscriber = behaviors. These systems look at behaviors of inbound and outbound = callers, and provide alarms/flags to the fraud department when there is = an anomaly occurring. One =93trick=94 used by fraud investigators is to = assign dark numbers throughout their number ranges. When the dark number = is hit several times, it indicates a hacker trying to create a hit list. = There are a number of variations to this technique but it is common for = fraudsters to spend a fair amount of time honing their hit lists prior = to launching an attack. > =20 > The FMS also looks for short calls, velocity of calls, etc to identify = anomalies, and there are thresholds in the network that fraudsters = eventually discover to ensure they =93fly under the radar=94 of these = systems. All of that said to make the point that fraudsters absolutely = care about the numbers being legitimate to prevent detection by the many = systems put in place by fraud departments. > =20 > In the case of the calling party name, is it thought that the name = display is critical to this process? My understanding is that the number = itself is the critical element, and the name is just a convenience = provided to subscribers. There are many errors in the calling name = database so personally I don=92t even pay attention to that anymore. The = number on the other hand is absolutely important. By the way, in = wireless communications, the calling party name is driven by the address = book on the device itself, and not CNAM. > =20 > I mention this because in the problem statement it sounds like the = calling party name is of equal importance to validation as the number. > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, December 10, 2013 5:25 PM > To: Travis Russell > Cc: stir@ietf.org List > Subject: Re: [stir] Comments/Queries? > =20 > The caller name comes from a database queried by the calling telephone = number. Usually, the display name in the SIP message is not used. = That=92s not always true (enterprise internal PBX for example). = Certainly, if you receive the call from a POTS phone, whatever is in the = SIP signaling for display name is not even available to the called party = or her service provider.=20 > =20 > The conventional implementation is the database is operated by the = calling service provider. The called service provider dips the database = with the calling party TN obtained in the signaling. =20 > =20 > If you can spoof the calling party number, you can cause the name to = be any name that is already in the database. > =20 > The fraud management systems you are referring to sound like the ones = inbound systems call centers use to identify fraudulent inbound callers. = I=92m not aware of any service provider attempting to identify = fraudulent callers on behalf of a typical residential or enterprise = customer. > =20 > We have most certainly considered number portability in this system. = The credentials will change when numbers port. The old credential will = become invalid (or the coverage of the credential will change if the = credential has more than one TN associated with it). A new credential = will be issued, or an existing credential will get another TN associated = with it. > =20 > We did agree that we could have some delay of this (or, rather, that = we would not attempt to invalidate cacheing of credentials. If, = following a port, the old holder could spoof the call for some minutes, = or even hours, that would probably be okay. > =20 > Brian > =20 > =20 > On Dec 10, 2013, at 3:31 PM, Travis Russell = wrote: >=20 >=20 >=20 >=20 > Looking at the following paragraph: > For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) database. > =20 > It is my experience that spoofing is simply accomplished via VoIP = servers modifying the SIP fields. There are a number of ways this has = been facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 identity. > =20 > I am not familiar with any cases where the spoofed identity was = retrieved from a SNAM server (although I may be wrong in this case). > =20 > In the paragraph immediately after: > For anonymization, the caller does not necessarily care whether the = number is in service, or who it is assigned to, and may switch rapidly = and possibly randomly between numbers. Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist numbers.=20 > =20 > A hacker or fraudster will typically use a =93hit list=94 when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign =93dark numbers=94 in their number ranges = to identify hackers looking for assigned numbers). They will try to use = assigned numbers of legitimate subscribers to alleviate discovery by FMS = or network =93traps=94 where dark numbers are assigned. It is the fact = that they are using legitimate subscriber identities that makes it = impossible to black list, because you are effecting the good subscribers = service. > =20 > QUESTION: How will validation/verification work in the case of number = portability where a number once assigned to one operator is now assigned = to another operator? Has consideration been given to updates through the = number portability process in these cases or is this a mute point? > =20 > --=20 > > Travis Russell | Technologist, Sr. Mgr > Phone: +1 9194602172 | Mobile: +1 9194121167=20 > Oracle CGBU Product Marketing > 5200 Paramount Pkwy | Morrisville, North Carolina 27560 > > Oracle is committed to developing practices and products that help = protect the environment > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 >=20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. --Apple-Mail=_9A392DBC-D91D-47BC-AD95-028E52F4DAE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, = although you recognize that we also have to deal with phase in, and = situations such as PSTN-PSTN that we can=92t realistically = affect.

Brian

On Dec 11, = 2013, at 11:06 AM, Gorman, Pierce A [NTK] <Pierce.Gorman@sprint.com> = wrote:

Is the goal to prevent misuse or = only to validate calling number where/when possible and therefore imply = when potential misuse may have occurred (because of a lack of = validation)? 

 

 

Best regards,

 

 

Pierce = Gorman

 

 

From: Michael Hammer [mailto:michael.hammer@yaanate= ch.com] 
Sent: December 11, 2013 9:27 = AM
To: br@brianrosen.net; travis.russell@oracle.comCc: stir@ietf.org
Subject: Re: [stir] = Comments/Queries?

 

AFAIK, the freephone SPs are authorized to originate = the calls on those numbers.
So, that is NOT spoofing.  Let=92s not water = down the meaning of terms.

 

The goal is to stop = someone from using numbers not assigned or delegated to = them.

 

Mike

 

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, December 11, = 2013 8:47 AM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

Inline
On Dec 11, = 2013, at 6:50 AM, Travis Russell <travis.russell@oracle.com> = wrote:
 
Thanks = Brian,

 

Agreed. But remember most = of us use our cell phones these days, and the name comes from your = address book based on number.
Not the problem calls - they aren=92t in your = address book.
 

 

Calling name will be a challenge since the service = providers providing CNAM services to the operators are challenged to get = the names right. And if you send a correction to your own name it = sometimes does not get fixed permanently as the next bulk load reverts = back to the old files.

Yes, there are quite a few challenges.  You might = go back into the archive of the knit list (and this list just before we = created cnit) where some solutions were proposed.

 

I like the label of =93pink=94 service providers. = There are also those that offer spoofing as a service. You call a = freephone number, your call is terminated on the VoIP switch where you = are asked for the number you want to appear, and the call re-originated. = These come through as legitimate calls to the major service providers, = and when tracing the call you can only trace as far back as the spoofing = service. Perfectly legitimate companies by the way, as there is nothing = illegal about spoofing your number.
The mechanisms we are discussing would stop this = unless the spoofing service was authorized to place calls on the numbers = it was using.  
 

 

I only provide all this info because it is important = for all of us to understand the problem and how it manifests itself = within service provider networks.
-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is = committed to developing practices and products that help protect the = environment

 

From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:46 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

What = users look at for numbers they have not memorized is name.  They = can=92t tell anything from the number.

 

In the IETF work, we have split  name and = number.  We=92ll come up with the number solution first, and then = work on name.  The name discussions are on a separate list = (cnit).

 

Most of the bad = calls we see are from what I usually call =93pink=94 service providers. =  They aren=92t actually complicit, but they look the other way as = their subscribers spoof name and number.  They don=92t run FMS = systems.  I am told that wholesale divisions of major carriers = sometimes are the unwitting origination carrier, because there are many = instances of permitted =93spoofing=94 (call centers calling on behalf of = another enterprise for example) which means they don=92t scrutinize = calling party number on the wholesale side.  However, the majority = of the bad calls come from these =93pink=94 carriers. =  

 

We all agree we = need to get the number reliable first.

 

Brian

 

 

On Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com> = wrote:



Thanks Brian for the clarifications. The FMS I am = referring to are the FSM used by service providers that look for = anomalies in subscriber behaviors. These systems look at behaviors of = inbound and outbound callers, and provide alarms/flags to the fraud = department when there is an anomaly occurring. One =93trick=94 used by = fraud investigators is to assign dark numbers throughout their number = ranges. When the dark number is hit several times, it indicates a hacker = trying to create a hit list. There are a number of variations to this = technique but it is common for fraudsters to spend a fair amount of time = honing their hit lists prior to launching an = attack.

 

The FMS also looks for = short calls, velocity of calls, etc to identify anomalies, and there are = thresholds in the network that fraudsters eventually discover to ensure = they =93fly under the radar=94 of these systems. All of that said to = make the point that fraudsters absolutely care about the numbers being = legitimate to prevent detection by the many systems put in place by = fraud departments.

 

In the case of the calling party name, is it thought = that the name display is critical to this process? My understanding is = that the number itself is the critical element, and the name is just a = convenience provided to subscribers. There are many errors in the = calling name database so personally I don=92t even pay attention to that = anymore. The number on the other hand is absolutely important. By the = way, in wireless communications, the calling party name is driven by the = address book on the device itself, and not = CNAM.

 

I mention this because in = the problem statement it sounds like the calling party name is of equal = importance to validation as the number.

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is = committed to developing practices and products that help protect the = environment

 

From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:25 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

The = caller name comes from a database queried by the calling telephone = number.  Usually, the display name in the SIP message is not used. =  That=92s not always true (enterprise internal PBX for example). =  Certainly, if you receive the call from a POTS phone, whatever is = in the SIP signaling for display name is not even available to the = called party or her service provider. 

 

The conventional implementation is the database is = operated by the calling service provider.  The called service = provider dips the database with the calling party TN obtained in the = signaling.  

 

If you can = spoof the calling party number, you can cause the name to be any name = that is already in the database.

 

The = fraud management systems you are referring to sound like the ones = inbound systems call centers use to identify fraudulent inbound callers. =  I=92m not aware of any service provider attempting to identify = fraudulent callers on behalf of a typical residential or enterprise = customer.

 

We have most = certainly considered number portability in this system.  The = credentials will change when numbers port.  The old credential will = become invalid (or the coverage of the credential will change if the = credential has more than one TN associated with it).  A new = credential will be issued, or an existing credential will get another TN = associated with it.

 

We = did agree that we could have some delay of this (or, rather, that we = would not attempt to invalidate cacheing of credentials.  If, = following a port, the old holder could spoof the call for some minutes, = or even hours, that would probably be okay.

 

Brian

 

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> = wrote:




Looking at = the following paragraph:
For numbers where the caller has suppressed textual caller = identification, number spoofing can be used to retrieve this = information, stored in the so-called Calling Name (CNAM) = database.

 

It is my = experience that spoofing is simply accomplished via VoIP servers = modifying the SIP fields. There are a number of ways this has been = facilitated =96 you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great =96 I have = tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new =93spoofed=94 = identity.

 

I am not = familiar with any cases where the spoofed identity was retrieved from a = SNAM server (although I may be wrong in this = case).

 

In the = paragraph immediately after:
For anonymization, the caller does not necessarily care = whether the number is in service, or who it is assigned to, and may = switch rapidly and possibly randomly between numbers.  = Anonymization facilitates automated illegal telemarketing or telephony = denial-of-service attacks, as described above, as it makes it difficult = to blacklist numbers. 

 

A hacker or fraudster will typically use a =93hit list=94 = when doing this, because fraud management systems look for calls to/from = unassigned numbers (many operators assign =93dark numbers=94 in their = number ranges to identify hackers looking for assigned numbers). They = will try to use assigned numbers of legitimate subscribers to alleviate = discovery by FMS or network =93traps=94 where dark numbers are assigned. = It is the fact that they are using legitimate subscriber identities that = makes it impossible to black list, because you are effecting the good = subscribers service.

 

QUESTION: How will validation/verification work in the case = of number portability where a number once assigned to one operator is = now assigned to another operator? Has consideration been given to = updates through the number portability process in these cases or is this = a mute point?

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172 | Mobile: +1 9194121167 
Oracle CGBU = Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina = 27560
Oracle is committed to developing practices and = products that help protect the = environment

 

_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 



This e-mail may contain = Sprint proprietary information intended for the sole use of the = recipient(s). Any use by others is prohibited. If you are not the = intended recipient, please contact the sender and delete all copies of = the message.

= --Apple-Mail=_9A392DBC-D91D-47BC-AD95-028E52F4DAE8-- From michael.hammer@yaanatech.com Wed Dec 11 08:41:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25F1AE101 for ; Wed, 11 Dec 2013 08:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45icuVivTcdH for ; Wed, 11 Dec 2013 08:41:46 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 096981AE107 for ; Wed, 11 Dec 2013 08:41:45 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 11 Dec 2013 08:41:40 -0800 From: Michael Hammer To: "br@brianrosen.net" , "Pierce.Gorman@sprint.com" Thread-Topic: [stir] Comments/Queries? Thread-Index: AQHO9ebkazRl0V0+qkKf14lDN/A/7ppOh4aAgAAD2YCAAAIeAIAA2ykAgAAgdQD//5TOcIAAklsAgAAEdYD//37GUA== Date: Wed, 11 Dec 2013 16:41:39 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF07E98@sc9-ex2k10mb1.corp.yaanatech.com> References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> <393B2F03-E77A-432B-9C9E-34E1C0FB4D13@brianrosen.net> In-Reply-To: <393B2F03-E77A-432B-9C9E-34E1C0FB4D13@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.97] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0089_01CEF665.F48A7ED0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "travis.russell@oracle.com" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:41:52 -0000 ------=_NextPart_000_0089_01CEF665.F48A7ED0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_008A_01CEF665.F48A7ED0" ------=_NextPart_001_008A_01CEF665.F48A7ED0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yeah, I guess to be more precise, allow receiver to know, when they can validate, that the number is good, or when they can't validate, to know that they don't know. Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, December 11, 2013 11:23 AM To: Gorman, Pierce A [NTK] Cc: Michael Hammer; travis.russell@oracle.com; stir@ietf.org Subject: Re: [stir] Comments/Queries? Yes, although you recognize that we also have to deal with phase in, and situations such as PSTN-PSTN that we can't realistically affect. Brian On Dec 11, 2013, at 11:06 AM, Gorman, Pierce A [NTK] wrote: Is the goal to prevent misuse or only to validate calling number where/when possible and therefore imply when potential misuse may have occurred (because of a lack of validation)? Best regards, Pierce Gorman From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: December 11, 2013 9:27 AM To: br@brianrosen.net; travis.russell@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Comments/Queries? AFAIK, the freephone SPs are authorized to originate the calls on those numbers. So, that is NOT spoofing. Let's not water down the meaning of terms. The goal is to stop someone from using numbers not assigned or delegated to them. Mike From: stir [ mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, December 11, 2013 8:47 AM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? Inline On Dec 11, 2013, at 6:50 AM, Travis Russell < travis.russell@oracle.com> wrote: Thanks Brian, Agreed. But remember most of us use our cell phones these days, and the name comes from your address book based on number. Not the problem calls - they aren't in your address book. Calling name will be a challenge since the service providers providing CNAM services to the operators are challenged to get the names right. And if you send a correction to your own name it sometimes does not get fixed permanently as the next bulk load reverts back to the old files. Yes, there are quite a few challenges. You might go back into the archive of the knit list (and this list just before we created cnit) where some solutions were proposed. I like the label of "pink" service providers. There are also those that offer spoofing as a service. You call a freephone number, your call is terminated on the VoIP switch where you are asked for the number you want to appear, and the call re-originated. These come through as legitimate calls to the major service providers, and when tracing the call you can only trace as far back as the spoofing service. Perfectly legitimate companies by the way, as there is nothing illegal about spoofing your number. The mechanisms we are discussing would stop this unless the spoofing service was authorized to place calls on the numbers it was using. I only provide all this info because it is important for all of us to understand the problem and how it manifests itself within service provider networks. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect the environment From: Brian Rosen [ mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:46 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? What users look at for numbers they have not memorized is name. They can't tell anything from the number. In the IETF work, we have split name and number. We'll come up with the number solution first, and then work on name. The name discussions are on a separate list (cnit). Most of the bad calls we see are from what I usually call "pink" service providers. They aren't actually complicit, but they look the other way as their subscribers spoof name and number. They don't run FMS systems. I am told that wholesale divisions of major carriers sometimes are the unwitting origination carrier, because there are many instances of permitted "spoofing" (call centers calling on behalf of another enterprise for example) which means they don't scrutinize calling party number on the wholesale side. However, the majority of the bad calls come from these "pink" carriers. We all agree we need to get the number reliable first. Brian On Dec 10, 2013, at 5:38 PM, Travis Russell < travis.russell@oracle.com> wrote: Thanks Brian for the clarifications. The FMS I am referring to are the FSM used by service providers that look for anomalies in subscriber behaviors. These systems look at behaviors of inbound and outbound callers, and provide alarms/flags to the fraud department when there is an anomaly occurring. One "trick" used by fraud investigators is to assign dark numbers throughout their number ranges. When the dark number is hit several times, it indicates a hacker trying to create a hit list. There are a number of variations to this technique but it is common for fraudsters to spend a fair amount of time honing their hit lists prior to launching an attack. The FMS also looks for short calls, velocity of calls, etc to identify anomalies, and there are thresholds in the network that fraudsters eventually discover to ensure they "fly under the radar" of these systems. All of that said to make the point that fraudsters absolutely care about the numbers being legitimate to prevent detection by the many systems put in place by fraud departments. In the case of the calling party name, is it thought that the name display is critical to this process? My understanding is that the number itself is the critical element, and the name is just a convenience provided to subscribers. There are many errors in the calling name database so personally I don't even pay attention to that anymore. The number on the other hand is absolutely important. By the way, in wireless communications, the calling party name is driven by the address book on the device itself, and not CNAM. I mention this because in the problem statement it sounds like the calling party name is of equal importance to validation as the number. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect the environment From: Brian Rosen [ mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:25 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? The caller name comes from a database queried by the calling telephone number. Usually, the display name in the SIP message is not used. That's not always true (enterprise internal PBX for example). Certainly, if you receive the call from a POTS phone, whatever is in the SIP signaling for display name is not even available to the called party or her service provider. The conventional implementation is the database is operated by the calling service provider. The called service provider dips the database with the calling party TN obtained in the signaling. If you can spoof the calling party number, you can cause the name to be any name that is already in the database. The fraud management systems you are referring to sound like the ones inbound systems call centers use to identify fraudulent inbound callers. I'm not aware of any service provider attempting to identify fraudulent callers on behalf of a typical residential or enterprise customer. We have most certainly considered number portability in this system. The credentials will change when numbers port. The old credential will become invalid (or the coverage of the credential will change if the credential has more than one TN associated with it). A new credential will be issued, or an existing credential will get another TN associated with it. We did agree that we could have some delay of this (or, rather, that we would not attempt to invalidate cacheing of credentials. If, following a port, the old holder could spoof the call for some minutes, or even hours, that would probably be okay. Brian On Dec 10, 2013, at 3:31 PM, Travis Russell < travis.russell@oracle.com> wrote: Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, number spoofing can be used to retrieve this information, stored in the so-called Calling Name (CNAM) database. It is my experience that spoofing is simply accomplished via VoIP servers modifying the SIP fields. There are a number of ways this has been facilitated - you can call a spoof service where the call is terminated on a VoIP server, and when prompted enter the telephone number you want to appear as the calling party (works great - I have tried this myself). The VoIP server than re-originates the call and sends it to the called party with the new "spoofed" identity. I am not familiar with any cases where the spoofed identity was retrieved from a SNAM server (although I may be wrong in this case). In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number is in service, or who it is assigned to, and may switch rapidly and possibly randomly between numbers. Anonymization facilitates automated illegal telemarketing or telephony denial-of-service attacks, as described above, as it makes it difficult to blacklist numbers. A hacker or fraudster will typically use a "hit list" when doing this, because fraud management systems look for calls to/from unassigned numbers (many operators assign "dark numbers" in their number ranges to identify hackers looking for assigned numbers). They will try to use assigned numbers of legitimate subscribers to alleviate discovery by FMS or network "traps" where dark numbers are assigned. It is the fact that they are using legitimate subscriber identities that makes it impossible to black list, because you are effecting the good subscribers service. QUESTION: How will validation/verification work in the case of number portability where a number once assigned to one operator is now assigned to another operator? Has consideration been given to updates through the number portability process in these cases or is this a mute point? -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect the environment _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_001_008A_01CEF665.F48A7ED0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Yeah, I guess to be more precise,

allow receiver to know, when they can validate, that the number is = good,

or when they can’t validate, to know that they don’t = know.

 

Mike

 

 

From:= = Brian Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, = December 11, 2013 11:23 AM
To: Gorman, Pierce A = [NTK]
Cc: Michael Hammer; travis.russell@oracle.com; = stir@ietf.org
Subject: Re: [stir] = Comments/Queries?

 

Yes, = although you recognize that we also have to deal with phase in, and = situations such as PSTN-PSTN that we can’t realistically = affect.

 

Brian

 

On = Dec 11, 2013, at 11:06 AM, Gorman, Pierce A [NTK] <Pierce.Gorman@sprint.com>= wrote:



Is the goal to prevent misuse or only to validate calling number = where/when possible and therefore imply when potential misuse may have = occurred (because of a lack of = validation)? 

 

 

Best regards,

 

 

Pierce = Gorman

 

 

From:=  Michael = Hammer [mailto:michael.hammer@yaanat= ech.com] 
Sent: December 11, 2013 9:27 = AM
To: br@brianrosen.net; travis.russell@oracle.comCc: stir@ietf.org
Subject: Re: [stir] = Comments/Queries?

 

AFAIK, the freephone SPs are authorized to originate the calls on = those numbers.

So, that is NOT spoofing.  Let’s not water down the = meaning of terms.

 

The goal is to stop someone from using numbers not assigned or = delegated to them.

 

Mike

 

 

From:=  stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, December 11, 2013 = 8:47 AM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

Inline

On Dec 11, 2013, at 6:50 AM, Travis Russell <travis.russell@oracle.com> = wrote:

 

Thanks Brian,

 

Agreed. But remember most of us use our cell phones these days, and = the name comes from your address book based on = number.

Not the problem calls - they aren’t in your = address book.

 

 

Calling name will be a challenge since the service providers = providing CNAM services to the operators are challenged to get the names = right. And if you send a correction to your own name it sometimes does = not get fixed permanently as the next bulk load reverts back to the old = files.

Yes, there are quite a few challenges. =  You might go back into the archive of the knit list (and this list = just before we created cnit) where some solutions were = proposed.

 

I like the label of “pink” service providers. There are = also those that offer spoofing as a service. You call a freephone = number, your call is terminated on the VoIP switch where you are asked = for the number you want to appear, and the call re-originated. These = come through as legitimate calls to the major service providers, and = when tracing the call you can only trace as far back as the spoofing = service. Perfectly legitimate companies by the way, as there is nothing = illegal about spoofing your = number.

The mechanisms we are discussing would stop this = unless the spoofing service was authorized to place calls on the numbers = it was using.  

 

 

I only provide all this info because it is important for all of us to = understand the problem and how it manifests itself within service = provider networks.

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 = 9194602172 | = Mobile: +1 = 9194121167 
O= racle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North = Carolina 27560

Oracle is committed to developing practices and products that help = protect the = environment

 

From:=  Brian Rosen = [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:46 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

What users look at for numbers they have not memorized = is name.  They can’t tell anything from the = number.

 

In the IETF work, we have split  name and number. =  We’ll come up with the number solution first, and then work = on name.  The name discussions are on a separate list = (cnit).

 

Most of the bad calls we see are from what I usually = call “pink” service providers.  They aren’t = actually complicit, but they look the other way as their subscribers = spoof name and number.  They don’t run FMS systems.  I = am told that wholesale divisions of major carriers sometimes are the = unwitting origination carrier, because there are many instances of = permitted “spoofing” (call centers calling on behalf of = another enterprise for example) which means they don’t scrutinize = calling party number on the wholesale side.  However, the majority = of the bad calls come from these “pink” carriers. =  

 

We all agree we need to get the number reliable = first.

 

Brian

 

 

On Dec 10, 2013, at 5:38 PM, Travis Russell <travis.russell@oracle.com> = wrote:

 

=

Thanks Brian for the clarifications. The FMS I am referring to are = the FSM used by service providers that look for anomalies in subscriber = behaviors. These systems look at behaviors of inbound and outbound = callers, and provide alarms/flags to the fraud department when there is = an anomaly occurring. One “trick” used by fraud = investigators is to assign dark numbers throughout their number ranges. = When the dark number is hit several times, it indicates a hacker trying = to create a hit list. There are a number of variations to this technique = but it is common for fraudsters to spend a fair amount of time honing = their hit lists prior to launching an = attack.

 

The FMS also looks for short calls, velocity of calls, etc to = identify anomalies, and there are thresholds in the network that = fraudsters eventually discover to ensure they “fly under the = radar” of these systems. All of that said to make the point that = fraudsters absolutely care about the numbers being legitimate to prevent = detection by the many systems put in place by fraud = departments.

 

In the case of the calling party name, is it thought that the name = display is critical to this process? My understanding is that the number = itself is the critical element, and the name is just a convenience = provided to subscribers. There are many errors in the calling name = database so personally I don’t even pay attention to that anymore. = The number on the other hand is absolutely important. By the way, in = wireless communications, the calling party name is driven by the address = book on the device itself, and not = CNAM.

 

I mention this because in the problem statement it sounds like the = calling party name is of equal importance to validation as the = number.

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 = 9194602172 | = Mobile: +1 = 9194121167 
O= racle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North = Carolina 27560

Oracle is committed to developing practices and products that help = protect the = environment

 

From:=  Brian Rosen = [mailto:br@brianrosen.net] 
Sent: Tuesday, December 10, 2013 = 5:25 PM
To: Travis = Russell
Cc: stir@ietf.org List
Subject: Re: [stir] = Comments/Queries?

 

The caller name comes from a database queried by the = calling telephone number.  Usually, the display name in the SIP = message is not used.  That’s not always true (enterprise = internal PBX for example).  Certainly, if you receive the call from = a POTS phone, whatever is in the SIP signaling for display name is not = even available to the called party or her service = provider. 

 

The conventional implementation is the database is = operated by the calling service provider.  The called service = provider dips the database with the calling party TN obtained in the = signaling.  

 

If you can spoof the calling party number, you can = cause the name to be any name that is already in the = database.

 

The fraud management systems you are referring to = sound like the ones inbound systems call centers use to identify = fraudulent inbound callers.  I’m not aware of any service = provider attempting to identify fraudulent callers on behalf of a = typical residential or enterprise = customer.

 

We have most certainly considered number portability = in this system.  The credentials will change when numbers port. =  The old credential will become invalid (or the coverage of the = credential will change if the credential has more than one TN associated = with it).  A new credential will be issued, or an existing = credential will get another TN associated with = it.

 

We did agree that we could have some delay of this = (or, rather, that we would not attempt to invalidate cacheing of = credentials.  If, following a port, the old holder could spoof the = call for some minutes, or even hours, that would probably be = okay.

 

Brian

 

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travis.russell@oracle.com> = wrote:



Looking at = the following paragraph:

For = numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the = so-called Calling Name (CNAM) = database.

 

It is my = experience that spoofing is simply accomplished via VoIP servers = modifying the SIP fields. There are a number of ways this has been = facilitated – you can call a spoof service where the call is = terminated on a VoIP server, and when prompted enter the telephone = number you want to appear as the calling party (works great – I = have tried this myself). The VoIP server than re-originates the call and = sends it to the called party with the new “spoofed” = identity.

 

I am not = familiar with any cases where the spoofed identity was retrieved from a = SNAM server (although I may be wrong in this = case).

 

In the = paragraph immediately = after:

For = anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and = possibly randomly between numbers.  Anonymization facilitates = automated illegal telemarketing or telephony denial-of-service attacks, = as described above, as it makes it difficult to blacklist = numbers. 

 

A hacker = or fraudster will typically use a “hit list” when doing = this, because fraud management systems look for calls to/from unassigned = numbers (many operators assign “dark numbers” in their = number ranges to identify hackers looking for assigned numbers). They = will try to use assigned numbers of legitimate subscribers to alleviate = discovery by FMS or network “traps” where dark numbers are = assigned. It is the fact that they are using legitimate subscriber = identities that makes it impossible to black list, because you are = effecting the good subscribers = service.

 

QUESTION: = How will validation/verification work in the case of number portability = where a number once assigned to one operator is now assigned to another = operator? Has consideration been given to updates through the number = portability process in these cases or is this a mute = point?

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 = 9194602172 | = Mobile: +1 = 9194121167 
O= racle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North = Carolina 27560

Oracle is committed to developing practices and products that help = protect the = environment

 

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

=

 

 = ;

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

 

------=_NextPart_001_008A_01CEF665.F48A7ED0-- ------=_NextPart_000_0089_01CEF665.F48A7ED0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIx MTE2NDEzOVowIwYJKoZIhvcNAQkEMRYEFKai+NetN/tYxN6jUD79JGkXSZ5WMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAhSc+6REv0FG2Y+OftcK+vVSKqwUk0gZ76a2N7zls 4Bphni+ZhpPbwJFjRGlFoQ6LdoQYheLawj4Rith7DN8NgXxCwB66VDInbrLuIi9+BZS7wAXqociO u1ZeByFSVKW5etY1PDL/KgFQ/X5QtEM4NUTRM93S444ynSaBPb5bJM1wHGd0fLG8ZiEzwzLh+4CS NQRPAhDU4MdBwyHwtMH4SYQAxcvFy4c3TV0+8myARCx426AQ8VHazHflNb2nxlErV4LQDhcFu/Gw lF5KpD1YtHnYh9WiLo0NEIySyKupbfpvg9D9HWSXSVYOWMEDT1PGmAczkaoceSuUoLsV+MdQXgAA AAAAAA== ------=_NextPart_000_0089_01CEF665.F48A7ED0-- From Pierce.Gorman@sprint.com Wed Dec 11 09:09:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAE11ADFA8 for ; Wed, 11 Dec 2013 09:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhgUPgoCO-4L for ; Wed, 11 Dec 2013 09:09:09 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8B1ADF2F for ; Wed, 11 Dec 2013 09:09:09 -0800 (PST) Received: from mail17-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Wed, 11 Dec 2013 17:09:03 +0000 Received: from mail17-tx2 (localhost [127.0.0.1]) by mail17-tx2-R.bigfish.com (Postfix) with ESMTP id B91F524017D; Wed, 11 Dec 2013 17:09:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.26; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm2.corp.sprint.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VS-34(zz98dI9371Ic85fh1418I1453Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275ch93eR1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h1155h) Received-SPF: pass (mail17-tx2: domain of sprint.com designates 144.230.168.26 as permitted sender) client-ip=144.230.168.26; envelope-from=Pierce.Gorman@sprint.com; helo=plsasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail17-tx2 (localhost.localdomain [127.0.0.1]) by mail17-tx2 (MessageSwitch) id 1386781739152342_18034; Wed, 11 Dec 2013 17:08:59 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.226]) by mail17-tx2.bigfish.com (Postfix) with ESMTP id 17A8E60075; Wed, 11 Dec 2013 17:08:59 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 11 Dec 2013 17:08:58 +0000 Received: from PLSWEH05.ad.sprint.com (plsweh05.corp.sprint.com [144.226.251.23]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rBBH8ve1018423 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 11:08:57 -0600 Received: from pdawm10a.ad.sprint.com ([169.254.2.104]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 11:08:57 -0600 From: "Gorman, Pierce A [NTK]" To: Michael Hammer , "br@brianrosen.net" Thread-Topic: [stir] Comments/Queries? Thread-Index: AQHO9oV7u+TyEbGOsUaF/Fva4Ojak5pPKK4ggABpR4CAAAVPgP//og+g Date: Wed, 11 Dec 2013 17:08:56 +0000 Message-ID: References: <95d7f94b-99b6-4ca8-9d06-10cfc7f5881d@default> <52E954B2-771D-4FF3-B244-98F07454F076@brianrosen.net> <0a1a55d5-2f3f-401e-86b5-1a59e89b683c@default> <01E42FD6-D293-4A58-91B3-1C6EEEEBE4B2@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF07D36@sc9-ex2k10mb1.corp.yaanatech.com> <393B2F03-E77A-432B-9C9E-34E1C0FB4D13@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF07E98@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF07E98@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.67] Content-Type: multipart/alternative; boundary="_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197A01PDAWM10Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "stir@ietf.org" , "travis.russell@oracle.com" Subject: Re: [stir] Comments/Queries? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:09:19 -0000 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197A01PDAWM10Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. I think that is the goal. Actual prevention of misuse implies far more than what can be practically a= chieved in a global context with a protocol implementation. Pierce Gorman From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: December 11, 2013 10:42 AM To: br@brianrosen.net; Gorman, Pierce A [NTK] Cc: travis.russell@oracle.com; stir@ietf.org Subject: RE: [stir] Comments/Queries? Yeah, I guess to be more precise, allow receiver to know, when they can validate, that the number is good, or when they can't validate, to know that they don't know. Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, December 11, 2013 11:23 AM To: Gorman, Pierce A [NTK] Cc: Michael Hammer; travis.russell@oracle.com; stir@ietf.org Subject: Re: [stir] Comments/Queries? Yes, although you recognize that we also have to deal with phase in, and si= tuations such as PSTN-PSTN that we can't realistically affect. Brian On Dec 11, 2013, at 11:06 AM, Gorman, Pierce A [NTK] > wrote: Is the goal to prevent misuse or only to validate calling number where/when= possible and therefore imply when potential misuse may have occurred (beca= use of a lack of validation)? Best regards, Pierce Gorman From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: December 11, 2013 9:27 AM To: br@brianrosen.net; travis.russell@oracle.com<= mailto:travis.russell@oracle.com> Cc: stir@ietf.org Subject: Re: [stir] Comments/Queries? AFAIK, the freephone SPs are authorized to originate the calls on those num= bers. So, that is NOT spoofing. Let's not water down the meaning of terms. The goal is to stop someone from using numbers not assigned or delegated to= them. Mike From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, December 11, 2013 8:47 AM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? Inline On Dec 11, 2013, at 6:50 AM, Travis Russell > wrote: Thanks Brian, Agreed. But remember most of us use our cell phones these days, and the nam= e comes from your address book based on number. Not the problem calls - they aren't in your address book. Calling name will be a challenge since the service providers providing CNAM= services to the operators are challenged to get the names right. And if yo= u send a correction to your own name it sometimes does not get fixed perman= ently as the next bulk load reverts back to the old files. Yes, there are quite a few challenges. You might go back into the archive = of the knit list (and this list just before we created cnit) where some sol= utions were proposed. I like the label of "pink" service providers. There are also those that off= er spoofing as a service. You call a freephone number, your call is termina= ted on the VoIP switch where you are asked for the number you want to appea= r, and the call re-originated. These come through as legitimate calls to th= e major service providers, and when tracing the call you can only trace as = far back as the spoofing service. Perfectly legitimate companies by the way= , as there is nothing illegal about spoofing your number. The mechanisms we are discussing would stop this unless the spoofing servic= e was authorized to place calls on the numbers it was using. I only provide all this info because it is important for all of us to under= stand the problem and how it manifests itself within service provider netwo= rks. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect = the environment From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:46 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? What users look at for numbers they have not memorized is name. They can't= tell anything from the number. In the IETF work, we have split name and number. We'll come up with the n= umber solution first, and then work on name. The name discussions are on a= separate list (cnit). Most of the bad calls we see are from what I usually call "pink" service pr= oviders. They aren't actually complicit, but they look the other way as th= eir subscribers spoof name and number. They don't run FMS systems. I am t= old that wholesale divisions of major carriers sometimes are the unwitting = origination carrier, because there are many instances of permitted "spoofin= g" (call centers calling on behalf of another enterprise for example) which= means they don't scrutinize calling party number on the wholesale side. H= owever, the majority of the bad calls come from these "pink" carriers. We all agree we need to get the number reliable first. Brian On Dec 10, 2013, at 5:38 PM, Travis Russell > wrote: Thanks Brian for the clarifications. The FMS I am referring to are the FSM = used by service providers that look for anomalies in subscriber behaviors. = These systems look at behaviors of inbound and outbound callers, and provid= e alarms/flags to the fraud department when there is an anomaly occurring. = One "trick" used by fraud investigators is to assign dark numbers throughou= t their number ranges. When the dark number is hit several times, it indica= tes a hacker trying to create a hit list. There are a number of variations = to this technique but it is common for fraudsters to spend a fair amount of= time honing their hit lists prior to launching an attack. The FMS also looks for short calls, velocity of calls, etc to identify anom= alies, and there are thresholds in the network that fraudsters eventually d= iscover to ensure they "fly under the radar" of these systems. All of that = said to make the point that fraudsters absolutely care about the numbers be= ing legitimate to prevent detection by the many systems put in place by fra= ud departments. In the case of the calling party name, is it thought that the name display = is critical to this process? My understanding is that the number itself is = the critical element, and the name is just a convenience provided to subscr= ibers. There are many errors in the calling name database so personally I d= on't even pay attention to that anymore. The number on the other hand is ab= solutely important. By the way, in wireless communications, the calling par= ty name is driven by the address book on the device itself, and not CNAM. I mention this because in the problem statement it sounds like the calling = party name is of equal importance to validation as the number. -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect = the environment From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, December 10, 2013 5:25 PM To: Travis Russell Cc: stir@ietf.org List Subject: Re: [stir] Comments/Queries? The caller name comes from a database queried by the calling telephone numb= er. Usually, the display name in the SIP message is not used. That's not = always true (enterprise internal PBX for example). Certainly, if you recei= ve the call from a POTS phone, whatever is in the SIP signaling for display= name is not even available to the called party or her service provider. The conventional implementation is the database is operated by the calling = service provider. The called service provider dips the database with the c= alling party TN obtained in the signaling. If you can spoof the calling party number, you can cause the name to be any= name that is already in the database. The fraud management systems you are referring to sound like the ones inbou= nd systems call centers use to identify fraudulent inbound callers. I'm no= t aware of any service provider attempting to identify fraudulent callers o= n behalf of a typical residential or enterprise customer. We have most certainly considered number portability in this system. The c= redentials will change when numbers port. The old credential will become i= nvalid (or the coverage of the credential will change if the credential has= more than one TN associated with it). A new credential will be issued, or= an existing credential will get another TN associated with it. We did agree that we could have some delay of this (or, rather, that we wou= ld not attempt to invalidate cacheing of credentials. If, following a port= , the old holder could spoof the call for some minutes, or even hours, that= would probably be okay. Brian On Dec 10, 2013, at 3:31 PM, Travis Russell > wrote: Looking at the following paragraph: For numbers where the caller has suppressed textual caller identification, = number spoofing can be used to retrieve this information, stored in the so-= called Calling Name (CNAM) database. It is my experience that spoofing is simply accomplished via VoIP servers m= odifying the SIP fields. There are a number of ways this has been facilitat= ed - you can call a spoof service where the call is terminated on a VoIP se= rver, and when prompted enter the telephone number you want to appear as th= e calling party (works great - I have tried this myself). The VoIP server t= han re-originates the call and sends it to the called party with the new "s= poofed" identity. I am not familiar with any cases where the spoofed identity was retrieved f= rom a SNAM server (although I may be wrong in this case). In the paragraph immediately after: For anonymization, the caller does not necessarily care whether the number = is in service, or who it is assigned to, and may switch rapidly and possibl= y randomly between numbers. Anonymization facilitates automated illegal te= lemarketing or telephony denial-of-service attacks, as described above, as = it makes it difficult to blacklist numbers. A hacker or fraudster will typically use a "hit list" when doing this, beca= use fraud management systems look for calls to/from unassigned numbers (man= y operators assign "dark numbers" in their number ranges to identify hacker= s looking for assigned numbers). They will try to use assigned numbers of l= egitimate subscribers to alleviate discovery by FMS or network "traps" wher= e dark numbers are assigned. It is the fact that they are using legitimate = subscriber identities that makes it impossible to black list, because you a= re effecting the good subscribers service. QUESTION: How will validation/verification work in the case of number porta= bility where a number once assigned to one operator is now assigned to anot= her operator? Has consideration been given to updates through the number po= rtability process in these cases or is this a mute point? -- Travis Russell | Technologist, Sr. Mgr Phone: +1 9194602172 | Mobile: +1 9194121167 Oracle CGBU Product Marketing 5200 Paramount Pkwy | Morrisville, North Carolina 27560 Oracle is committed to developing practices and products that help protect = the environment _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197A01PDAWM10Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes.  I think that i= s the goal.

 

Actual prevention of misu= se implies far more than what can be practically achieved in a global conte= xt with a protocol implementation.

 

Pierce Gorman

 

From: Michae= l Hammer [mailto:michael.hammer@yaanatech.com]
Sent: December 11, 2013 10:42 AM
To: br@brianrosen.net; Gorman, Pierce A [NTK]
Cc: travis.russell@oracle.com; stir@ietf.org
Subject: RE: [stir] Comments/Queries?

 

Yeah, I guess to be mor= e precise,

allow receiver to know,= when they can validate, that the number is good,

or when they can’= t validate, to know that they don’t know.

 

Mike

 

 

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, December 11, 2013 11:23 AM
To: Gorman, Pierce A [NTK]
Cc: Michael Hammer; tra= vis.russell@oracle.com; stir@ietf.org
Subject: Re: [stir] Comments/Queries?

 

Yes, although you recognize that we also have to dea= l with phase in, and situations such as PSTN-PSTN that we can’t reali= stically affect.

 

Brian

 

On Dec 11, 2013, at 11:06 AM, Gorman, Pierce A [NTK]= <Pierce.Gorman@sprint.com> wrote:

 

Is the goal to prevent mi= suse or only to validate calling number where/when possible and therefore i= mply when potential misuse may have occurred (because of a lack of validation)? 

 

 

Best regards,

 

 

Pierce Gorman

 

 

From: Michael Hammer [mailto:michael.ham= mer@yaanatech.com]  Sent: December 11,= 2013 9:27 AM
To: br@brianrosen.net; travis.russell@oracle.com<= br> Cc: stir@ietf.org
Subject: Re: [stir= ] Comments/Queries?

 

AFAIK, the freephone SP= s are authorized to originate the calls on those numbers.

So, that is NOT spoofin= g.  Let’s not water down the meaning of terms.

 

The goal is to stop som= eone from using numbers not assigned or delegated to them.

 

Mike

 

 

From: stir [mai= lto:stir-bounces@ietf.org]=  On Behalf Of Brian Rosen
Sent: Wednesday, D= ecember 11, 2013 8:47 AM
To: Travis Russell=
Cc: stir@ietf.org List
Subject: Re: [stir= ] Comments/Queries?

 

Inline

On Dec 11, 2013, at 6:50 AM, Travis Russell <travi= s.russell@oracle.com> wrote:

 

Thanks Brian,

 

Agreed. But remember mo= st of us use our cell phones these days, and the name comes from your addre= ss book based on number.

Not the problem calls - they aren’t in your ad= dress book.

 

 

Calling name will be a = challenge since the service providers providing CNAM services to the operat= ors are challenged to get the names right. And if you send a correction to your own name it sometimes does not get fixed permanently = as the next bulk load reverts back to the old files.

Yes, there are quite = a few challenges.  You might go back into the archive of the knit list= (and this list just before we created cnit) where some solutions were prop= osed.

 

I like the label of = 220;pink” service providers. There are also those that offer spoofing= as a service. You call a freephone number, your call is terminated on the VoIP switch where you are asked for the number you want to appear, = and the call re-originated. These come through as legitimate calls to the m= ajor service providers, and when tracing the call you can only trace as far= back as the spoofing service. Perfectly legitimate companies by the way, as there is nothing illegal about spoofin= g your number.

The mechanisms we are discussing would stop this unl= ess the spoofing service was authorized to place calls on the numbers it wa= s using.  

 

 

I only provide all this= info because it is important for all of us to understand the problem and h= ow it manifests itself within service provider networks.

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr<= br> Phone: +1 9194602172=  | Mobile: +1 9194121167  Oracle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 27560

Oracle is committed to d= eveloping practices and products that help protect the environment

 

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: Tuesday, Dec= ember 10, 2013 5:46 PM
To: Travis Russell=
Cc: stir@ietf.org List
Subject: Re: [stir= ] Comments/Queries?

 

What users look at for numbers they have not memoriz= ed is name.  They can’t tell anything from the number.

 

In the IETF work, we have split  name and numbe= r.  We’ll come up with the number solution first, and then work = on name.  The name discussions are on a separate list (cnit).

 

Most of the bad calls we see are from what I usually= call “pink” service providers.  They aren’t actuall= y complicit, but they look the other way as their subscribers spoof name an= d number.  They don’t run FMS systems.  I am told that whol= esale divisions of major carriers sometimes are the unwitting origination carrie= r, because there are many instances of permitted “spoofing” (ca= ll centers calling on behalf of another enterprise for example) which means= they don’t scrutinize calling party number on the wholesale side.  However, the majority of the bad calls come f= rom these “pink” carriers.  

 

We all agree we need to get the number reliable firs= t.

 

Brian

 

 

On Dec 10, 2013, at 5:38 PM, Travis Russell <travi= s.russell@oracle.com> wrote:

 

Thanks Brian for the cl= arifications. The FMS I am referring to are the FSM used by service provide= rs that look for anomalies in subscriber behaviors. These systems look at behaviors of inbound and outbound callers, and provide ala= rms/flags to the fraud department when there is an anomaly occurring. One &= #8220;trick” used by fraud investigators is to assign dark numbers th= roughout their number ranges. When the dark number is hit several times, it indicates a hacker trying to create a hit = list. There are a number of variations to this technique but it is common f= or fraudsters to spend a fair amount of time honing their hit lists prior t= o launching an attack.

 

The FMS also looks for = short calls, velocity of calls, etc to identify anomalies, and there are th= resholds in the network that fraudsters eventually discover to ensure they “fly under the radar” of these systems. All of = that said to make the point that fraudsters absolutely care about the numbe= rs being legitimate to prevent detection by the many systems put in place b= y fraud departments.

 

In the case of the call= ing party name, is it thought that the name display is critical to this pro= cess? My understanding is that the number itself is the critical element, and the name is just a convenience provided to subscribe= rs. There are many errors in the calling name database so personally I don&= #8217;t even pay attention to that anymore. The number on the other hand is= absolutely important. By the way, in wireless communications, the calling party name is driven by the address b= ook on the device itself, and not CNAM.

 

I mention this because = in the problem statement it sounds like the calling party name is of equal = importance to validation as the number.

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr<= br> Phone: +1 9194602172=  | Mobile: +1 9194121167  Oracle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 27560

Oracle is committed to d= eveloping practices and products that help protect the environment

 

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: Tuesday, Dec= ember 10, 2013 5:25 PM
To: Travis Russell=
Cc: stir@ietf.org List
Subject: Re: [stir= ] Comments/Queries?

 

The caller name comes from a database queried by the= calling telephone number.  Usually, the display name in the SIP messa= ge is not used.  That’s not always true (enterprise internal PBX= for example).  Certainly, if you receive the call from a POTS phone, whatever is in the SIP signaling for display name is no= t even available to the called party or her service provider. 

 

The conventional implementation is the database is o= perated by the calling service provider.  The called service provider = dips the database with the calling party TN obtained in the signaling. &nbs= p;

 

If you can spoof the calling party number, you can c= ause the name to be any name that is already in the database.

 

The fraud management systems you are referring to so= und like the ones inbound systems call centers use to identify fraudulent i= nbound callers.  I’m not aware of any service provider attemptin= g to identify fraudulent callers on behalf of a typical residential or enterprise customer.

 

We have most certainly considered number portability= in this system.  The credentials will change when numbers port.  = ;The old credential will become invalid (or the coverage of the credential = will change if the credential has more than one TN associated with it).  A new credential will be issued, or an e= xisting credential will get another TN associated with it.

 

We did agree that we could have some delay of this (= or, rather, that we would not attempt to invalidate cacheing of credentials= .  If, following a port, the old holder could spoof the call for some = minutes, or even hours, that would probably be okay.

 

Brian

 

 

On Dec 10, 2013, at 3:31 PM, Travis Russell <travi= s.russell@oracle.com> wrote:

 

Looking at the following paragraph:

For numbers where the caller has suppr= essed textual caller identification, number spoofing can be used to retriev= e this information, stored in the so-called Calling Name (CNAM) database.

 

It is my experience that spoofing is s= imply accomplished via VoIP servers modifying the SIP fields. There are a n= umber of ways this has been facilitated – you can call a spoof service where the call is terminated on a VoIP server, and when prom= pted enter the telephone number you want to appear as the calling party (wo= rks great – I have tried this myself). The VoIP server than re-origin= ates the call and sends it to the called party with the new “spoofed” identity.

 

I am not familiar with any cases where= the spoofed identity was retrieved from a SNAM server (although I may be w= rong in this case).

 

In the paragraph immediately after:

For anonymization, the caller does not= necessarily care whether the number is in service, or who it is assigned t= o, and may switch rapidly and possibly randomly between numbers.  Anonymization facilitates automated illegal telemarketing o= r telephony denial-of-service attacks, as described above, as it makes it d= ifficult to blacklist numbers. 

 

A hacker or fraudster will typically u= se a “hit list” when doing this, because fraud management syste= ms look for calls to/from unassigned numbers (many operators assign “dark numbers” in their number ranges to identify hackers look= ing for assigned numbers). They will try to use assigned numbers of legitim= ate subscribers to alleviate discovery by FMS or network “traps”= ; where dark numbers are assigned. It is the fact that they are using legitimate subscriber identities that makes it impossible to bla= ck list, because you are effecting the good subscribers service.

 

QUESTION: How will validation/verifica= tion work in the case of number portability where a number once assigned to= one operator is now assigned to another operator? Has consideration been given to updates through the number portability process in these case= s or is this a mute point?

 

-- 
<image001.gif>
Travis Russell | Technologist, Sr. Mgr
Phone: +1 9194602172=  | Mobile: +1 9194121167  Oracle CGBU Product Marketing
5200 Paramount Pkwy | Morrisville, North Carolina 27560

Oracle is committed to d= eveloping practices and products that help protect the environment

 

_____________________________________= __________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855197A01PDAWM10Aadsprin_-- From rjsparks@nostrum.com Mon Dec 16 07:48:25 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28C71AE348 for ; Mon, 16 Dec 2013 07:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1V6fpaW2EtI for ; Mon, 16 Dec 2013 07:48:24 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 576E11AE343 for ; Mon, 16 Dec 2013 07:48:24 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGFmNru082487 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Mon, 16 Dec 2013 09:48:23 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <52AF20C8.8080809@nostrum.com> Date: Mon, 16 Dec 2013 09:48:24 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: stir@ietf.org References: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> In-Reply-To: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism) Subject: Re: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 15:48:25 -0000 One week remains in this LC. Please send any input you wish to have reflected as soon as you can. Thanks, RjS On 12/9/13 1:12 PM, Russ Housley wrote: > The authors have posted an updated Internet-Draft on the STIR problem statement. It can be found here: http://www.ietf.org/id/draft-ietf-stir-problem-statement-01.txt. > > Is this document ready for the STIR WG to pass to the IESG, requesting publication as an Informational RFC? Please provide your input on this mail list by end-of-business on 23 December 2013. If you have issues or concerns, please tell us what changes to the document are necessary to resolve them. > > Russ > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dfrankel@zipdx.com Mon Dec 16 12:22:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CFD1AC4C1 for ; Mon, 16 Dec 2013 12:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMYvxjBlMb0l for ; Mon, 16 Dec 2013 12:21:59 -0800 (PST) Received: from xdev1sjc.zipdx.com (sjc119.zipdx.com [72.51.53.119]) by ietfa.amsl.com (Postfix) with ESMTP id C63001AC499 for ; Mon, 16 Dec 2013 12:21:59 -0800 (PST) Received: from DPFyoga (c-76-103-140-126.hsd1.ca.comcast.net [76.103.140.126]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dfrankel) by xdev1sjc.zipdx.com (Postfix) with ESMTPSA id 1B9A78BC040; Mon, 16 Dec 2013 12:21:59 -0800 (PST) From: "David Frankel" To: "'Robert Sparks'" , References: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> <52AF20C8.8080809@nostrum.com> In-Reply-To: <52AF20C8.8080809@nostrum.com> Date: Mon, 16 Dec 2013 12:21:55 -0800 Organization: ZipDX LLC Message-ID: <03fe01cefa9c$772a5bf0$657f13d0$@zipdx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNDRgBhp2jC2Oa6zPjqjQf/5cjczwH8+Ks5l167O6A= Content-Language: en-us Subject: Re: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:22:03 -0000 Here are four comments on the Problem Statement draft: A) In section 2 there is the statement: "...the Federal Communications Commission (FCC) recently organized a robocall competition..." This is erroneous; the robocall competition was organized (or at least sponsored) by the Federal TRADE Commission (FTC). The same error is in footnote 18. B) In section 2, there is a comment that "[a]nonymization facilitates automated illegal telemarketing or telephone denial-of-service attacks, as described above, as it makes it difficult to blacklist numbers." I suggest augmenting this to indicate that it makes it easy for the perpetrators to evade detection and enforcement (which is the implication in the next sentence.) My point is that blacklisting is not really a desirable solution (blacklists are administratively quite challenging), so "enabling" blacklisting is not such a great outcome. Improved tracing, tracking and enforcement by means of a verifiable originating address will serve as a significant deterrent. C) There is a lot of discussion throughout the document of B2BUAs. Typically these relays are set up by the "network" as a call is handed off from one provider/carrier to another. There is another type of relay, "Call Forwarding," that is end-user controlled; Brian Rosen and others contributed some discussion of that earlier on the list. It might be worth adding a reference to this type of relay. Its use is pervasive in legacy voice-mail systems (referenced elsewhere in the document as a hacking target), and is also common in "Find-Me/Follow-Me" or "One-Number" services. Calls that are forwarded this way retain the FROM telephone number of the originating caller; the forwarded-to number becomes the destination (TO header) and the intermediary (forwarding) number is most often (in my experience) captured in the DIVERSION header, which is interworked with the ISUP REDIRECTING NUMBER information element. Under what circumstances, if any, the STIR effort would address these relays remains to be seen, but it probably ought to be mentioned as part of the Problem Statement to insure that it gets dealt with explicitly. D) Other telephone numbers also show up in call signaling. There is an ISUP CHARGE NUMBER (sometimes called ANI) that is often interworked with SIP P-CHARGE-INFO. The authenticity of this number might or might not be validated by the mechanisms contemplated in STIR; again, it might be worth a mention in the Problem Statement. Spoofing or other manipulation of this value occurs frequently in the USA to arbitrage intercarrier compensation (which admittedly may be completely gone by the time STIR sees the light of day). David Frankel ZipDXR LLC Los Gatos CA USA Tel: 1-800-FRANKEL (1-800-372-6535) -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, December 16, 2013 7:48 AM To: stir@ietf.org Subject: Re: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt One week remains in this LC. Please send any input you wish to have reflected as soon as you can. Thanks, RjS On 12/9/13 1:12 PM, Russ Housley wrote: > The authors have posted an updated Internet-Draft on the STIR problem statement. It can be found here: http://www.ietf.org/id/draft-ietf-stir-problem-statement-01.txt. > > Is this document ready for the STIR WG to pass to the IESG, requesting publication as an Informational RFC? Please provide your input on this mail list by end-of-business on 23 December 2013. If you have issues or concerns, please tell us what changes to the document are necessary to resolve them. > > Russ > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Tue Dec 17 13:45:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4711AC49D for ; Tue, 17 Dec 2013 13:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.301 X-Spam-Level: X-Spam-Status: No, score=-104.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMcXUv76Lbvw for ; Tue, 17 Dec 2013 13:45:16 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBA21A9313 for ; Tue, 17 Dec 2013 13:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1387316872; x=1702659052; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ScN+51CTfk UJL9NAqCCsRz/0Dk5XXU/z8FFjgila1sk=; b=bXlfgSGM1FIyaGApKxHNpPnRJP YouwJatNFHOLAeEawj4Lkves/8Rb8he2mGx1L4XWatjtASM+kal6omoDiW3w== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.36517799; Tue, 17 Dec 2013 16:47:51 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.245]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 17 Dec 2013 16:45:08 -0500 From: "Peterson, Jon" To: David Frankel , 'Robert Sparks' , "stir@ietf.org" Thread-Topic: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt Thread-Index: AQHO9RLJUTIShWRHrUOuZKdkie12BZpXVi0AgABMbICAASN1gA== Date: Tue, 17 Dec 2013 21:45:08 +0000 Message-ID: In-Reply-To: <03fe01cefa9c$772a5bf0$657f13d0$@zipdx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.129.172] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: fDXmxHGPEgxJHfXxwXgXbA== Content-Type: text/plain; charset="us-ascii" Content-ID: <0CE2BDCA13A15646A5A6BF16018ACF8E@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 21:45:18 -0000 Thanks for these comments, David. A few notes below: >A) In section 2 there is the statement: "...the Federal Communications >Commission (FCC) recently organized a robocall competition..." This is >erroneous; the robocall competition was organized (or at least sponsored) >by >the Federal TRADE Commission (FTC). The same error is in footnote 18. Right, will fix that. >B) In section 2, there is a comment that "[a]nonymization facilitates >automated illegal telemarketing or telephone denial-of-service attacks, as >described above, as it makes it difficult to blacklist numbers." I suggest >augmenting this to indicate that it makes it easy for the perpetrators to >evade detection and enforcement (which is the implication in the next >sentence.) My point is that blacklisting is not really a desirable >solution >(blacklists are administratively quite challenging), so "enabling" >blacklisting is not such a great outcome. Improved tracing, tracking and >enforcement by means of a verifiable originating address will serve as a >significant deterrent. I'd certainly be willing to change to that to "as it makes it difficult to identity perpetrators and craft policies to block them." >C) There is a lot of discussion throughout the document of B2BUAs. >Typically >these relays are set up by the "network" as a call is handed off from one >provider/carrier to another. There is another type of relay, "Call >Forwarding," that is end-user controlled; Brian Rosen and others >contributed >some discussion of that earlier on the list. It might be worth adding a >reference to this type of relay. Its use is pervasive in legacy voice-mail >systems (referenced elsewhere in the document as a hacking target), and is >also common in "Find-Me/Follow-Me" or "One-Number" services. Calls that >are >forwarded this way retain the FROM telephone number of the originating >caller; the forwarded-to number becomes the destination (TO header) and >the >intermediary (forwarding) number is most often (in my experience) captured >in the DIVERSION header, which is interworked with the ISUP REDIRECTING >NUMBER information element. Under what circumstances, if any, the STIR >effort would address these relays remains to be seen, but it probably >ought >to be mentioned as part of the Problem Statement to insure that it gets >dealt with explicitly. We did add some text about call forwarding in the last version of the draft, see the last paragraph of Section 2 (before the bullet points). It explicitly mentions the fact that calls forwarded in this fashion retain their original" From" number. It doesn't explicitly call out "Fine Me/Follow Me" or similar services, but it notes the core problem. >D) Other telephone numbers also show up in call signaling. There is an >ISUP >CHARGE NUMBER (sometimes called ANI) that is often interworked with SIP >P-CHARGE-INFO. The authenticity of this number might or might not be >validated by the mechanisms contemplated in STIR; again, it might be >worth a >mention in the Problem Statement. Spoofing or other manipulation of this >value occurs frequently in the USA to arbitrage intercarrier compensation >(which admittedly may be completely gone by the time STIR sees the light >of >day). I think the current scope of STIR is to identify the calling telephone number. Securing other information signaled within the call, except where necessary for reference integrity to bind the calling telephone number to a particular call, is out of scope. Jon Peterson Neustar, Inc. >David Frankel >ZipDXR LLC >Los Gatos CA USA >Tel: 1-800-FRANKEL (1-800-372-6535) > >-----Original Message----- >From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks >Sent: Monday, December 16, 2013 7:48 AM >To: stir@ietf.org >Subject: Re: [stir] WG Last Call on >draft-ietf-stir-problem-statement-01.txt > >One week remains in this LC. Please send any input you wish to have >reflected as soon as you can. > >Thanks, >RjS > >On 12/9/13 1:12 PM, Russ Housley wrote: >> The authors have posted an updated Internet-Draft on the STIR problem >statement. It can be found here: >http://www.ietf.org/id/draft-ietf-stir-problem-statement-01.txt. >> >> Is this document ready for the STIR WG to pass to the IESG, requesting >publication as an Informational RFC? Please provide your input on this >mail >list by end-of-business on 23 December 2013. If you have issues or >concerns, please tell us what changes to the document are necessary to >resolve them. >> >> Russ >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Mon Dec 23 08:48:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B31AE165 for ; Mon, 23 Dec 2013 08:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syv-xqyhvGHT for ; Mon, 23 Dec 2013 08:48:00 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 52F8A1ADF6E for ; Mon, 23 Dec 2013 08:48:00 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 859BB9A420D for ; Mon, 23 Dec 2013 11:47:47 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id VGdKGJhvjyB8 for ; Mon, 23 Dec 2013 11:47:26 -0500 (EST) Received: from [192.168.2.110] (pool-96-255-140-248.washdc.fios.verizon.net [96.255.140.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B70AB9A41FD for ; Mon, 23 Dec 2013 11:47:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> Date: Mon, 23 Dec 2013 11:47:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7845402A-8859-459D-8636-E1081274E9F7@vigilsec.com> References: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 16:48:02 -0000 WG Last Call ends today. Based on the messages that I have seen so far, = a few changes are needed to the document, and Jon has agreed to make = them. Russ On Dec 9, 2013, at 2:12 PM, Russ Housley wrote: > The authors have posted an updated Internet-Draft on the STIR problem = statement. It can be found here: = http://www.ietf.org/id/draft-ietf-stir-problem-statement-01.txt. >=20 > Is this document ready for the STIR WG to pass to the IESG, requesting = publication as an Informational RFC? Please provide your input on this = mail list by end-of-business on 23 December 2013. If you have issues or = concerns, please tell us what changes to the document are necessary to = resolve them. >=20 > Russ From housley@vigilsec.com Tue Dec 24 08:04:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7961ADFB0 for ; Tue, 24 Dec 2013 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o-VYjtcDa8g for ; Tue, 24 Dec 2013 08:04:45 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECD31ADFA7 for ; Tue, 24 Dec 2013 08:04:45 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 1912B9A4210 for ; Tue, 24 Dec 2013 11:04:32 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id dOJqR8DdR1Tk for ; Tue, 24 Dec 2013 11:04:10 -0500 (EST) Received: from [192.168.2.110] (pool-96-255-140-248.washdc.fios.verizon.net [96.255.140.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B3B009A420F for ; Tue, 24 Dec 2013 11:04:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <7845402A-8859-459D-8636-E1081274E9F7@vigilsec.com> Date: Tue, 24 Dec 2013 11:03:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68E39A12-0897-4D9C-846C-8F6F2C217C46@vigilsec.com> References: <5B9321E4-CD56-462A-902A-C5D102563901@vigilsec.com> <7845402A-8859-459D-8636-E1081274E9F7@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] WG Last Call on draft-ietf-stir-problem-statement-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 16:04:47 -0000 I did not see any new comments by yesterday, so once Jon makes the = changes to the problem statement document, it will be ready for the = IESG. Please enjoy the holidays. We will begin WG Last Call on the threats = document shortly after the holidays. Russ On Dec 23, 2013, at 11:47 AM, Russ Housley wrote: > WG Last Call ends today. Based on the messages that I have seen so = far, a few changes are needed to the document, and Jon has agreed to = make them. >=20 > Russ >=20 >=20 > On Dec 9, 2013, at 2:12 PM, Russ Housley wrote: >=20 >> The authors have posted an updated Internet-Draft on the STIR problem = statement. It can be found here: = http://www.ietf.org/id/draft-ietf-stir-problem-statement-01.txt. >>=20 >> Is this document ready for the STIR WG to pass to the IESG, = requesting publication as an Informational RFC? Please provide your = input on this mail list by end-of-business on 23 December 2013. If you = have issues or concerns, please tell us what changes to the document are = necessary to resolve them. >>=20 >> Russ >=20