Oct 082010

There is a discussion to be had on the usage of long-lived routing identifiers. The paper from Smetters and Van Jacobson assert that embedding long-lived identifiers (here: URLs) into the routing fabric allows for solving the content security problem by making it hard to subvert it. They assert that solutions like in PURSUIT, which uses self-certified labels, separate the (name) resolution from the identifier and make it harder to secure the content (since it needs to secure the resolution mechanism). Is this a bug or a feature?

From our perspective, it is a feature:

  1. Separating name resolution from identifier management separates tussle spaces that allow for solutions in naming governance while not affecting the routing fabric (a very different function).
  2. It faces up to the reality that one form of long-lived identifiers is possibly not the only one (the world is not only about hierarchical names – or DNS for that matter!!).
  3. It avoids long-lived identifiers as the norm and introduces the possibility to link to long-lived identifiers via separate resolution mechanisms, if necessary. This is to accommodate cases where long-lived identifiers are unnecessary and the dealing with its governance is more of a burden than an advantage.
  4. It tries to avoid leverage on routing level to act on long-lived identifiers – as pointed out by David Clark in a to-appear publication at ReArch 2010: if one exposes the long-lived meaning of data on routing level, it can create appetite for parties to act on it (through blockage or dropping) in unwanted ways. If the issues are decoupled, a party being faced with these actions can subvert them by falling back to the resolution mechanism at hand (if this is out of hands of the party acting by dropping/blocking) by changing the assignment of identifier to name or simply not using any standardized mechanism in the first place.

But there’s a deeper issue: Are long-lived identifiers really useful? And is there one commonly agreed form of it? Most URLs, while being human-readable, are not human-understandable anyways. And if they are, they don’t matter. Most URLs are hidden behind link descriptions that are more telling to humans than their URL representation. The address bar in browsers has transformed into a combined address/search bar, providing a seamless swapping of “human understandable search terms” and agreed/defined URL for accessing information on the web (legend has that the most searched term in Google on 9/11 was “CNN” ). And email is in parts already replaced by Facebook messages, tweets etc. In other words, there are many concepts of human understandable identification that is used at the app layer anyways – many of them not strictly hierarchical, BTW. So you will end up relying on some form of resolution in any case. So why burdening oneself with a specific form of it if you can instead decouple the function and tie it into the content security problem once needed!

There’s more to be discussed on this issue. We need to understand the considerations on labeling vs naming!

 Posted by at 08:21
Sep 152010

A couple of weeks ago Jimmy and I started to integrate the Click Modular Router with the Blackhawk, the FreeBSD VM-based pub/sub system we developed in the PSIRP project. The basic idea of this work is that you will be able to build your own protocols, interfacing directly with Blackhawk from Click.  In Click, you will see Blackhawk as two new elements classes, Subscribe and Publish.

Every instance of the Subscribe element class will generate a Packet whenever there is a new version of the publication subscribed to. Conversely, whenever fed with a new Packet, an instance of the Publish element class will publish a new version of the document. The needed SIDs and RIDs are given as configuration parameters, as well as enough of information to determine e.g. what kind of objects the Publish element is publishing, i.e. if it is publishing pages, versions, or “normal” publications.

This is all very much work in progress. If you are interested in affecting what we are doing, I guess the best way is to e-mail me directly, as I don’t know if I get automatically notified about the comments etc on this blog post.  You see, I am an old fart who doesn’t really understand this “social website” thingy.


 Posted by at 07:26
Aug 192010

As a form of engagement with the non-project audience that might be interested in our research, this website will feature topics under the discussions category. These topics are contributed by project members relating to problems or issues encountered in our research work for which we seek the contributions and comments of the wider audience. Contributions here will be comment-enabled like a normal blog. Hence, anybody can contribute to the discussions, as long as you pass the simple captcha test :lol:

 Posted by at 17:30