Re: [stir] Permitted spoofing

"Rosen, Brian" <Brian.Rosen@neustar.biz> Mon, 10 June 2013 12:57 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 4C5F221F8B35 for <stir@ietfa.amsl.com>; Mon, 10 Jun 2013 05:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.417
X-Spam-Level:
X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, 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 XemMyHuwUVES for <stir@ietfa.amsl.com>; Mon, 10 Jun 2013 05:57:35 -0700 (PDT)
Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70321F8F4A for <stir@ietf.org>; Mon, 10 Jun 2013 05:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370868933; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=OIbbkBoqdm 6NMhZQILjy4jFuftCl7KNLDe1czbAfF5Q=; b=n/Sh6Nj8hLqNaETWYKm3GlH1HE e8CmFmFNnrUEpeeyKymYsRWkwdMfO62nJBi3r4XLZ2ce68YVFDuYLGvIM0hw==
Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19346061; Mon, 10 Jun 2013 08:55:31 -0400
Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 08:57:18 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 08:57:13 -0400
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
Thread-Topic: [stir] Permitted spoofing
Thread-Index: AQHOY+81QVR2lI4PHEaFqY34c3fHK5ksZHCAgAADK4CAAAkdAIACvoMA
Date: Mon, 10 Jun 2013 12:57:12 +0000
Message-ID: <A037F1CD-2F94-4529-AAE1-67AB0A716839@neustar.biz>
References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> <E18AFC23-F162-4EEE-AAC1-FEA53438E15A@oracle.com>
In-Reply-To: <E18AFC23-F162-4EEE-AAC1-FEA53438E15A@oracle.com>
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: 9K2Ml2bh0FzerJgisEXSQA==
Content-Type: text/plain; charset="us-ascii"
Content-ID: <880E09F043FFED41BCF2DA4C1CAF81AF@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Rosen, Brian" <Brian.Rosen@neustar.biz>, "hgs@cs.columbia.edu" <hgs@cs.columbia.edu>, Michael Hammer <michael.hammer@yaanatech.com>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] Permitted spoofing
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: Mon, 10 Jun 2013 12:57:40 -0000

I agree, the point is to prevent bad calls.  I understand that following calls back through CDRs  is very difficult and time consuming from the point of view of the law enforcement agency doing the tracking.  That's why Henning would like us to come up with a way of automating that traceback.

Brian

On Jun 8, 2013, at 3:02 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

> 
> I think the hope was to proactively prevent a bogus call from succeeding, as opposed to reactively hunting down the perpetrators after it happened.  The latter case should be possible now, since CDRs record enough to backtrack to the upstream provider, and that provider's CDRs can find its upstream provider, etc.
> 
> -hadriel
> 
> 
> On Jun 8, 2013, at 2:30 PM, Michael Hammer <michael.hammer@yaanatech.com> wrote:
> 
>> Question:  Do we really care how many redirections occurred in the middle
>> network hops if we know what the original source of the signaling was?
>> 
>> Put another way, if we have a legitimate scape-goat for a problem call, do
>> you need to catch all the stooges all at once?
>> 
>> Mike
>> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir