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

Peter Musgrave <peter.musgrave@magorcorp.com> Wed, 02 June 2010 18:50 UTC

Return-Path: <peter.musgrave@magorcorp.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 9A2E93A6359 for <dispatch@core3.amsl.com>; Wed, 2 Jun 2010 11:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Level:
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
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 OETteVeLZMgJ for <dispatch@core3.amsl.com>; Wed, 2 Jun 2010 11:50:30 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CA20B28C190 for <dispatch@ietf.org>; Wed, 2 Jun 2010 11:49:52 -0700 (PDT)
Received: by gyh4 with SMTP id 4so5015531gyh.31 for <dispatch@ietf.org>; Wed, 02 Jun 2010 11:49:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.114.1 with SMTP id m1mr7670713ybc.354.1275504576726; Wed, 02 Jun 2010 11:49:36 -0700 (PDT)
Received: by 10.150.199.12 with HTTP; Wed, 2 Jun 2010 11:49:36 -0700 (PDT)
In-Reply-To: <33870CEC-3737-4070-8880-18ED4818D82F@cisco.com>
References: <D92721E4-36AC-4B75-BCDF-E90A9242A286@cisco.com> <AANLkTim2q0p7XX1Cdx3M8BikV-5nGPhegLdsWu_a_nRs@mail.gmail.com> <33870CEC-3737-4070-8880-18ED4818D82F@cisco.com>
Date: Wed, 02 Jun 2010 14:49:36 -0400
Message-ID: <AANLkTilbtT5V7cn1_DORFQ3wEcIluC8MrU9jW-yyy1Sm@mail.gmail.com>
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (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, 02 Jun 2010 18:50:35 -0000

How about:

"The essential characteristic of ViPR is establishing authentication
by PSTN reachability and not by e.g. direct reference to ENUM
databases or other assertions of PSTN number ownership. Elements such
as public ENUM may be employed indirectly as part of assessing the
PSTN reachability but no direct interaction with ENUM will be
required. "

Peter

On Wed, Jun 2, 2010 at 2:35 PM, Cullen Jennings <fluffy@cisco.com> wrote:
>
> I kept trying to write something about the relation of ViPR to ENUM but it kept coming out sounding like public ENUM had failed - which was not really what I wanted to say so I eventually deleted it. If someone had some good text about ENUM, would be nice to add it.
>
> I view infrastructure and carrier ENUM as somewhat unrelated to this but public ENUM is related. However, ENUM talks about how to query the database, but it is somewhat silent on how data gets in the database. How does the database authorize that someone is authoritative for a number and can put write a record into the ENUM database. VIPR is more about that side of the problem.
>
> And +1 to Paul's answers of the other questions ....
>
> On Jun 1, 2010, at 12:28 PM, Peter Musgrave wrote:
>
>> Hi Cullen,
>>
>> Does the charter need to say anything explicitly about not relying on
>> any of the work which uses ENUMs in DNS as a way of associating SIP
>> endpoints and IP addresses?
>>
>> AFAIK ViPR is about *using* a SIP call to determine a path to the
>> endpoint (however that happens to work).
>>
>> Does the charter need to stipulate that the mapping from a PSTN number
>> to a SIP device is a one-to-one mapping? Does there need to be text
>> about how multiple endpoints which are behind a border device (and all
>> appear as the same PSTN number) are to be handled?.
>>
>> ViPR so far describes an "edge-device" approach. Is the charter
>> restricted to this approach?
>>
>> Thanks,
>>
>> Peter Musgrave
>>
>>
>>
>> On Tue, Jun 1, 2010 at 12:55 PM, Cullen Jennings <fluffy@cisco.com> wrote:
>> >
>> > 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
>
>
>
>