You are correct that 802.1X is the "Port Based Network Access Control" standard. That standard has hooks to permit it to be used in 802.11 networks as well as in switches.
802.1X is becoming widely adopted as a security adjunct to 802.11 WLAN infrastructures. In fact, the 802.11 Task Group "i" is developing its enhanced security additions to 802.11 on the basis of 802.1X. With "i", 802.11 and 802.1X become joined at the hip.
While your criticism is somewhat accurate, the use of 802.1X in the title is actually quite relevant to the discussion of evolving 802.11 security.
You think YOU had a rounding bug????
on
Pet Bugs?
·
· Score: 5, Interesting
Get this: A few years ago I was doing real-time driver development for an embedded DSP subsystem using TI 54X processors. Months into the development, one of the processors started "losing" a serial port transmitter interrupt. This was an interrupt that (kinda like a machine gun) *MUST* fire every time, or it will never fire again.
This was a major issue, because when the interrupt was lost the system froze up and had to be rebooted (this is an embedded app - not a desktop).
I offered to assist the engineer responsible for this code. We spent two days tracing the problem in extreme detail, checking and cross-checking our results. We both concluded that the processor was simply "losing" the interrupt. There was no rational explanation. We adopted the countermeasure of using a fine grain watchdog timer to look for the lost interrupt. This isn't the best solution, since what was to keep the watchdog interrupt from being lost??? But it was the best we could do. And it worked.
The project lead, however, was very unhappy with our solution. He was convinced that we had overlooked the cause of the problem, which had to be software-based. I countered that, though he could certainly be right, it would be better to leave the watchdog in and let the project move ahead until we stumbled across the real cause in due time. He reluctantly accepted this approach.
My vindication took five months, but what sweet irony when it did. It turned out that some other company, which also used the 54X chip, had encountered the same problem, but they figured it out (and I'll never know how). The problem was that the 54X (at that time) had a silicon flaw that, when certain integer rounding instructions executed at the same instant that an interrupt were being asserted, the interrupt could be "lost". This was confirmed by TI to be a silicon fault, and no amount of software handstands or cartwheels could fix it. The only workaround was to not use those rounding instructions!
802.11a is legal only in the United States, because it operates in the 5 GHz "Unlicensed National Information Infrastructure" (U-NII) band. The IEEE 802.11 committee has a task group that is pursuing changes to the 802.11a design to improve its ability to coexist with radar that uses these frequencies in European countries. This requires adding Dynamic Frequency Assignment and Transmit Power Control (DFA/TPC, as it's referred to in the committee) to the 802.11 design. Only then will the European regulatory bodies be able to legalize it in their countries. (It is, of course, the radar operators and manufacturers who must be satisfied that 802.11a won't damage the operation of their systems.)
Here are a few tidbits of FACT that you can also process in your haste to flame LinkSys...
a) Until quite recently, the only chipset available from which to build an 802.11a radio, either user or access point, was from Atheros. Now, Resonext has released a chipset and someday (soon?) Intersil will release their Indigo chipset for 802.11a. At present, you can almost be certain that any 802.11a product you can buy uses the Atheros chipset.
b) Atheros is being VERY tight with tech specs. You most assuredly would have to sign an NDA, and probably sign a purchase agreement, committing to buy 5 to 10 thousand chips before they will THINK about letting you peek at the technical info you need to write a driver.
c) An Atheros employee told me in March that a Linux driver was under development, and would be out in "a couple of months" (so it's due, like, now).
d) Proxim sells an 802.11a Mini-PCI card as an OEM product. See: http://www.proxim.com/products/all/oem/9350/index. html and you will find that under "Drivers Available" they state: "Source code may be licensed to facilitate design-in for non-PC platforms." But don't get too excited. I'm sure you will have to sign an NDA and convince them you're gonna buy a truckload or two of cards. And I'm also sure you will find that Atheros has bound their hands also, with respect to low-level technical info needed to write a Linux driver.
c) The 72 Mbit/sec "Turbo" mode is a feature of the Atheros chipset -- Linksys just inherited it by virtue of using their chip.
And finally...
The 54 Mbit/sec (or 72 Mbit/sec "turbo") is extremely range limited. At 100 ft, 802.11a drops back to a speed which is very close to 802.11b. But there are many reasons (other than raw throughput) that 802.11a is a Good Thing (tm), so let's look on the bright side that we have it.
And by the way, let's tip our hats to Apple Computer for supporting the efforts in its advanced technology team to petition the FCC for unlicensed spectrum. I was there. I can tell you that Apple deserves praise for paying the salaries of people who did nothing but work toward getting unlicensed spectrum (e.g. U-NII, where 802.11a operates) available for us geeks:)
You just articulated my personal tirade as well. When working with other people's "open source" code, I frequently reach the point of deciding that writing my own from scratch will actually be quicker....
Let me start by admitting that I am not a regular reader of WinInfo. In fact, I did not know of its existence until this article (mentioned in the subject of this e-mail) was linked from another site.
I reviewed the statistics you refer to at securityfocus.com. I believe that the conclusions drawn from the statistics have some serious deficiencies:
In particular, "vulnerabilities" is a nebulous measure of the actual security of a system. In particular, comparing Linux vulnerabilities to Windows vulnerabilities is, at best, an apples to oranges comparison.
Why do I say this? Because it is commonplace for Linux vulnerabilities to be reported on the basis of source code examination only, with no history whatsoever of actual exploitation of the hypothesized vulnerability. Since Windows source code, even with recent liberalizations by Microsoft, enjoys a MUCH SMALLER distribution, it logically follows that a much larger percentage of Windows vulnerabilities will be "actual" exploits (seen "in the wild" so to speak) as compared to Linux.
In fact, I take it as a credit to the Linux community that, even with these "hypothetical vulnerabilities" included in the tally, the number of reported vulnerabilities are so close to Windows - an operating system that is nowhere nearly as "friendly" to discovery of "latent" vulnerabilities.
I offer these comments because you promise to "...check back on this story..." to see if this "trend" continues. I hope you will take into consideration this fundamental difference in the assessment of "more secure" in future articles.
I have a D-Link DWL-1000AP (access point) product. It uses NWN (No Wires Needed) chipset for MAC and access point functions. NWN was purchased by Intersil. I'm pretty sure the D-Link RF part is Intersil, not Atmel.
As some posters have reported, it is possible to increase usable range by boosting the output power of the Linksys box. However, you should keep in mind that the wireless link between your client device and the AP is limited by the weaker direction. Say, for instance that you have a 1 watt transmitter in your (industrial-strength) AP, but only a 10 milliwatt transmitter in your client (handheld PDA) device. All other things being equal, your 100X greater AP transmit power will be wasted, because the AP will not be able to hear your puny 10 mW handheld device more than 30 feet away...
The formal term for the analysis of effective range between two stations is LINK BUDGET. This is influenced by the following:
a) Raw transmitter power
b) Receiver sensitivity
c) Feed losses (e.g. long coax runs)
d) Antenna "gain"
All of these must be factored in to determine the effect on range which may be obtained by altering ANY of them.
The key here is that since both the AP *AND* the client device must be "hearable" by each other, boosting transmitter power on one end and changing nothing else has limited (if any) benefit.
In practice, you may be able to get an appreciable improvement in usable range by boosting the AP's transmitter power, simply because if you're using the wireless link for web surfing, you are receiving (on your client device) much more often than you are transmitting. In actuality, your client device may be re-transmitting those HTTP "GET" messages a number of times before it is heard by the AP, but the effect is inconsequential when the bulk of the traffic is being received by the client device.
Turn it around and try making your laptop a web server and see how "symmetrical" the performance turns out to be...
But that won't be where it stops. What good will that do to stop terrorism? Do you think any self-respecting terrorist would use a crypto product with a known back door in it?
No, the REAL agenda is to start there and after it proves to be totally ineffective (duh!), it will be "realized" that it must be made to be a crime to transmit any information that cannot be decrypted on demand (by whatever means). Just better hope you're not in the "random number research" field, when that day comes. You can already spend 2 years in the Graybar Hotel if you're a Brit and your "data" gets challenged.
I've listened to the "establishment" crying like babies for years now about how hard it is to fight crime and terrorism when (traitors?) citizens like YouKnowWho write and distribute free software like PeeGeePee. If a terrorist organizer can afford to send a number of recruits to flight training school, and provide their full financial support in addition to tuition, pay for all the logistical costs, etc. to pull such a thing off, I bet that organization can cobble together a "Pretty Good" crypto system to circumvent any silly back door.
" the right of the wealthy to erase the past and rewrite it in their own image..." ... like Spielberg editing out all the guns in the upcoming DVD release of ET??? see here
True, as far as yours goes, too. However, I have yet to see an 802.11b product which separates transmit and receive antenna paths. Now if you want to come up with an auto-sensing T/R switch that can switch the antenna path, I suppose you could play the asymmetric antenna game. But this is a long way from "off the shelf". I only intended to alert readers to the existence of the legal limit, and exemplify its effects on U.S. users.
Thank you for raising the question. This *IS* a legitimate concern!
In the U.S., the FCC has established EIRP limits on Part 15 spread spectrum applications (which includes 802.11 in all its forms). Other countries have their own limits - generally more strict than the U.S., IIRC
The Part 15 limits on EIRP go something like this:
a) You are allowed up to 1 watt (+30dBm) output from your transmitter.
b) You are allowed up to +6dB antenna gain (over isotropic) with a 1 watt transmitter.
c) For every dB reduction in transmitter output, you are allowed a corresponding dB in antenna gain.
In essence, this means that you are limited to +36dBm EIRP (effective isotropic radiated power). I do not know whether you can subtract transmission line/connector losses from this.
Most 802.11b transmitters are at about 30 mW, or -15 dBm. In other words, you are 15 dB below the maximum allowed transmitter power. So your antenna gain must not exceed 15 + 6 or 21 dB. Judging from the pictures in the article, it looks like they are using dish antennae with probably 23 dB of gain.
Also: The 30 mW transmit power output is an assumption -- Some radios can output 100 mW. This would reduce the legal antenna gain from 21 dB to 16 dB, which would almost certainly push them past the legal limit.
Not that I expect the FBI SWAT team to knock down your door:), but just thought I would point out that the amount of antenna gain you can utilize - and stay legal - is finite.
This topic concerns me because the more that is said in a public forum (such as this story), the more likely the FCC will be to tighten up on 802.11b uses. I have already heard that the FCC is considering making it illegal to manufacture a Part 15 transmitter (which all U.S. 802.11b products are) with an external antenna, for this very reason. I hope that does not come to pass...
Re:Ahem ... look inside your Airport ....
on
Open Networking
·
· Score: 1
No - this "frequency band" was not requested by Apple - it already existed. Apple requested additional frequencies (which were eventually allocated under the name "unlicensed NII").
The 2.4 GHz band is one of the Industrial, Scientific, and Medical (ISM) bands which have existed for some time.
The amount raised in spectrum auctions wouldn't pay half the interest on the national debt. Much fanfare is made of the revenues from spectrum auctioning, but realistically, it's a drop in the bucket.
And you're wrong, anyway. On January 9, 1997, the FCC issued a rulemaking establishing the Unlicensed National Information Infrastructure (U-NII) band. It provides unlicensed (i.e. "free") use of 300 MHz of spectrum at 5.15-5.35 GHz and 5.725-5.825 GHz.
Some products do exist for use in this band, bur ironically, they are about as far from the "spirit" of the band as you can get. Last year I installed a Wavespan (brand) point to point microwave link in the U-NII band. It carries 20 Mbits/sec plus two T1 circuits over a 1.2 mile span. Cost? Around $60,000:)
So the frequencies are there. Anybody want to develop "free" radio hardware for the "free" band?
Slashdot Mirror
You are correct that 802.1X is the "Port Based Network Access Control" standard. That standard has hooks to permit it to be used in 802.11 networks as well as in switches.
802.1X is becoming widely adopted as a security adjunct to 802.11 WLAN infrastructures. In fact, the 802.11 Task Group "i" is developing its enhanced security additions to 802.11 on the basis of 802.1X. With "i", 802.11 and 802.1X become joined at the hip.
While your criticism is somewhat accurate, the use of 802.1X in the title is actually quite relevant to the discussion of evolving 802.11 security.
This was a major issue, because when the interrupt was lost the system froze up and had to be rebooted (this is an embedded app - not a desktop).
I offered to assist the engineer responsible for this code. We spent two days tracing the problem in extreme detail, checking and cross-checking our results. We both concluded that the processor was simply "losing" the interrupt. There was no rational explanation. We adopted the countermeasure of using a fine grain watchdog timer to look for the lost interrupt. This isn't the best solution, since what was to keep the watchdog interrupt from being lost??? But it was the best we could do. And it worked.
The project lead, however, was very unhappy with our solution. He was convinced that we had overlooked the cause of the problem, which had to be software-based. I countered that, though he could certainly be right, it would be better to leave the watchdog in and let the project move ahead until we stumbled across the real cause in due time. He reluctantly accepted this approach.
My vindication took five months, but what sweet irony when it did. It turned out that some other company, which also used the 54X chip, had encountered the same problem, but they figured it out (and I'll never know how). The problem was that the 54X (at that time) had a silicon flaw that, when certain integer rounding instructions executed at the same instant that an interrupt were being asserted, the interrupt could be "lost". This was confirmed by TI to be a silicon fault, and no amount of software handstands or cartwheels could fix it. The only workaround was to not use those rounding instructions!
OK- top that....
...by the well connected
Your little protest
summarily rejected
It's an inside job
like it always is
Just chalk it up
to business as usual...
802.11a is legal only in the United States, because it operates in the 5 GHz "Unlicensed National Information Infrastructure" (U-NII) band. The IEEE 802.11 committee has a task group that is pursuing changes to the 802.11a design to improve its ability to coexist with radar that uses these frequencies in European countries. This requires adding Dynamic Frequency Assignment and Transmit Power Control (DFA/TPC, as it's referred to in the committee) to the 802.11 design. Only then will the European regulatory bodies be able to legalize it in their countries. (It is, of course, the radar operators and manufacturers who must be satisfied that 802.11a won't damage the operation of their systems.)
Here are a few tidbits of FACT that you can also process in your haste to flame LinkSys...
. html and you will find that under "Drivers Available" they state: "Source code may be licensed to facilitate design-in for non-PC platforms." But don't get too excited. I'm sure you will have to sign an NDA and convince them you're gonna buy a truckload or two of cards. And I'm also sure you will find that Atheros has bound their hands also, with respect to low-level technical info needed to write a Linux driver.
:)
a) Until quite recently, the only chipset available from which to build an 802.11a radio, either user or access point, was from Atheros. Now, Resonext has released a chipset and someday (soon?) Intersil will release their Indigo chipset for 802.11a. At present, you can almost be certain that any 802.11a product you can buy uses the Atheros chipset.
b) Atheros is being VERY tight with tech specs. You most assuredly would have to sign an NDA, and probably sign a purchase agreement, committing to buy 5 to 10 thousand chips before they will THINK about letting you peek at the technical info you need to write a driver.
c) An Atheros employee told me in March that a Linux driver was under development, and would be out in "a couple of months" (so it's due, like, now).
d) Proxim sells an 802.11a Mini-PCI card as an OEM product. See: http://www.proxim.com/products/all/oem/9350/index
c) The 72 Mbit/sec "Turbo" mode is a feature of the Atheros chipset -- Linksys just inherited it by virtue of using their chip.
And finally...
The 54 Mbit/sec (or 72 Mbit/sec "turbo") is extremely range limited. At 100 ft, 802.11a drops back to a speed which is very close to 802.11b. But there are many reasons (other than raw throughput) that 802.11a is a Good Thing (tm), so let's look on the bright side that we have it.
And by the way, let's tip our hats to Apple Computer for supporting the efforts in its advanced technology team to petition the FCC for unlicensed spectrum. I was there. I can tell you that Apple deserves praise for paying the salaries of people who did nothing but work toward getting unlicensed spectrum (e.g. U-NII, where 802.11a operates) available for us geeks
THANK YOU!
You just articulated my personal tirade as well. When working with other people's "open source" code, I frequently reach the point of deciding that writing my own from scratch will actually be quicker....
Mr. Thurrott,
Let me start by admitting that I am not a regular reader of WinInfo. In fact, I did not know of its existence until this article (mentioned in the subject of this e-mail) was linked from another site.
I reviewed the statistics you refer to at securityfocus.com. I believe that the conclusions drawn from the statistics have some serious deficiencies:
In particular, "vulnerabilities" is a nebulous measure of the actual security of a system. In particular, comparing Linux vulnerabilities to Windows vulnerabilities is, at best, an apples to oranges comparison.
Why do I say this? Because it is commonplace for Linux vulnerabilities to be reported on the basis of source code examination only, with no history whatsoever of actual exploitation of the hypothesized vulnerability. Since Windows source code, even with recent liberalizations by Microsoft, enjoys a MUCH SMALLER distribution, it logically follows that a much larger percentage of Windows vulnerabilities will be "actual" exploits (seen "in the wild" so to speak) as compared to Linux.
In fact, I take it as a credit to the Linux community that, even with these "hypothetical vulnerabilities" included in the tally, the number of reported vulnerabilities are so close to Windows - an operating system that is nowhere nearly as "friendly" to discovery of "latent" vulnerabilities.
I offer these comments because you promise to "...check back on this story..." to see if this "trend" continues. I hope you will take into consideration this fundamental difference in the assessment of "more secure" in future articles.
Regards,
(flatulus)
I have a D-Link DWL-1000AP (access point) product. It uses NWN (No Wires Needed) chipset for MAC and access point functions. NWN was purchased by Intersil. I'm pretty sure the D-Link RF part is Intersil, not Atmel.
As some posters have reported, it is possible to increase usable range by boosting the output power of the Linksys box. However, you should keep in mind that the wireless link between your client device and the AP is limited by the weaker direction. Say, for instance that you have a 1 watt transmitter in your (industrial-strength) AP, but only a 10 milliwatt transmitter in your client (handheld PDA) device. All other things being equal, your 100X greater AP transmit power will be wasted, because the AP will not be able to hear your puny 10 mW handheld device more than 30 feet away...
The formal term for the analysis of effective range between two stations is LINK BUDGET. This is influenced by the following:
a) Raw transmitter power
b) Receiver sensitivity
c) Feed losses (e.g. long coax runs)
d) Antenna "gain"
All of these must be factored in to determine the effect on range which may be obtained by altering ANY of them.
The key here is that since both the AP *AND* the client device must be "hearable" by each other, boosting transmitter power on one end and changing nothing else has limited (if any) benefit.
In practice, you may be able to get an appreciable improvement in usable range by boosting the AP's transmitter power, simply because if you're using the wireless link for web surfing, you are receiving (on your client device) much more often than you are transmitting. In actuality, your client device may be re-transmitting those HTTP "GET" messages a number of times before it is heard by the AP, but the effect is inconsequential when the bulk of the traffic is being received by the client device.
Turn it around and try making your laptop a web server and see how "symmetrical" the performance turns out to be...
But that won't be where it stops. What good will that do to stop terrorism? Do you think any self-respecting terrorist would use a crypto product with a known back door in it?
No, the REAL agenda is to start there and after it proves to be totally ineffective (duh!), it will be "realized" that it must be made to be a crime to transmit any information that cannot be decrypted on demand (by whatever means). Just better hope you're not in the "random number research" field, when that day comes. You can already spend 2 years in the Graybar Hotel if you're a Brit and your "data" gets challenged.
I've listened to the "establishment" crying like babies for years now about how hard it is to fight crime and terrorism when (traitors?) citizens like YouKnowWho write and distribute free software like PeeGeePee. If a terrorist organizer can afford to send a number of recruits to flight training school, and provide their full financial support in addition to tuition, pay for all the logistical costs, etc. to pull such a thing off, I bet that organization can cobble together a "Pretty Good" crypto system to circumvent any silly back door.
" the right of the wealthy to erase the past and rewrite it in their own image..." ... like Spielberg editing out all the guns in the upcoming DVD release of ET??? see here
True, as far as yours goes, too. However, I have yet to see an 802.11b product which separates transmit and receive antenna paths. Now if you want to come up with an auto-sensing T/R switch that can switch the antenna path, I suppose you could play the asymmetric antenna game. But this is a long way from "off the shelf". I only intended to alert readers to the existence of the legal limit, and exemplify its effects on U.S. users.
In the U.S., the FCC has established EIRP limits on Part 15 spread spectrum applications (which includes 802.11 in all its forms). Other countries have their own limits - generally more strict than the U.S., IIRC
The Part 15 limits on EIRP go something like this:
a) You are allowed up to 1 watt (+30dBm) output from your transmitter.
b) You are allowed up to +6dB antenna gain (over isotropic) with a 1 watt transmitter.
c) For every dB reduction in transmitter output, you are allowed a corresponding dB in antenna gain.
In essence, this means that you are limited to +36dBm EIRP (effective isotropic radiated power). I do not know whether you can subtract transmission line/connector losses from this.
Most 802.11b transmitters are at about 30 mW, or -15 dBm. In other words, you are 15 dB below the maximum allowed transmitter power. So your antenna gain must not exceed 15 + 6 or 21 dB. Judging from the pictures in the article, it looks like they are using dish antennae with probably 23 dB of gain.
Also: The 30 mW transmit power output is an assumption -- Some radios can output 100 mW. This would reduce the legal antenna gain from 21 dB to 16 dB, which would almost certainly push them past the legal limit.
Not that I expect the FBI SWAT team to knock down your door :), but just thought I would point out that the amount of antenna gain you can utilize - and stay legal - is finite.
This topic concerns me because the more that is said in a public forum (such as this story), the more likely the FCC will be to tighten up on 802.11b uses. I have already heard that the FCC is considering making it illegal to manufacture a Part 15 transmitter (which all U.S. 802.11b products are) with an external antenna, for this very reason. I hope that does not come to pass...
No - this "frequency band" was not requested by Apple - it already existed. Apple requested additional frequencies (which were eventually allocated under the name "unlicensed NII"). The 2.4 GHz band is one of the Industrial, Scientific, and Medical (ISM) bands which have existed for some time.
The amount raised in spectrum auctions wouldn't pay half the interest on the national debt. Much fanfare is made of the revenues from spectrum auctioning, but realistically, it's a drop in the bucket.
:)
And you're wrong, anyway. On January 9, 1997, the FCC issued a rulemaking establishing the Unlicensed National Information Infrastructure (U-NII) band. It provides unlicensed (i.e. "free") use of 300 MHz of spectrum at 5.15-5.35 GHz and 5.725-5.825 GHz.
Some products do exist for use in this band, bur ironically, they are about as far from the "spirit" of the band as you can get. Last year I installed a Wavespan (brand) point to point microwave link in the U-NII band. It carries 20 Mbits/sec plus two T1 circuits over a 1.2 mile span. Cost? Around $60,000
So the frequencies are there. Anybody want to develop "free" radio hardware for the "free" band?
... thought not....