Re: [stir] STIR's basic operational model with SIP

Richard Shockey <richard@shockey.us> Wed, 10 August 2016 19:57 UTC

Return-Path: <richard@shockey.us>
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 0679D12B04B for <stir@ietfa.amsl.com>; Wed, 10 Aug 2016 12:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
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 cUBRw3fOgLpD for <stir@ietfa.amsl.com>; Wed, 10 Aug 2016 12:57:35 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 9066712D0B3 for <stir@ietf.org>; Wed, 10 Aug 2016 12:57:35 -0700 (PDT)
Received: (qmail 5346 invoked by uid 0); 10 Aug 2016 19:57:32 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 10 Aug 2016 19:57:32 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id VXsU1t00m1MNPNq01XsXVg; Wed, 10 Aug 2016 13:52:32 -0600
X-Authority-Analysis: v=2.1 cv=LOD1Hvm9 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=etTHQkYnwnYA:10 a=7z1cN_iqozsA:10 a=PeFO9FbFhS32YxYntvkA:9 a=M0OflfRGAAAA:8 a=HLLxP2VMAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=h-sXjZp9n5SqkSxe7T4A:9 a=df5f4K9NEhm3VrW8:21 a=icWvjc1XmxlvJVfG:21 a=QEXdDO2ut3YA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ONCuO51ud02Kl9e9azAA:9 a=yEsC2vKTknWlYOJ_:21 a=XT1TtnKZXoHwabyw:21 a=I7pwPLVKm0WnmpVm:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=6yl0mh0s51TKORVA8GqK:22 a=5oret6oapBRfLy7jekVI:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date; bh=lasLYCEJDqq2FK7eC9+Pgow1GCCN4ppR9YvP8bX6ZrQ=; b=jEbn sXyiN90QRQ6gjwhVEVYAaMwDtm6Ly4skQVaXg0w5JQzWA3P/TM5AbefQS8gpNuQd/ST7XWpg/brpu kjLkdjgvH+3rSUs/ExnxZhwi9ivgX7MZKAN7ZNgrOxCGZvI;
Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:49990 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <richard@shockey.us>) id 1bXZYC-0003as-JE; Wed, 10 Aug 2016 13:52:28 -0600
User-Agent: Microsoft-MacOutlook/f.18.0.160709
Date: Wed, 10 Aug 2016 15:52:26 -0400
From: Richard Shockey <richard@shockey.us>
To: Brian Rosen <br@brianrosen.net>, Andy Hutton <andyhutton.ietf@gmail.com>
Message-ID: <A655CCEB-ED6C-4782-9693-2CC321C2E2EC@shockey.us>
Thread-Topic: [stir] STIR's basic operational model with SIP
References: <3e59df1a-741a-9d3a-71fc-203015efbe0b@dcrocker.net> <4C001BD1-4879-4F8E-8A7B-038103A72A85@brianrosen.net> <F8E2025E-D824-431B-96B9-5FCDE8559165@shockey.us> <ec6ae21b-0561-dd4c-9459-dd297dbbfe3d@alum.mit.edu> <E787B179-6CF0-4331-825A-D8C881113686@shockey.us> <CAB7PXwRLTcw1jDBoMw1FQDPeM6eXta6i-Yhbr8JbNe-n+p5_YA@mail.gmail.com> <9800E7EE-3888-45D0-AC50-F7A69D5BBD14@brianrosen.net>
In-Reply-To: <9800E7EE-3888-45D0-AC50-F7A69D5BBD14@brianrosen.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3553689148_1851025030"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.40.228 authed with richard+shockey.us}
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box462.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-Source-IP: 100.36.40.228
X-Exim-ID: 1bXZYC-0003as-JE
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:49990
X-Source-Auth: richard+shockey.us
X-Email-Count: 0
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/NOFlgxL4rfGOoss1Y1jZI5FteyQ>
Cc: IETF STIR Mail List <stir@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [stir] STIR's basic operational model with SIP
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 10 Aug 2016 19:57:39 -0000

 

Thank you Brian… That is exactly what some of us have in mind ..Call Validation Display Framework derived from the Network Validation process. 

 

http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,819/Itemid,261/

 

We can argue about whether the validation should be done at the device or within the network, but the consumer need to see what is going on. 


 

From: Brian Rosen <br@brianrosen.net>
Date: Wednesday, August 10, 2016 at 9:02 AM
To: Andy Hutton <andyhutton.ietf@gmail.com>
Cc: Richard Shockey <richard@shockey.us>, IETF STIR Mail List <stir@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [stir] STIR's basic operational model with SIP

 

I don’t think that is at all true.  If validation is done at, say a transit network interconnect, and the transit network refuses to accept the call without a valid signature (assuming it does not run afoul of its local regulations in doing so), then there is value to the consumer.  If the termination network does the same, value.  If the termination network modifies the signaling towards the consumer so that the display name is “suspicious call” or  “unknown caller”, that is of great value to the consumer.  If it offers an option to the consumer to send calls with bad signatures or no signatures direct to voicemail, that is of great value.

 

So, while I really, really do want to do the validation on the device (because the consumer will have more options available of that is what happens), I think the mechanism can help consumers way before it shows up on the device and the device is able to do something with it.

 

Brian

 

On Aug 10, 2016, at 8:41 AM, Andy Hutton <andyhutton.ietf@gmail.com> wrote:

 

 

Also as Dave Crocker pointed out what happens at the callee is also important if no validation is possible at the callee's device then surely there is no real benefit to the consumer.

 

Regards

Andy

 

On Tue, Aug 9, 2016 at 6:09 PM, Richard Shockey <richard@shockey.us> wrote:



On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <stir-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:

    On 8/9/16 12:25 PM, Richard Shockey wrote:
    >
    > +1 it has to start some where.
    >
    > The circles of trust start first with the circles of authority and then can be delegated as requirements dictate.  The integrity numbering plan is a direct and plenary responsibility of NRA’s period full stop.
    >
    > I’m less confident we will ever get to the device level..at least not for the foreeable future aka my lifetime.

    If the SPs have an incentive to *not* delegate then it will be very hard
    to get there.

RS> Not our concern.   Way beyond our scope of competence here. Don’t forget the NRA’s have the real “Maxwell’s Silver Hammer” and you can be sure they can use it if delegation or lack thereof is perceived to be anti competitive.


    OTOH, if they have an incentive then the chances are better.

    Brian and Paul R outlined some possible incentives to delegate. That
    gives some hope.

        Thanks,
        Paul



_______________________________________________
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