Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR)

Roni Even <Even.roni@huawei.com> Wed, 07 July 2010 20:35 UTC

Return-Path: <Even.roni@huawei.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B69D3A68B8 for <dispatch@core3.amsl.com>; Wed, 7 Jul 2010 13:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM-dOBZ2kO0B for <dispatch@core3.amsl.com>; Wed, 7 Jul 2010 13:35:30 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D0C3E3A686B for <dispatch@ietf.org>; Wed, 7 Jul 2010 13:35:29 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L57000HPFUYF5@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 08 Jul 2010 04:35:23 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5700B9PFUYFV@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 08 Jul 2010 04:35:22 +0800 (CST)
Received: from windows8d787f9 ([109.66.52.27]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L570098LFUQIC@szxml02-in.huawei.com>; Thu, 08 Jul 2010 04:35:22 +0800 (CST)
Date: Wed, 07 Jul 2010 23:34:52 +0300
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <A5B09E0E-740B-44E5-9D0E-6D189A0AE7DD@cisco.com>
To: 'Cullen Jennings' <fluffy@cisco.com>
Message-id: <017001cb1e13$df126e10$9d374a30$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-us
Content-transfer-encoding: 7bit
Thread-index: AcseDokt/ohiYMH/RbyQu1fGXX7QpAABJsBQ
References: <D92721E4-36AC-4B75-BCDF-E90A9242A286@cisco.com> <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> <A5B09E0E-740B-44E5-9D0E-6D189A0AE7DD@cisco.com>
Cc: 'DISPATCH list' <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2010 20:35:31 -0000

Cullen,
I am not talking about the vipr drafts but about the charter, I thought we
are discussion a charter and not a solution.
"One initial validation protocol will be based on a domain being able to
prove it received a particular phone call over the PSTN based on both sides
knowing the start and stop times of that call"
What do you mean by "received a particular phone call" - my understanding
from reading the sentence is that it is based on the caller ID; the start
and stop time may not be unique, so my reading is that the charter means
caller-id and start and stop time.

Roni Even

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Wednesday, July 07, 2010 10:57 PM
> To: Roni Even
> Cc: DISPATCH list
> Subject: Re: [dispatch] Charter Proposal: Verification Involving
> PSTNReachability (VIPR)
> 
> 
> On Jun 15, 2010, at 4:23 PM, Roni Even wrote:
> 
> > Hi Cullen,
> > I think that other standard body should be consulted like ITU.
> 
> What would you like to ask the ITU about?
> 
> > The reason is
> > that I see that one assumption is to use the PSTN numbering plan
> using also
> > the caller id.
> > My experience is that this is not information that can be
> > reliable when going between PSTN service providers and it gets worse
> on
> > international calls.
> 
> Yes, caller-id is often missing and is trival to spoof. That is why
> none of vipr drafts uses calling name or number. I'm not really sure
> what you are getting at here.
> 
> 
> > Roni Even
> >
> > > -----Original Message-----
> > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
> On
> > > Behalf Of Cullen Jennings
> > > Sent: Tuesday, June 01, 2010 7:55 PM
> > > To: DISPATCH list
> > > Subject: [dispatch] Charter Proposal: Verification Involving PSTN
> > > Reachability (VIPR)
> > >
> > >
> > > I've been talking to a lot of people about the VIPR drafts  - here
> is a
> > > first cut of a proposal for a WG that could do this. I'm sure the
> > > charter proposal needs a bunch of work but I wanted to get the
> > > discussion rolling on the list.
> > >
> > > Thanks, Cullen
> > >
> > > (PS - this is sent in my individual contributor role. Take all my
> posts
> > > about VIPR to be in my individual role not my co-chair role)
> > >
> > > -------------------------------------------------------
> > >
> > > ViPR Charter Proposal (Version 0)
> > >
> > > WG Name:  Verification Involving PSTN Reachability (VIPR)
> > >
> > > There are two globally deployed address spaces for communications
> that
> > > more than a billion people use on a daily basis. They are phone
> numbers
> > > and DNS rooted address such as web servers and email addresses. The
> > > federation design of SIP is primarily designed for email style
> > > addresses yet a large percentage of SIP deployments primarily use
> phone
> > > numbers for identifying users. The goal of this working group is to
> > > allows people to use SIP to federate over the the internet while
> still
> > > using phone numbers to identify the person they wish to communicate
> > > with.
> > >
> > > The VIPR WG will address this problem by developing a peer to peer
> > > based approach to finding SIP domains that claim to be responsible
> for
> > > a given phone number and the WG will design validation protocols to
> > > ensure a reasonable likelihood that a given domain actually is
> > > responsible for the phone number. One initial validation protocol
> will
> > > be based on a domain being able to prove it received a particular
> phone
> > > call over the PSTN based on both sides knowing the start and stop
> times
> > > of that call. Other validation schemes, such as examining
> fingerprints
> > > or watermarking of PSTN media, to show that a domain received a
> > > particular PSTN phone call may be considered by the working group.
> To
> > > help mitigate SPAM over SIP issues, the WG will define an token
> based
> > > authorization scheme so that domain using SIP to federate can
> choose to
> > > check that incoming SIP calls are from a domain that successfully
> > > validated a phone number.
> > >
> > > The problem statement and some possible starting points for
> solutions
> > > are further desired in the following internet drafts which shall
> form
> > > the bases of the WG documents:
> > > draft-rosenberg-dispatch-vipr-overview
> > > draft-rosenberg-dispatch-vipr-reload-usage
> > > draft-rosenberg-dispatch-vipr-pvp
> > > draft-rosenberg-dispatch-vipr-sip-antispam
> > >
> > > The working group will carefully coordinate with the security area,
> O&M
> > > area, as well as the appropriate RAI WG including sipcore and
> p2psip.
> > >
> > >
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> >
> >
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>