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

Sorry, the comment form is closed at this time.