[dispatch] VIPR - proposed charter version 3

Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 28 June 2010 17:38 UTC

Return-Path: <mary.ietf.barnes@gmail.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 DB6BA3A6782 for <dispatch@core3.amsl.com>; Mon, 28 Jun 2010 10:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
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 xSuTE8-oDw0Y for <dispatch@core3.amsl.com>; Mon, 28 Jun 2010 10:38:22 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 83DCC28C129 for <dispatch@ietf.org>; Mon, 28 Jun 2010 10:38:22 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id d26so96136eyd.51 for <dispatch@ietf.org>; Mon, 28 Jun 2010 10:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ZJlWxrgwPzleR1mN0LSZaqduCVN0z7jgMOxX665YqQY=; b=oyFjHXutw1mCvZaoMg8XB9TK7ZflSAws7LMhpKz08vkKWudZGYTPY5QZGNQ3pFK4np WhA2VN85YmQJT5HkdbQc+V05HiNINlI44/2wjaUBkRhIimK+aIyBgv3M+a/ZATU/TAsf EgoDWq1sX79MYSk7VY/rQ01PtPnRyvP8rvP78=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ASmwRQtQMVKNcC5iERMMS7+gvAM7DgMrCqANLeK1psBzXGCo1ecTJ88Do0zkw38xy8 w5B+7dsnC7X23PeRjGmErqlzBOPD99oSmXvJbIUUo2cP6ljFOZbxhpR0LYwZ8b0ZudLY adKNfzv6s0P57kMQ1v9pMnx+qlOaTGHIWnBCg=
MIME-Version: 1.0
Received: by 10.213.31.141 with SMTP id y13mr1154636ebc.34.1277746708604; Mon, 28 Jun 2010 10:38:28 -0700 (PDT)
Received: by 10.231.146.206 with HTTP; Mon, 28 Jun 2010 10:38:28 -0700 (PDT)
Date: Mon, 28 Jun 2010 12:38:28 -0500
Message-ID: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [dispatch] VIPR - proposed charter version 3
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: Mon, 28 Jun 2010 17:38:24 -0000

Hi all,

Below, please find version 3 of the VIPR proposed charter. It's been
updated to reflect ML feedback, in particular VAP has been added and
clarifications have been made with regards to impacts (i.e., none) on
existing PSTN interfaces.

Regards,
Mary
(DISPATCH WG co-chair)

============================================
VIPR Charter Proposal (Version 3)

WG Name:  Verification Involving PSTN Reachability (VIPR)

There are two globally deployed address spaces for communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users. The goal of this working group is to enable
inter-domain communications over the the Internet, using protocols such
as SIP, while still allowing people to use phone numbers to identify the
person with whom they wish to communicate.

The VIPR WG will address this problem by developing a peer to peer based
approach to finding domains that claim to be responsible for a given
phone number and validation protocols to ensure a reasonable likelihood
that a given domain actually is responsible for the phone number. In
this context, "responsible" means an administrative domain, which is at
least one of the domains, to which a PSTN call to this phone number
would be routed. Once the domain responsible for the phone number is
found, existing protocols, such as SIP, can be used for inter-domain
communications.

Some validation protocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received over
the PSTN based on start and stop times. Other validation schemes, such
as examining fingerprints or watermarking of PSTN media to show that a
domain received a particular PSTN phone call, may also be considered by
the working group. This validation will be accomplished using publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate.  The WG will select and
standardize at least one validation scheme.

The validation mechanism requires a domain to gather and maintain
information related to PSTN calls.  This information is used by call
agents such as phones, SBCs and IP PBXs to route calls.  The WG will
define a client-server protocol between these call agents and the entity
within a domain that maintains the information.

To help mitigate SPAM issues when using SIP between domains, the WG will
define a mechanism to enable one domain to check that incoming SIP
messages are coming from a validated phone number.  A phone number is
considered validated if it is coming from a domain to which the calling
domain had previously successfully placed a PSTN call.  The working
group will define new SIP headers and option tags, as necessary, to
enable this.

The essential characteristic of VIPR is establishing authentication by
PSTN reachability when it is not possible to use a direct reference to
ENUM databases or other direct assertions of PSTN number
ownership. Elements such as public ENUM easily coexist with VIPR but no
direct interaction with ENUM will be required.  The solution set defined
by this WG will be incrementally deployable using only existing
interfaces to the PSTN.  No changes will be required to existing PSTN
capabilities, no new database access is needed nor is any new support
from PSTN service providers required.

The problem statement and some possible starting points for solutions
are further discussed 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
draft-rosenberg-dispatch-vipr-vap

The working group will carefully coordinate with the security area, O&M
area, as well as the appropriate RAI WGs such as sipcore and p2psip.