RE: [dispatch] VIPR - proposed charter version 3

"Richard Shockey" <richard@shockey.us> Thu, 08 July 2010 15:46 UTC

Return-Path: <richard@shockey.us>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61833A6B1B for <ietf@core3.amsl.com>; Thu, 8 Jul 2010 08:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.465
X-Spam-Level:
X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 3c1TQGTuRQzg for <ietf@core3.amsl.com>; Thu, 8 Jul 2010 08:46:54 -0700 (PDT)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id A13A33A6B1A for <ietf@ietf.org>; Thu, 8 Jul 2010 08:46:54 -0700 (PDT)
Received: (qmail 8271 invoked by uid 0); 8 Jul 2010 15:46:58 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 8 Jul 2010 15:46:58 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=C7U7HMIcP4x/N42IZPNuuYhKmJOi7Nv0MCCrLEOAI8GPN5PdGTpNLMpX04M/OMFg7Fvd1YDRU/K4XnaClXP6oM3VG2GWqR072UKF7Iz4O5PvLe9hWuuNjyHOJfXXbCFi;
Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1OWtJS-0002zJ-93; Thu, 08 Jul 2010 09:46:58 -0600
From: Richard Shockey <richard@shockey.us>
To: 'Dan Wing' <dwing@cisco.com>, 'Paul Kyzivat' <pkyzivat@cisco.com>
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F40FB@307622ANEX5.global.avaya.com> <AANLkTinCs4ooaP7qczjOf_CMJB2tZg9XR9Ro5H-WWHK6@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F4219@307622ANEX5.global.avaya.com> <001201cb1ade$4195f680$c4c1e380$@us> <AANLkTimGO9mf_q78EYJJ_UwuM834m3vJ0i4BiGqEB4KJ@mail.gmail.com> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <2a2201cb1e5a$85b5df90$91219eb0$@com>
In-Reply-To: <2a2201cb1e5a$85b5df90$91219eb0$@com>
Subject: RE: [dispatch] VIPR - proposed charter version 3
Date: Thu, 08 Jul 2010 11:46:55 -0400
Message-ID: <00f401cb1eb4$cbb98230$632c8690$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcscaX8dN4iSVSfAR6+wCu3OeaBQegABPUEwAGgp2uAAKLVBgA==
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us}
Cc: 'DISPATCH' <dispatch@ietf.org>, 'IETF-Discussion list' <ietf@ietf.org>, 'Peter Musgrave' <peter.musgrave@magorcorp.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2010 15:46:56 -0000

> 
> Paul of course I've read them, though the PVP document is uniquely
> dense and gave me a headache. Security by ID Obscurity.
> 
> My assertion still stands. In the absence of any linkage in the PVP to
> the E164 numbering authorities and or databases any assertion about
> verification and validation of a E.164 is in essence self validation. 
> The charter does NOT state that. My point is the proposed charter is badly

> written and implies a trust model that does not exist.

I guess your "no-SS7" hat doesn't fit anymore?

RS> Well I have to swap it from time to time with my NO PRI hat.  I'm still
trying to kill it off SS7 if someone will let me put metadata in ENUM
databases. :-) 

That trust model which "does not exist" is exactly the trust model
that we all use, daily, whenever we dial the pizza joint across
the street, the paint contractor with the spiffy one-page advertisement
in the yellow pages, pay FedEx or the postal service to deliver
a package, or pay a shipper to send a crate full of Champagne
from France to some other country, or call the Sears & Roebuck 
catalog number give them our credit card and expect them to use
a shipper (FedEx/postal service/UPS/DHL) to send us the product.


RS> There is a reasonable trust model in the PSTN that relies on several
factors ..first the regulatory structure that says "you will route e164
transactions by law if you are a licenced carrier" and access to the root
numbering structures and databases which in North America are the LERG and
the NPAC GTT etc. You can determine who is the responsible carrier of record
for nearly any E.164 number out there. You just have real trouble
determining who was issued that number.  

I agree that trust model is imperfect.

But that trust model is what delivers almost all of the commerce
and business in the world.  To assert that this trust model "does 
not exist" is a false assertion.

RS> You cannot authoritatively determine a binding between a phone number
and a consumer (domain) without access to the databases.


> You make a phone call if it answers and you hopefully get a caller ID
> that
> hasn't been spoofed then maybe you are OK and maybe you hope the TTL is
> set
> to some interval that doesn't cause number hijacking. But gee what
> happens when the number is disconnected from the PSTN? Hummmm

Similar disconnections (and resales) of telephone numbers happen,
today, on the PSTN.  I dial a restaurant (now out of business) 
which has taken over the same physical location (oh my gosh, 
Identity Thieves!) and paid to acquire the previous restaurant's
phone number.  Other, non-restaurant businesses do similar 
things.  SBC bought the assets of AT&T including its brand name, 
doing something similar with the att.com domain itself and,
I'm sure, with its 800 services.

But the routing data aka the DPC's were updated to reflect those
transactions.


So, it's not as if querying SS7 would provide some magic sauce
to prevent the problem.  The problem is different, to be sure,
just as IP addresses, domain names, physical (street) addresses,
email addresses, telephone numbers, are not all quite exactly
"the same".  But each is considered an "identity" to a varying 
degree.

> The use of the term validation and or verification here implies
> authentication and my assertion is that any authentication of the
> responsible domain for a E.164 number outside of the PSTN service
> provider
> or national numbering authority is not possible under the current
> regulatory circumstances.  Consequently the charter implies an 
> ability to develop a solution which we all know is impossible.

I disagree.

> Solution rewrite the charter to note that fact that this is, in fact,
> "best efforts" only, "full disclosure" or "caveat emptor" to be 
> precise.

Once I know someone owned an E.164 and I can, afterwards,
do crypto to ensure I know I'm talking to the same entity -- that
is *far* more reliable than what occurs, today, on the PSTN.  The PSTN
where phone numbers are bought and sold willy-nilly.


RS> for the 352nd time you don't own E.164 numbers. They are not property by
treaty. 


RS> Well this could go on forever.  My point is still that the charter as
written implies a service level and trust binding that unrealistic and what
is proposed is essentially a "best efforts" service. Ok there is nothing
wrong with that. TCP?   The underlying DHT technology here has been
demonstrated to work in the past but to imply that ViPR is some way cool new
new thing I'm going to rely on just because it made a successful PSTN call
with a ill determined TTL binding  .. please.