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

Cullen Jennings <fluffy@cisco.com> Tue, 15 June 2010 17:23 UTC

Return-Path: <fluffy@cisco.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 3D9853A6852 for <dispatch@core3.amsl.com>; Tue, 15 Jun 2010 10:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.799
X-Spam-Level:
X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 pC24jSN4BZSk for <dispatch@core3.amsl.com>; Tue, 15 Jun 2010 10:23:36 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D7FE63A68B7 for <dispatch@ietf.org>; Tue, 15 Jun 2010 10:23:36 -0700 (PDT)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEtUF0yrR7Ht/2dsb2JhbACedHGmWpotglmCQQSDTw
X-IronPort-AV: E=Sophos;i="4.53,421,1272844800"; d="scan'208";a="226572859"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2010 17:23:41 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5FHNEND018261; Tue, 15 Jun 2010 17:23:40 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg>
Date: Tue, 15 Jun 2010 11:23:40 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <44DA64DC-00F6-416C-8300-3373B9FA4076@cisco.com>
References: <D92721E4-36AC-4B75-BCDF-E90A9242A286@cisco.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg>
To: Jean-Francois Mule <jf.mule@cablelabs.com>
X-Mailer: Apple Mail (2.1078)
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: Tue, 15 Jun 2010 17:23:38 -0000

Hi - many thanks for the great comments - few comments inline but I agree with all your points and tried to update the charter appropriately. 

On Jun 2, 2010, at 2:59 PM, Jean-Francois Mule wrote:

> Hi,
> 
>   I support this proposed work to be taken by IETF under a new working group.  There are certainly concrete deliverables that would merit IETF consensus to spur multi-vendor interoperability.
> 
>  A few comments below, mostly to help bash the proposed charter.
> 
> Jean-Francois.
> 
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
>> On Behalf Of Cullen Jennings
>> Sent: Tuesday, June 01, 2010 10:55 AM
>> 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
>                 ^^^^^^^^^^^^^^^^^^^^^^^^
> Given some folks talk about SIP federations in the context of speermint (http://tools.ietf.org/html/rfc5486#section-5) and I don't think this is what you mean here, this choice of terms may not be the best.  As much as some folks disagree on the worthiness of the output of speermint, at least SIP federations are described there.  Would recommend clarifying this somehow.

yah - agree. "Federation" means a lot of things but conflicting with speermint terminology seems like a bad plan. I'll try and rephrase in terms of "inter domain calling" 

> 
>> 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
>                                       ^^^^^^^^^^^^^^^^^^^
> my understanding is that those people would not only use SIP but some other smarts to put some stuff in DHTs to enable PSTN reachability verification. This implies that the solution solely relies on SIP.  May want to expand or clarify, or else qualify the sentence further.

yep ... I think this works for more than just SIP

> 
>> 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
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That may open a rathole: what does it mean to be responsible for a given phone number (worst case, Rich Shockey will chime in and will muddy this more, or John Elwell will claim this should have been in speermint but it cannot be found there...).
> 
> Do you mean any SIP Service Provider (http://tools.ietf.org/html/rfc5486#section-3.9) on the signaling path of a SIP invite or dialog-initiating request for that telephone number?  Do you mean the SIP domain responsible for the last hop before the SIP UA? Both?  Or is it the latter with the pre-requisite that PSTN connectivity is required somehow?

It's was deliberately a bit vague. The real goal is to get the best approximation we can of the administrative domain who controls the phone that rings when you dial that number. The whole concept of ownership of a phone number is so muddled that trying to use owner is clearly useless. It's very unclear if my cell phone number is owned by me (I can LNP to wherever I want and Cisco lets me take on termination of my employment), to Cisco (they pay the bill), to AT&T, to Neustar, or to some government, or any of the other parties that could cause it not to work. I think the best definition we can come up with of responsible is an administrative domain that is always involved in the call signaling of a PSTN call to that phone number. I tired to clear up in the charter a bit but this is going to need a bunch of people to help fine tune text. 

> 
>> 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
> This last sentence is advocating one specific solution.  
> I think the VIPR drafts are powerful and this may be part of a working solution.  But at this stage in the WG charter definition, would it be preferable to say something like:
> 	Some validation protocols may be based on additional knowledge gathered around a SIP call, for example, the ability to prove a call was received over the PSTN based on start and stop times.
> 
> It leave things open and welcomes other proposals.  It also does not preclude the validation protocol you have documented.

Fair enough - I changed draft charter to you suggested text.  If we think there is a reasonable chance that we might not do this start/stop time validations, then this change makes sense but if we are pretty certain we will do this approach, then I generally prefer making the charters as specific as possible. 

> 
>> 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. 
> These are additional examples that must be part of the same bucket as the one before imo.  Currently it reads that PSTN+start+stop is the initial one, others may be considered later.  
> I have no preference and like the elegance of the approach in some the VIPR drafts.  But the charter should make clear that the WG will decide this.

OK

> 
>> 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.
> Same here, you state a solution to a pb.  I would prefer to have a requirement in the charter that mandates the WG comes up with a method to help mitigate SPIT by ensuring that a domain using SIP can validate incoming calls are indeed from a domain that successfully validated the TN.

Ok - changed to say that. 

> 
> 
>> 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