(This article appeared in Networked Comms Insight during 2003)

Network security is a difficult business, particularly desktop access. Like most regulation, it imposes a burden on the majority of users because of the risk from a few. Authentication of a user used to be a simple process but is nowadays somewhat fraught.

Take the whole genre of passwords, for example. Once upon a time, passwords were simplistic, obvious, easily remembered to those who needed to know them and basically just a way of keeping out casual users who could cause inadvertent damage.

A good example of this was the GEC SL-X system in the late 70s. To get into the software diagnostic area, the password was “S803”, which was an abbreviation for Section 803, the bit where the developers worked. Everyone who needed to know could readily remember it and the consequence of someone misusing it was not too important, other than possibly causing a system reload, something generally career limiting!

Nowadays, passwords are individual, tailored, have to follow arcane rules and are an absolute pain. It has to be memorable to you but not obvious. It shouldn’t include obvious dictionary words. It needs to be mixed case alphanumeric with as many obscure characters as possible. It can’t be something you have used in living memory of the system and the sodding thing will start pestering you to change it just when you have got used to the existing one. No doubt, in three months time, the memo will come round that we have to jump through even more hoops.

Why do we have to be so precise with making our passwords so complex? After all, the network only allows you three bites of the cherry before being consigned to lockout limbo and the subsequent password reset purgatory from the service desk.

The answer comes in the way passwords are encrypted within the domain controller and across the network. Whilst supposedly secure, they can be broken by brute force using widely available tools. Widely available, that is, to script kiddies as well as security managers. Whilst domain control can be on a secure server in a protected location, the local files on laptops that enable us to work offline are much more vulnerable, as are the packets flying round the network, particularly if Wireless is involved.

The need to have numerous shared passwords to get into a range of applications is less of an issue these days as more and more software falls in line with the authentication policy so the days of several post-it notes surrounding the screen are drawing to an end. However, we still have the need to identify ourselves to the network at logon and after every short pause where the screensaver kicks in. It is tiresome, tedious and costs big business a lot of wasted effort in managing the scheme.

So, what is the answer? There are possibilities of using biometrics, whether fingerprints, face recognition, voice recognition, retinal scans and measuring the dynamics of signature analysis. They all have their merits and their pitfalls. How soon before we have the first publicised cyber crime that involves physical mutilation in the style of Arnie Schwarzenegger?

The biggest problem with the current password regime recommendations is that if users can’t use memorable words, they will tend to make up gibberish based on easy to remember key sequences which can be observed and reproduced. This is particularly prevalent for cash card crime, where a user is observed, distracted and then the card palmed to be used five minutes later down the road.

Assuming that the mechanism for cracking password files is a losing battle then the need for avoiding memorable words is probably bogus as they will all be cracked with negligible time differential. It isn’t bogus if the words are guessable, however! What we need to do is have individually memorable words but varying key entry. The banking industry have something called scrambler locks- a 6 digit pin code to open the door from the banking hall to the secure area, but the keypad randomly scrambles the numerals and they are only viewable close up from a very narrow viewing angle (indeed the last one I saw and used up close used decadic counter (Nixie) tubes that I hadn’t seen in instrumentation since the days before LED displays). I can see that scrambler keyboards would make a lot of sense on cash point machines, as well as on the arrival of PIN & CHIP point of sale terminals for credit cards that we have seen in France for nearly a decade.

Back to our Corporate laptops, where scrambler keyboards are not likely to appear. What would be a better way of securing them, or better still, unsecuring them when we (and only we) want access?

Well, my most recent ID card contains an RFID chip, the big brother device that the civil liberty and tin foil hat brigade warn us will be used to track our every waking moment when all of our possessions are chipped and the Home Secretary has insisted that we get one implanted in order to qualify for anything other than emergency tax code.

Despite the 1984 connotations, the card is a boon- I don’t have to swipe it or fiddle about with PIN codes, doors and barriers unlock in my presence. I still have to do a bit of vague genuflection in the direction of the sensors but future products will no doubt have a bigger sensor catchment zone and it will simply be a case of walking through portals.

