Posts Tagged with hypervisor

posted by brwyatt on September 22, 2013

I've been thinking, I need to use this blog more. Because I can.

Not much really goes on around here, really, but I have some interesting ideas and projects I'm starting or will start, or at least want to offer up for others. But I do also have the random ramblings of a crazy person, too. In theory, I assume that if I throw enough stuff on here, something may be useful to someone. Maybe.

Last weekend, I finally decided to "break into" my 24-port SGE2000P Linksys switch again. QoS managed to turn itself on again, and as a bonus, all the settings were reset. Long story short, I found out why, and any Cisco device user will instantly know why. Needless to say, any time it loses power, it will reset to it's "startup config". This is a great failsafe if you manage to make a change that breaks everything. But, I was able to get back into the router, change the settings, and then found the copy config section in the settings (yes, I'm using the web GUI, I'm too lazy to learn IOS right now) so I could copy the running config to the startup config. What this means for me, is no more having my download randomly drop from 20mbps down to 0.2mbps while trying to watch Youtube.

In somewhat related news, I've got an 8-core box sitting in with my servers at the moment, but powered down. It has been there for a while, and I've been wanting to get it configured to jump-start my virtual environment before I get the real hypervisor I'm planning to get sometime in January. My thinking was that I could set this small server up, get all the core network infrastructure setup on it (DHCP, DNS, Puppet master, network auth (NIS? LDAP?), Zabbix, etc), as well as learning how to setup and configure OpenStack, and start tinkering with it NOW, so that when the expensive hardware comes in, I can just move everything over to it, and start playing with more useful stuff such as moving everything off my old server (MySQL (Postgres instead?), Tor, Freenet, Minecraft server, etc) over to it, and even start messing with some more fun things like metrics and things like Redis and RabbitMQ. My only issue is not exactly FINDING time... but MAKING time. As soon as I walk in the door to my aparement, my brain just turns off. This effects my other personal projects as well.

Speaking of personal projects...

I have more than a few "personal projects", all under the name Jungle Cat Software, and hosted publicly on GitHub. As you can see there, I have a few things up with varying degees of work put into them. I probably have the most work put into Bad Science! and BRGE (the engine behind Bad Science!), which was probably the most fun project, but also the least useful. BitcoinAccess was a Bitcoin RPC client that could talk back to either an RPC-enabled client you left running at home, or a service that follows the Bitcoin RPC standard, and is probably the more reasonably useful project... if I finish it. If anyone is inclined to help on any of these projects, I would happily welcome it, and you can find more about what I planned by looking at their boards on the Trello account.

More recently, I started (for some definition of the word "started") another project aiming to combine several ideas in Tor and Freenet; basically using routing more similar to Freenet, but in a real-time way such as Tor, and preferencing low-latency paths and neighbors. I'm personally quite fond of this idea, and I think it could actually be useful. So let me talk about CryptNet for a moment.

So here is my thinking. Largely, it's intent is to be oriented aroud the idea of a "OpenNet", and connect to anyone nearby that you can, possibly even scanning your LAN for connections. Once connected, you now become a part of the network, and route traffic just as a relay in Tor or a node in Freenet would. Except for some differences. Freenet is, essentially, a distributed datastore; incomming requests are checked locally to see if you have data, and then passed on to nodes that appear to be "closer" to the data if you don't (there is a bunch of math and stuff happening here that I'm not going to get into). There is also some stuff with the ranomly-decrementing TTL to hide the originator, and then found (or not found) data travels back along the same path and that's that. Tor, in contrast, creates "circuits" in order to route requests. If a request to an external resource is made, then it is created to an exit node and your traffic passes through a series of three nodes on the network, then out to the destination (some services, like DuckDuckGo, will host a router that can exit to their services, and traffic will be routed to their exit to improve performance). Traffic to an internal network resource again creates a circuit, and then is routed to that resource.

What I'm proposing is something slightly different, and something that can take advantage of the higher bandwidths available. But, then again, we still don't want to flood the Internet! If each client has a handful of "addressable keys" (think GPG fingerprints or Bitcoin addresses), a user can discard or create new ones as necessary, but keys should typically stick around for at least a little while during a given "transaction" on the network (A file download, a conversation, etc). From here, we can start building a kind of "table" of what keys we find from which of our connections to the network, and if we see them on multiple, we can determine which link(s) are faster, so we can start building a graph, but where we can only see a small part of it, specifically, our own connections to our neighbors, and which keys they route through them. But this only gives us half the story. Our connection to "A" might be lower-latency, but a user with a given key might be closer to node "B" (or may even be owned BY "B"!), and may have a shorter round-trip time. So we can get into some interesting Math and huristics there.

It may also be possible to send the same message through ALL of the nodes you are connected to, and those nodes could do the same. Obviously this can get out of hand really fast. By using the key table mentioned before, nodes can eliminate some paths if they don't have the key, and we can even send responses back upstream to say "I don't know this key" if a request is received and you know the key doesn't exist or is unroutable from you, thus eliminating that node as a valid path. Nodes on the network also need to NEVER route a duplicate message with the same ID, in case of duplicate paths. It is expected to receive duplicate messages at times, and they need to be handled correctly (that is to say: ignored and NOT passed on again), it may be also good to transmit a "key not found" back upstream to the node that sent the duplicate message, to remove the slower path from their routing tables. In this way, the network can find the fastest paths through the network.

However, this does bring up an interesting concern for attacks similar to Freenet, where if an attacker has all your connections, they can start to reasonably determine who you are and your activities. But also, due to "path reduction", this attack could become possible from a distance. Thus, Key rotation, but keys can be linked as the same person with enough data (like bitcoin addresses). Rotating connections (dropping some connections, and creating new ones), much like Tor circuits, can help resolve some of that, changing the landscape of the network as nodes move around in the graph. So this brings up interesting routing challenges; and, as you can see, can result in a bit of bandwidth consumption, especially with newer connections.

But one thing I really like, is the idea of having a common "key store" on the client that plugins can use to store keys, so that the client can properly determine which messages are for itself, and route them to the proper plugin. And since all the messages are a common format, any kind of data can be routed through even older nodes that may not even support the plugin. In it's simplest state, the client is simply a router for the network. It keeps track of keys it sees and connections, and that's it. You can add plugins which create and manage keys for the user, and allow interaction on the network. Someone could easily write a plugin to act like an exit node and a proxy node, to allow regular network traffic (like HTTP) to be proxied over it (just like Tor), or write a datastore, just like Freenet, or even write encrypted communications on top of it, even run things like Tor hidden services, or possibly filesharing like as on DC++ or Gnutella.

I think it has potential, but maybe not. I think the bandwidth hit is survivable, especially on LANs, and the architecture could provide, essentially, a faster kind of Freenet for more real-time applications. What do y'all think?