Actually, I'll make this even easier, and use the fact that 32 bit IP addresses fit 32 bit unix timestamps juuuuuuuust fine. So you'd do a gethostbyname and recast the response!
Hmmm. I'm neck-deep in DNS code anyway; is there any interest in a protocol that would encode update times -- probably not the updates themselves -- in DNS?
The concept is that every time you updated your blog, you'd do a Dynamic DNS push to a RSS name, say, rss.www.slashdot.org's TXT record, containing the Unix time in seconds of the last update (alternatively, and this is how I'd probably implement it in my custom server, lookups to rss.www.slashdot.org would cause a date-check on the entry). The TTL of the DNS entry could be increased to limit the update frequency of clients.
If this is cool (I'm sure some RSS dev's are trolling these comments), throw me an email or reply here. I'll do the server side if someone will integrate support for it into their client.
It'd actually be very, very cool to click on a face in your album and have all similar faces in your collection located. In fact, I'd wager it'd be a killer app, massively suited to Google.
And it's not like this is unheard of technology, either. Face detection algorithms are extremely common.
There are some very, very ugly active attacks that people haven't even begun to explore.
That being said -- 11i solves the problem of, given a widely distributed network of corporate access points, how do you prevent people from rummaging around your internal network without going to a concentrator? Answer -- force them to check in w/ 11i.
Encrypted wlan communication needs to be so straightforward that end users can connect to *any* access point and be assured of privacy without any additional configuration.
No.
Because then you don't necessarily know if you're connecting to an attacker's access point or not. This is mostly why security doesn't belong at L2 -- you don't care or trust the next hop, you trust the endpoint (or at least some faraway gateway that gets you into the endpoint).
There's something very disturbing about this -- Democrat or Republican, that the rules of decision making are altered until the desired decision is made is at best browbeating unbecoming a free decision making body and at worst uncomfortably corrupt.
"You may vote for whatever you like as long as we like it to" does not a fair process make.
I did load balancing stuff last year; created this entire system whereby a central distribution node could have its outgoing traffic actually brokered across any number of volunteering other hosts that would spoof the outgoing traffic. ACKs would come back to you, though, so you'd get K/s figures on data streams you couldn't even see.
Turned out I had just reinvented some stuff from a few years back, Alteon did similar things with dedicated hosts. There's actually some neat load balancing stuff w/ DNS involving race conditions (which DNS reply or SYN|ACK makes it to the customer site first) but Radware's done alot of good stuff here. Ultimately, load balancing is pretty mature...DNS tricks surprisingly aren't.
Ultimately, yeah, the massive amount of open recursive caching servers is probably bad.
BT is more small-data -- one to ten packets through the architecture.
My thought experiment was -- how can we efficiently place an arbitrary amount of data in the DNS? The answer is to not respect the heirarchy ourselves but to simply distribute the chunks, scattershot, across large numbers of servers.
Putting data in DNS -- not new, I say that very early and often. What is sort of new is the idea that you can connect to many, many servers to amortize the download speed across Internet-scale networks, using their caches as short but useful term storage devices.
Also, short term caching allows for unexpectedly useful distributed voice transmission.
Lets watch how the initial implementation of SSH over DNS works:
SSH connects to HTTPtunnel's TCP proxy, which converts TCP to HTTP (another TCP protocol, but record oriented with all sorts of limitations). These HTTP packets are then captured by a DNS translator, which sends the packets out over UDP. The UDP packets route across the net, themselves encapsulated in IP, MPLS, and Ethernet, potentially bouncing off a local DNS server. They arrive, are decapsulated more times than I can count, and are eventually given to an SSH server.
Now, the SSH client opens up a SOCKS daemon, and uses it to direct port forwards on the faraway SSH server. For those keeping score, to achieve this VPN, we've used:
SSH TCP HTTP DNS UDP IP MPLS Ethernet...all at the same time, just for a simple encrypted session across the very wide Internet.
Bonus points if you realized you can bounce off all the DNS servers out there, meaning the outgoing packets in the SSH over DNS link are potentially spreadable in arbtirary directions like so many dandelion seeds...:-D
It is indeed a thought experiment -- but one that's led to some interesting stuff. Voice over DNS was actually a really surprising hack -- here you have a globally deployed caching system, sometimes several levels deep, that actually has the capacity to host the minimal bitrate for a minimally compressed voice link.
There's millions of servers out there that we can interface with -- what's the impact of that? If nothing else, it's fun to be playing with something other than TCP headers:-)
--Dan
P.S. A broom can be used to sweep the floor -- or to knock something out of a tree, or to scare off a wild animal, or to burn for heat. There's something to be said for separating common uses from "inherent purposes". HTTP was certainly never designed to host as much dynamic content as it does now!
Hmmm. We've been hearing about agent technology / mobile code for years, and not only has its functionality been a bit sketchy at best, but its security is a nightmare. Note -- you can't post Javascript on Slashdot or PHP within common forums, and there's a reason.
Putting TCL in DNS as a commonly used standard is a bit worrisome -- you'd have programmatic access to an execution context within any mail server. Not rejecting the idea outright -- but what are the functionality gains that justify such an outright expansion of remote access to untrusted parties?
It's quite hard to compare a status quo to an invisible alternative state -- this is a huge problem in business, politics, and especially economics. But at least I've determined that simply using vulnerability metrics -- i.e. "Finding bugs does not lead to less bugs being found" -- is ultimately not a representative metric for the actual risk mitigated.
To use a straightforward analogy -- possessing an immune system does not by a significant means reduce the pathogenic population, yet lacking one is death. The case is quite similar with vulnerabilities and virii -- it would be very simple for us to completely lack the infrastructure to manage an Internet-wide vulnerability. The low grade malware floating around -- though infuriating -- forces us to create a management infrastructure, on pain of losing connectivity. What the consistent stream of discovered vulnerabilities creates is not fewer vulnerabilities -- software simply isn't mature enough, nor would we really want it to be -- but more managable failures. Put simply, it doesn't matter what this way comes, because we've already been forced to deploy backups, create procedures, and implement recovery strategies.
The alternative state is far more terrifying: Bugs are not talked about, and the strategy is not to fix them but to silence their open researchers. A black market opens up -- it will always be in the benefit of some to have the means to exploit others. These means always work, because nobody defends. Are there fewer with these means? Yes, but one person can write an attack, and the motive to blackmail the entire Internet population (pay me, and I'll "protect" you from the next wave) is quite strong.
Bottom line -- and it's something that took me some time to realize myself, being an active member of the security community who doesn't deal in exploits heavily -- is that whatever the headaches are of full disclosure, the alternative is much worse.
Yeah, Metro Area Net. Cells in the rural context are relatively straightforward -- stick an antenna on something high, cover alot of space, hand off every once in a while. Cells in the urban context start having extreme demands for managing variable density deployments and managed handoffs / signal strengths over short periods of time. It's just different tech, particularly vs. WiFi which doesn't even have a real handoff model.
The problem with pure sample duplication is that for any significant timescale, it sou-sou-sou-sounds pretty awful. That's because any sort of increasing or decreasing envelope will get duped into a sawtooth pattern with all sorts of fugly high frequency artifacts. The game in concealment then is not to duplicate features but to eliminate spectral artifacts that the human auditory system can pick on. The elimination of such artifacts is different between music, mid-sentence voice, and end of sentence voice (the histories of compression for speech and music are radically different, btw) and thus one size fits all solutions rarely do.
Yes, all the carriers use VoIP on their backbones, about as controlled an environment as you'll find. The real question is VoIP to the endpoints, particularly over wireless. The answer is -- it's doable, but you need a much more aggressively correcting implementation than what's commonly deployed.
Cell nets aren't LANs, btw -- they're either MANs or WANs. There are real differences -- in protocol, in problems, in nature.
Without echo cancellation, anything past one or two hundred milliseconds becomes unusable. With it, you only know about delays during interperson handoffs.
There are absurd delays on cell phones. I'm sure there are studies that show that, because of this, noticably different talk patterns have evolved.
Slashdot Mirror
Actually, I'll make this even easier, and use the fact that 32 bit IP addresses fit 32 bit unix timestamps juuuuuuuust fine. So you'd do a gethostbyname and recast the response!
--Dan
Hmmm. I'm neck-deep in DNS code anyway; is there any interest in a protocol that would encode update times -- probably not the updates themselves -- in DNS?
The concept is that every time you updated your blog, you'd do a Dynamic DNS push to a RSS name, say, rss.www.slashdot.org's TXT record, containing the Unix time in seconds of the last update (alternatively, and this is how I'd probably implement it in my custom server, lookups to rss.www.slashdot.org would cause a date-check on the entry). The TTL of the DNS entry could be increased to limit the update frequency of clients.
If this is cool (I'm sure some RSS dev's are trolling these comments), throw me an email or reply here. I'll do the server side if someone will integrate support for it into their client.
--Dan
Disco Stu says...Thuggin' ALIVE!
It'd actually be very, very cool to click on a face in your album and have all similar faces in your collection located. In fact, I'd wager it'd be a killer app, massively suited to Google.
And it's not like this is unheard of technology, either. Face detection algorithms are extremely common.
--Dan
Scientific Progress Goes BOINC.
Limits passive listeners, not active.
There are some very, very ugly active attacks that people haven't even begun to explore.
That being said -- 11i solves the problem of, given a widely distributed network of corporate access points, how do you prevent people from rummaging around your internal network without going to a concentrator? Answer -- force them to check in w/ 11i.
--Dan
Encrypted wlan communication needs to be so straightforward that end users can connect to *any* access point and be assured of privacy without any additional configuration.
No.
Because then you don't necessarily know if you're connecting to an attacker's access point or not. This is mostly why security doesn't belong at L2 -- you don't care or trust the next hop, you trust the endpoint (or at least some faraway gateway that gets you into the endpoint).
--Dan
There's something very disturbing about this -- Democrat or Republican, that the rules of decision making are altered until the desired decision is made is at best browbeating unbecoming a free decision making body and at worst uncomfortably corrupt.
"You may vote for whatever you like as long as we like it to" does not a fair process make.
--Dan
Seriously.
If they try to extract the named data, the database will crash. Of this I have no doubt. Why? Hehe.
It's not a bug. It's a feature.
--Dan
Does what you're describing.
I did load balancing stuff last year; created this entire system whereby a central distribution node could have its outgoing traffic actually brokered across any number of volunteering other hosts that would spoof the outgoing traffic. ACKs would come back to you, though, so you'd get K/s figures on data streams you couldn't even see.
Turned out I had just reinvented some stuff from a few years back, Alteon did similar things with dedicated hosts. There's actually some neat load balancing stuff w/ DNS involving race conditions (which DNS reply or SYN|ACK makes it to the customer site first) but Radware's done alot of good stuff here. Ultimately, load balancing is pretty mature...DNS tricks surprisingly aren't.
Ultimately, yeah, the massive amount of open recursive caching servers is probably bad.
--Dan
BT is more small-data -- one to ten packets through the architecture.
My thought experiment was -- how can we efficiently place an arbitrary amount of data in the DNS? The answer is to not respect the heirarchy ourselves but to simply distribute the chunks, scattershot, across large numbers of servers.
--Dan
Wow.
Freaking Zalewski :-) I hadn't seen this paper. Super cool, it'll help the next version of this speech greatly!
(I directly name Zalewski in one of my apps; believe me, if I had seen this, I'd have credited him.)
--Dan
Well, there are two kinds of people in the world -- those who see SOCKS over SSH over TCP over HTTP over DNS over UDP as neat, and those who don't.
The DNS backchannel through a firewall, by abusing the heirarchy, is a real problem.
--Dan
Putting data in DNS -- not new, I say that very early and often. What is sort of new is the idea that you can connect to many, many servers to amortize the download speed across Internet-scale networks, using their caches as short but useful term storage devices.
Also, short term caching allows for unexpectedly useful distributed voice transmission.
--Dan
Lets watch how the initial implementation of SSH over DNS works:
...all at the same time, just for a simple encrypted session across the very wide Internet.
:-D
SSH connects to HTTPtunnel's TCP proxy, which converts TCP to HTTP (another TCP protocol, but record oriented with all sorts of limitations). These HTTP packets are then captured by a DNS translator, which sends the packets out over UDP. The UDP packets route across the net, themselves encapsulated in IP, MPLS, and Ethernet, potentially bouncing off a local DNS server. They arrive, are decapsulated more times than I can count, and are eventually given to an SSH server.
Now, the SSH client opens up a SOCKS daemon, and uses it to direct port forwards on the faraway SSH server. For those keeping score, to achieve this VPN, we've used:
SSH
TCP
HTTP
DNS
UDP
IP
MPLS
Ethernet
Bonus points if you realized you can bounce off all the DNS servers out there, meaning the outgoing packets in the SSH over DNS link are potentially spreadable in arbtirary directions like so many dandelion seeds...
--Dan
It is indeed a thought experiment -- but one that's led to some interesting stuff. Voice over DNS was actually a really surprising hack -- here you have a globally deployed caching system, sometimes several levels deep, that actually has the capacity to host the minimal bitrate for a minimally compressed voice link.
:-)
There's millions of servers out there that we can interface with -- what's the impact of that? If nothing else, it's fun to be playing with something other than TCP headers
--Dan
P.S. A broom can be used to sweep the floor -- or to knock something out of a tree, or to scare off a wild animal, or to burn for heat. There's something to be said for separating common uses from "inherent purposes". HTTP was certainly never designed to host as much dynamic content as it does now!
Hmmm. We've been hearing about agent technology / mobile code for years, and not only has its functionality been a bit sketchy at best, but its security is a nightmare. Note -- you can't post Javascript on Slashdot or PHP within common forums, and there's a reason.
Putting TCL in DNS as a commonly used standard is a bit worrisome -- you'd have programmatic access to an execution context within any mail server. Not rejecting the idea outright -- but what are the functionality gains that justify such an outright expansion of remote access to untrusted parties?
--Dan
You know that whole thing, where you come back from a trip to Vegas only to see a metric ton (expletive removed) of work sitting in your inbox?
Hi. Ask questions, I'll reply and eventually integrate into the Doxpara home page.
--Dan
It's quite hard to compare a status quo to an invisible alternative state -- this is a huge problem in business, politics, and especially economics. But at least I've determined that simply using vulnerability metrics -- i.e. "Finding bugs does not lead to less bugs being found" -- is ultimately not a representative metric for the actual risk mitigated.
To use a straightforward analogy -- possessing an immune system does not by a significant means reduce the pathogenic population, yet lacking one is death. The case is quite similar with vulnerabilities and virii -- it would be very simple for us to completely lack the infrastructure to manage an Internet-wide vulnerability. The low grade malware floating around -- though infuriating -- forces us to create a management infrastructure, on pain of losing connectivity. What the consistent stream of discovered vulnerabilities creates is not fewer vulnerabilities -- software simply isn't mature enough, nor would we really want it to be -- but more managable failures. Put simply, it doesn't matter what this way comes, because we've already been forced to deploy backups, create procedures, and implement recovery strategies.
The alternative state is far more terrifying: Bugs are not talked about, and the strategy is not to fix them but to silence their open researchers. A black market opens up -- it will always be in the benefit of some to have the means to exploit others. These means always work, because nobody defends. Are there fewer with these means? Yes, but one person can write an attack, and the motive to blackmail the entire Internet population (pay me, and I'll "protect" you from the next wave) is quite strong.
Bottom line -- and it's something that took me some time to realize myself, being an active member of the security community who doesn't deal in exploits heavily -- is that whatever the headaches are of full disclosure, the alternative is much worse.
--Dan
Yeah, Metro Area Net. Cells in the rural context are relatively straightforward -- stick an antenna on something high, cover alot of space, hand off every once in a while. Cells in the urban context start having extreme demands for managing variable density deployments and managed handoffs / signal strengths over short periods of time. It's just different tech, particularly vs. WiFi which doesn't even have a real handoff model.
--Dan
The problem with pure sample duplication is that for any significant timescale, it sou-sou-sou-sounds pretty awful. That's because any sort of increasing or decreasing envelope will get duped into a sawtooth pattern with all sorts of fugly high frequency artifacts. The game in concealment then is not to duplicate features but to eliminate spectral artifacts that the human auditory system can pick on. The elimination of such artifacts is different between music, mid-sentence voice, and end of sentence voice (the histories of compression for speech and music are radically different, btw) and thus one size fits all solutions rarely do.
--Dan
Yes, all the carriers use VoIP on their backbones, about as controlled an environment as you'll find. The real question is VoIP to the endpoints, particularly over wireless. The answer is -- it's doable, but you need a much more aggressively correcting implementation than what's commonly deployed.
Cell nets aren't LANs, btw -- they're either MANs or WANs. There are real differences -- in protocol, in problems, in nature.
--Dan
Without echo cancellation, anything past one or two hundred milliseconds becomes unusable. With it, you only know about delays during interperson handoffs.
There are absurd delays on cell phones. I'm sure there are studies that show that, because of this, noticably different talk patterns have evolved.
--Dan