Re: [stir] current draft charter

Hadriel Kaplan <hadriel.kaplan@oracle.com> Wed, 12 June 2013 22:52 UTC

Return-Path: <hadriel.kaplan@oracle.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 8F3B611E8101 for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 15:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.281
X-Spam-Level:
X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 rEQwYum7p0er for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 15:51:53 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1524621F994E for <stir@ietf.org>; Wed, 12 Jun 2013 15:51:51 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5CMphlD025907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 22:51:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5CMpgfO012994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 22:51:42 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5CMpf7r005071; Wed, 12 Jun 2013 22:51:41 GMT
Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 15:51:41 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net>
Date: Wed, 12 Jun 2013 18:51:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <984AC1B1-0AEB-41BA-8DB8-1685D9A7E894@oracle.com>
References: <CDDE44D8.D939%york@isoc.org> <B6D6C44E-3FE3-4342-9BDD-4096D4B66DD7@oracle.com> <51B8EB34.9030803@bbiw.net> <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net>
To: Brian Rosen <br@brianrosen.net>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "stir@ietf.org" <stir@ietf.org>, Dave Crocker <dcrocker@bbiw.net>
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: Wed, 12 Jun 2013 22:52:03 -0000

Before I respond to your points below in a separate email, I think we might be talking past each other somewhat...

When I say "we might be able to use an ENUM model", I certainly don't mean populating the e164.arpa subtree with NAPTRs of SIP URIs.

I mean populating a new DNS subtree, say cid.arpa or whatever, with cert/pub-key information records (e.g. a CERT Resource Record or whatever), but based on the same reverse-number-dotted-notation for the domain name "key" as described in ENUM.  This new subtree would be purely for the purposes of caller-id verification, not routing.

In a perfect world, IANA would delegate the authority/owner of .cid.arpa to be the ITU, and the ITU would delegate .1.cid.arpa to NANPA and .4.4.cid.arpa to OFCOM and .9.4.cid.arpa to the Bundesnetzagentur and so on. 

Nor would I call it "ENUM" at all in any document whatsoever, just to avoid this type of confusion and stigma.  It just seemed like a convenient way to describe it in this email list discussion so far.

-hadriel


On Jun 12, 2013, at 6:02 PM, Brian Rosen <br@brianrosen.net> wrote:

> 1. the "global root" problem - who owns and manages e164.arpa, and what are the rules?
> 2. It took action by the regulator before anything happened.  Because many regulators didn't understand what this thing was, and still don't, they didn't act
> 3. It took a level of cooperation between service providers who owned parts of the hierarchy that could not be gained
> 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
> 7. The DNS query was a poor fit for the problem - what evolved was a SIP redirect interface because no vendors liked the DNS interface
> 8. Delegation of numbers don't fit a tree model any more
> 9. URIs and other things you put in the DNS were insufficient for the problem
> 10. Other databases for the problems existed, and it was easier to use them, mostly because they existed.  These are non-public databases
> 
> As Rich Shockey notes, there is a fair amount of "ENUM" deployment inside carriers, although it's a SIP redirect interface.  The underlying data structures are the same as ENUM.  Actually, it's only the interfaces for provisioning that are the same.  No one ever does a DNS query.
> 
> If we want this deployed soon, it's my considered opinion you can't have a public per-TN database.
> 
> We learned in ENUM that DNS is not a good fit for a telephone number.  We understand it looks attractive, but it doesn't fit, primarily because the tree doesn't reflect the delegation model, and a complete tree out to each individual TN is not really a practical solution.  Delegations are ranges.  DNS doesn't do ranges.  Delegations have port-out issues, which DNS doesn't do unless you populate the whole tree.  It's a bad fit.
> 
> The DNS guys, at the time, kept asking us "do the limitations of DNS work for you"?  We kept believing, and saying yes.  I now understand why they kept asking the same damn question over and over.  The limitations do not work for us.
> 
> My company has built ENUM based systems.  We continuously trip over the mismatch between the DNS model and the problem.  We fix it by ignoring the DNS model, building a database that matches the actual delegation model and treating the DNS query as an awkward, but solvable interface issue.  And it still bites us on things like UDP (very bad for DDoS security) and the restrictions on what a NAPTR can do.
> 
> Brian
>