Thursday, January 17, 2013

Random Ramblings about DDoS and content-oriented networking...

This is not intended to be original in any form, as usual, mostly to capture my own thought processes in an exhibio- (uh... the spell checker does not take any of the variants of this word but you get what I am talking about) kind of way. With that, let's proceed.

So, first wild assumption: there are no useful (human undetectable) cryptographic hash collisions. So we can assume that one can run over every piece of content in the world and enumerate them by sha1(what_you_get_from_network).

So, with that assumption in mind, let's just throw away the entire host-based URI thing and use the hash to address the content. Seriously - I either click on my URLs or search for them - so, it really does not matter. Let's call this new scheme "hash", with the new hash://sha1:4e1243bd22c66e76c2ba9eddc1f91394e57f9f83/

This is shorter than a lot of existing URLs. Moreover, with our first assumption, you can actually tell that as soon as you get anything other than "test" in response - it's the wrong content.

So, if you were an SP transiting this content - you could trivially cache the whole thing, and give a near-instantaneous replies for the content you already saw.

Of course, this whole new hash:// protocol is a misnomer - even with the current catastrophic worldwide finances I probably have more chances to retire than to see it ever implemented. Why ?

Because http://4e1243bd22c66e76c2ba9eddc1f91394e57f9f83.sha1.subdomain.tld/ could serve just as well...

Provided that it were agreed upon, such a "subdomain.tld" would mean that the originator says:

1) "I authorise anyone to make a cached copy of the content, based on the subdomain name to derive the algorithm, and with the hash value as specified in the sub-subdomain, and to serve that as an immediate replacement for the content that I am offering at that URL."

2) "I authorize the MITM on the subdomain.tld domain by your name servers, and redirecting the lookups to whatever the content servers are at your install - given that the client can verify the content anyway".

Of course you would not use this kind of URL right away or when the content is changing - so you'd either use an iframe-based container, or a redirect.

But, this seems to allow a few gradual steps towards the content-driven static data:

1) dedicated domain, same as now, RTT ~ 50..200ms

2) caching at the ISP level, RTT ~30ms.

3) caching at the LAN level, RTT ~1ms.

4) caching at the user agent level, RTT ~0.1ms.

So overall it seems like a doable and reasonable approach with fallback ?


p.s. This was for static content. You can do similar tricks for the code, but that's a topic for another day...

Saturday, January 5, 2013

ifConfig 1.0 for iOS - a simple free utility to show the interface addresses

I've finished building and submitted to AppStore another nice little utility, which I have called "ifConfig" - it is a very simple way to see the IPv4 and IPv6 addresses assigned to the interfaces, and copy the addresses to the clipboard.

It's nothing fancy but mostly a convenient way to see the addresses at once.

For now, only the addresses are shown, with no subnet mask/prefix length or any other information - the goal is a very simple and very clean single-screen interface functionality.

Thursday, January 3, 2013

WiFi RoamTracker 1.0

The RoamTracker is a relatively simple iOS app that I needed for myself to do some debugging, and thought that it might be useful to the others as well..

Basically it is a polling loop which every second takes a note of the current SSID and BSSID, and maintains the history of the changes, and gives a short click sound with each change.

It also has a button to mail the contents of the history as a CSV text via your configured mail account.

That is pretty much all that there is to it, for now.

If you are using it and have the feedback/bug reports: feel free to do it here via comments.