Intel's 802.11A Wireless: 5x Faster

Jaben writes: "Intel today released the first 802.11A wireless LAN devices which offer more than a fivefold increase in speed over the current 802.11B. as soon as more devices get onto the market this new technology will really make wireless a possible alternative instead of a neat item to play with."

Comments

802.11b isn't a toy

[tonyc.com]

"[T]his new technology will really make wireless a possible alternative instead of a neat item to play with."

Excuse me, but an 11 megabit wireless connection isn't quite worthless just yet. How many home users, even with DSL or cable modems, are pushing this limit? And how many offices are still using 10baseT LANs, or 10baseT hubs on even faster LANs? To all these users, 802.11b is still 10% overkill. Will 400% overkill make us any happier or more productive?

Plus, 802.11a is much more power-hungry, making it a decidedly unattractive choice for wireless PDAs. What say ye?

Not the first

[mosch]

Despite what this article says, Intel is not the first company to release 802.11a devices. Proxim has the Harmony line of 802.11a devices, and has for some time.

Slashdot needs a fact checker.

Re:5x more secure?

[cymen]

IPSec. Why waste your time with anything else? I really want a guide for getting Linux with FreeSwan to talk to FreeBSDs IPSec (using racoon?). There are a number of guides to getting IPSec working on Windows 2000, FreeBSD, OpenBSD, etc... Here are a few links:


How to setup IPsec interoperable for Linux, OpenBSD and PGPNet
Replacing WEP With IPsec

Why does IPSec with Linux seem like such a hack? FreeSwan is pretty annoying - why don't they just get IPSec into the kernel and go from there? Instead there appears to be a megapatch. It just makes me nervous. It's probably ok but man... Also, while I'm bitching, IPSec is a bit of a pain - or at least the implementations are. It doesn't need to be this complicated.

Re:5x more secure?

[cduffy]

It doesn't have to be secure (think IPsec), but I'm sure that everyone can see major benfits of making a technology that openly broadcasts data more secure.

I don't.

Picture this:

I have an incoming connection, a router, and a wireless network. I have several hosts on the wireless network. The router uses IPsec to communicate with the internal hosts, accepts only hosts with known keys, and ignores all other connections.

What is the advantage of having the wireless protocol itself have the overhead of a separate, redundant security layer? Why would you want the separate software complexity of configuring and tracking allowed-host lists for two protocol layers instead of one?

Down that path lies having every last protocol layer being complicated by trying to do a job which is handled satisfactorily by every other one. Far better to have a single layer which does security and Does It Right than to complicate 802.11 (or any other low-level protocol) by adding complex functionality which can be handled somewhere else.

Further, consider: If 802.11 has security built into it, then whenever that security is broken, 802.11 (and the hardware that uses it) needs to be changed; same for every other low-level layer. Much better to have only one higher-level layer to keep current/secure (and have to swap out the router and install new endpoint drivers in my theoretical example, but not have to replace the wireless hardware).

Why products are insecure

[billstewart]

Cell phones, cordless phones, wireless networking, etc. should all use strong encryption, yet none of them do?

Sometimes you have to attribute it to malice, sometimes to stupidity, sometimes to changes in technology.

• Analog cellphones were too early, and you need to digitize data to do effective encryption. Analog cordless phones have the same problem, plus they're trying to be cheap.
• Digital cellphones are primarily weak because of malice - the US government armtwisted the US TDMA and CDMA standards committees into using obnoxiously weak encryption, with the leverage that crypto export laws could be used to prevent them from selling profit-making cell site equipment internationally and getting cheap handsets made internationally.
  
• The European GSM primary encryption algorithm A5/1 is technically incompetent, and doesn't have enough bits in the encryption keys, but as Goldberg et al. discovered, it's further weakened by setting 10 of its bits to all-zeros. And the alternate encryption algorithms designed for non-politically-connected countries are even weaker. The algorithm incompetence could have been prevented by developing it in public, with some competent peer review, but the demands for secrecy blocked it - as anybody in the crypto business knows, that's a big lose.
  
• Anything using 40 or 64 bit crypto is limited by US export laws (either current at the time the stuff was designed, or obsolete but old habit.)
  
• 56-bit DES encryption used to be adequate technology, but reality caught up with them. Unfortunately, it does enough slow bit-twiddling that the triple-DES variation, which is strong enough for anything, is too slow for many high-speed applications unless you add appropriate hardware implementations or a fast CPU. Also, there are applications that only use 56-bit single-DES for US export law reasons (again, generally no longer applicable, but some countries also restrict imports.)
  
• Any current 128-bit symmetric algorithm is strong enough (though some of them use MD5 hashes to generate keys, and those are looking technically shaky - but you can avoid that.) IDEA had minor patent problems (but Ascom-tech was friendly about free licenses for non-commercial use, and reasonably priced for commercial use.)
  
• RC4 encryption has a few simple rules about using it safely, like "never use the same key twice" and "if you're using it to XOR with your plaintext, make sure to design your application so it doesn't give away information." That's what killed Microsoft PPTP, and it's one of the problems with WEP. No malice, just incompetence.
  
• Authentication is hard. Sure, the RSA algorithm provides some of the fundamental tools, and now that the patent's expired it's easier to use them, but if you want to limit access to authenticated authorized users, you have to solve the problem of deciding who's authorized to do what, how to authenticate that they are, and how to distribute the data to enforce it. This is where many systems choke. Do you need PKIs? Do you want to distribute shared secrets? Do you want to allow promiscuous connections from anybody driving by with am 802.11b in their laptop and still have something you call security?
  
• The market is usually more concerned about authentication than privacy. Not too many people eavesdrop on cellphone calls for the content, compared to the likelihood that if a bad authentication method makes it easy for Bad Guys to clone your cellphone and make $500 calls to Bolivia which you'll refuse to pay The Phone Company for, so that's where the emphasis is. Privacy is important to some users (and there are things many people won't talk about over cellphones), but if it doesn't leak password information it's often just not a priority.
  
• Add your own issues here. There are lots of them...