This RFID chip lives around my neck every waking corporate moment upon pain of disciplinary action. Provided I don’t lose it, it is considered secure enough to get me everywhere I am entitled to, with additional PIN code access for particularly sensitive areas. If my laptop could sense the presence of the ID card then that would solve a big problem straight away- if I am there the PC unlocks and if I go for a coffee the portcullis slams down and the drawbridge goes up.

The trouble is that the RFID chip is passive, it simply spits out a stream of data when requested and that request could be from a hostile source. Active RFID chips exist- you probably have one on your key ring to unlock the car. The downside is that they currently need batteries.

So what will the future hold? I see terminal devices including a Web cam as a matter of course so a combination of RFID, face recognition and the occasional challenge for particularly sensitive stuff as smoothing the process. What it will muck up though, is the common-or-garden business presentation- there will need to be a PowerPoint mode where it trusts you for a bit standing at the front of the room waving your arms about!

What do we do now in the meantime? Bruce Schnier is a well-respected security guru who writes a monthly e-newsletter that is well worth subscribing to (see http://www.counterpane.com/crypto-gram.html). He does a good job of debunking the FUD that vendors come up with and has made himself very unpopular with the U.S. Government by pointing out the fallacies in the draconian homeland security legislation rushed into place after the World Trade Center atrocity.

(Every time I see it called 9-11 I think “November 9th?” I’m happy to call it Center instead of Centre though, in the same was as I’m happy to pronounce Paris as Paree the way the French do, after all, it isn’t cement).

By the way, I’m a generalist, specialism is for insects. However, I spend enough time asking the right people the right questions to know enough to not be dangerous, so to speak. (Well, most of the time!.)

Back to passwords, his advice for password management is classic KISS (Keep it simple stupid). Paraphrasing his and other suggestions, I adopt the following:-

Create an easy to remember username and low level password that you use for all of the unimportant stuff across the web. Sometimes you may have to tweak it slightly due to bizarre rules, but that’s life.

For the important stuff like banking, spending money, sensitive details, don’t try to memorise them any more. Instead, make them long and complex, write them down and keep them in your wallet. Treat them like a credit card- important and remedial action needed if lost or stolen.

As for the corporate workstation? Do the latter, but you will have to remember it if you don’t want to look in your purse or wallet 20 times a day. Roll on the future!

(This article appeared in Networked Comms Insight during 2003)

Once upon a time, business telephony was fairly simple. When you wanted to ring up a Company, you dialled their switchboard number and the friendly Operator put you through. Customers didn’t ring businesses that much as the standard response was often a request to put the query in writing anyway.

The arrival of DDI, ACD, Networking, messaging and CTI gradually led to more efficient call handling within the Corporate environment. Firms that could afford it were able to invest in powerful software based phone systems and train up staff to be able to match the business needs to the functionality available. There was an irony here- Businesses could do all sorts of clever call manipulation on-site whilst the public network was mostly constrained to delivering the calls to the targeted geographic number.

The rise of the large call centre must have put considerable strain on the local exchange- an average System X Concentrator serving up to 4000 users would generally have been served via a PDH 34 Meg feed and probably only had 8 E1 links back to the parent exchange. Even when provisioning was not an issue, filling the pipes efficiently has always been a challenge for more complex call centres, as well as number management as trading products are refreshed and replaced.

The first generation of non-geographic number services brought a major change of approach. The so-called “Intelligent Network” provided a mechanism for translating the number dialled into the number to be delivered to. Suddenly, businesses had the opportunity to get decisions taken in the network, rather than on their own switches. This enabled call distribution between sites based on ratios, time, date etc. Unfortunately, anyone who has had to manage call plans on behalf of business users knows that the results are based on what the Carrier software can achieve rather than what the user wants. Sometimes they are the same but not always so!

IN has gained in functionality through further developments in recent years and can now offer comparative sophistication in results. The main stumbling block, however, is that it is not particularly intelligent when it comes to understanding what is really going on in your business in real-time. Businesses that need to re-route calls elsewhere in anything other than broad brush rules have had to over-provision links and private circuits due to the tandeming involved.

The second generation of callflow functionality came with mechanisms integrated between the PSTN and local phone and IT systems. The best known solution arrived from a small Company called Geotel in America. This replaced the IN mechanism with a system known as Intelligent Call Routing, or ICR. With this solution, ICR has visibility of your systems and can make sensible decisions in real-time of which agents are free (or likely to become free) who are appropriately skilled to handle particular calls. Cisco bought up Geotel and developed it further to be more than just voice, renaming it Intelligent Contact Management, or ICM. Now most of the major carriers are able to offer a flavour of ICM, although it is probably a good idea to research it carefully as it can be a complex subject and there are different approaches taken providing subtly different solutions. The other thing that has to be understood is how well ICM integrates with your favourite PBX- sometimes it is call routing based on educated guesswork and doesn’t always do what you expect.

Rather than manipulate call flow in the core, an alternative approach has been to manipulate it at the edge, still on Telco property but with data links to the Customer IT. This works because there is still full visibility and access to C7 signalling at the edge of the network that is not provided via DASS or Euro ISDN on the private switches. Whilst there is some inevitable tandeming if there is a need to route calls elsewhere, it doesn’t impact on channels from the exchange to the PBX. Gematech have some interesting solutions to this but it does require co-operation from your carrier. Of course, as this type of solution generates extra minutes of traffic, this is something that a lot of carriers like!

There are two pitfalls with these second generation solutions that increase risk to business. Firstly they are based on proprietary solutions so further developments depend on the success of the product and the business drivers to enhance it. Secondly, it makes the business somewhat beholden to the carrier involved, moving business is considerably more complex than simply porting the number as the implementations vary.

What Businesses really want is for the solution to be based on business rules, not Telco ones. Let us imagine a third generation solution of the future.

Someone, somewhere, wants to contact our Company and has dialled one of our numbers. In real-time, over a high speed data link, we learn of this. The Carrier sends us as much information as is available about this particular call which at a minimum is the target number called. Based on this information, we make an intelligent decision. The calling number is recognised as Mrs. Wilson who called yesterday for a quotation. The called number and IVR data-capture is recognised as the “hot quote” number allocated to Mrs. Wilson. She talked to Sue Jones who is working today and likely to become available in the next 45 seconds. We make a decision- play Mrs. Wilson a “thank you for calling back” message, tailored as to Sue’s availability and the option to wait, queue jump or get an immediate callback. We also prepare our systems to flag Sue’s queue for a priority call until we get a Mrs. Wilson update.

The next call that arrives is recognised as Mr. Hughes who also called yesterday. However, this time, Mr. Hughes is calling the number for an allied product. We decide that he is simply shopping around and downgrade his priority, based on the current call answering performance which is a little below par at the moment- there is a major team brief happening at site one and site two has an ongoing (false) fire alarm situation. It will resolve in five minutes.

Meanwhile, Mrs.Wilson has decided to talk to the next available Agent. There are four overflow home workers available and Ruth Coshak is chosen as having the personality style most closely matching Sue Jones. The call is presented to Ruth along with a brief “whisper” prompt whilst Mrs. Wilson is thanked for her choice. Ruth also gets an account popup showing clearly what the call is about. (Ruth also gets an indication 30 seconds into the call that Sue is now available, however she chooses to cancel this as she has started to develop a rapport with Mrs. Wilson.)

The key differentiator in these scenarios is that the Telco reports the call details and the Business tells the Telco what to actually do with the call. This is not just setup- it could include subsequent segments of the call where it is modified through a “take back and transfer” basis, something of a holy grail for Call Centre Telecoms Managers. What we need is what the software guys call an API, or application programming interface. Most PBXs have APIs for Computer/Telephony Integration but an API for the Business to control the PSTN is what we want.

Is this a pipedream? No, not at all. The Parlay project is intended to offer this functionality and rather a lot more- it isn’t just about voice but embraces multiple contact channels and applications. The Parlay API has been specified and updated, what we need now are some real products and participating Carriers. There are some interesting names on the list but quite a few are conspicuous by their absence. Will this functionality appear on the PSTN, or do we have to wait for the Business Internet? Will it feature in UMTS?

Some questions remain to be answered. Can businesses be trusted to manage callflow without safeguards? What happens when the disgruntled employee arranges to deliver 300 Erlangs of traffic to the local Pizza Hut? We all know Back-office applications are as tetchy as a class of stage-school infants and will sulk for almost any reason. How do we integrate in the face of unreliability? How do we pay the carrier for it all?

These are all challenges and I don’t envy the early adopters for getting the bugs out & getting to grips with doing it well. However, this is certainly a route to competitive advantage & making the most efficient use of resources and technology. It also needs a change of mindset within both IT and the business teams, anything becomes possible, provided we plan and implement it well enough.

Find out more about Parlay at http://www.parlay.org

This article appeared in Networked Comms Insight during 2003

The title of the article asks two questions, depending which way you read it. When will the PSTN disappear, to be replaced by something else, which for argument’s sake, I’ll call the PNCN? Or, when will we stop having to use hard to remember numbers, to communicate with others?

I’d like to think the two go hand in hand, but I’ll cover off the first one first. The PNCN is already here- the Internet is the Public Non-switched Communication Network. The four letters warrant closer examination as each has an interesting parallel with the past.

Starting with “Network”, this simply implies devices connected together. In the case of a private network, it is a firmly closed user group, a public one accessible to all (based on availability of connection and ability to pay). The PSTN is global in reach but the only common denominator is 300Hz-3.4kHz analogue speech for basic telephony, everything else we take for granted in the first world (such as 64k clear channel) patchy at best in the third world. By comparison, the Internet is also Global in reach but the throughput and bandwidth available is rather more difficult to predict. We have also covered off “Public” by default here but we can take it as read that despotic regimes aside, where people want to get access they will be able to do so, mostly unfettered by the regulation that held back Telecoms post-nationalisation.

“Non-switched” vs “switched” – is of negligible interest to most users. When you talk to someone, you don’t care if your speech is packetised, encrypted, sent by multiple methods or indeed played to dolphins at sea World through underwater ultrasonic speakers en-route provided that it is something resembling commercial speech to both parties. However to the carrier, it is much more problematic. With the PSTN, the engineering comes in the unswitched capacity, once you managed to get through, you generally kept the connection as long as you needed it and the quality remained the same provided wireless wasn’t involved. With the PNCN, however, as it currently involves multiple technologies, effective capacity management must be an operational nightmare.

Finally, we come to “Telephone” versus “Communication”. The PSTN is admirably suited to talking and can be used for low speed data, whether bonded multiple 64k channels, or 300 baud modems. The Internet as a whole, however, is pretty hopeless at coping with speech from end to end unless you are prepared to accept random quality and poor reliability levels. As for real-time video, forget it.

That is not to say that significant chunks of the Internet cannot be used for carrier class telephony within the same supplier. Indeed, how many Carriers would swear on the bible that all of their private circuits provided to Customers as such are actually genuine, dedicated, uncontended provision?

Now, onto the thorny subject of numbers. We take telephone numbers for granted and they are comparatively easy for the public to understand and use. If they are so simple, why don’t we use them on emails? Well, in the early days of Compuserve, that was the case. If you wanted to send me a message, I was something like [123.456789]@compuserve.com. (I didn’t actually want a Compuserve account, having jumped into the Internet deep end with Demon when the setup was fairly complex, but it came free with a project I was working on). Account names often had semi-random alpha numerics in them, generally at the whim of a Sysadmin because simplicity and scalability hadn’t really been thought through at the time. These days, the de-facto standard seems to be firstname.lastname@company.type which is fine if you aren’t called John Smith, or in the Gulf Countries, Mohammed Abdullah. So why don’t we do the same with telephony?

Well, the reality is that we do. In our diaries, on our mobiles, on our featurephones, we create an alias that we immediately recognise and can associate with who we want to contact. We can remember a handful of numbers but there comes a point where we have to look them up, whether on a piece of paper, or having to dial 118£££. With instant messaging, we create “buddies”. With email, we create distribution lists or mailing lists. With favourite websites, we create shortcuts. However, it is not normal to number them!

I bought a couple of cheap phones on ebay recently to replace my home caller display units that were getting unreliable. After living with them for a while, something struck me about how the speed dialling worked that was unusual for a wireline instrument. Rather than bring up a numbered list, the list was sorted alphabetically. It did mean that you couldn’t do < 3> <2> for entry 32, but instead, when you pressed speed dial, you simply chose who you wanted in the same way that you type SMS on most phones, i.e. to access entries beginning with K, you pressed 5 twice. The phone positively encouraged you to label and store calls, both incoming and outgoing. Whilst this was fine, I eventually realised that I had to do exactly the same chores again on the upstairs set!

So, are numbers better than meaningful names? Yes and no. Numbers are quicker, but harder to remember. Text is more straight-forward, but requires greater accuracy. Dyslexia affects numbers as well as names, we get a lot of calls to a test phone on 01422 xxxxxx when the caller meant to dial 01442 xxxxxx, i.e. Hemel Hempstead, not Halifax!

ENUM is an interesting development, which is an attempt to provide a mechanism to contact someone by any channel. It works a bit like the Internet DNS lookup that turns a URL such as www.dilbert.com into an IP address such as 192.168.0.1. In simple terms, you ring, fax, email or message the one number, which is then translated to the appropriate address for delivery.

I see the future as including both- When you want to contact someone from a PNCN device, you find who you want quickly and intuitively from contextual menus guided by what information you already know. However, if you are in a Bedouin village in the Sahara, you find the ENUM from the community solar powered PC like-device, then queue up for your turn on the rotary telephone. (Or buy a journalist a large drink and borrow his Satcom system!)

So is the number up for the PSTN? Not yet. Too many security problems on the emerging networks at the moment. Too many technical issues, Telcos feeling the pinch, not enough investment. But, why should there only be one internet?

When I checked out Bob Emerson’s site via the link in the last posting, I’m delighted to see that he is now giving away 21st Century Communications as a .pdf as the book is out of print.

Of course, there ain’t no such thing as a free lunch, the book might do your head in or something.

(This article appeared in Networked Comms Insight during 2003)

Up until a decade ago, I used to work on the dark side, deriving most of my income from Telecoms manufacturers. I was involved with many new developments, generally at field trial (beta) stage, where the work tends to be with Customers who are early adopters, who actually want the solution being offered.

What it is easy to overlook working for a large Corporate in a globetrotting, ground breaking environment, is that sometimes developments are solutions looking for a problem. This is where the magical world of marketing takes over, in persuading Customers they may have a problem that their solution is optimal towards solving.

Packet switched telephony is just such a solution. I was reliably informed by clever people that circuit switched technology was a dinosaur back in 1988, but here we are 15 years later and whilst it is now starting to look very old and tired, it still hasn’t become extinct yet. Why is this?

Well, speaking as a Telecoms Manager, 50% of the sector seems to have a vested interest in my being sceptical. IP from the new boys leaves something to be desired, they hint. It might be quite reliable now, but a lot of those features that you take for granted just aren’t there. Never mind the quality, feel the width. Of course, our solution gives you the best of both worlds, everything you want, in an IP environment, fully integrated with your legacy stuff.

Hang on, though, I think. You guys have been charging an arm and a leg for functionality that has paid for its development many times over. If I want to add clever stuff in my old and new bits I still have to pay through the nose for it. If I don’t you deem it to be legacy and I have to pay catch-up to do the slightest thing a few years down the line.

But hang on again, all these licensing and legacy things seem to be a very similar scenario to the way the IT Software industry has gone anyway, so I am going to have exactly the same issues with the new players on the block. Lets take a closer look at their story.

The idea of convergence, it seems, is to bring voice, data and applications together in one cohesive whole, a true Information & Telecoms Technology (ICT), or perhaps better expressed as INS, or Information and Network Services. One network saves on costs and is a great enabler for multi-channel, unified functionality. Bob Emmerson, the well-known industry watcher has coined an even more interesting term that embraces the applications, connectivity and process in a holistic manner. He calls it UCI, which stands for Unified Communications and Information. So, yes, there is a definite problem that IP can be an enabler for solving; our communications channels are islands of functionality isolated from our processes and each other.

Well, that sounds great. However, not all of us are blue-chips with huge budgets. So what do we need to do to start trusting our voice to IP?

Our biggest hurdle is the Network.

Firstly, we have to tackle the problems of packet loss, delay, jitter etc. Voice doesn’t need massive bandwidth but it is hugely intolerant to any mucking about. This means the network has to be fully switched from edge to edge where you want to talk, with 100 Meg to the desktop and Gigabit core. It needs to support packet prioritisation, probably at both layer 2 locally and layer 3 when routed.

Prioritisation by itself doesn’t help in overload situations. A bit too much voice will dramatically impact on the non-voice throughput; way too much voice could cause bottlenecks and quality deterioration. Whilst bandwidth planning isn’t constrained by real channels any more, there is still the need to plan and engineer the network.

Resilience is crucial to continue to deliver high availability that phone users have always expected. It is a good idea to provide UPS further out towards the network edges so that phone conversations are immune to power cuts. Hang on though, many IP phones have power bricks into 13A sockets. Fortunately, 802.11af power over Ethernet has now been standardised. Always ensure there is adequate provision of Ethernet power, whether via in-line adapters or switches that include it. Given time, in-line power will become standard rather than an up-lift and one less variant to manage.

Once the network is voice ready, we then have to take stock of our legacy voice systems. They are also a big hurdle, because their legacy gets in the way of a UCI approach. Some of the vendors are starting to show what we might call green shoots of UCI, as there are some interesting partial solutions out there. The Cisco’s and 3Coms of the world also have their own UCI offerings.

I think that having an IP phone on every desk is a bit of a red herring in the majority of Companies. Yes, making the configuration follow the phone means that the instrument can go into the packing crate along with the files when someone moves and the functionality follows them. However, we have to get away from the mentality of the number belonging to the phone. When we move, we want to leave the thing on the desk, log in and then the associated phone becomes ours, for the duration, or by default if we choose it to be (semi) permanent.

I want us to get away from having a separate phone and PC, but I’m not talking about kludges like soft phones, USB interfaces or sound cards. My ideal workstation looks like a PC with a handset, headset or bluetooth associated with it. However, here is the crunch. The phone is actually built into the keyboard and is the network connection, powered via Ethernet. A small display & message waiting light above the numeric keypad is the only immediately obvious difference, along with the cradle, if fitted. When we arrive in the morning, we have a fully working traditional phone, however, once the PC has booted up and we have logged in that is when the phone really performs, being fully integrated with all our other communication channels and applications.

What about all of the users who just need POTS? Initially, put IP to analogue gateways in the closets and patch them as distributed analogue devices locally. There comes a point when IP-POTS will be cost effective enough to spend £50 on a simple IP phone and not have to manage them as a special case. In the IP world, vanilla telephony (PIPS) can include a display, message waiting light and half a dozen feature buttons, as the marginal cost between production runs of nasty phones compared to basic ones will indeed be marginal.

Having moved on to futures, let us return to the present. There are two further obstacles to achieving voice UCI. Security is an obvious one & there are (possibly) urban myths about denial of service attacks, hacking & viruses taking down IP phone systems. There are also stories of full voice IP systems running physically separated from the main data network, not just Vlan which is the virtual equivalent. Security has to be ubiquitous and multi-tiered, a point not to be laboured here.

Once we have ourselves a secure, resilient, reliable, robust IP network, our final hurdle is to manage it. The move, change & feature bit is probably a lot easier than what the voice people have been used to. However, what is the really critical bit is network management, both from a real-time and historic perspective. With the success of Cisco AVVID, there seems to have been a clutch of enterprising small companies who have popped up to provide useful tools outside of the scope (& huge cost) of the traditional tools like HP Openview, Cisco Works, Transcend et-al. We also have to work out how to get our voice, application & data staff trained up with the right skill set to do it, or find a partner who will.

Will I trust my telephony to IP? Well, I would if I had the time, money and resources. In the meantime, I have one IP phone and am thinking about installing another one! Now if only the IP-PSTN were here today…

Bob Emmerson can be found at www.electric-words.org