Exclusivity is indeed a key part of the performance of the SS7 network. Administrative controls are valid means to accomplish a goal, just like technical and physical controls. Another side of this is the general recognition that you can't rely solely on technical controls to defend against a determined malicious threat. If you've got a huge pile of CAPEX, a fat stream of OPEX, and the careers of several cords of VPs on the line, you think differently than a guy that just figured out how to run asterisk in a vm for his undergrad project. If I can use administrative controls and financial hurdles to exclude those that don't live and breath global stability and uptime, sign me up. David On Thu, Aug 20, 2009 at 7:07 AM, Alex Balashov<abalashov at evaristesys.com> wrote:

David Hiers wrote:

...

I like the static nature of SS7/PSTN, and wonder how many of those five nines can be attributed to it's static routing. ?Sure, you can translate global titles all day, but you always come back to choosing among a set of static routes to complete your call.

I wonder if some of this has as much to do with exclusivity, i.e. SS7's security-by-plutocracy and/or regulation, as much as with static routing.

-- Alex Balashov - Principal Evariste Systems Web ? ? : http://www.evaristesys.com/ Tel ? ? : (+1) (678) 954-0670 Direct ?: (+1) (678) 954-0671

The work of maintaining BGP-style filters by upstreams to provide technical solutions for the trust issues for individual phone numbers would be ... formidable. It would have to operate in blocks, which hampers portability. Jonathan Thurman wrote:

I am not a carrier, nor do I intend to be a carrier. My view point comes from working in K-12 education where saving money is a high priority. I wish we could get out phone number assignment from ARIN and deal Voice like we do IP. Of course you could have issues when you open up and start trusting others, but I would say that BGP works. It is going to take baby steps to change the way that the telephone industry provides services, and those changes are probably going to be grass-root type projects. David, you are right that I probably live in a different world. While it might be more bleeding edge that you can afford, it's coming. Otherwise we all might as well turn our SIP/H.323 devices off now and go home.

So the reason I initially asked this question is that we are looking to peer with other agencies. I have looked a many of the different ideas/projects/technologies out in the wild and I like TRIP. ENUM doesn't change anything. Someone still holds all the keys, and you are constantly querying for the answers. DUNDi is closer, but still requires more time to complete the call when you have to search every time how to route it. TRIP lets you hold the whole routing table, so you know how to get where right away.

-Jonathan

On Thu, Aug 20, 2009 at 8:38 AM, David Hiers <hiersd at gmail.com <mailto:hiersd at gmail.com>> wrote:

Exclusivity is indeed a key part of the performance of the SS7 network. Administrative controls are valid means to accomplish a goal, just like technical and physical controls. Another side of this is the general recognition that you can't rely solely on technical controls to defend against a determined malicious threat.

If you've got a huge pile of CAPEX, a fat stream of OPEX, and the careers of several cords of VPs on the line, you think differently than a guy that just figured out how to run asterisk in a vm for his undergrad project. If I can use administrative controls and financial hurdles to exclude those that don't live and breath global stability and uptime, sign me up.

David

On Thu, Aug 20, 2009 at 7:07 AM, Alex Balashov<abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote: > David Hiers wrote: > >> I like the static nature of SS7/PSTN, and wonder how many of those >> five nines can be attributed to it's static routing. Sure, you can >> translate global titles all day, but you always come back to choosing >> among a set of static routes to complete your call. > > I wonder if some of this has as much to do with exclusivity, i.e. SS7's > security-by-plutocracy and/or regulation, as much as with static routing. > > -- > Alex Balashov - Principal > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

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

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

On Aug 20, 2009, at 2:36 PM, Kenny Sallee wrote:

Otherwise we all might as well turn our SIP/H.323 devices off now and go home.

I have to agree with this. However, mindset changes typically happen at engineering levels first (if we are comfy we push them) and if business models and $$ can be made are learned by the VP's we all care about. Like David said tho - if we can make it work from a policy standpoint and use our engineering skills to protect us from the idiots (I'm sure most of us in our engineering careers have been one at some point) then something like TRIP sounds very interesting to me.

BGP is solid - but the engineers who configure it and global nature of errors are what make people who care about phone calls shy away from it. Those are some of the problems we'd need to address to reach a phone via some global directory. Have to be able to trust it and the path. The TRIP RFC was implemented back in 2002 and perhaps was ahead of it's time like so many other .com's and it's time to look at it again

