Re:Slightly OT: Reserved IP adresses in IPv6
on
IPv6 is Here
·
· Score: 1
The IETF is in the process of deprecating the IPv6 site-local addresses, which are the moral equivalent of the IPv4 "private" addresses defined in RFC 1918. See the working group charter and the latest draft for more details.
You're thinking of the link-local prefix, which is fe80::/16. These are not the same, and are morally equivalent to the 169.254/16 IPv4 prefix used in zeroconf addressing.
The privacy and integrity of the transport data is protected by CCMP in each packet, but the HMAC-SHA1 function protects the integrity of the key exchange handshake-- which happens in the clear.
If you're worried about the integrity of your data, you care about what steps the protocol takes to prevent rogue access points from spoofing the exchange that negotiates the key that will be used for integrity checks on all your transport payloads.
My apologies for not explaining my thinking in my first post. Bad language on my part. Thanks for catching it.
Re:OK, but how does it actually work
on
IEEE Approves 802.11i
·
· Score: 5, Informative
I am a wireless expert.
802.11i uses AES for privacy, HMAC-SHA1 for integrity, and it defines its own protocol for establishing transient unicast and group session keys. You can use it with a pre-shared master key (derived from a simple passphrase), or you can use it conjunction with 802.1X and get per-user pairwise master keys derived from the authentication service.
The Wi-Fi Alliance (I'm told) is calling 802.11i by the name WPA2. If you have hardware that supports the AES variant of WPA, then your vendor should be able to supply a firmware upgrade soon that will support WPA2.
Yeah, it would be so qool to do that, wouldn't it? First thing you would do? Push the audio stream from your FPS game to the stereo.
Right about then, you would discover the problem with reliable timely delivery of datagrams over unreliable wireless media.
Hint: the word you are thinking of is 'latency'-- unfortunately, you will not be able to measure the range to your opponent by counting the milliseconds between the flash and the boom.
The shorter way to say this: single/childless people need just as much time off from work for "lifestyle management" reasons as married/parents do. There is at least one explanation for this that should come to mind readily: getting your lifestyle into a position where transitioning from single/childless to married/parenting with a somewhat manageable level of insanity is something that takes a lot of time and effort.
You do not want to waste your youthful good looks on some stupid deathmarch and wake up in your late thirties without any prospects of starting a family. Okay, maybe you do--but your insensitive clod manager doesn't need to know that.
After seeing the now infamous images of American military reservists and civilian contractors in the interrogation block of the Abu Ghraib detention facility, I am now seriously thinking about defecting to the West.
I know a thing or two about ground control and telemetry systems. I bet I can design a ground control system for a surveillance drone that would cost well under what the one for the Predator probably costs. All I need is a loan to cover relocation expenses and maybe some language classes. Anybody know if there are openings at Aerospatiale for a slightly-used American?
I may be a pedantic academic pinhead, but your P2P file-sharing network is still hopeless vulnerable to DOS-attack. Good luck rolling out a patch to Gnutella, Limewire, etc. to fix this vulnerability before RIAA figures out how to just shut it completely off for everyone.
[...] In the absence of vendor patching of the TCP implementation, the following are general mitigating steps: Implement IP Security (IPSEC) which will encrypt traffic at the network layer, so TCP information will not be visible; [...]
We told you not to deploy NAT because (among other reasons) it would break IPsec authenticated header (AH) mode. You did it anyway and told us we were pedantic academic pinheads.
In the United States, the conventional wisdom of most economists can be a little baffling to the people facing the immediate lifestyle-management effects of increased offshore outsourcing of white-collar service jobs.
A lot of economists will spin out a line that-- after you strip off all the jargon, and the econoleetspeek--will sound an awful lot like "Quit whining, you slacker, and get a real job."
It's really easy to find a million clones of Donald Luskin. You can't hardly swing a dead cat without running into economists who will tell you that global free trade in services is unqualifiably good in the short run, the long run and everything in between. It's harder to find thoughtful economists who might have pesky questions about how the mobility of capital can be easily reconciled with the immobility of most labor.
Making lazy evaluation "atomic" in the presence of concurrency is the generalized problem I was trying to surface. The mutual exclusion lock would destroy the "real-time" property of the deque operations.
Marshall in the Ocaml standard library cannot serialize/deserialize values of type Lazy.t, and that means values of my Cf_deque.t can't be used with Marshall. (This is a trivial issue in practice, because what you would do is convert a 'a Cf_deque.t into a 'a list and marshall the list.)
Both of these issues are resolved by using the Kaplan-Tarjan-Okasaki real-time catenable pure functional deque algorithm, but that structure-- to be precise about what I am contending-- has substantially larger constant multipliers in its complexity for the environment profile where I am making the comparison (which I think is a fairly common one). I'm choosing not to pay for pure functional properties where all I really care about is a) functional, b) catenable, c) constant amortized runtime cost for all operations, d) sub-linear worst-case runtime cost (actually I get O(log log N) worst case).
By the way, the Kaplan-Tarjan-Okasaki algorithm is not in the book reviewed in the top-level article.
Seriously. It's easy to learn. You don't have to immerse yourself in it for hundreds of hours just to learn how the syntax and semantics of the language work. You can pick up the whole enchilada in a couple hours of fooling around with it.
Other functional languages might be preferable for specific applications, but Scheme is the one that I would recommend learning first. It has all the basic features you need for functional programming. Learn how Scheme coders write algorithms on sequences of values and you'll cover the most useful ground in the shortest time.
Download the code and have a look. (It uses the Lazy module in the standard library, for concatenation only).
Concurrency in Ocaml is an illusion solely for the purpose of providing control inversion. There is one big lock around the entire interpreter (and an equivalent lock in native code). If you use the Thread module (with userland threads or POSIX threads, it doesn't matter which) then you can only get one thread at a time running Ocaml functions. All the other threads have to be blocked (or in the case of POSIX threads, executing outside the Ocaml runtime environment).
The distinction about "pure" functional data structures I'm making with regard to concurrency would require the data structure itself to be distributed among a network of concurrently running processing, possibly hosted on physically different machines. (My implementations don't try to do that.)
(What do I mean by "distributed among a network of concurrently running processes" in the above? Imagine that the references between components of a data structure are not pointers into a memory heap, but are Universal Resource Locators or Message Reference Identifiers instead. That should help you visualize what I'm talking about.)
Ad-hoc polymorhism / overloading does not imply implicit conversions.
Actually, the phrase 'ad-hoc' here is the killer.
What is the type of this function?
let f x y = x + y
It can't be this:
val f: 'a -> 'a -> 'a
...because then this would make no sense:
let n = f `Foo `Bar
There is an experimental extension to Ocaml (called Gcaml) that gives support for explicit overloading to the language. But that keeps it from being 'ad-hoc' now, doesn't it?
It would be nice to get 'generics' added to Ocaml and there appear to be some sound reasons for doing it, if the comments from the Caml team at INRIA are to be believed. However, it doesn't seem like there is any sound way to do it and still be 'ad-hoc' about it.
You're going to have to explicitly indicate all the specializations of an overloaded function or operator.
Because lazy evaluation is really a way of "hiding" the mutation behind a functional representation. What is happening under the sheets, of course, is that a block of memory containing a pointer to a function mutates so that it subsequently contains the result of the function instead.
For the data structure to be "pure" functional, it would have to be constructed entirely out of non-mutable components, and therefore no lazy evaluation would be permissible.
In practice, i.e. in most applications of functional languages, you wouldn't care about this distinction one single bit. In theory, however, you would care about it in the presence of concurrency or in environments where mutation is simply not possible, like when you're streaming into a read-only medium.
Here's what that really means: my Cf_deque.t type can't be used with the Marshall module in the Ocaml standard library, because it's not a "pure" functional data structure. If I had used the Kaplan-Tarjan-Okasaki realtime catenable deque structure (substantially more complicated and costly at runtime, I contend), then it would have been usable with Marshall.
If you're interested in Objective Caml, I have implemented some of the data structures mentioned in this book, i.e. just the ones I wanted the most.
Red-black binary tree
Skew-binomial heap
Real-time catenable deque
They're buried in a library containing a lot of other goodies that I haven't ported to all the platforms where Ocaml runs. The data structure modules are pure Ocaml, though- so, you can just lift them. The library is BSD licensed (two-clause), so take all the liberties you want as long as you give me props in your distribution and you can cope with the fact that you get NO WARRANTY from me. (It would be nice if you told me you were using it too-- that would help motivate me to care about timely release of updates.)
* The real-time deque is not technically a pure functional data structure since it uses lazy evaluation for handling concatenation, but- to be fair, a lot of the algorithms in Okasaki's book have a similar property. He is, of course, careful to distinguish the difference between pure and non-pure functional data structures.
Re:Can we still NAT if we want to?
on
The State of IPv6
·
· Score: 1
With IPv6, there is no such thing as a "private" address. However, there are two reasonable ways for you to get what you want:
1) Use addresses from the global realm and just don't publish a route to them on the Internet. No route = no forwarding path = your private hosts are unreachable.
2) Don't connect your private LAN to the Internet-- use link-local addresses instead.
If you really want to use a NAT, you'll probably have to write your own... there's really no good earthly reason to use one (except in the special case of NAT-PT, which is a transition mechanism for translating between IPv6 and IPv4).
It's a lack of professionalism, not intellegence -- the guy is plenty smart. Adding a little fear to the mix (we print checks dammit!) doesn't raise his concern too much.
Take it from a guy who has been where you are before... when you are brought before the grand jury, you will thank your lucky stars you kept a diary. If you're not keeping a diary now, then start one. Learn by watching other people make mistakes.
...WPA started as a kludgy workaround, however, to try and turn a weak crypto designed fixed into hardware into something with some degree of security. It was an acceptable (and trivially obvious) workaround, but enshrining it as a standard and principled security solution is going too far.
It may have started out as "a kludgy workaround" but it will finish its life very soon in an approved amendment to 802.11 as a well-engineered replacement for WEP that offers a full range of strengths: from "minimally better than WEP" to "as good as we can make it" depending on how much you're willing to change at once in your migration plans. WPA2 with AES and EAPOL should be all the "wired-equivalent privacy" that even China needs.
I'd really like to hear an explanation for why we should think that WPA2 with AES and EAPOL should be regarded as an insufficiently strong cryptographic protocol.
China is completely justified in not going down that road: why should they be saddled with the complexities of WPA if they don't have a large installed base? And why should they trust the IEEE to get it right this time?
China needs no justification to go down any road it wants. It already has the mandate of Heaven.
All I'm saying is that we ought not to get too worked up about WAPI as if it might be some superior alternative to WPA2 when there is no evidence of that yet, and even China hasn't really refused to accept the IEEE work.
The Wi-Fi Alliance has already greatly improved upon WEP with Wireless Protected Access (WPA). WPA is based on an earlier draft of the emerging 802.11i amendment. The Wi-Fi Alliance has already decided that WPA2 will be whatever the IEEE finally approves in 802.11i, which is expected to get finalized soon (where 'soon' means spring 2004).
If the typical thing happens, then vendors will be shipping WPA2 gear before the standard is finalized (since the final approval process rarely changes anything really critical). Most vendors are already shipping WPA gear that is designed to be upgraded in the field to support WPA2 when it arrives.
WPA is already an adequate security protocol for many installations, so the complaint about WEP is irrelevant. There is no reason to believe that the WAPI specification is really any better than WPA. There is also no reason to believe that WPA2 will be any worse than WPA. So the IEEE is correct to be concerned, and we should hope that China and the IEEE can reach a compromise.
I think this is just China playing hardball with the IEEE, trying either 1) to set a fire under TGi to get a standard finally approved; and/or 2) to get some amendment of theirs into the TGi process by some extraordinary means.
If China can't come to agreement with the rest of IEEE, then the open question will be whether equipment vendors will be able to achieve interoperability between WPA2 and WAPI.
That's not really great advice. If you can use WPA w/EAPOL, then use WPA w/EAPOL. If you can't be bothered to run an authorization server (or you don't know what that is), then use WPA w/PSK (pre-shared key).
Robert Moskowitz is telling us that securing a network with a poorly-chosen shared secret is a bad idea, because dictionary attacks are easy to mount. If your WEP key is an ASCII string of characters spelling out the word "PEANUT" then you're just as vulnerable (if not more) than if you had used that secret as your WPA pre-shared key passphrase.
Why? Because, in addition to the well-known weakness of WEP, it's also the case that an offline dictionary attack might succeed sooner. Just snarf a pile of WEP-encrypted frames and mount a dictionary attack on the raw WEP key used to encrypt the IP headers.
And if the access point is an Apple AirPort Base Station, then the WEP key is actually most likely the product of a hash function (one not widely published, but it's no secret). That's only a little speedbump.
The problem has always been there. It isn't getting any worse with WPA pre-shared key. If you can upgrade to WPA, you have no good reason to stick with WEP other than you're lazy. (Don't get me wrong-- lazy can be a perfectly good reason.)
And if you're a network administrator, and you care deeply about wireless security, because-- I don't know-- you're on contract to the U.S. Department of Homeland Paranoia, then install a RADIUS server and run WPA w/EAPOL. And spend the extra $49.95 per station for the hardware upgrade to support AES rather than TKIP. All your deepest fears should be ameliorated by this.
A more cogent point to be made: all of these operating systems that currently support IPv6 do not have the full suite of transition mechanisms that are required to keep the user from having to know whether they are using IPv4 or IPv6 for any given application.
There's a long list of important transition mechanism protocols that need to be deployed to smooth the transition to IPv6, e.g. 6to4, Teredo, NAPT, etc. And they just aren't there yet.
Another thing that has to be fixed before IPv6 will start showing up is dual-stack IPv6/IPv4 residential gateway boxes. There are specs for these things floating around, and that implies that there are people planning to build them and roll them out.
But right now, your average cable-modem system and DSL router are designed to give customers exactly one IPv4 address (and maybe not even a public realm one). Getting IPv6 deployed over the top of this infrastructure is an ongoing process. It's happening now, but it will take years. Maybe even the better part of this decade. Maybe more.
Most people reading this thread will eventually upgrade to IPv6... without knowing it. A few will upgrade only when they discover how much more they're spending on maintainance of their old IPv4 network compared to what they would have spent if they had upgraded to IPv6 earlier. The rest of you will be killing yourselves, trying to keep from upgrading to IPv6, because you all belong to some kind of sick religious cult.
More accurately, if enough people share the responsibility for a mistake, then no one really gets enough of the blame.
The problem for the prosecutors is not I think that too many people are responsible for the cratering of EBS. It's that there are so many players, it's hard to sort out the truly culpable from the merely incompetent.
There were three executives in the "Office of the Chairman" and there were something like thirty-six Vice Presidents that directly reported to them. One of my directors called those Tuesday morning teleconferences by the disparaging term the "Mosh Pit" meeting. (They were on Tuesdays, right? See-- I should have kept a diary.)
There's this beer-swilling conspiracy theorist in the back of my head who thinks the apparent disarray may have been engineered specifically to cover the tracks for a swindle of monumental proportions. Proving it happened, I think, will be next to impossible.
Okay, so I went and read the NYT article. It says what I said, plus a whole lot else that I don't find particularly new. (Though, I was amused to see the name 'InterAgent' crop up in the context of the 'petty infighting' between engineering managers-- tells me a lot about who is talking to the reporters from the Times...) Loved the title: Deception, or Disarray? My answer: probably equal parts of both.
There are still some questions hanging in the air for me, but I'll keep them to myself. I'll say this: if what certain people told me in confidence about those analyst demonstrations in January is true, then I certainly hope it comes out. It was pretty disturbing to me when I heard the rumor.
I believe the prosecution is talking with people who will tell the truth in their testimony, but I am not optimistic that the government will be able to get a conviction. The story is just way too confusing and there are so many players that it's impossible to track them all. I'll bet the investigators and the prosecutors are lost in a maze of twisty little passages, all alike. "There is a bone here."
Slashdot Mirror
The IETF is in the process of deprecating the IPv6 site-local addresses, which are the moral equivalent of the IPv4 "private" addresses defined in RFC 1918. See the working group charter and the latest draft for more details.
You're thinking of the link-local prefix, which is fe80::/16. These are not the same, and are morally equivalent to the 169.254/16 IPv4 prefix used in zeroconf addressing.
--
The privacy and integrity of the transport data is protected by CCMP in each packet, but the HMAC-SHA1 function protects the integrity of the key exchange handshake-- which happens in the clear.
If you're worried about the integrity of your data, you care about what steps the protocol takes to prevent rogue access points from spoofing the exchange that negotiates the key that will be used for integrity checks on all your transport payloads.
My apologies for not explaining my thinking in my first post. Bad language on my part. Thanks for catching it.
I am a wireless expert.
802.11i uses AES for privacy, HMAC-SHA1 for integrity, and it defines its own protocol for establishing transient unicast and group session keys. You can use it with a pre-shared master key (derived from a simple passphrase), or you can use it conjunction with 802.1X and get per-user pairwise master keys derived from the authentication service.
The Wi-Fi Alliance (I'm told) is calling 802.11i by the name WPA2. If you have hardware that supports the AES variant of WPA, then your vendor should be able to supply a firmware upgrade soon that will support WPA2.
Yeah, it would be so qool to do that, wouldn't it? First thing you would do? Push the audio stream from your FPS game to the stereo.
Right about then, you would discover the problem with reliable timely delivery of datagrams over unreliable wireless media.
Hint: the word you are thinking of is 'latency'-- unfortunately, you will not be able to measure the range to your opponent by counting the milliseconds between the flash and the boom.
The shorter way to say this: single/childless people need just as much time off from work for "lifestyle management" reasons as married/parents do. There is at least one explanation for this that should come to mind readily: getting your lifestyle into a position where transitioning from single/childless to married/parenting with a somewhat manageable level of insanity is something that takes a lot of time and effort.
You do not want to waste your youthful good looks on some stupid deathmarch and wake up in your late thirties without any prospects of starting a family. Okay, maybe you do--but your insensitive clod manager doesn't need to know that.
After seeing the now infamous images of American military reservists and civilian contractors in the interrogation block of the Abu Ghraib detention facility, I am now seriously thinking about defecting to the West.
I know a thing or two about ground control and telemetry systems. I bet I can design a ground control system for a surveillance drone that would cost well under what the one for the Predator probably costs. All I need is a loan to cover relocation expenses and maybe some language classes. Anybody know if there are openings at Aerospatiale for a slightly-used American?
-
I may be a pedantic academic pinhead, but your P2P file-sharing network is still hopeless vulnerable to DOS-attack. Good luck rolling out a patch to Gnutella, Limewire, etc. to fix this vulnerability before RIAA figures out how to just shut it completely off for everyone.
--
From the advisory:
We told you not to deploy NAT because (among other reasons) it would break IPsec authenticated header (AH) mode. You did it anyway and told us we were pedantic academic pinheads.
You deserve what you get.
--
In the United States, the conventional wisdom of most economists can be a little baffling to the people facing the immediate lifestyle-management effects of increased offshore outsourcing of white-collar service jobs.
A lot of economists will spin out a line that-- after you strip off all the jargon, and the econoleetspeek--will sound an awful lot like "Quit whining, you slacker, and get a real job."
That's why I recommend Max Sawicky's Guide To Economics Web Sites. He works for The Economic Policy Institute, a "liberal" economics think tank.
It's really easy to find a million clones of Donald Luskin. You can't hardly swing a dead cat without running into economists who will tell you that global free trade in services is unqualifiably good in the short run, the long run and everything in between. It's harder to find thoughtful economists who might have pesky questions about how the mobility of capital can be easily reconciled with the immobility of most labor.
Both of these issues are resolved by using the Kaplan-Tarjan-Okasaki real-time catenable pure functional deque algorithm, but that structure-- to be precise about what I am contending-- has substantially larger constant multipliers in its complexity for the environment profile where I am making the comparison (which I think is a fairly common one). I'm choosing not to pay for pure functional properties where all I really care about is a) functional, b) catenable, c) constant amortized runtime cost for all operations, d) sub-linear worst-case runtime cost (actually I get O(log log N) worst case).
By the way, the Kaplan-Tarjan-Okasaki algorithm is not in the book reviewed in the top-level article.
--
Scheme.
Seriously. It's easy to learn. You don't have to immerse yourself in it for hundreds of hours just to learn how the syntax and semantics of the language work. You can pick up the whole enchilada in a couple hours of fooling around with it.
Other functional languages might be preferable for specific applications, but Scheme is the one that I would recommend learning first. It has all the basic features you need for functional programming. Learn how Scheme coders write algorithms on sequences of values and you'll cover the most useful ground in the shortest time.
--
Download the code and have a look. (It uses the Lazy module in the standard library, for concatenation only).
Concurrency in Ocaml is an illusion solely for the purpose of providing control inversion. There is one big lock around the entire interpreter (and an equivalent lock in native code). If you use the Thread module (with userland threads or POSIX threads, it doesn't matter which) then you can only get one thread at a time running Ocaml functions. All the other threads have to be blocked (or in the case of POSIX threads, executing outside the Ocaml runtime environment).
The distinction about "pure" functional data structures I'm making with regard to concurrency would require the data structure itself to be distributed among a network of concurrently running processing, possibly hosted on physically different machines. (My implementations don't try to do that.)
(What do I mean by "distributed among a network of concurrently running processes" in the above? Imagine that the references between components of a data structure are not pointers into a memory heap, but are Universal Resource Locators or Message Reference Identifiers instead. That should help you visualize what I'm talking about.)
Actually, the phrase 'ad-hoc' here is the killer.
What is the type of this function?It can't be this:...because then this would make no sense:There is an experimental extension to Ocaml (called Gcaml) that gives support for explicit overloading to the language. But that keeps it from being 'ad-hoc' now, doesn't it?
It would be nice to get 'generics' added to Ocaml and there appear to be some sound reasons for doing it, if the comments from the Caml team at INRIA are to be believed. However, it doesn't seem like there is any sound way to do it and still be 'ad-hoc' about it.
You're going to have to explicitly indicate all the specializations of an overloaded function or operator.
--
Because lazy evaluation is really a way of "hiding" the mutation behind a functional representation. What is happening under the sheets, of course, is that a block of memory containing a pointer to a function mutates so that it subsequently contains the result of the function instead.
For the data structure to be "pure" functional, it would have to be constructed entirely out of non-mutable components, and therefore no lazy evaluation would be permissible.
In practice, i.e. in most applications of functional languages, you wouldn't care about this distinction one single bit. In theory, however, you would care about it in the presence of concurrency or in environments where mutation is simply not possible, like when you're streaming into a read-only medium.
Here's what that really means: my Cf_deque.t type can't be used with the Marshall module in the Ocaml standard library, because it's not a "pure" functional data structure. If I had used the Kaplan-Tarjan-Okasaki realtime catenable deque structure (substantially more complicated and costly at runtime, I contend), then it would have been usable with Marshall.
Red-black binary tree
Skew-binomial heap
Real-time catenable deque
They're buried in a library containing a lot of other goodies that I haven't ported to all the platforms where Ocaml runs. The data structure modules are pure Ocaml, though- so, you can just lift them. The library is BSD licensed (two-clause), so take all the liberties you want as long as you give me props in your distribution and you can cope with the fact that you get NO WARRANTY from me. (It would be nice if you told me you were using it too-- that would help motivate me to care about timely release of updates.)
* The real-time deque is not technically a pure functional data structure since it uses lazy evaluation for handling concatenation, but- to be fair, a lot of the algorithms in Okasaki's book have a similar property. He is, of course, careful to distinguish the difference between pure and non-pure functional data structures.
With IPv6, there is no such thing as a "private" address. However, there are two reasonable ways for you to get what you want:
.
1) Use addresses from the global realm and just don't publish a route to them on the Internet. No route = no forwarding path = your private hosts are unreachable.
2) Don't connect your private LAN to the Internet-- use link-local addresses instead.
If you really want to use a NAT, you'll probably have to write your own... there's really no good earthly reason to use one (except in the special case of NAT-PT, which is a transition mechanism for translating between IPv6 and IPv4)
Don't expect people to have a change of heart and to suddenly go back to the bad old days of every system being wide open on the wild west Internet.
Please explain to me how the "bad old days" were any *worse* than the situation we have today.
It's a lack of professionalism, not intellegence -- the guy is plenty smart. Adding a little fear to the mix (we print checks dammit!) doesn't raise his concern too much.
Take it from a guy who has been where you are before... when you are brought before the grand jury, you will thank your lucky stars you kept a diary. If you're not keeping a diary now, then start one. Learn by watching other people make mistakes.
--
...WPA started as a kludgy workaround, however, to try and turn a weak crypto designed fixed into hardware into something with some degree of security. It was an acceptable (and trivially obvious) workaround, but enshrining it as a standard and principled security solution is going too far.
It may have started out as "a kludgy workaround" but it will finish its life very soon in an approved amendment to 802.11 as a well-engineered replacement for WEP that offers a full range of strengths: from "minimally better than WEP" to "as good as we can make it" depending on how much you're willing to change at once in your migration plans. WPA2 with AES and EAPOL should be all the "wired-equivalent privacy" that even China needs.
I'd really like to hear an explanation for why we should think that WPA2 with AES and EAPOL should be regarded as an insufficiently strong cryptographic protocol.
China is completely justified in not going down that road: why should they be saddled with the complexities of WPA if they don't have a large installed base? And why should they trust the IEEE to get it right this time?
China needs no justification to go down any road it wants. It already has the mandate of Heaven.
All I'm saying is that we ought not to get too worked up about WAPI as if it might be some superior alternative to WPA2 when there is no evidence of that yet, and even China hasn't really refused to accept the IEEE work.
--
The Wi-Fi Alliance has already greatly improved upon WEP with Wireless Protected Access (WPA). WPA is based on an earlier draft of the emerging 802.11i amendment. The Wi-Fi Alliance has already decided that WPA2 will be whatever the IEEE finally approves in 802.11i, which is expected to get finalized soon (where 'soon' means spring 2004).
If the typical thing happens, then vendors will be shipping WPA2 gear before the standard is finalized (since the final approval process rarely changes anything really critical). Most vendors are already shipping WPA gear that is designed to be upgraded in the field to support WPA2 when it arrives.
WPA is already an adequate security protocol for many installations, so the complaint about WEP is irrelevant. There is no reason to believe that the WAPI specification is really any better than WPA. There is also no reason to believe that WPA2 will be any worse than WPA. So the IEEE is correct to be concerned, and we should hope that China and the IEEE can reach a compromise.
I think this is just China playing hardball with the IEEE, trying either 1) to set a fire under TGi to get a standard finally approved; and/or 2) to get some amendment of theirs into the TGi process by some extraordinary means.
If China can't come to agreement with the rest of IEEE, then the open question will be whether equipment vendors will be able to achieve interoperability between WPA2 and WAPI.
--
"At least use WEP?"
That's not really great advice. If you can use WPA w/EAPOL, then use WPA w/EAPOL. If you can't be bothered to run an authorization server (or you don't know what that is), then use WPA w/PSK (pre-shared key).
Robert Moskowitz is telling us that securing a network with a poorly-chosen shared secret is a bad idea, because dictionary attacks are easy to mount. If your WEP key is an ASCII string of characters spelling out the word "PEANUT" then you're just as vulnerable (if not more) than if you had used that secret as your WPA pre-shared key passphrase.
Why? Because, in addition to the well-known weakness of WEP, it's also the case that an offline dictionary attack might succeed sooner. Just snarf a pile of WEP-encrypted frames and mount a dictionary attack on the raw WEP key used to encrypt the IP headers.
And if the access point is an Apple AirPort Base Station, then the WEP key is actually most likely the product of a hash function (one not widely published, but it's no secret). That's only a little speedbump.
The problem has always been there. It isn't getting any worse with WPA pre-shared key. If you can upgrade to WPA, you have no good reason to stick with WEP other than you're lazy. (Don't get me wrong-- lazy can be a perfectly good reason.)
And if you're a network administrator, and you care deeply about wireless security, because-- I don't know-- you're on contract to the U.S. Department of Homeland Paranoia, then install a RADIUS server and run WPA w/EAPOL. And spend the extra $49.95 per station for the hardware upgrade to support AES rather than TKIP. All your deepest fears should be ameliorated by this.
--
A more cogent point to be made: all of these operating systems that currently support IPv6 do not have the full suite of transition mechanisms that are required to keep the user from having to know whether they are using IPv4 or IPv6 for any given application.
There's a long list of important transition mechanism protocols that need to be deployed to smooth the transition to IPv6, e.g. 6to4, Teredo, NAPT, etc. And they just aren't there yet.
Another thing that has to be fixed before IPv6 will start showing up is dual-stack IPv6/IPv4 residential gateway boxes. There are specs for these things floating around, and that implies that there are people planning to build them and roll them out.
But right now, your average cable-modem system and DSL router are designed to give customers exactly one IPv4 address (and maybe not even a public realm one). Getting IPv6 deployed over the top of this infrastructure is an ongoing process. It's happening now, but it will take years. Maybe even the better part of this decade. Maybe more.
Most people reading this thread will eventually upgrade to IPv6... without knowing it. A few will upgrade only when they discover how much more they're spending on maintainance of their old IPv4 network compared to what they would have spent if they had upgraded to IPv6 earlier. The rest of you will be killing yourselves, trying to keep from upgrading to IPv6, because you all belong to some kind of sick religious cult.
--
...oh that's right. We're too smart for organizing into labor unions. What was I THINKING about?
More accurately, if enough people share the responsibility for a mistake, then no one really gets enough of the blame.
The problem for the prosecutors is not I think that too many people are responsible for the cratering of EBS. It's that there are so many players, it's hard to sort out the truly culpable from the merely incompetent.
There were three executives in the "Office of the Chairman" and there were something like thirty-six Vice Presidents that directly reported to them. One of my directors called those Tuesday morning teleconferences by the disparaging term the "Mosh Pit" meeting. (They were on Tuesdays, right? See-- I should have kept a diary.)
There's this beer-swilling conspiracy theorist in the back of my head who thinks the apparent disarray may have been engineered specifically to cover the tracks for a swindle of monumental proportions. Proving it happened, I think, will be next to impossible.
Okay, so I went and read the NYT article. It says what I said, plus a whole lot else that I don't find particularly new. (Though, I was amused to see the name 'InterAgent' crop up in the context of the 'petty infighting' between engineering managers-- tells me a lot about who is talking to the reporters from the Times...) Loved the title: Deception, or Disarray? My answer: probably equal parts of both.
There are still some questions hanging in the air for me, but I'll keep them to myself. I'll say this: if what certain people told me in confidence about those analyst demonstrations in January is true, then I certainly hope it comes out. It was pretty disturbing to me when I heard the rumor.
I believe the prosecution is talking with people who will tell the truth in their testimony, but I am not optimistic that the government will be able to get a conviction. The story is just way too confusing and there are so many players that it's impossible to track them all. I'll bet the investigators and the prosecutors are lost in a maze of twisty little passages, all alike. "There is a bone here."