Subject: [Enum] Carrier ENUM

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Thu, 23 Jun 2005 10:29:11 -0400

Jim:
To be clear, the aspect of carrier ENUM that is the focus of the
original I-D is carrier ENUM for interconnection
between carriers. Whether carriers use infrastructure ENUM internally
for routing is (mostly) orthogonal.
Since we see interconnection via IP eventually replacing TDM
interconnection, we would like ENUM to be able to make
pointers that *may* be eventually resolved to the carrier's border
function element generally available. Things may start off with just a
group of carriers that agree to interconnect but then expand. We believe
that split DNS may indeed provide ways for interconnection partners to
resolve differently from non-partners or even each other. We understand
that queries must resolve even if to NXDOMAIN rather than being dropped
on the floor and generating retries.

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Jim Reid
Sent: Thursday, June 23, 2005 9:57 AM
To: Stastny Richard
Cc: <enum at ietf.org>
Subject: [Enum] Name Spaces & Domain Names (was Non-Terrminal
NAPTRsConsidered Harmful)

On Jun 22, 2005, at 11:50, Stastny Richard wrote:

> 1) Should (user) ENUM and Infrastructure (Carrier) ENUM
> implementations be mixed within e.164.arpa?

Probably not though it depends on your definitions of "mixed" and 
"Carrier ENUM" and "User ENUM".

> 2) If yes, how should this be done technically?

Split DNS. Though I can hear Rich Shockey screaming "No!" as I type 
this... :-)

This discussion seems to be doing around in circles and never gets 
anywhere. It also seems to get hung up about the choice of domain name, 
which is beside the point quite frankly. The focus should be on 
requirements and name spaces IMO, not the domain name. Once the 
requirements are clear, the proper DNS architecture will suggest 
itself.
And after that's clear, then it's time to consider what the domain name 
should be.

Let's try to refocus the discussion. User ENUM is inherently an opt-in 
process. The user of a number gets the delegation and populates it with 
whatever they want. Carrier or Infrastructure ENUM is not opt-in as a 
telco will want to provision that for all the numbers they provide 
service for. Consent by the users of those numbers will not be 
required. To all intents and purposes this means Infrastructure ENUM 
can't be in the public DNS. Carriers wouldn't want that anyway since 
this could disclose data they'd prefer to keep secret: location of 
their border gateways, internal network topology, which numbers are in 
use or have been ported, where and how they interconnect with other 
carriers, etc, etc.

So a telco implementing Infrastructure ENUM wouldn't want to use the 
public User ENUM infrastructure. Besides, they won't want that for 
operational reasons. They would not be in control of the public 
infrastructure:  placement and performance of DNS servers, choice of 
hardware and DNS software, monitoring, (D)DoS protection, choice of TTL 
values, propagation of updates, support, etc, etc. It's very unlikely 
any telco would choose to depend on anyone else's infrastructure for 
their most critical network operations: routing phone calls. This means 
that a telco will almost certainly operate their own Carrier ENUM 
infrastructure according to their own operational requirements. Notice 
I've not yet said anything about the domain name that they'd use for 
Infrastructure ENUM.

Therefore each telco will want to set up and run their own Carrier ENUM 
infrastructure according to their own rules and populate that with 
whatever they want. Which is fine. This infrastructure probably 
shouldn't be visible to the public internet anyway. The question is 
then which domain name is used. Well, the first thing to agree is that 
there should be exactly one domain name for Infrastructure/Carrier 
ENUM. This means that there's a common standard that can be followed by 
telcos, vendors, developers and solution suppliers. The same domain 
name will work inside every telco's network. Secondly, it makes it a 
whole lot easier to merge or split these name spaces whenever telcos 
merge their operations or divest something. [If say Verizon and BT 
merge, combining their two private Infrastructure ENUM trees would be 
far simpler if they both use enum.foo (say) instead of one using 
something like enum.us and the other using e164.bt.net.] So the telcos 
need to agree a standard or a convention for the domain name that 
anchors these name spaces.

Now what should be the name of the zone apex that would be at the top 
of this forest of trees, one tree per telco? IMO this should be 
e164.arpa. That's the IETF standard for mapping E.164 numbers to domain 
names after all. So we now have N+1 name spaces for this domain. 
There's the public one on the internet. And there's a private one 
operated and controlled by each telco for its own internal purposes.