A few points that I've noticed in my thinking over the last 10 years or so trying to come up with clever ways to do telephony routing.. 1) TRIP is great, but ultimately doesn't work on a global basis. It may work in tightly-coupled environments, such as a large multi- national firm, or even a keiretsu-style conglomerate of companies, but in "the wild" it would be unworkable. Why? a) Phone numbers are not in large spans of sequential space, and are growing more fractured by the day. Just the amount of route injections to cover transferred mobile numbers would (I suspect) be in the hundreds of thousands of records per day if even 50% of the world's phone numbers were in the tables. (Look at some of the update and churn numbers in China and India to make your head spin.) b) The trust model of who "owns" a number is unworkable in an endpoint-trusted environment with a non-hierarchical routing structure. Who, really, is supposed to get the call for a particular E.164 address? Well, that sounds like the role of a central authority to me. So why have TRIP if you have a central repository? (Feel free to exchange the words "central authority" for "several dozen or even several hundred nationally-designated legally compliant bodies of authority with geographic reign") c) The potential for abuse or misconfiguration is serious, and filtering to prevent that type of problem (as Alex Balashov notes) is formidable. That would be an understatement. It is nearly impossible. The fluctuations of the route tables would be significant, and even one incident where an "important" number is mis- routed to the wrong person would have possibly two orders of magnitude more of a press/public opinion result than those events that occur with some frequency in the BGP tables. 2) ENUM is great, but suffers from 1(a) and 1(b). Additionally, it suffers from a political structure in many nations that is highly resistant to re-distribution of number space at the geographically national level away from the hands of a very small minority of controllers, typically incumbents. In my opinion, ENUM in North America is currently dead for these issues regardless of whatever anyone says. 3) E.164 is outdated, and should be banished. Why? a) See 1a-1c and 2, which are all results of E.164's political and geographic constraints. Regardless of (3), we're stuck with E.164 for a while. Working in small pockets with equally trusted members and a low risk of unknown or uncertified members of the routing information mesh, technologies such as ENUM, DUNDi, and TRIP all work well. But they do not scale across organizational boundaries easily. In the instance of a school system or group of school systems (to Jonathan's query/point) that may be small enough to work. Uncertainty grows with the number of fingers typing configurations, and one must also consider the risk of "stale" or inaccurate routing data - is it really an issue for your user community if something "bad" happens? My punchline to this whole thing is "Look at freenum.org" since while it has the significant downside of introducing a new numbering scheme, it avoids almost all of the downsides of E.164 and various E.164 routing methods I list above. (Even the downside is an upside, actually.) JT

As a technologist, I really dig clever stuff, and personally wouldn't mind a fully-dynamic, self-discovering TN routing scheme. In fact, as soon as my VP replaces "reliability" with "dynamic TN routing" on my bonus plan, I'll be all over it! Looking back, it was quite a leap to go from being an IP guy that wanted nothing but instant, stable, route table updates to being a phone guy that gets the quarterly LERG on a CD. I just couldn't believe that SS7 was just a bunch of static route sets on link sets, and that the routing table was not in my switch as much as it was in the SS7 network. I kept thinking that I was reading about SS7v1, and that all the cool stuff was in the SS7v2 docs that I could not find... Since I don't know exactly which geese are laying the golden eggs to make my analog POTS phone so reliable, I'm a bit careful when I'm out picking the bird for the next big dinner :) David On Thu, Aug 20, 2009 at 9:42 PM, Paul Timmins<paul at timmins.net> wrote:

John Todd wrote:

...

1) TRIP is great, but ultimately doesn't work on a global basis. ?It may work in tightly-coupled environments, such as a large multi-national firm, or even a keiretsu-style conglomerate of companies, but in "the wild" it would be unworkable. ?Why?

? a) Phone numbers are not in large spans of sequential space, and are growing more fractured by the day. ?Just the amount of route injections to cover transferred mobile numbers would (I suspect) be in the hundreds of thousands of records per day if even 50% of the world's phone numbers were in the tables. ?(Look at some of the update and churn numbers in China and India to make your head spin.)

?b) The trust model of who "owns" a number is unworkable in an endpoint-trusted environment with a non-hierarchical routing structure. ?Who, really, is supposed to get the call for a particular E.164 address? ?Well, that sounds like the role of a central authority to me. ?So why have TRIP if you have a central repository? ?(Feel free to exchange the words "central authority" for "several dozen or even several hundred nationally-designated legally compliant bodies of authority with geographic reign")

?c) The potential for abuse or misconfiguration is serious, and filtering to prevent that type of problem (as Alex Balashov notes) is formidable. ?That would be an understatement. ?It is nearly impossible. ?The fluctuations of the route tables would be significant, and even one incident where an "important" number is mis-routed to the wrong person would have possibly two orders of magnitude more of a press/public opinion result than those events that occur with some frequency in the BGP tables.

And as a corollary to this, one only has to look at NANOG and ARIN-Discuss to see that there is a lot of focus on routing table size and prefix length and bloat, especially as it appears to continue growing. And those are just publically routed networks, such as the two /22s my employer has (each customer's /29, etc don't appear in BGP). Routers are already handling something like 300,000 routes right now, and rising.

My back of the napkin calculations say that if you wanted to handle routes for every possible thousands block out of every NPA/NXX allocated by NANPA and the CNAC at this time, you'd have 1,627,520 routes in your switch, all of which could be changing at any minute with a dynamic protocol. If each route and its destination took 15 bytes to store, the routing table size would be 24,412,800 bytes (about 24MB) per copy of the table you store. I would assume you would get a copy from each of your vendors, and do some math to determine which one is the cheapest at any given time. Mind you, this is constantly changing (BGP changes enough where you can't even keep the protocol in sync over a 64k ISDN line anymore because of the sheer amount of changes being made to the table at any given time). This sounds easy from the "but my computer has lots of RAM" standpoint, but if your computer is your switch, it should probably focus on doing realtime things like routing audio rather than constantly updating a thrashing routing database. If your computer isn't your switch, realize that this gets that much more unrealistic, as many switches are embedded systems that often have at the most 64M-128M of RAM.

And all of this is so each switch can know the endpoint state of every other switch in the world (or maybe just the US?) and maybe its location? This doesn't scale well.

Many of the "We can't keep going on like this forever" solutions being proposed in IP land for the issue of route table explosion are similar to enum or the existing US LNP databases, which scale amazingly well compared to the solutions used by ISPs.

Note that in a real world deployment, each switch would have to have every ported number in its BGP-like database. ?I note the emails that I get sometimes that warn that someone will be porting more than 15,000 numbers in an hour from the NPAC, and am very, very glad I don't see things like that on my switch, and have the luxury of just dipping those databases when I need to know who owns a number and where to route it.

I'm not necessarily in full favor of the status quo here, but I'm thinking this isn't a good solution to the problem.

-Paul _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops