Modeling DSR

The DSR protocol is a well known reactive ad hoc on-demand source routing protocol [14]. Although DSR does not include any security goals, we build initial Promela DSR models to ensure that the SPIN finite space model checker can successfully model source routing protocols. The subsequently modeled protocols utilize the core DSR model development.

DSR model development. DSR constructs a route to a desired destination when the route is needed. Figure 3 on page 7 and Figure 28 below illustrate DSR route discovery by providing a high level description over the route discovery process.

rreq process:

• Initiator node

o Initiate a rreq to target • Intermediate nodes

o If previously seen rreq→ take no action o Else

ƒ If not target → append id to path and retransmit rreq ƒ If target → generate rrep

rrep process:

• Target node o Unicast the rrep

• Intermediate nodes (along the unicast path) o If not initiator → retransmit rrep

o If initiator → accept route

Figure 28. High Level DSR Route Discovery Process

The DSR route discovery message format can be viewed as:

<msg_type, initiator, target, id, accum_path>.

The msg_type labels the message as a rreq or a rrep, with the initiator and target indicating the source-destination pair for the desired route. The id is a unique identifier used to ensure a node forwards a given rreq once, the first time it sees the request. As many rreqs occur in an operational setting, each node tracks the <initiator, id> for each rreq received. In the protocol model, we focus on a single route discovery process at a time. Therefore, we remove the id from the message and apply a simple Boolean flag in each node that tracks if the given node has sent a rreq. The accumulated path (accum_path) lists all intermediate nodes in the path and is updated at each node that processes the rreq. In the model, we list all nodes in the accumulated path, to include the initiator and target nodes. Listing all nodes allows us to subsequently use this field to check against the network connectivity array during analysis. We discuss the analysis check further in Chapter 7. We also add a position value (accum_pos) to track the array element that the current node adds its own id to. The modeled DSR message format follows as:

<msg_type, initiator, target, accum_path, accum_pos>.

Once the rreq is delivered to the intended target, a rrep is generated and sent back to the initiator. During the rrep, the accumulated path and the current array position are read by the wireless medium server to determine the next-hop destination node for the unicasted rrep. As previously mentioned, wireless rrep messages in real-world physical implementations are received by all nodes within the current node’s transmission footprint and each receiving node determines if it is the intended next-hop in the explicitly labeled unicast transmission. While normally each receiving node decides whether to process and retransmit the unicasted rrep, we

model the routing decision in the wireless medium process and send a single message to the next-hop identified by the embedded route. We also send the transmission to any malicious nodes that may be within the current transmission footprint. By modeling message transmission in this manner, we reduce the model state space by decreasing the number of modeled message transmissions.

The resulting SPIN generated FSA for the modeled DSR non-malicious node, shown in Appendix A, contains 21 states.

DSR model validation. Following the validation criteria formed in Section 6.3, we validate the DSR model to ensure routes are discovered according to the protocol specifications. We evaluate the SPIN produced messages for the 5-node network topology shown in Figure 29. In this configuration, node 0 is the initiator and node 4 is the target. The DSR Promela models are constructed such that node 0 attempts to establish a path to the highest labeled non-malicious node, which in this case is node 4. During validation, the target is allowed to respond to all received rreqs, resulting in the following possible routes: 0-4, 0-1-2-4, and 0-1-2-3-4. Since DSR does not implement any security mechanisms, no further model validation is required.

1

0

3 2

4

Figure 29. Path Validation Topology

Figure 30 contains SPIN generated output for the three returned paths at the initiator node 0.

Path 0-4: from_wm_local?rrep,0,4,0,4,255,255,255,0 Route Discovered Path 0-1-2-4: from_wm_local?rrep,0,4,0,1,2,4,255,0 Route Discovered Path 0-1-2-3-4: from_wm_local?rrep,0,4,0,1,2,3,4,0 Route Discovered

Figure 30. DSR Path Validation

In the DSR validation output, the bold underlined portions in each message indicate the accumulated path constructed during the rreq, as it is returned to the initiator in the rrep. The 255

large enough to accept the longest available path length (N), in case all nodes in the network topology are included in the path. The from_wm_local prior to the receive operator (?) indicates the communication channel. The rrep after the receive operator indicates the message type. The initial non-bolded 0,4 indicates the initiator-target pair. The trailing 0 during the rrep indicates the array position to identify the next-hop to which the wireless medium transmits the unicast message.