Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 23 Oct 2006 16:09:43 -0400

Brian,

You confuse associating a TN to an ingress point used to route the call,
with associating a TN to a particular end-user.  The former can be
accomplished without doing the latter.  You conflate the two.

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 2:34 PM
> To: Michael Hammer (mhammer); 'Otmar Lendl'; 'Richard Shockey'
> Cc: 'Nieminen Klaus'; [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> Well, here in the U.S., the stated reluctance of the 
> regulator to permit TNs in a public database is due to the 
> fact that people's telephone numbers would be in a public 
> database.  They are concerned with the privacy aspects of the 
> problem.  So, they actually WANT private databases where 
> people's telephone numbers are concerned.  And this concern 
> started in User ENUM, not just infrastructure ENUM.  I 
> understand there are other regulators who have this concern.
> 
> I do think there is some validity to your concern about one 
> carrier, or a group of carriers, restricting access to their 
> customers for termination from other carriers, and I agree 
> the regulators would probably not allow it.
> Making routing data public has not yet been, and I don't 
> think will be, the remedy.  
> 
> Brian
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Monday, October 23, 2006 12:01 PM
> > To: Otmar Lendl; Richard Shockey
> > Cc: Nieminen Klaus; [email-masked]
> > Subject: RE: [Speermint] Basic Peering Requirements
> > 
> > Concerning de-regulation:
> > 
> > If a group were to try to keep the system closed and certain call 
> > routing information private, whether intentionally or 
> unintentionally 
> > to raise barriers to competition; I think the regulators would feel 
> > compelled to step in and make such call routing information 
> publicly 
> > available.
> > 
> > So, if you want to keep the regulators idle, design the 
> system so that 
> > any VSP that can reliably authenticate themselves can take the 
> > sequence of steps that leads them to the ingress points and allows 
> > them to deliver calls to another VSP.  The key is having secure 
> > controls versus having static clubs.
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Otmar Lendl [mailto:[email-masked]]
> > > Sent: Monday, October 23, 2006 11:40 AM
> > > To: Richard Shockey
> > > Cc: [email-masked]; 'Nieminen Klaus'
> > > Subject: Re: [Speermint] Basic Peering Requirements
> > >
> > > On 2006/10/23 17:10, Richard Shockey <[email-masked]> wrote:
> > > >
> > > > > There are several arguments why carriers will never put
> > > there TNs in
> > > > > public ENUM trees, e.g.:
> > > > > - "Carriers are afraid that others can query how many
> > > > > numbers(customers) they have."
> > > > > - "Carriers are afraid that other carriers can find out
> > > the current
> > > > > carrier-of-record of an enterprise and to poach this customer"
> > > >
> > > > Both of these arguments as you mention are completely specious..
> > >
> > > We know. Klaus just quoted what we sometimes hear from carriers.
> > > You know, they don't always make sense.
> > >
> > > > > maybe others can tell us why carriers never will put
> > > there numbers
> > > > > into public infrastructure ENUM?
> > > >
> > > >
> > > > The real reason carriers will never put their numbers into
> > > any form of
> > > > public infrastructure ENUM is two fold.
> > > >
> > > > A. Only a mad man would put the location of critical 
> VoIP ingress 
> > > > elements edge or otherwise into a public DNS 
> infrastructure. The 
> > > > potential for DDoS alone is massive.
> > >
> > > Agreed. That's the reason we developed the domain policy DDDS 
> > > proposal which can used to really de-couple the URI from 
> the ingress 
> > > elements.
> > > E.g. if the only things you can learn from the public DNS is that 
> > > example.com is a member of federation X and Y, and uses
> > >
> > > fedx-ingress.example.com 	A	10.0.0.42
> > >
> > > and
> > >
> > > fedy-ingress.example.com 	A	172.27.10.10
> > >
> > > as the ingress elements on the respective shared L3 
> infrastructure 
> > > then I don't see the DDoS potential here.
> > >
> > > > B. Infrastructure ENUM as it has been proposed almost 
> guarantees 
> > > > national regulatory delegation and oversight and most
> > > carriers are in
> > > > favor of DE-Regulation of telecom not RE-Regulation.
> > >
> > > Wait a second: you're now switching from the issue of a 
> public tree 
> > > to the question of whether that should be a NRA-approved 
> one under 
> > > ie164.arpa.
> > >
> > > If the regulator proves to be a burden in all this, then nothing 
> > > stops an industry consortium to establish a tree under a 
> different 
> > > apex. (As the forest of trees out there shows.)
> > >
> > > > C. Some form of trusted registry of TN 2 URI mappings is 
> > > > absolutely necessary to insure interoperability but I 
> suspect it 
> > > > will
> > > be carriers
> > > > them selves that attempt to control the organization and
> > > distribution
> > > > of such data.
> > >
> > > Oh yes. Who argued against the carriers establishing a 
> such a tree?
> > >
> > > IMHO the best case is if the regulators *and* the carries 
> agree on 
> > > someone who runs that trusted registry. Whether that will 
> then be a 
> > > private tree or a public one, is an independent question.
> > >
> > > Given the fact that the number of "carriers" is bound to increase 
> > > and international resolution of TN->URI will be an issue, I doubt 
> > > that it will be easy to establish a sensible, universal 
> rule which 
> > > describes who should have access to that private tree.
> > >
> > > Once the number of organizations which have access to a 
> private tree 
> > > exceeds as certain number, the security benefits you get from 
> > > keeping it non-public are dwarfed by the complexities of 
> maintaining 
> > > access control rules.
> > >
> > > Or, as other events prove every now and then, the PSTN method of 
> > > maintaining security ("trust all other carriers") is already 
> > > breaking down right now. So why perpetuate that model?
> > >
> > > It's just case of security by obscurity.
> > >
> > > /ol
> > > --
> > > < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > 
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Oct 2006 16:25:22 -0400

I don't think I do.  User ENUM does not have user identifiable information
in it, although if you have a number of service providers, you could learn
some information about the set of URIs in the database.

Nothing we are doing has direct user identity information in it.

Brian

> Sent: Monday, October 23, 2006 4:10 PM
> To: Brian Rosen; Otmar Lendl; Richard Shockey