The basic idea is that a travel guide, as described in the paper, has a trust model which designates one or more sets of nodes that various of its clients trust. Wlog we consider just one trusted node set for our travel guide. The client selects a guide that it trusts and whose trusted node set is included in the client’s own set of trusted nodes. The guide selects routes that lie entirely in this node set. Node identity for this may be a public key whose private counterpart resides solely in the trusted node.
While enough trusted nodes remain operational and connected the guide will be able to route information. If the trusted nodes encrypt the links between them, there is no need for end-to-end encryption but this may be of only theoretical interest.
The ARPA net architecture required enough nodes and links to be up to provide sufficient connectivity. So does the above scheme. The difference is that if an ARPA net node were captured and reprogrammed then security was totally gone. Current internet switching nodes do not entirely follow the ARPA net routing protocols and may be less vulnerable.
Some communication technologies may provide intermittent connections. DSR has so far been predicated on rather stable links; it does not support new connections between nodes previously unknown to each other, as in Apple’s AirPort technology.
There is nothing requiring a node to belong to only one trust set. Nodes that belong to trust sets of antagonistic enterprises must take precautions to maintain such mutual trust. Furthermore they must be seen to take such precautions if their clients are to have confidence in continued service despite hostile actions of the other client. Most of the current DSR design assumes incentive structures that may take time to equilibrate. Nodes serving antagonistic enterprises may use schemes such as Fluent IO to ensure availability of bandwidth and means to switch it.