I still need to read an article but your explanation uses a non-zero capacity channels. Each channel has some bandwidth for quantum bits. If channel is not able to transfer that bits then it has a real zero capacity. If channel has some noise-from-middleman then the idea doesn't work.
I think it can be a right interpretation of Shannon theory.
I would also assume that any private scientist who works on something would stay away from the US. Since they readily share any information with "their" own corps you can bet that any big breakthrough will "leak" to your biggest competitors in the US before you can say patent.
It is not new and did happen in other field - UBS bank restricted traveling of it's own managers to US because of danger of detaining them and interrogation about UBS clients.
Well, it reminds me the USSR vs USA epogh... with reversed roles.
In course of RU-BIND development I researched an issue something around 14 years ago (1994). After some discussions with Paul Vixie in 1995 I decided that problem is mostly overblown. To reach a success an attacker should do something very unreliable and a lot of lack:
1. Attacker should know what NS records cache server knows. Specificly, attack goes nowhere if cache server has a record. That means that attack is useless for popular sites and can be done only for unpopular sites which has a very short reference from root or.com server. It still has sense to hide identity.
2. Attacker should know which root server or another authoritative server would be used by cache server. It is practically possible for handfull cache servers only or for 3rd level domains (something below company.com)
3. Any activity on cache server actually disrupts an attack. To reach the success an attacker needs to send a couple forged responses with a specific response ID. In regular BIND response ID can be calculated UNTIL there is a traffic. In case of traffic it is needed to send a couple of responses with sequence of IDs. The most of Linux hosts limit the unprocessed UDP queue to 1000 packets only, but not 64K. Any unprocessed packet which exceeds 1000 will be discarded.
4. Attacker has a one chance per domain name per server. He can repeat it only after TTL expiration. Yes, it is short for popular sites but BIND restricts it to 5min minimum. And that has much much more value (12h typical) for overseas countries.
5. Attacker should explore DNS space before attack - what fills a local cache server with records, so attack has sense for remote cache servers only. But remote cache server has a shorter distance to authoritative server, so the arrival time of forged responses is difficult to calculate.
So, the success chance is very slim. Attacker is restricted by 3rd level domains, overseas countries and remote cache servers in most cases. Under that it has sense only to hide identity behind some overseas domain.
After that I implemented a simple cryptographic ID conversion of 16bits ID in RU-BIND (Russion BIND version) and calculation shows that it dramaticly decreased the chance of an attack success, something which can happens in couple of years. Taking into account a verification of server responsibility (I listened it was implemented later in regular BIND too) it effectively nullifies the chances of attacker to poison a cache.
Which is why Im personally fine with the whole idea. Why track me? I go to college and do collegey type things, then on weekends I work in a shop doing shoppy things.
"Why track me?" - just to be sure that you do not visit a meeting with opposition or whatever. If you do - you would be jailed for 90 days to limit a damage for goverment party.
More exactly - just to find out who is an opposition LEADER before people start listening and vote. And jail him for 90 days.
I don't know why these things always raise the specter that the world is turning Big Brother all the time. Many crimes have been solved (and who knows how many have been prevented) by surveillance devices, thank goodness!
The Nazi Germany had a VERY little crime rate. Because of state-wide surveillance system. But they used it to track people (jews and others) and suppress a political opposition.
Having multiple regular cameras makes it easier to passively monitor the progress of vehicles. What this will give the government/police is the ability to track certain people, and more importantly, to gain an understanding of road usage patterns.
It depends from who is in government. Stalin and Saddam consider a tracking people en mass more important... It helps them to monitor an opposition and have a control of elections.
No, if there is a list of exceptional license plates when it could be stolen or system can be tested against it and criminal can just put a faked license plate to avoid a surveillance.
1984 must be for anybody w/out exclusions ! You like it in full or you hate it in full - no tradeoffs.
It looks like it is a perfect time to sue some big retailer on the base of that law. He definitely sells DVD readers (tools for copyright protection violation) etc. Some big splash about suit in media can help to get attention to this law.
I am a average man in Palm use and bought and upgraded a lot of years. Palm III, IIIxe, IIIc, Vx, m500 and Tungsten E - many. However, I just sad about Palm perspective. At least 4 years I wanted to have a small intellectual (database included !) notebook which replaces paper stickers (Hi-Note), unit conversion (YAUC) etc. And WiFi or any another cheap consumer way to connect my data to base system. Hot sync is great but not enough because I want to make queries in Starbacks and so on.
What I wanted:
1. small device 32MB, SD/SDIO for extension, WiFi (and may be Bluetooth) as communication capability. 3. Light touch screen - old Vx/m500 have a hard one, only Tungsten T/E have a good. It is very sensitive to use stylus instead of keyboard, w/out that many people have a negative summary conclusion on usefullness of that kind of device.
What I got - the best is Tungsten E, no WiFi, memory 28MB etc. To my dismay Palm started some fight with Socket about WiFi software ownership which effectively killed SDIO WiFi for M500 and Tungsten E.
Finally I got tired and gives up - now I want Linux box. Most modern Linux boxes has CF slot and can use WiFi. Yes, we are back again in size dimension (they do not fit a pocket) but at least Linux boxes never miss WiFi connection capability and understand the memory requirements very well from the beginning. Palm lost it's shine in geeks eyes anymore and turns to WinCE...
Who cares about MB power consumption ? My mini-ATX box (VIA M10K) eat whole power in 200GB hard disk. At least I fight the HD cooling but not CPU or chipset. 30min of intensive work and HD temperature goes to clouds but CPU/MB T stays stable.
There is a simple solution - just use pair of any NON public IP addresses on both sides of BGP links. This addresses are not published (not propogated via BGP itself) and nobody is able to send packets to it besides BGP peer partener.
Problem exists only for stupid IS staff.
I observed this problem 10 years ago from Soviet Union and can confirm it - traffic jitter on Europe-US link from European hosts produced a dramatic decrease in TCP performance on Sun Solaris (or just timeout it with enough bandwidth !) and I researched this problem that time.
However, article does not take into account the typical server behaviour - server has _essentially_ more output then input and typical bottleneck is in _output_ direction. It is more difficult to dramaticly increase RTT by overloading low-loaded input channel via bottleneck or attacker should find some equally-side loaded bottleneck like LAN-to-LAN with servers on both sides. It could be a problem for big Universities but rarely for comercial companies like Yahoo or Ebay.
O, you can overload an output channel too but you have to have an open TCP link to server inside and show your real IP address and use high-volume output requests to server!
Finally, attack is simple as long as victim's router has a LIMITED inbound traffic queue size. Unfortunately it is very offten today - it is a simplest way to increase an interactive response time. Victim should use protocol-selective bottleneck router queue to improve his response time instead of short-sized buffers in inbound routers: it can eliminate a packet loss and smooth a problem.
Slashdot Mirror
M$ now has Nokia in hands and is in battle.
I still need to read an article but your explanation uses a non-zero capacity channels. Each channel has some bandwidth for quantum bits. If channel is not able to transfer that bits then it has a real zero capacity. If channel has some noise-from-middleman then the idea doesn't work.
I think it can be a right interpretation of Shannon theory.
I would also assume that any private scientist who works on something would stay away from the US. Since they readily share any information with "their" own corps you can bet that any big breakthrough will "leak" to your biggest competitors in the US before you can say patent.
It is not new and did happen in other field - UBS bank restricted traveling of it's own managers to US because of danger of detaining them and interrogation about UBS clients.
Well, it reminds me the USSR vs USA epogh... with reversed roles.
In course of RU-BIND development I researched an issue something around 14 years ago (1994). After some discussions with Paul Vixie in 1995 I decided that problem is mostly overblown. To reach a success an attacker should do something very unreliable and a lot of lack:
1. Attacker should know what NS records cache server knows. Specificly, attack goes nowhere if cache server has a record. That means that attack is useless for popular sites and can be done only for unpopular sites which has a very short reference from root or .com server. It still has sense to hide identity.
2. Attacker should know which root server or another authoritative server would be used by cache server. It is practically possible for handfull cache servers only or for 3rd level domains (something below company.com)
3. Any activity on cache server actually disrupts an attack. To reach the success an attacker needs to send a couple forged responses with a specific response ID. In regular BIND response ID can be calculated UNTIL there is a traffic. In case of traffic it is needed to send a couple of responses with sequence of IDs. The most of Linux hosts limit the unprocessed UDP queue to 1000 packets only, but not 64K. Any unprocessed packet which exceeds 1000 will be discarded.
4. Attacker has a one chance per domain name per server. He can repeat it only after TTL expiration. Yes, it is short for popular sites but BIND restricts it to 5min minimum. And that has much much more value (12h typical) for overseas countries.
5. Attacker should explore DNS space before attack - what fills a local cache server with records, so attack has sense for remote cache servers only. But remote cache server has a shorter distance to authoritative server, so the arrival time of forged responses is difficult to calculate.
So, the success chance is very slim. Attacker is restricted by 3rd level domains, overseas countries and remote cache servers in most cases. Under that it has sense only to hide identity behind some overseas domain.
After that I implemented a simple cryptographic ID conversion of 16bits ID in RU-BIND (Russion BIND version) and calculation shows that it dramaticly decreased the chance of an attack success, something which can happens in couple of years. Taking into account a verification of server responsibility (I listened it was implemented later in regular BIND too) it effectively nullifies the chances of attacker to poison a cache.
More exactly - just to find out who is an opposition LEADER before people start listening and vote. And jail him for 90 days.
So, just prey they are not in command yet.
No, if there is a list of exceptional license plates when it could be stolen or system can be tested against it and criminal can just put a faked license plate to avoid a surveillance.
1984 must be for anybody w/out exclusions ! You like it in full or you hate it in full - no tradeoffs.
It looks like it is a perfect time to sue some big retailer on the base of that law. He definitely sells DVD readers (tools for copyright protection violation) etc. Some big splash about suit in media can help to get attention to this law.
I am a average man in Palm use and bought and upgraded a lot of years. Palm III, IIIxe, IIIc, Vx, m500 and Tungsten E - many. However, I just sad about Palm perspective. At least 4 years I wanted to have a small intellectual (database included !) notebook which replaces paper stickers (Hi-Note), unit conversion (YAUC) etc. And WiFi or any another cheap consumer way to connect my data to base system. Hot sync is great but not enough because I want to make queries in Starbacks and so on.
What I wanted:
1. small device 32MB, SD/SDIO for extension, WiFi (and may be Bluetooth) as communication capability.
3. Light touch screen - old Vx/m500 have a hard one, only Tungsten T/E have a good.
It is very sensitive to use stylus instead of keyboard, w/out that many people have a negative summary conclusion on usefullness of that kind of device.
What I got - the best is Tungsten E, no WiFi, memory 28MB etc. To my dismay Palm started some fight with Socket about WiFi software ownership which effectively killed SDIO WiFi for M500 and Tungsten E.
Finally I got tired and gives up - now I want Linux box. Most modern Linux boxes has CF slot and can use WiFi. Yes, we are back again in size dimension (they do not fit a pocket) but at least Linux boxes never miss WiFi connection capability and understand the memory requirements very well from the beginning. Palm lost it's shine in geeks eyes anymore and turns to WinCE...
Hi-Tech states lost. Look on map.
Who cares about MB power consumption ? My mini-ATX box (VIA M10K) eat whole power in 200GB hard disk. At least I fight the HD cooling but not CPU or chipset. 30min of intensive work and HD temperature goes to clouds but CPU/MB T stays stable.
There is a simple solution - just use pair of any NON public IP addresses on both sides of BGP links. This addresses are not published (not propogated via BGP itself) and nobody is able to send packets to it besides BGP peer partener. Problem exists only for stupid IS staff.
I observed this problem 10 years ago from Soviet Union and can confirm it - traffic jitter on Europe-US link from European hosts produced a dramatic decrease in TCP performance on Sun Solaris (or just timeout it with enough bandwidth !) and I researched this problem that time.
However, article does not take into account the typical server behaviour - server has _essentially_ more output then input and typical bottleneck is in _output_ direction. It is more difficult to dramaticly increase RTT by overloading low-loaded input channel via bottleneck or attacker should find some equally-side loaded bottleneck like LAN-to-LAN with servers on both sides. It could be a problem for big Universities but rarely for comercial companies like Yahoo or Ebay.
O, you can overload an output channel too but you have to have an open TCP link to server inside and show your real IP address and use high-volume output requests to server!
Finally, attack is simple as long as victim's router has a LIMITED inbound traffic queue size. Unfortunately it is very offten today - it is a simplest way to increase an interactive response time. Victim should use protocol-selective bottleneck router queue to improve his response time instead of short-sized buffers in inbound routers: it can eliminate a packet loss and smooth a problem.
- Leonid Yegoshin.