Re: [dispatch] VIPR - proposed charter version 3

Mary Barnes <mary.ietf.barnes@gmail.com> Tue, 29 June 2010 16:17 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 92F773A6C08 for <dispatch@core3.amsl.com>; Tue, 29 Jun 2010 09:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level:
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599]
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 BCr1s+CddS85 for <dispatch@core3.amsl.com>; Tue, 29 Jun 2010 09:17:27 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 16FC43A6A6C for <dispatch@ietf.org>; Tue, 29 Jun 2010 09:17:27 -0700 (PDT)
Received: by iwn40 with SMTP id 40so1178558iwn.31 for <dispatch@ietf.org>; Tue, 29 Jun 2010 09:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3jTVqWxrVlMFNISUAXRXVYrJJQ2334LT3vNt+gr5Dz0=; b=YKwEgHpNd7LKbuji8lxK+BoB3zWgn3T3sC6GjkG/8kFPRMBGUUfsyTNP/ruRj00vKF 27R2hOOOZWUYVlNFlcj2AIATta+MxF+SLk8RtzIm0icFXiqPWtF/3D97rFoi5Q+mdlaD Bb0OWO5JjvZQQ0l7+/3TZqPFj5ygf/vSJJH/Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QRATpQlco/IzAp//0q5cMDHSs+g0nciH4yoAvLGdVj309KcZzgxNTjcs6eYFL1e1tr BGeXvD39zX41WKVqd2RgoTNZ73WxLiX5eZNEHnqxIGXBXsbZue7BvmN4SHfBlZU1yNMs jrLbxHyERCfJlaFz/FYAw+sQIuo7jdQWO2YU0=
MIME-Version: 1.0
Received: by 10.231.14.2 with SMTP id e2mr1197084iba.155.1277828257334; Tue, 29 Jun 2010 09:17:37 -0700 (PDT)
Received: by 10.231.146.206 with HTTP; Tue, 29 Jun 2010 09:17:37 -0700 (PDT)
In-Reply-To: <35FE871E2B085542A35726420E29DA6B0444E234@gaalpa1msgusr7a.ugd.att.com>
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com> <35FE871E2B085542A35726420E29DA6B0444E234@gaalpa1msgusr7a.ugd.att.com>
Date: Tue, 29 Jun 2010 11:17:37 -0500
Message-ID: <AANLkTin7pksU_f7t90ASdQFCHx4v0uOZSFC1APBOH497@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "PFAUTZ, PENN L (ATTCORP)" <pp3129@att.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [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: Tue, 29 Jun 2010 16:17:28 -0000

Hi Penn,

Absolutely, the WG would discuss the criteria for validation - the
last sentence in the 3rd paragraph discusses this and notes:
" The WG will select and standardize at least one validation scheme."

The sentence you are asking about is in the SPAM section which is
something that happens on top of the validation - i.e., if phone
numbers associated with a specific domain have been validated, this
validation criteria is applicable to other numbers from the same
domain.

Thanks,
Mary.

On Tue, Jun 29, 2010 at 8:30 AM, PFAUTZ, PENN L (ATTCORP)
<pp3129@att.com> wrote:
> I'd like to understand precisely what is meant by "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."
> More importantly, I think the WG should discuss what the criteria for
> validation should be.
>
> Penn Pfautz
> AT&T Access Management
> +1-732-420-4962
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Mary Barnes
> Sent: Monday, June 28, 2010 1:38 PM
> To: DISPATCH
> Subject: [dispatch] VIPR - proposed charter version 3
>
> 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.
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>