Slashdot Mirror

Uh. I have plenty of dual-chain 5km+ wifi radio links that use dual-polarisation. "which is basically impossible" hardly, it's a standard shipping feature from Mikrotik, Ubiquity, etc.

And infact you can get more channels through the same air using spatially diversified coherent receivers aka: MIMO. This comes from the fact that you can coherently downconvert the signal from multiple antennas, sample to IQ pairs, and arithmetically separate the multiple signals appearing at the antennas. This is basically the same as how you can hear sounds from multiple points with your two ears.

Additionally all wifi packets begin with a known preamble, from this it is possible with multiple antennas to decode the start of an interfering packet, regenerate it, subtract it from the signal, recover part of another packet, use that to resolve more of the first packet, then use that to resolve more of the second packet. This is called Zigzag decoding and has been experimentally demonstrated in 2008. It wouldn't surprise me to find out that it is integrated into the 802.11ac standard, though I haven't read it yet.

There is some existing work on the same basic idea of massively parallelizing regex matching by doing all the NFA branches in parallel, but using a GPU. Now a GPU is not necessarily perfectly suited to this problem, but it does have the advantage of being a mass-market consumer product, which produces economies of mass-market scale that let the average GPU have a ton more processing units and RAM than this Automata processor does. Would be interesting to see if an NFA-specialized processor gets enough of a speedup to overcome the manufacturing advantage of just throwing a beefy GPU at the problem.

Not even that. The US Government already has the ability to sign certificates themselves (yes, as an intermediate signing certificate courtesy of VeriSign, which your browser trusts...) They don't even have to ask VeriSign, they can do it themselves.

See http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

And it's worse than you state, your browser trusts not only the list of CAs it has, but also a whole chain of intermediary signing certificates ultimately signed by one of those root CAs... And there is no registry of those intermediate signing certificate or who they belong to.

Yes, this.

"We also saw a number of commercial authorities that provided a smaller number of certificates to seemingly unrelated entities. For example, VeriSign, Inc. provided intermediates for Oracle, Symantec, and the U.S. Government"

Source: http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

Your browser trusts VeriSign, so your browser trusts the US Government, and not just one signing certificate, a bunch of them:

"All but a handful of the authorities 4 or more intermediates away from a browser-trusted root belonged to agencies within the U.S. Federal Government."

In all, their most recent survey found that 85 government agencies (from around the world, not just US, but quite probably MOSTLY US) had signed 17,865 certificates in active use. In almost all cases, any entity with signing authority is able to sign certificates for ANY domain. And of course such a survey is unlikely to notice any targeted MITMs against a particular suspect.

SSL can be MITM'd so long as you can sign a certificate in a way trusted by web browsers. And it turns out quite a number of branches of the US Government are among the nearly 2000 entities with the ability to sign certificates for any domain that will be accepted by web browsers as valid and trusted (which I did not know previously). See http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

And RSA did recently ask developers to stop using all versions of the BSAFE toolikit (including Crypto-C ME, Micro Edition Suite, Crypto-J, Cert-J, SSL-J, Crypto-C, Cert-C, and SSL-C), which default to using Dual EC DRBG, and for all customers of RSA Data Protection Manager (DPM) server and clients to change the pseudo random number generator in use, since it also defaults to using Dual EC DRBG. See http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/

Not even that. The US Government has certificate signing power already. They don't need to copy any existing certificates, they can just generate and sign a certificate for whatever domain they want to MITM, and it will be accepted by the major browsers. If they don't have the cooperation of the ISP, they can easily hack a router.

Reference: http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

We really need a new system of trust. Some mechanisms are in place to be more trustworthy, but they're not being used. For instance, the US Government COULD be empowered to sign certificates only for .gov or .mil domains. But, like nearly all entities with signing authority, they can sign certificates for ANY domain.

Paul Francis is quoted because he's studied this exact phenomena. The relevant paper is here: Challenges in Measuring Online Advertising Systems Internet Measurement Conference 2011 Saikat Guha (Microsoft Research) Bin Cheng (MPI-SWS) Paul Francis (MPI-SWS) http://conferences.sigcomm.org/imc/2010/papers/p81.pdf Part of the paper focuses on how Facebook ads are targeted. Experiment 8, page 5, looks at the impact of sexual preference on ads. The result is that gay men on Facebook are targeted with ads that 1) target them exclusively, and 2) don't mention that they are gay related. The example given is an ad for nursing school. The problem is even if a person isn't publicly revealing their sexual preference, an advertiser can infer user's preference based on clicks. The user has no idea that they are implicitly disclosing the information, because they have no idea they are being targeted by a very narrow segment of ads. I would agree though, if you're really, really worried about your sexual preference leaking, then Facebook isn't a wise organization to entrust the information to...

Was this a third-party app or an official Google app? If it's third-party, Google has no control. One packet every 3 minutes is, honestly, pretty damn good for some apps. Skype can cause a device to wake up once every few seconds (which is the main reason it's an epic battery hog).

Google's own apps are about as efficient as they can be in order to minimize periodic data, because keepalives and checkins wake the device, draining battery. The problem is that some major carriers have broken NAT boxes ( http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf ), forcing Google to reduce keepalive intervals so that these carriers don't kill TCP connections - which forces an expensive (in terms of time, battery, and network resources) connection setup sequence.

