CSM uses a simple mobility model that is inspired more by the active networking community than by the mobile agent community. One reason is that the envisioned applications for mobile measurement agents can be implemented by agents that are sent to a location, perform their measurement there while sending some results and
then terminate. For such an application it is simply not necessary that the agent can roam self-directed through the networks [BLP00]. Self-directed agents need well funded knowledge about the network and a more complex communication infras- tructure. But measurement agents should be small and simple so that customers can program them. This favors a simple send-execute-terminate style of mobility. Nevertheless, sending out many agents one-by-one is a tedious and inefficient pro- cedure. Therefore, this thesis proposes mobility support that is simple, secure and efficient.
4.4.1 Supported Mobility Models
As mentioned above the proposed mobility model is inspired by active network- ing. There, executable data packets (capsules) are forwarded through the network and get executed wherever there is an execution environment. Ideally, they are ex- ecuted in every router. This is convenient because then the capsules do not need sophisticated knowledge about the network. They can rely on the local routing in- formation. For CSM however there is no built-in support that extracts the agents from the data stream. CSM is a non-intrusive Internet application that does not as- sume CSM specific execution environments in the routers. Instead, the CSM nodes provide agent forwarding functionality: an agent that arrives at a node is copied, just like a data packet would have been and the copy is forwarded to other nodes, if requested.
We foresee different kinds of forwarding modes:
No forwarding. An agent arriving in this trivial mode is executed at the node but not forwarded to any other node. This model is also referred to as sending an agent end-to-end.
Broadcast. A broadcasted agent is first started in the target node. If the agent starts without causing problems (e.g. false authentication) the agent is forwarded (in broadcast mode) to all neighbor nodes. Agents have an identity which is defined by a serial number and the owner’s identifier. Each execution environment executes only one agent of a given identity. Thus, the broadcast terminates similarly to a flooding algorithm.
Hop-by-hop. The agent carries a destination IP or node address. The node starts the agent. If the agent starts without causing problems the node for- wards it (in hop-by-hop mode) to the next node on the route towards the destination address. For that purpose the nodes need access to routing infor- mation (see section5.7.2).
The broadcast mode allows the customer to easily and efficiently spread agents e.g. to monitor a service at as many locations as possible. The hop-by-hop mode is useful to watch the service behavior along a path, e.g. between two customer subnets connected through the Internet with a VPN tunnel (see chapter 6). It is
obvious that both broadcasting and hop-by-hop forwarding save communication capacity when a user wants to install an agent at many nodes. Of course the for- warding of the agents must be limited. Therefore, the agent transmission protocol should carry a time-to-live field that is decremented for each agent instance that is executed. Also, it is important that a node only executes an agent if no agent of that type and of the same user is currently running. This is necessary to avoid that a broadcasted agent fills all available agent places. Another interesting feature is the use of forwarding probabilities. For example, broadcasting an agent with a small forwarding probability could be used to cover a local area with the agent. Another interesting scheme is the hop-by-hop scheme combined with a probabil- ity regulated broadcast to cover an area around a network path. The probability idea could be extended with the introduction of an execution probability. The for- warding would then be decoupled from the execution. Some nodes would e.g. just forward an agent but not execute it. This allows sparse distribution of agents. Yet, when only agents that execute without a problem are forwarded this increases secu- rity and reduces the possibility of a denial-of-service attack. Note, that a possible model extension is described in section6.5.2.
4.4.2 Forwarding Security
Since forwarding of agents allows a customer to request resources at many places at (almost) the same time, all agents that request forwarding (and thus multiplying) must be strongly authenticated. The customer signs the agent before sending it. Note that this scheme rules out strong mobility for the agent. To support strong mobility the node has to send the run-time state of the agent. The state changes when the agent is roaming in the network and so the signature is invalidated. The solution would be that the executing node signs the agent. But how can the node take responsibility for the agent in the new state? Think of an agent that develops malicious behavior if it gets in a certain state. The customer signs the static code while the node signs the state. Who is to blame for the malicious behavior? Maybe a previous node manipulated the state so that the agent became unsafe or maybe the customer planned the whole attack. In the CSM approach the customer is fully re- sponsible and it signs the whole agent code. The node only forwards copies of that code. The customer’s signature stays valid. However, the node first executes the agent and thus when it forwards the agent it guarantees that the agent is executable. The node can also additionally sign the forwarded agent to increase security. As mentioned before, the forwarding must be limited to a finite number of executions by a time-to-live field value which may be authenticated by the nodes. It cannot be authenticated by the customer because the hosting nodes decrement the number in the field.