[stir] Call Forward/Follow-me

"Rosen, Brian" <Brian.Rosen@neustar.biz> Fri, 07 June 2013 18:18 UTC

Return-Path: <brian.rosen@neustar.biz>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F1321F9986 for <stir@ietfa.amsl.com>; Fri, 7 Jun 2013 11:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZJIPiXGWQVE for <stir@ietfa.amsl.com>; Fri, 7 Jun 2013 11:18:06 -0700 (PDT)
Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6483721F9977 for <stir@ietf.org>; Fri, 7 Jun 2013 11:18:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370629264; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=UKF0q2cVEO KFp+/z6pSH5OpToEFvhPXQOm4pBjihQVY=; b=NLdKh1Ik3KworvtWG3GlCCyQ6r 1ZhMLcJ5KT3A/tGdmMmJn5yC0NyutvSVcM/RfSNzNDGLd6BRkIzf6f67Ruqg==
Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24781497; Fri, 07 Jun 2013 14:21:03 -0400
Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 14:18:01 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:17:58 -0400
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: "stir@ietf.org" <stir@ietf.org>
Thread-Topic: Call Forward/Follow-me
Thread-Index: AQHOY6tWGjfCXtwTp0y4gL5mXFSX9A==
Date: Fri, 07 Jun 2013 18:17:57 +0000
Message-ID: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.193.6]
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: hY3rjWjF8ZCiNaniJIOnXA==
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C32F342A865DFC4EA3801DAF61522A28@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [stir] Call Forward/Follow-me
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jun 2013 18:18:11 -0000

A problem that has been noted is PBXs and other services that implement Call Forward and Follow-me by spoofing From to be the original caller when they originate a call from the PBX to the ultimate destination.  They do this so that the called party sees the original caller when they get the call.

If we outlaw spoofing, these services wouldn't be able to do that.  They would have to use History or other headers to pass the original calling party number.

I believe that we can't continue to allow this kind of spoofing.  There are other headers which are appropriate for use.

One of the arguments given is that in older systems such as POTS or 2G/3G, there is no way to get caller ID to show data from the other headers.  I think we have to accept such limitations.  Newer systems would not have that problem of course.

While it may be unfortunate that something like forward or follow-me doesn't work as well as it did, I think that it's the right tradeoff.

Please note that there are another class of calling party number spoofing circumstances we CAN do something about.  Suppose a doctor wants to place a call on her mobile that appears to come from her office number.  In that case the doctor can authorize the service that arranges that call.  They can get the cert for the office number and authorize the service to place calls with that number by giving them a cert for that authorization.  This also works for, as an example, a call center placing calls for an enterprise.

The difference is, of course, that the "spoofed" number is a number delegated to the entity spoofing, rather than the forward/follow me case where the spoofed number is the calling party and the entity spoofing is authorized by the called party.

Brian