IETF Logo Mail Archive

Re: [stir] Permitted spoofing

Michael Hammer <michael.hammer@yaanatech.com> Tue, 11 June 2013 06:13 UTC

Return-Path: <michael.hammer@yaanatech.com>
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 AFD1B21F9A73 for <stir@ietfa.amsl.com>; Mon, 10 Jun 2013 23:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
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 PluPi1mZA1La for <stir@ietfa.amsl.com>; Mon, 10 Jun 2013 23:12:55 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 93BDB21F8EB3 for <stir@ietf.org>; Mon, 10 Jun 2013 23:12:55 -0700 (PDT)
Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 10 Jun 2013 23:12:54 -0700
From: Michael Hammer <michael.hammer@yaanatech.com>
To: "hadriel.kaplan@oracle.com" <hadriel.kaplan@oracle.com>
Thread-Topic: [stir] Permitted spoofing
Thread-Index: AQHOY+81k0Rag7WUmkWt6dxCH9sPJpkslruA//+M/0CAAH9IAIADajdg
Date: Tue, 11 Jun 2013 06:12:53 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com>
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: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.17.100.132]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0000_01CE6683.D42D2380"
MIME-Version: 1.0
Cc: "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, "stir@ietf.org" <stir@ietf.org>, "hgs@cs.columbia.edu" <hgs@cs.columbia.edu>
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: Tue, 11 Jun 2013 06:13:00 -0000

If you stop it at the start, wouldn't that solve some fraction of the
problem?

Do we know how many calls are spoofed from the start versus from
redirections?

Mike


-----Original Message-----
From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] 
Sent: Saturday, June 08, 2013 10:03 PM
To: Michael Hammer
Cc: hgs@cs.columbia.edu; Brian.Rosen@neustar.biz; stir@ietf.org
Subject: Re: [stir] Permitted spoofing


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
>

v2.23.0 | Report a Bug | By Email