Why choose e164.arpa? Well the chances are that the appications used on 
the public internet are very likely to be very similar or identical to 
those used by telcos inside their own networks. On the internet, end 
users are likely to publish details of which SIP server to use to 
terminate VoIP traffic for their telephone number. Unless I've missed 
something, a telco is likely (amongst other things) to use 
Infrastructure ENUM to figure out which SIP server to use for 
terminating VoIP traffic for a given telephone number. So it makes 
sense to be able to use the same software in both places. Though 
obviously, telcos will prefer "carrier class" software from their 
approved suppliers rather than an open source SIP server that has no 
support. The only real difference is that inside the telco's network, 
resolvers are configured to query internal name servers that know about 
the internal DNS infrastructure for e164.arpa instead of the public 
one.

Now telcos could probably share a single, private tree for 
Infrastructure ENUM. This would be a lot cleaner, more efficient and 
very much cheaper to operate. However I think this is an unrealistic 
goal. It would be very difficult to get all the telcos to agree a 
common set of requirements, far less figure out a way to pay for the 
setup and operation of that shared infrastructure.

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Jun 2005 18:35:19 -0400

On Jun 23, 2005, at 07:28, Pfautz, Penn L, NEO wrote:
To be clear, the aspect of carrier ENUM that is the focus of the
original I-D is carrier ENUM for interconnection
between carriers.
As I have suggested to you a few times, if "carrier ENUM" is only to  
be used by a known group of organizations and noone else, there is  
absolutely no reason what so ever to have the DNS names in e164.arpa.  
The only reason to have records there is if carriers want to put data  
in DNS that anyone should be able to access.

If the argument for carrier ENUM is to only let some people be able  
to do the lookup, it should be done in a different corner of the DNS  
hierarchy, and what corner that is can be part of the contractual  
agreement between the carriers when they set up their "traffic  
exchange agreement".

   paf

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 24 Jun 2005 02:48:19 -0400

> agreement between the carriers when they set up their "traffic  

However, you don't want to use 57 different domain names if you have 57
different partners you exchange traffic with.

There should be a single domain that can be configured into all carrier
ENUM systems. Whether this is carrier.e164.arpa, or carrier-enum.info, or
what, I don't care.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Jun 2005 04:02:03 -0400

On Jun 23, 2005, at 23:47, Clive D.W. Feather wrote:
However, you don't want to use 57 different domain names if you  
have 57
different partners you exchange traffic with.

There should be a single domain that can be configured into all  
carrier
ENUM systems. Whether this is carrier.e164.arpa, or carrier- 
enum.info, or
what, I don't care.

You will need one carrier enum domain for each "club" of carriers. I  
have already heard one carrier wanting to publish their "ENUM data"  
in such a way that two peers see different information. Just because  
they wanted different ingress points for SIP calls to their "sip  
server clouds".

So, believing you will get only one root domain for "hidden" domains  
for carriers I see has already lost the battle in the form of private  
agreements.

What we discuss here on this list is the situation when someone else  
than the owner/holder of the E.164 want to make ENUM data publicly  
available for everyone to use. At least from my point of view, and I  
have not been convinced I am wrong -- yet... :-)

    paf

---

From: Jim Reid <[email-masked]>
Date: Fri, 24 Jun 2005 04:14:29 -0400

On Jun 23, 2005, at 23:34, Patrik Fältström wrote:
As I have suggested to you a few times, if "carrier ENUM" is only to 
be used by a known group of organizations and noone else, there is 
absolutely no reason what so ever to have the DNS names in e164.arpa. 
The only reason to have records there is if carriers want to put data 
in DNS that anyone should be able to access.
Just to make things crystal-clear Patrik, you're saying there's no 
justification for putting *private* data in the *public* e164.arpa 
tree. Right? An organisation or groups of organisations are free to put 
their own private data in their own private instance of an e164.arpa 
zone. And if they do that, they don't need to get permission from 
anyone. In other words, what someone does in private behind closed 
doors is nobody else's business.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Jun 2005 04:27:23 -0400

