May 27, 2004
Boadband over Powerlines
this message is part of this thread: http://www.the-collective.net/mailinglist/pen/msg14766.html
It's not geeks vs. geeks. It's geeks vs. industrial and regulatory morass.
Picture a city with two transportation systems, one network of roads and one network of canals. Traditionally, the milkman has made his rounds in a cart, leaving bottles of milk on doorsteps as you might imagine. But the company who runs the canals sees an opportunity to compete in the milk delivery business. It's very simple, they just dump a million gallons of milk into the canal system, and install special pumps at each building to suck up the milk, filter it, and bottle it. It's completely the wrong way to do things, but it's the only way the canal company can get into the milk industry.
Any geek with a modicum of physical-layer understanding will tell you why BPL is a conceptual abortion. Power lines carry a lot of current at very high voltage, but luckily 60Hz is a low frequency. They still blast a lot of noise out, because it's not practical to shape them in such a way as to keep the interference contained. We deal with it. Any audio engineer will tell you the extreme measures it takes to keep 60Hz noise out of a recording. Certain types of measurement gear include special sampling strategies to ignore 60Hz noise which would otherwise swamp the subject signal. ULF radio transmissions use other frequencies, because 60Hz is just useless. And of course, property values are lower near large powerlines because of the potential health effects of the magnetic field. (I'm not going to get into the verifiability of those effects, simply saying that the effect on property value is real.)
All this is because powerlines are spaced several feet apart, to keep the voltage from arcing from one conductor to the other. This spacing turns them into effective antennae, happily radiating the signal that's fed into them. If aliens are going to notice Earth, it'll be from the low-frequency emanations from our power grids.
Now consider Ethernet for a moment, specifically its original incarnation, known as 10base2. The name tells us a lot, 10 is the signalling rate, in megabits per second. "base" means it's a baseband medium, that the signalling is applied directly to the wire, not used as a modulation for some sort of a carrier signal. The 2 tells us the kind of wire, 2-conductor coaxial cable. The inner conductor is used for the signal, and the outer shield keeps the noise from leaking out. This is important, because in order to achieve a useful data rate in the megabits, the spectral width of the signal is pretty huge. If not carefully contained in cabling designed for it, your LAN would obliterate radio transmissions for quite a radius. And that's just the energy produced by a little network card, intended to go a few hundred feet through cable.
Now consider DSL and cable modems. Each of these technologies uses modulation to shift the baseband data up into another part of the radio spectrum. DSL uses the same twisted pair that carries POTS, but since voice only uses about 4KHz of bandwidth, they put the data starting just above 4KHz, and let it run up to about 2.2MHz. (Different DSL flavors split the spectrum differently between upstream and downstream directions) Sending a balanced signal down twisted pair also keeps the noise in check, so you can run several DSL circuits in the same binder and they don't interfere with each other very much. Cable modems do a similar technique, but since their cable is already carrying TV signals, they use different bits of the spectrum for it. The trick here is that the cable network is a bus architecture, and each modem's upstream transmissions have to be strong enough to be heard at the head end. This means that careful shielding is critical. A noisy cable amplifier can splatter interference all over, causing problems with any number of radio systems.
Providing a useful data rate to customers means generating a lot of RF energy, and then keeping it contained to minimize interference. Cable and DSL have their work cut out for them, simply maintain the physical network and the signal stays in the wires where it belongs. Wireless ISPs do things differently, using antennae to carefully focus their transmissions, and occasionally using filters to clean up the edges of their spectrum where the equipment might be a bit too noisy.
Broadband over powerlines does just the opposite. BPL uses a modulated signal like you might find in DSL or cable, but it blasts the signal onto a wiring system that can't possibly contain the noise. Because of the extremely poor match between the signal and the wiring, the power levels are very high just to get a useful signal at the receiver. The power lost in the middle is all noise, and it goes everywhere. The power grid acts as an antenna. There's no way to make it work cleanly and efficiently, short of replacing all the powerlines with coax or twisted pair, and at that point it won't be useful as a power grid anymore.
BPL is the wrong thing to do with data, and it's the wrong thing to do with powerlines. It happens to be the only way the electric utility can compete in the data arena, and I don't really blame them for trying. If competition for cable and DSL service were meaningful, the power grid might not be the avenue of last resort. That's a problem with regulation and monopolies, broader than I want to get into right now. The fact remains that BPL is destructive to radio spectrum and a bad idea in general. If you understand this mess, it's your responsibility to oppose BPL with every resource available to you.
-Myself-
May 05, 2004
sasser and CSA
This is a notice from Cisco about how the Cisco Security Agent "Protects" against the sasser worm. That is for the people who have not patched thier machines.
It has come to my attention that there is some confusion regarding what our CSA for Voice Applications protects against regarding the recent Sasser worm.
Here is what we know so far:
- our policies do prevent sasser from copying itself.
- our policies do prevent sasser from executing.
- our policies do not prevent sasser from crashing LSASS.EXE with a buffer overrun, therefore creating a denial of service attack risk since this crash causes the machine to reboot.
The CSA for Voice Applications policies do include the default bufffer overrun rule from the CSA product, but apparently this was not effective in this case. We are still working with VsecBU on this and will keep you posted once we know more.
In the meantime, even though our custumers that have CSA properly running on their voice application servers will not get infected with Sasser, they need to patch their systems to prevent them from rebooting once/if the worm makes it into the network those servers are directly connected to (firewalls are effective at stoping sasser). We don't know exactly at what rate they are bound to see the DOS attack occur, but we do know it can happen.
Included below you will find instructions on patching customer's servers as per the the announcement posted on customer-ccm-announce@cisco.com on Monday titled:
"Fixes for Sasser Virus (active exploit of MS04-011) for Cisco CallManager and Unity":
Callmanager, CER, PA, etc (non-Unity):
MS04-011 is in 2000.2.5sr7 and sr8 or 2000.2.6 posted on Cisco.com:
http://www.cisco.com/cgi-bin/tablebuild.pl/cmva-3des
For CallManager, please install the win-OS update and do not apply the patch from Microsoft.
Unity:
Since this is not a service pack, you can install the MS04-011 patch directly to a Unity server.
http://www.microsoft.com/technet/security/bulletin/MS04-011.mspx
Microsoft's Official Page:
http://www.microsoft.com/security/incident/sasser.asp
This page also includes a link to run a program to remove the virus AFTER the patch has been installed.
More information on the virus:
http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=125008
http://securityresponse.symantec.com/avcenter/venc/data/w32.sasser.worm.html
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_SASSER.A
There are at least 3 variants A, AB, and B.
Please let me know if you have further concerns regarding the effect of sasser on our voice application servers.
Welcome
This is a new project of mine to start a weblog about networking, managing and implementing them.
Why another blog? I have yet to find something out there the is vendor neutral and talks in a real world way about networking.