They already do - it's called Cloud to Device Messaging (C2DM).

If C2DM is sending syncs/keepalives every 3-5 minutes, it's because broken carrier NAT boxes are forcing them to.

http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf

Docomo seems to claim that it's background sync/checking traffic - but Google makes a point of reducing this as much as possible. There's good reason to do this - the less often data is transferred to keep "checked in", the less often a device needs to wake up, and the better battery life is.

This is, for example, why IM apps that use Google C2DM (Such as Google Talk - but any IM app author can use C2DM) have a minimal impact on battery life, while poorly written apps that are not even remotely suited to mobile devices (like Skype) are massive battery hogs.

If Google's services are "checking in" that often on DoCoMo, it's probably because DoCoMo's NAT boxes are broken - http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf

* The following torrent sites were studied: Mininova in December 2008, The Pirate Bay in November 2009, and The Pirate Bay again in April 2010.

* Roughly 3,000 user accounts uploaded torrent files to the sites.

* 100 user accounts uploaded 67% of the torrent files, and those torrents accounted for 75% of the downloads.

* Fake content uploaders (antipiracy agencies and malware) accounted for 30% of the torrent files and 25% of the downloads. Many of those accounts could be traced to a small number of IP addresses.

* Profit-driven uploaders (who use free content to advertise private trackers and/or commercial content) accounted for 30% of the torrent files and 40% of the downloads. This is where advertising comes into the picture: people aren't getting paid for the ads shown on torrent sites, they're uploading content as a form of advertising.

* Altruistic uploaders (who release copyrighted content with no profit motive) accounted for 11.5% of the torrent files and 11.5% of the downloads.

(Yes, I realise the figures don't quite add up - I guess there's some rounding in there.)

Here it is: http://conferences.sigcomm.org/co-next/2010/CoNEXT_papers/11-Cuevas.pdf

Sounds a lot like "Stealthy IP Prefix Hijacking". Advertise a BGP route that will be accepted by some people to attract their traffic. Do it correctly, it may be less noticeable than a full prefix hijacking (though it was obviously noticed in this case). You can also attempt to moderate the amount of traffic you receive so that you don't DOS yourself with the incoming flow and you can analyze the traffic easier. BGP is a pretty insecure protocol and depends a lot upon the upstream providers filtering announcements properly.

Good point. A colleague of John Doyle also agrees with you:

What would Darwin Think about Clean-Slate Architectures? ACM Computer Communications Review (CCR), Editorial Zone, January 2008.

http://www.sigcomm.org/ccr/drupal/files/p29-v38n1g-dovrolis.pdf

From the abstract:

"As significant resources are directed towards clean-slate networking
research, it is imperative to understand how cleanslate
architectural research compares to the diametrically
opposite paradigm of evolutionary research. This paper approaches
the âoeevolution versus clean-slateâ debate through
a biological metaphor. We argue that evolutionary research
can lead to less costly (more competitive) and more robust
designs than clean-slate architectural research. We also argue
that the Internet architecture is not ossified, as recently
claimed, but that its core protocols play the role of âoeevolutionary
kernelsâ, meaning that they are conserved so that
complexity and diversity can emerge at the lower and higher
layers. We then discuss the factors that determine the deployment
of new architectures or protocols, and argue, based
on the notion of âoeauto-catalytic setsâ, that successful innovations
are those that become synergistic components in
closed loops of existing modules. The paper closes emphasizing
the role of evolutionary Internet research."

This was already proposed by Bindal et al in ICDCS 2006 and evaluated in simulation by Aggarwal et al in SIGCOMM CCR (July 2007). Besides, there is already software out there for the Azureus BitTorrent client (called Ono) that does similar things without relying on the ISPs and without restricting what you download.

But if the ISPs really wanted to hurt BitTorrent they'd just block incoming TCP connections - I guess they realise that if they push too hard, customers will start to leave, so they're trying to make it inconvenient to use P2P but not impossible.

According the guys running the conference network, Macs were about 40% of the machines at SIGCOMM 2007. I don't have numbers but I've observed similar at IETFs and other networking geek gatherings.

IT at the medium-sized, engineering driven technology company where I work recently came to its senses and approved Macs as a supported platform. Naturally everyone I know is in line to trade their Stinkpad in.

That's exaclty what skype does. All voice (video/chat/file) flows are encrypted, and they go from you to your party. Only if both of you are behind a NAT or/and firewall, then skype routes the call through another node. If you want more infos, have a look at "Revealing Skype Traffic: when randomness plays with you" and references therein... http://www.sigcomm.org/ccr/drupal/?q=node/245

" Satellites == poor TCP performance (doesn't mean you could not use another format of course:http://citeseer.ist.psu.edu/470799.html " http://citeseer.ist.psu.edu/470799.html, File not Found Did you mean to cite "Congestion Control for High Bandwidth-Delay Product Networks" XCP : http://www.sigcomm.org/sigcomm2002/papers/xcp.pdf ?

http://www.sigcomm.org/HotNets-IV/papers/ballani.p df

Mind you, BitTorrent makes up such a huge fraction of traffic these days that you could probably get 80-90% accuracy by just classifying everything as BitTorrent. ;-)