On Jun 24, 2005, at 01:12, Jim Reid wrote:
Just to make things crystal-clear Patrik, you're saying there's no  
justification for putting *private* data in the *public* e164.arpa  
tree. Right? An organisation or groups of organisations are free to  
put their own private data in their own private instance of an  
e164.arpa zone. And if they do that, they don't need to get  
permission from anyone. In other words, what someone does in  
private behind closed doors is nobody else's business.
Correct, *I* can not see any justification. It is the contrary, I can  
see problems with having data in the public area if some of the DNS  
servers are not reachable.

Sure, split DNS can take care of some of this, but I MUCH rather see  
split dns for e164.foo. than 3.4.5.1.2.e164.arpa. Simply because I am  
nervous for leakage. If people want to play around with such things,  
do it somewhere else (unless someone really see some reason why it  
must be in the (public) e164.arpa tree.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Jun 2005 04:30:49 -0400

On Jun 24, 2005, at 01:12, Jim Reid wrote:
An organisation or groups of organisations are free to put their  
own private data in their own private instance of an e164.arpa  
zone. And if they do that, they don't need to get permission from  
anyone. In other words, what someone does in private behind closed  
doors is nobody else's business.
Let me explain in a different way:
- If A want to make information available to B, and only B, A and B  
probably have a contract that stipulates how that data can be used  
etc. That contract/agreement can also include information what root  
in the DNS hierarchy the data is in (together with access/ 
authorization information etc).

- If A and B do not have any agreement, which is the case when B is  
anyone in the world, they have to fall back to the ENUM RFC that tell  
e164.arpa is to be used.

   paf

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 24 Jun 2005 11:08:31 -0400

Jim Reid technology liberalism, vs Cisco telco business planning!

Let's reflect on operations reality, as practiced in the US telco market!

Two providers of private management domain of name servers can always share
a private copy of the e.164.arpa service, served with cached and/or
augmented information sets. Cached copies of "high-quality-serviced" public
information will quite normally be augmented with additional information
objects only relevant to the user of the interconnect - another cooperating
provider. Such cache slaves may be only a 1ms out of date, in practice, so
this is all "Cache" semantics, really. What really matters is the augmented
data, and its accuracy.

In the X.500 equivalent of these name resolver processes in commercial
communities, the cached slave entries of an AD would be augmented with acls
limiting which ADs and PMDs could replicate or chain operations to
particular portions of that particular slave copy of the public name space.
Normal practice had subordinate objects stored in the publicly named entry
of the slave DIB, which was only available to interconnecting parties, and
was provisioned by the maintainer for private consumption in the
interconnected provider group. These datasets commonly contained
registration info, security (certificates from the interconnect parties CAs,
for security policy enforcement and value add secure messaging service
delivery within the interconnect community) and billing/token counting
information shared as part of the commercial practices of the interconnect.

12 years ago, Einar and Marshall created quite a reputable set of operating
practices for sharing a public naming tree (see NADF RFCs), suited to the
way interconnects amongst those issuing PRIVATE security credentials and
billing rights benefiting PUBLIC end users usually work. It was tuned to
unique way interconnect business works in the US telco services and
management services market. 

An alternative to look at is the European SIM/SAM model for orchestrating
security interconnects in the roaming-centric cellular space, which add the
offline dimension of management, control and security key provisioning to
the domain interconnects.

> Patrik Fältström
> Sent: Friday, June 24, 2005 1:30 AM
> To: Jim Reid
> Cc: enum at ietf.org; Stastny Richard; Pfautz, Penn L,NEO
> Subject: Re: [Enum] Carrier ENUM
>

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Jun 2005 12:25:22 -0400

On Jun 24, 2005, at 08:08, Peter Williams wrote:
Two providers of private management domain of name servers can  
always share
a private copy of the e.164.arpa service, served with cached and/or
augmented information sets.
Absolutely, but if they have a private copy that both know about (a)  
they really don't have to have it in e164.arpa, but they can have it  
somewhere else (b) there is no argument why it have to be in  
e164.arpa and (this is important) (c) setting up split DNS so that  
100% of the lookups are actually responded correctly with absolutely  
no leakage of the responses is extremely difficult.

DNS is designed to be koherent, that all queries get responded with  
the same data, and because of this DNS protocol / caches etc by  
design is hard to run within a walled garden. For telephony call  
routing, it is enough with one wrongly routed call, and you as a  
carrier have problems. Because of this, and the fact I don't see any  
need for the "walled garden ENUM tree" have to be rooted in e164.arpa  
I don't think it should be there.

If you don't agree with me (and to be honest, I don't know whether  
you do or not), please explain why it has to be in e164.arpa.

    paf

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 24 Jun 2005 20:37:25 -0400

