Agreed, if only we'd done one thin-enough-for-Apple-fetishists revamp of ethernet before USB came along, and made a protocol that allowed peripheral PANs to coexist on ethernet switches with the LAN, we could have wasted a lot less silicon with a universal ethernet/peripheral port instead of USB.
One good push to get ethernet where it needs to be for the mobile market would be great, IMO, but only one, done right the first time and not priced out of the market by licensing fees -- the latter of which is probably the only reason a crummy standard like USB got adopted, with what, at the time, was incredibly CPU-unfriendly hardware level a protocol stack which was just a bodged together mess poised to create an even bigger mess as it was extended to eventually catch up to the state of the art.
If we could trust USB bodies not to invent yet another plug it might be possible to use the current pinout of the latest USB and autodetect whether you are plugged into ethernet or USB. Unfortunately any such trust would be foolish, even if they promised.
Mostly only the newsworthy ones get them, ones that need widespread attention even for administrative domains that can't afford a dedicated security person/department. It's a lot easier to give them names then have meetings saying "where do we stand on CVE-year-four-digit-number" simply because the human brain wraps around names better. Especially if a clue as to the shape of the exploit is embedded in the name, serving as a mnemonic -- e.g. HeartBlead is used to blead information from heartbeat exchanges.
There's less evidence to support significant voter fraud than there is to support significant election fraud and voter suppression.
I hope one of the things Donald Trump does when he's in office is to start implementing the electoral system that America deserves, not this farce
Hah! I'm sure he'd tell you he will, even though it won't be under his purview. In fact, he might even think he's telling the truth (for a change) in that case because he probably does not know the office of the president doesn't have the authority over that.
...and obtaining a database of such models for various users becomes further motivation to compromise webcams. Way to go Amazon, keeping the cracker economy vibrant.
I think kb+mouse will always have the advantage but if game devs would stop making dead zones designed for senior citizens it could narrow the gap a bit.
Let's say we were talking not of cell phones but of hard drives. Should future SSDs be banned because they are easier to fully erase/destroy? Back to platters, just for the sake of law enforcement? No thanks.
Well, it's better than the last FC powered drone ("Hycopter") that had nice glass tubes full of compressed gaseous H2 eagerly pleading for a nice crash into a telephone pole transformer.
So you kill DNS-SD over mDNS (Apple's Bonjour)? No printer discovery, no discovery of streaming media servers, no IPTV?
Yeah pretty much stomp the crap out of any protocol that is built on the erroneous premise that network segmentation has any bearing on the borders of a LAN/PAN anymore, and then use vendor solutions to filter it and distribute it to specific hosts, both in and outside the IP broadcast domain (the latter part can only be done with protocols that don't have a ban on using servers outside their subnet, so no MS media players.)
Though, demand has not been high enough for my boss to elevate setting that up on my TODO list yet. So right now only devices logged in under the same username can see each other (setup of that was a just a button push.)
I used to wish journalist wouldn't do this, and use the "enough to power X homes" energy measure, on principle (choosing that energy measure because it is easy enough for journalists to understand.) Now I wish they wouldn't do it just because of the number of replies it generates on Internet threads to point out the error.
The principle advantage I have seen claimed for natural gas other than the lower carbon content is that the generators used for natural gas in electricity production can be quickly ramped up and down to adapt to demand. A possible marginal benefit is that infrastructure for natural gas distribution in heating could also start mixing in biogas, perhaps even replacing it completely with a renewable. Also it is probably easier to get a PEM fuel cell to work on it.
Lower power, possibly cheaper hardware, and can unify IoT device management with WiFi seem to be the primary potential benefits. How well it does and how long it can afford to stay proprietary and still be bothered with is a matter market economics will have to decide.
802.11b in this case. Considering the phase this research is at it is not surprising compliance tests have not been engaged.
Assuming they aren't polluting outside their band, given the range they demonstrated they've got something viable here -- WiFi is headed towards a microcell architecture (consumer gear has yet to realize it, but the enterprise is already moving that way) and APs could easily embed side-stream transmitters, and maybe even wedge it into the channel plan in one of the 802.14.5 troughs (or in a stray channel up in 5GHz.)
Whether they'll be able to get this to work on 11n/11a/11ac and manage to secure it compatibly with WPA2-enterprise are interesting questions. Then again IoT manufacturers have shown they are going to ignore the latter point entirely until such a time as they get sued enough that it starts to hurt their bottom line. That probably won't happen until the sector has raced to the bottom and has almost no profit margin. The lawyers will be the only ones happy after the dust settles.
First, stateless configuration you just kill off with extreme prejudice.
Second, broadcast is indeed essential for almost every protocol that runs over ethernet (because ARP) but that doesn't stop us from turning off everything but the bare essentials. Almost all enterprise gear knows how to let ARP (or ND) and DHCP through while blocking everything else. The better gear even allows you to let users hear the broadcast from other devices which that user owns, but does not forward them to any other clients (and you can build groups of users that can hear certain multicast servers as well, and restrict the advertisement to APs that both have one of those clients, and are within a reasonable physical distance of an asset (Usually no reason anyone should be logging into the meeting-room video-conferencing unit from the cafeteria.)
While almost nobody has closed hole 196, you can also convert all broadcast which you DO allow back out of APs to unicast on the RF side, so at least mulitcast used in that attack sticks out like a sore thumb, and in fact this works very well, since the odds of two devices actually being on the same AP to benefit from the "efficiency" of multicast is actually rather small, and getting smaller the denser we make the cells. So you generally end up sending one packet per mc packet per client anyway.
In addition, some people also just have the gateway proxy-arp everything so the clients never see another client's MAC address.
Plus they don't get the meta-data from people logging in to Google accounts just to download apps. (They could just as easily have posted signatures or digests for approved apps, but then they wouldn't have a monopoly on the web traffic and resulting log data.)
Except that no enterprise network engineer in their right mind will use the stateless autoconfig you refer to, because it cannot be secured. One joker sending his own RAs and you're whole network is p0wned, no spoof protection beyond what your vendor implements in their equipment, which, just like IPV4, has to be configured. Not that IPv6 is a bad thing, and enterprise gear is now shipping that has the same level of first-hop security features we've come to expect from IPv4 feature sets. Someday maybe there will be enough space between other projects to implement it on my net.
As to the OP, compared to what clients do, RAs are the least of your problems -- first job of a wifi engineer that cares about not draining batteries is to start to turn off AP propagation of all broadcast and multicast traffic. Whatever you can get away with without users complaining, turn it off before they start to rely on some service that uses it. Then hope to hell your WiFi vendor has a solution for selectively enabling PAN/multicast groups before the requests to use AppleTVs in meeting rooms get to a PHB.
This from TFA mystifies me: "an ancient practice from the older days of the Internet, where connectivity uptime was a must"
These guys must think everyone uses only iPads and never games. (Not that they are wrong about tuning down RAs.)
It's not for lack of complaining that this feature still has yet to be put back into chrome/opera. The devs just ignore the complaints. SOP these days. If you're lucky someone has made a plugin to emulate whatever feature they arbitrarily decided to exclude that will work for a few months before the core breaks it somehow.
If the new algorithm also helps indoor positioning enough to be accurate over a decent sized floorplan, it could be useful for indoor wifi surveys when deploying or upgrading enterprise networks. Last time I looked there still was not a product that didn't require manual entry of your position on a map during a survey, which is error prone and drives up manpower costs. Eventually WiFi clients could be extended to report back position information to the network so dead spots could be eliminated without a survey.
Slashdot Mirror
Agreed, if only we'd done one thin-enough-for-Apple-fetishists revamp of ethernet before USB came along, and made a protocol that allowed peripheral PANs to coexist on ethernet switches with the LAN, we could have wasted a lot less silicon with a universal ethernet/peripheral port instead of USB.
One good push to get ethernet where it needs to be for the mobile market would be great, IMO, but only one, done right the first time and not priced out of the market by licensing fees -- the latter of which is probably the only reason a crummy standard like USB got adopted, with what, at the time, was incredibly CPU-unfriendly hardware level a protocol stack which was just a bodged together mess poised to create an even bigger mess as it was extended to eventually catch up to the state of the art.
If we could trust USB bodies not to invent yet another plug it might be possible to use the current pinout of the latest USB and autodetect whether you are plugged into ethernet or USB. Unfortunately any such trust would be foolish, even if they promised.
Mostly only the newsworthy ones get them, ones that need widespread attention even for administrative domains that can't afford a dedicated security person/department. It's a lot easier to give them names then have meetings saying "where do we stand on CVE-year-four-digit-number" simply because the human brain wraps around names better. Especially if a clue as to the shape of the exploit is embedded in the name, serving as a mnemonic -- e.g. HeartBlead is used to blead information from heartbeat exchanges.
Setting aside the point of what constitutes a police state, "isn't" != "never will be" and it's the latter that matters.
There's less evidence to support significant voter fraud than there is to support significant election fraud and voter suppression.
I hope one of the things Donald Trump does when he's in office is to start implementing the electoral system that America deserves, not this farce
Hah! I'm sure he'd tell you he will, even though it won't be under his purview. In fact, he might even think he's telling the truth (for a change) in that case because he probably does not know the office of the president doesn't have the authority over that.
...and obtaining a database of such models for various users becomes further motivation to compromise webcams. Way to go Amazon, keeping the cracker economy vibrant.
I think kb+mouse will always have the advantage but if game devs would stop making dead zones designed for senior citizens it could narrow the gap a bit.
Couldn't hurt to use a different font for each participating network.
Let's say we were talking not of cell phones but of hard drives. Should future SSDs be banned because they are easier to fully erase/destroy? Back to platters, just for the sake of law enforcement? No thanks.
Nobody would say anything because it wouldn't be any surprise whatsoever.
Well, it's better than the last FC powered drone ("Hycopter") that had nice glass tubes full of compressed gaseous H2 eagerly pleading for a nice crash into a telephone pole transformer.
So you kill DNS-SD over mDNS (Apple's Bonjour)? No printer discovery, no discovery of streaming media servers, no IPTV?
Yeah pretty much stomp the crap out of any protocol that is built on the erroneous premise that network segmentation has any bearing on the borders of a LAN/PAN anymore, and then use vendor solutions to filter it and distribute it to specific hosts, both in and outside the IP broadcast domain (the latter part can only be done with protocols that don't have a ban on using servers outside their subnet, so no MS media players.)
Though, demand has not been high enough for my boss to elevate setting that up on my TODO list yet. So right now only devices logged in under the same username can see each other (setup of that was a just a button push.)
I used to wish journalist wouldn't do this, and use the "enough to power X homes" energy measure, on principle (choosing that energy measure because it is easy enough for journalists to understand.) Now I wish they wouldn't do it just because of the number of replies it generates on Internet threads to point out the error.
China has 4 times as many people.
But yes, we can do better. Especially if we can get the obstructionists to step down.
The principle advantage I have seen claimed for natural gas other than the lower carbon content is that the generators used for natural gas in electricity production can be quickly ramped up and down to adapt to demand. A possible marginal benefit is that infrastructure for natural gas distribution in heating could also start mixing in biogas, perhaps even replacing it completely with a renewable. Also it is probably easier to get a PEM fuel cell to work on it.
Yeah but think about when they cash in that huge stock option benefit... oh... wait.
You know what, I don't actually care if it is theater if it keeps people talking and thinking about security, for a change.
People can talk secretly. Over large distances. The sooner the government comes to grip with this simple fact, the better.
Lower power, possibly cheaper hardware, and can unify IoT device management with WiFi seem to be the primary potential benefits. How well it does and how long it can afford to stay proprietary and still be bothered with is a matter market economics will have to decide.
802.11b in this case. Considering the phase this research is at it is not surprising compliance tests have not been engaged.
Assuming they aren't polluting outside their band, given the range they demonstrated they've got something viable here -- WiFi is headed towards a microcell architecture (consumer gear has yet to realize it, but the enterprise is already moving that way) and APs could easily embed side-stream transmitters, and maybe even wedge it into the channel plan in one of the 802.14.5 troughs (or in a stray channel up in 5GHz.)
Whether they'll be able to get this to work on 11n/11a/11ac and manage to secure it compatibly with WPA2-enterprise are interesting questions. Then again IoT manufacturers have shown they are going to ignore the latter point entirely until such a time as they get sued enough that it starts to hurt their bottom line. That probably won't happen until the sector has raced to the bottom and has almost no profit margin. The lawyers will be the only ones happy after the dust settles.
First, stateless configuration you just kill off with extreme prejudice.
Second, broadcast is indeed essential for almost every protocol that runs over ethernet (because ARP)
but that doesn't stop us from turning off everything but the bare essentials. Almost all enterprise gear knows
how to let ARP (or ND) and DHCP through while blocking everything else. The better gear even allows you to let
users hear the broadcast from other devices which that user owns, but does not forward them to any other
clients (and you can build groups of users that can hear certain multicast servers as well, and restrict the
advertisement to APs that both have one of those clients, and are within a reasonable physical distance of
an asset (Usually no reason anyone should be logging into the meeting-room video-conferencing unit from
the cafeteria.)
While almost nobody has closed hole 196, you can also convert all broadcast which you DO allow back out
of APs to unicast on the RF side, so at least mulitcast used in that attack sticks out like a sore thumb, and
in fact this works very well, since the odds of two devices actually being on the same AP to benefit from
the "efficiency" of multicast is actually rather small, and getting smaller the denser we make the cells. So
you generally end up sending one packet per mc packet per client anyway.
In addition, some people also just have the gateway proxy-arp everything so the clients never see another
client's MAC address.
Plus they don't get the meta-data from people logging in to Google accounts just to download apps. (They could just as easily have posted signatures or digests for approved apps, but then they wouldn't have a monopoly on the web traffic and resulting log data.)
Remember the last robot story you opened and were underwhelmed to find it was just a reinvented roomba? The person who built that.
Seriously, though, all these... ehem... "languages" and still not one that is a DSL for actual dynamic digital control systems. SIgh.
Except that no enterprise network engineer in their right mind will use the stateless autoconfig you refer to, because it cannot be secured.
One joker sending his own RAs and you're whole network is p0wned, no spoof protection beyond what your vendor implements in their equipment,
which, just like IPV4, has to be configured. Not that IPv6 is a bad thing, and enterprise gear is now shipping that has the same
level of first-hop security features we've come to expect from IPv4 feature sets. Someday maybe there will be enough space between other projects
to implement it on my net.
As to the OP, compared to what clients do, RAs are the least of your problems -- first job of a wifi engineer that cares about not
draining batteries is to start to turn off AP propagation of all broadcast and multicast traffic. Whatever you can get away with without users
complaining, turn it off before they start to rely on some service that uses it. Then hope to hell your WiFi vendor has a solution
for selectively enabling PAN/multicast groups before the requests to use AppleTVs in meeting rooms get to a PHB.
This from TFA mystifies me: "an ancient practice from the older days of the Internet, where connectivity uptime was a must"
These guys must think everyone uses only iPads and never games. (Not that they are wrong about tuning down RAs.)
It's not for lack of complaining that this feature still has yet to be put back into chrome/opera. The devs just ignore the complaints. SOP these days. If you're lucky someone has made a plugin to emulate whatever feature they arbitrarily decided to exclude that will work for a few months before the core breaks it somehow.
If the new algorithm also helps indoor positioning enough to be accurate over a decent sized floorplan, it could be useful for indoor wifi surveys when deploying or upgrading enterprise networks. Last time I looked there still was not a product that didn't require manual entry of your position on a map during a survey, which is error prone and drives up manpower costs. Eventually WiFi clients could be extended to report back position information to the network so dead spots could be eliminated without a survey.