Deloitte got some fantastic free press this week when they launched a their Telecommunication Predictions for 2007, and chose to summarise a fairly balanced article on transit capacity with the sentence ‘One of the key possibilities for 2007 is that the internet could be approaching its capacity’ (p4).
Bold words, that the bbc have also been publicising.
The study then clarifies on page six that what they actually mean is that demand might outstrip supply, which is very much a different thing. Economics suggests that markets cope just fine with surges in demand by increasing the price for goods and services, so what Deloitte should have predicted is that the price of transit will rise. The degree to how much the price will change depends how elastic the demand is, or in other words, “Could we cope with not paying for as much upstream connectivity?”
I don’t think that that coping with a surge in demand should cause immediate concern, as luckily many ISPs employ clever people to think around these problems. I’d rather see a “bad year” for the internet lead to something other than just higher prices:
More IXes, and better co-operation between exchanges in close proximity, e.g. sharing routes that they may aggregate on their route-servers.
The larger providers finding more incentive to peer widely at exchanges, to take the pressure off their (and their new peers’) congested and now expensive upstream transit connections.
There’s no point growing out your peering matrix if your users still direct the majority of your traffic across the world because they have left a file-sharing tool running. p2p software, if p2p must exist at all, needs to understand that the every user in the entire world is not your equal peer, and someone, 200+ ms away, sharing a file on the other side of the world should never be preferred over a user that you can see over peering.
Suddenly, if the price of transit grows, it becomes much more cost-effective to cut down on unintended data use (DDOSes, virus attacks). Consumer ISPs should operate more of a ‘walled garden’ service, proxied web and smtp access, on-network access only to DNS, maybe also access to off-network mail, ftp and VPN services, and nothing else. This would stop many botnets in their tracks, and therefore the data that these networks produce.
A similar point to the one above; spam is now costing you a lot more money. If you are a big ISP in the US paying a few dollars a Mbit for inbound spam from the far east, you care a lot less than a UK company that may be paying more than 20 or 30 pounds a Mbit to get the spam. Stopping spam – an economic problem – with technology, has not stopped spam being generated. Just because it doesn’t reach your inbox doesn’t solve the whole problem.
If transit beomes more expensive and profitable (remember, in this scenario, the price increase has been caused by demand outstripping supply, so the extra cash can be pocketed by Level(3), VSNL and the like), it becomes much easier to deliver a business case to run many more undersea cables, that follow different physical paths. Similarly customers (ISPs in this case) will care more about availability of transit, and will therefore put increased pressure on their suppliers to improve redundancy, or take business to those providers who have done so.
So not all doom and gloom. Yes, we may be paying a little more for our connectivity in 2008, but you could argue that consumer services are underpriced right now, killing innovation in the ISP space. However, we may get a better service thanks to the improvements that an upward price for transit may cause.
My telnet mantra has always been ‘Telnet is only dangerous if you use it’. Leaving it enabled as an emergency way-in during ssh upgrades, for example, is a good idea. It’s a better idea to leave it turned on and visable to just your home or office, but not use it unless you only pass through your own switched network between your desktop and server running telnet.
All this changed at the weekend with the disclosure of a flaw in the authentication model for Solaris’ in.telnetd. To try it out, first enable telnet
# inetadm -e telnet
Then connect from another machine in this way:
factory:~ andy$ telnet -l “-fbin” grumps.nosignal.org
Trying 213.232.80.121…
Connected to grumps.nosignal.org.
Escape character is ‘^]’.
couldn’t set locale correctly
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
————————————————————Welcome to grumps.
$
Then (quickly) disable telnetd with an
# inetadm -d telnet
This attack raises some questions, the most interesting ones in my mind include :
The flaw was only discovered because the source to in.telnetd had been released as part of the disclosure of source to the OpenSolaris project. If the code had not been released this flaw would have not been noticed (yet), and therefore might have been picked up by the vendor and handled in a sensitive manner. On the other hand, releasing the code to the community has picked up this flaw quickly, so does the open source model lead to inherently more secure code?
It is certainly much more polite to contact the vendor so that a structured damage-limitatione exercise can begin! I don’t care that someone picks up a vulnerability in the software I use as long as one of the first people to find out is the vendor. With open source software, there is possibly no central ‘vendor’ to inform, but for the examples of the commercial companies, and huge projects like the Mozilla Foundation. The person reporting it to full-disclosure may have tried to tell Sun first, but there is no evidence to suggest this.
Well, Sun have released a patch in any case, but now that my remote sun boxes have Lights out Management cards I think it’s now time for a new mantra: Let Telnet Die. I still maintain that it’s no inherantly less secure than ssh (if used with ssl, of course), and perhaps more secure than ssh because the port-forwarding features in ssh aren’t present, but in the interests of exposing as little as possible to the outside world, I’m leaving it turned off.