Subject: [VIPR] Creating an alt-root for E.164

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 31 Mar 2011 10:36:34 -0400

Howdy,
I apologize if this has been hashed out already - if so please tell me to RTFM and I'll try and find the thread. (I did google already without luck)

I have a question about why we're ok with creating an alt-root for ITU's ownership of E.164 in an IETF protocol.  By that I mean that for however long the vipr client is willing to believe the vipr-resolved URI represents the E.164, it is not querying the authoritative database (ie, the PSTN).  The truth of the matter is your phone does not own and is not authoritative for the E.164 phone number - afaik only the ITU is truly authoritative for it (but yes assigns them out downhill).

So for example, right now if you dial the E.164 +1-781-328-4428, it resolves to my desk phone (well, actually to voicemail since I never answer my desk phone).  Let's pretend my desk phone did vipr.  If I get fired or quit tomorrow, my employer would re-allocate my number immediately - most likely to a receptionist for some period of time, and ultimately to a new employee.  From my employer's perspective, they "own" +1-781-328-4428, and should have the right/power to reallocate it at their leisure/whim.  Yet VIPR moves the ownership time decision to the caller, for whatever duration time it wants to use. 

In the IETF we have a long-standing concern with creating an alt-root for DNS.  So to put this in terms people here may grok, imagine if we have vipr resolve email addresses instead of E.164 numbers.  I send an email through my email server to "[email-masked]".  My email server subsequently uses a vipr model to learn a "direct" URI of "mail:[email-masked]" or even "mail:[email-masked]", and sends all my subsequent emails for "mail:[email-masked]" to the "direct" one.  Would that be ok?  Would it be ok to use vipr to resolve-cache from "mail:[email-masked]" to "mail:[email-masked]" for the next 6 months?

-hadriel

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 09:50:17 -0700

Hey Hadriel,

> Yet VIPR moves the ownership time decision to the caller, for whatever duration time it wants to use. 

I think you've got the wrong metaphor here.  VIPR is an empirical system: Since PSTN-VoIP mappings can't be queried directly (as they would through ENUM), VIPR infers them based on empirical observations of the PSTN (through calls).  This is inherently an estimate, which comes with experimental uncertainty.

There's actually a direct analogy here to geolocation services.  Telephone networks have a very good idea of where user devices are, but they refuse to share this information with "over-the-top" services (except for a very few exceptions).  So the people who were interested in locating mobile phones developed a system based on empirical measurements (i.e., wardriving), which is a major basis for location-based mobile applications today.  It's less accurate than the authoritative data that the telcos have, but it works without telco intervention.

The upshot of your comment is that there is some inherent uncertainty in VIPR mappings.  I don't think that's a controversial point.  The more productive question is how to manage this uncertainty, e.g., through mapping timeouts or frequency of measurement.

If it's directly replication of e164.arpa that you're worried about, that's already being done on some scale.  The biggest project I'm aware of is that a consortium of European NRENs are exchanging VoIP using ENUM under the nrenum.net tree:
<https://www.nrenum.net/>

--Richard

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 31 Mar 2011 18:18:59 -0400

> There's actually a direct analogy here to geolocation services.  Telephone networks have a very good idea of where user devices are, but they refuse to share this information with "over-the-top" se…

That's not a corollary to my metaphor - the actual physical location information has no owner, and no authoritative entity who administers it.  Wardriving does not create an alternate cache of the location information for a phone number or line (which is what the telco's have), but rather of the IP.  And even if it did do it for a phone number, it's not competing with what the telco database has because the two databases aren't used by the same clients/queriers.  What we're talking about here is different - you *can* and *do* query the PSTN authoritative database for E.164 number to URI resolution, by making a call - the PSTN and IP-PBX's just do it on your behalf and don't let you see nor cache the query result.  Once you start auto-determining the result, caching it and using it for the same purposes, it's effectively removing their authority over the number.  

Vipr is more analogous to local DNS caching, but without allowing the authoritative DNS servers to set the TTL in the response.  The IETF has long struggled with the problems (and benefits) caused by DNS caching, which is why I find it surprising we seem to have no qualms or second thoughts about doing it to someone else's resolution database.

> <https://www.nrenum.net/>

Nope, not worried about that.  (1) nrenum requires you to try the authoritative e164.arpa database first, before every call; (2) nrenum only adds a country if the country does not have an authoritative e164.arpa registry, and if one is created the nrenum one is removed; (3) only a NREN can be delegated to, so it's someone to administer it if it's wrong.  

But of course someone can make some e164.evil registry of their own, just like someone can go create an alternate root for DNS, mapping acmepacket.com to whatever they want - but if no one points to that root it won't matter, and we can figure out who's doing it... and more importantly the IETF isn't going to go publish RFCs on how to do it in an automated fashion. :)

-hadriel