Patrick, and IETF friends:

I think of things really simply - focussing on the case that a (mega-)
carrier creates a superior "service quality level" for some fragment of
public e164.arpa name space, and perhaps even sells one or more variants of
that enhanced ENUM resolution service to other carriers - who nominally
administer other fragments in that same naming space. Conventionally, part
of the value add providers create is security management. Lets say,
practically, that 5 particular fragment providers all agree to act as a
single security domain, and thus their ENUM resolver infrastructures all
respect either other's user security credentials (provided by a common ISP,
perhaps). Surely this is a perfectly reasonable operating model?

For example, in the theoretical cs.ucl.ac.uk.e164.arpa enum name space, lets
imagine that it?s the AC.UK domain admin (and provider) that actually hosts
the ENUM services for all universities in that ac domain, including cs.ucl.
When resolving an ENUM tree walk involving peter.cs.ucl.ac.uk.e164.arpa, the
mega carrier for all AC.UK naming fragments will, "for AC.UK sourced DNS
requests on UK targets ONLY" provide additional ENUM tree walking
capabilities to requestors. This will allow the ENUM resolution algorithm to
ALSO wander into some NON public ENUM name fragments (operated also by
AC.UK, and which do not even have a public access point, perhaps) but only
when the two sip end points are known to be UK-regulated. 

In said extra fragments in a private tree, perhaps a second set of E.164/SIP
mappings are maintained, ones for which there are some crypto keys
pre-provisioned, with UK-based key escrow, for voip phones protocol usage.
In said practical telco culture, the ENUM Algorithm will only be permitted
to resolve to entries bearing keys IF the underlying VOIP transport carrier
has an interconnect agreement with the ENNUM provider @AC.UK. This agreement
will comply with and enforce UK government licensing rules - to ensure, for
example, that the various legal message interception capabilities are in
place on the VOIP carrier's transport services, should a user actually
invoke the security modes ,and the key escrow and consumer privacy rules are
working, etc., etc. If these interconnect rules are not satisfied, no secure
mode resolution is available: only insecure mappings are ever provided.

The security domain vs naming domain models of X.500 were always provider
centric. Even if the name space was a public ADMD, the security domain was
managed behind the scenes within the provider interconnect arrangements- to
allow for regulation on a interconnect basis.

------------

Its hard to know (despite the theory of the universal DNS, now with a tree
walking ENUM algorithm added) why IETF would want to DENY folks this model,
per se. I'm not really arguing for or against, only detecting the
resistance, to the idea itself.

If the retort is essentially, well one is challenging the fundamental
religion of the Taoist internet, well... lets get real. We dumped all that
dogma, in 1994 when the DARPA/NSF/NASA walls came a tumbling down, along
with the "thou shalt not sell" rule. If DNS and now ENUM resolution is the
last bastion of early IP religion, then its walls SHALL also tumble.
I suspect, on half reading the emails, and sensing the tone (mostly), we are
dealing with such a religious perspective, here.

As you seem to want a formal opinion, this is it: I never like religious
operating doctrine disguised as technical rules in protocol standards,
addressing bits and bytes. Unfortunately, this is common in the security and
DNS WGs, and stems from IAB and US regulatory policy usually. In this
community, I would not bother to vote one way or the other, not being
sufficiently involved, and thus having no real right to much of a voice.
But, I DO wonder WHY its SUCH an issue: letting (professional carrier grade
architects) build any deployment (and interconnect-based) model they want,
in and across their fragment(s) of the public tree! 

Peter.

> Sent: Friday, June 24, 2005 9:25 AM
> To: Peter Williams
> Cc: enum at ietf.org