Re: [stir] current draft charter

"Wendt, Chris" <Chris_Wendt@cable.comcast.com> Thu, 13 June 2013 13:38 UTC

Return-Path: <chris_wendt@cable.comcast.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E2421F9AED for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 06:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.231
X-Spam-Level:
X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve509nB3S0sF for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 06:37:59 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4377E21F9AC4 for <stir@ietf.org>; Thu, 13 Jun 2013 06:37:59 -0700 (PDT)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.77056077; Thu, 13 Jun 2013 07:37:25 -0600
Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 13 Jun 2013 09:37:33 -0400
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.49]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Thu, 13 Jun 2013 09:37:33 -0400
From: "Wendt, Chris" <Chris_Wendt@cable.comcast.com>
To: Dan York <york@isoc.org>
Thread-Topic: [stir] current draft charter
Thread-Index: AQHOaDsmzzxiRhKUq0SNP5wemGrczQ==
Date: Thu, 13 Jun 2013 13:37:31 +0000
Message-ID: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com>
References: <CDDF354D.DD9A%york@isoc.org>
In-Reply-To: <CDDF354D.DD9A%york@isoc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [68.87.16.246]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B53FC8516957234393CF4B3829E3DFC0@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, Hadriel Kaplan <hadriel.kaplan@oracle.com>, "stir@ietf.org" <stir@ietf.org>, Dave Crocker <dcrocker@bbiw.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [stir] current draft charter
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 13:38:04 -0000

Hi Folks,

I believe it couldn't be a better time to start discussing public routing.  While this is a little beyond the scope of protecting caller-id, I think the effort is highly complimentary, and solving both together will provide a better path to get things implemented in service provider networks.

IP communications is evolving whether you want to get on the train or not.  I applaud Henning's efforts to push the ball forward.

Moving more to an internet model for routing is inevitable, IMHO.  There is questions about how relevant TN is or will be in the near future.  For the sake of having any chance of success, let's simplify the effort and focus on the future.  There will be a transition process to get there, no doubt, but let's focus on the end goal, and not focus on fixing problems of the past.  We are already in a world of multiple private peering arrangements, LCR, and managing multiple egress points anyway, so the transition should not be that difficult.

I believe a common routing mechanism for both user@domain and TN/e164 based identities should be the focus.  Treat both as first class citizens for IP communications.

Use DNS and domain based routing for all.  Use DNSEC to validate and cryptographically associate TN/caller-id with a domain (for good guys) and do domain routing from there.  
Forget about trying to protect TN's individually, that is too complex.

It's up to the consumer service providers to enforce and block bad things from bad domains.
It's up to wholesale/trunking providers to allow customers to assert their own domain, or be responsible for asserting domains on their behalf at the risk of being considered a "bad guy".

This is high level, and perhaps a sunny day view of the world, but I don't think unrealistic.  Frankly, if there is any chance of a common federated communications system continuing to be relevant, I believe a simple approach that matches the internet model is the only choice.

You should see more concrete opinions from Comcast in the future, but I wanted to take the opportunity to express these thoughts and would love feedback on why this should or should not be the model going forward.

If there is agreement, I believe some of this should be addressed in the charter, because I think some of the assumptions may not enable this path. 

-Chris




On Jun 13, 2013, at 8:51 AM, Dan York <york@isoc.org> wrote:

> Hadriel,
> 
> On 6/12/13 5:38 PM, "Hadriel Kaplan" <hadriel.kaplan@oracle.com> wrote:
> 
>> That begs the question of what issues you think made Public ENUM fail,
>> and why we won't hit the same issues in whatever model we choose.
> 
> Since you addressed this question to me, I feel compelled to answer... but
> in the meantime both Brian and Jon have given much more detailed answers
> with which I mostly agree.
> 
> I saw security/privacy issues as the main issues that made Public ENUM not
> work, i.e. Brian's points 4, 5 and 6:
> 
>> 4. Any public database that was able to show any information about a
>> telephone number was considered a privacy issue, requiring a lot of "sign
>> off", which never happened.
>> 5. Everyone objected to being able to determine what numbers were "live"
>> 6. Carriers objected to a public database that told competitors what
>> numbers they controlled
> 
> 
> The potential for spam was also high.  Five or six years ago there was at
> least one tool circulating around that would walk an ENUM tree, generate a
> list of all potential phone numbers and then send SIP INVITEs to all of
> those numbers.  I remember either seeing a video or reading about how
> someone did this with all the public ENUM numbers published for Germany
> (at that time). So using Public ENUM could be a fantastic way to
> potentially get yourself on the calling lists for telemarketers.
> 
> Ideally, I think a public service *would* be a useful way to enable
> ubiquitous usage. I'm just not sure how to get there without also opening
> a solution up to these same kind of security/privacy issues.
> 
> Dan
> 
> --
> Dan York
> Senior Content Strategist, Internet Society
> york@isoc.org <mailto:york@isoc.org>   +1-802-735-1624
> Jabber: york@jabber.isoc.org <mailto:york@jabber.isoc.org>
> Skype: danyork   http://twitter.com/danyork
> 
> http://www.internetsociety.org/deploy360/
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir