Michael J. O'Donnell
Date: 22 August, 2002
I propose a system of Open Network Handles to provide permanent primitive network handles promiscuously to all who request them. Handles provide an intermediate level of service between IP numbers and domain names. While assignment of IP numbers is constrained by routing considerations, the owner of a handle may reassign it to different addresses over time for mobility or changes in configuration of resources. Unlike domain names, handles carry no significance in natural language, so they should not have high commercial value, nor should they attract disputes based on assertions of rights in significant names.
This document describes a protocol for an open network handle system at the abstract level--what information needs to be in each type of message--but no syntax or other implementation detail.
I propose a system of open network handles, similar to domain names, but deliberately free of humanly meaningful semantics. A handle is intended to provide permanent global consistent reference to a particular agent, and nothing else.
This article describes a protocol for an Open Network Handle System (ONHS) at an abstract level. It only describes the messages sent and received by users of the system, not the internal messages, data structures, and algorithms needed to implement such a system. It describes messages abstractly in terms of the information that they carry. All questions of format, syntax, and other implementation details are left to a later work.
Most if not all of the difficult problems that must be solved to implement ONHS have already been addressed in the implementation of the Domain Name System, so there is little uncertainty regarding the feasibility of the system. In the short run, the service provided by ONHS is a subset of the service provided by DNS. By cutting back service to a logical minimum, ONHS hopes to provide stronger confidence in the permanence of handle resolution than DNS provides for domain name resolution, mainly because by avoiding humanly meaningful semantics, we can avoid the administrative disputes surrounding name resolution.
I have discussed elsewhere the nature of handles, and their relations to routes, addresses, and names []. For present purposes, it suffices that an agent participating in the global Internet may own a handle, and may bind and rebind it at will to addresses at which the agent may be reached. Any agent may query ONHS to discover the address currently bound to a given handle.
ONHS deals with communications between handle owners, queriers, and handle servers who constitute a highly distributed global system. Many or even most handle owners and queriers will also participate in the global system as handle servers, but it is convenient to separate their actions according to the roles they serve.
ONHS is only intended to provide a sort of continuity in communication with an agent whose address changes from time to time. It is not intended to provide any sort of assurance regarding the identity nor the good behavior of that agent, including the agent's good faith and competence in managing his handle.
ONHS provides mechanisms for an agent to acquire a handle, and to announce bindings of that handle to different addresses over time. When another agent queries the system, it tries to return a hint, giving the address most recently bound to that handle by the owner.
The global system focuses on putting each querier in contact with the correct handle owner. As much as possible, authentication of the handle owner, and all other assurance of quality in communication, are left as the responsibilities of the querier and handle owner. The ONHS global system takes responsibility for responding to each query with the correct resolvent address promptly with high probability. The precise promptness of response and highness of probability are determined by the needs and capabilities of the global network at any time. The global system is only responsible for overall productivity--owners and queriers are responsible for the reliability of individual transactions. Responses to queries are called hints, because the global system does not try to make them individually highly reliable.
Although the global system does not take direct responsibility for the correctness of individual hints, to be useful it must operate in a manner that allows owners and queriers to authenticate their communications effectively. To this end, the global system also takes responsibility for maintaining a low rate of false hints. In a distributed system, we usually cannot enforce a one-to-one correspondence between queries and responses, so the low rate of false hints is a separate goal from the high probability of prompt correct response.
With current public-key authentication techniques, and presumably with other authentication techniques invented in the future, individual agents have the tools to insure the correctness of their communications, as long as their authentication techniques remain secure. But improvements in computing speed and mathematical advances tend naturally to break the security of any particular technique, so as a secondary goal, the global system should help handle owners through transitions in authentication techniques. This seems to be best done by allowing a combination of self-authentication and third-party authentication, along with support for irrevocable announcements by handle owners transferring the meaning of an old handle to a new one. Such transfer can be used to reassign a handle to a new agent, as well as to a new authentication technique.
Since no mathematical technique can make authentication foolproof, the global system should also provide handle owners and queriers with hooks by which they may audit security.
The global system operates in a highly distributed fashion on a loose coalition of more and less trusted hosts. A good system should allow individual queriers and handle owners, as well as coalitions, to contract with vendors who participate in the global system on their behalf to improve performance and reliability for particular handles in which they take a special interest. A good system also allows essentially unlimited subspaces of the handle space to be administered locally by any authority who cares to do so.
describes the authentication used for announcements of handle bindings. Queriers and handle owners are at liberty to use the method specified by for end-to-end authentication, or to agree on another method.
When and
If , , and
The hierarchy of handles in ONHS is intended to be purely a hierarchy of authority over handle bindings, not a hierarchy of meaningful descriptions of the uses of the handles. An outermost handle comprising a single item is assigned according to generally agreed rules, but those rules should allow the most promiscuous possible assignment of handles. The owner of each handle determines the rules for ownership of all descendant handles.
In general, all that we require of an address is that it allows delivery to a consistently determined agent no matter where in the network it is invoked.
The meaning of a sequencer is local to a particular type of value associated with a particular handle. Sequencers may be set from a clock, or an incremented register, or by any method the handle owner chooses. They are used only to compare the recentness of conflicting announcements about a single handle.
The minimum sequencer is used in queries, but not in announcements. The maximum sequencer makes an announcement irrevocable.
Virtual agents may also be distributed among multiple hosts, so as soon as possible, if not initially, we should probably add address types like the following.
The ability to rebind handles deals with relatively slow, unpredictable mobility of agents. But for fine-grained and/or predictable mobility, as well as for intermittently connected agents, and predictable or measurable rapid variations in network traffic, we might choose to add the following.
Once we start thinking of extensions to the list of address types, it's hard to stop. To control such extensions in the future, we should apply two principles: (1) add an address type only when it supports an interesting new concept of virtual agent; (2) add an address type only when it allows efficient techniques that could not be implemented end-to-end between the querier and owner. For example, hunt lists look like a good type of extension because: (1) they allow multiple redundant agents to compose a single virtual agent; (2) the querier needs the hunt list precisely when he cannot reach the agent at the first address. Of course, distributed virtual agents may be queriers as well as handle owners, and I haven't yet thought about the implications of that generalization.
In the following sections, I describe the different sorts of messages that may be sent by queriers, the global system, and handle owners. I do not describe messages sent between participants in the global system--I leave those to the implementation. To allow the greatest possible flexibility in distributed implementation, I distinguish messages that are essential to system utility, and messages that may improve system performance and/or utility but are not essential. I describe messages in a self-contained form, so that each message has a clear meaning entirely by itself without any conversational context. I also describe messages containing the smallest increments of information that seem to make sense. A particular implementation may allow some of the information to be determined by conversational context, and/or it may bundle messages for efficiency.
A handle owner's policy depends on the importance of her handle.
To avoid the risk of differential delays reordering announcements, a handle owner should use increasing values in announcements. Without increasing values in her announcements, a handle owner is vulnerable to resubmission of a saved announcement by an adversary.
A handle owner should verify the effect of an important announcement with a test query.
A single value only lasts as long as its authentication technique remains secure. We hope that new and stronger authentication techniques will be invented months or years before old techniques become insecure, providing a substantial upgrade window. A handle owner who needs handle service beyond the lifetime of a particular authentication technique should create a new handle with a stronger new technique as soon as it becomes available, and announce an irrevocable transfer from the old handle to the new one. All queriers who use the old handle before it becomes insecure should redirect to the new one. Depending on the importance of the handle, the owner may provide authentication of identity out of band, and gather additional certificates of transfer from trusted third parties. A trusted time stamp, showing that the transfer was made before the old handle became insecure, is particularly valuable. The additional certificates are not included in the ONHS protocols: the handle owner may provide them directly to the querier.
A handle owner should not depend on ONHS to establish the authenticity of individual contacts made through the handle system. The handle owner has no defense against the credulity of a misdirected querier who consents to transactions without authentication. But the handle owner may present authentication policies to her correspondents as early as possible in the correspondence, to reduce the likelihood of loss of a correspondent through misdirection.
As soon as a handle owner learns that an adversary has gained the power to issue authentic-looking announcements, she may limit the damage by announcing a compromise, and using trusted third parties out of band to try to recapture lost correspondents. The existence of an unauthorized binding with a correct certificate often indicates that the handle authentication technique is compromised, but it may indicate another sort of compromise of the handle owner's computing and communication resources. If cancellation of handles is supported, the owner should cancel a compromised handle. By announcing compromise and cancellation, the owner limits the consequences of unauthorized bindings and delegations and directs attention to trusted third parties out of band.
Mention policy for transfers, including recipients of transfers.
We are only interested in handles that appear to be in use.
The set of authentic announcements known to name servers determine partial resolutions of handles to other handles, and full resolutions of handles to addresses.
After a long sequence of announcements, there are likely to be many ways to fully resolve a given handle, but all but one of them are usually obsolete.
The attribution of security compromise is even more confusing than resolution. If a handle is compromised, then all of its descendants inheriting authentication from it are presumably compromised as well. Other handles with the same authentication method and the same key are probably compromised, but there probably won't be very many of those, and it seems to much to expect the ONHS to track them down.
Queries ask for hints derived from announcements sent previously by handle owners.
There are some additional messages that may be useful to a querier, but they are discussed under Section 7 on Audit Requests.
Mention trusting the ONHS, end-to-end authentication, selective auditing.
Handle owners, queriers, and other interested parties may audit the operation of the ONHS system, by querying individual announcements and by requesting notification of all announcements for a given handle.
Responses by handle servers to queries, checks, and audit requests include:
A handle server should respond to each message as promptly as possible with an address or handle bound to the nearest/lowest possible ancestor of the given handle. If the server is aware of more than one binding to the same ancestor, it should prefer the one with the highest sequencer. If sequencers are the same, the server may apply any sensible local policy.
The global system should make a best effort to respond promptly to every address query with the irrevocable transfer of the handle if there is one, and the authentic binding of that handle carrying the latest time stamp if there is no reassignment. The system is useful only if the probability of such a prompt response is very high. The system may guide and/or limit its effort based on performance parameters provided by the querier. If two or more authentic bindings to the same handle tie for the latest time stamp value, the highest priority is to return at least one of them. If the cost is reasonable, the system should return as many of them as possible, or at least announce the existence of the multiplicity.
The system should keep the probability of a false hint very low. If there is a conflict, this takes precedence over prompt correct response. A correct response has little value when buried in incorrect responses. On the other hand, avoiding incorrect responses has some value even when correct responses are absent.
The real technical point of authentication within the global system is to keep the rate of false hints low, and to avoid masking a correct announcement behind an inauthentic one. Once a querier is in contact with the correct handle owner, they may perform all sorts of end-to-end authentication completely independently of the ONHS, using other sorts of trusted registries if they like.
The global system should make a best effort to report a security compromise of a given handle promptly in response to every query of every sort involving the same handle. If a binding is discoverable at a sensible cost, it should provide that binding also. But compromise announcements should be stored in such a way that cost is never or at most very seldom an issue in discovering an authentic announcement of a security compromise.
The global system may find it valuable to give higher priority to discovery of an irrevocable reassignment than to discovery of a binding to an address, so that failure to find a binding will be even rarer in the case of reassignment than in the case of a normal binding.
As long as the cost is moderate, the system should provide certificates authenticating announcements even when they are not requested, and especially in the case of reassignment.
The system should provide the promptest and fullest possible notification and explanation of negative results that is feasible at a sensible cost.
Mention audit policies, priority to handle owner.
This document was generated using the LaTeX2HTML translator Version 99.2beta6 (1.42)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -show_section_numbers -no_navigation abstract_protocol.tex
The translation was initiated by Mike O'Donnell on 2002-08-22