OPTIMIZED LINK-STATE ROUTING PROTOCOL

Optimized link-state routing protocol (OLSR) [61] is a typical proactive link state routing protocol that has been optimized for use in a MANET environment. As discussed in Section 4.1.1, in link-state routing protocols, nodes transmit routing advertisements listing their direct neighbors. These advertisements, called link-state advertisements (LSA), are flooded throughout the network. Since MANET networks usually have limited available bandwidth, OLSR incorporates a concept for efficient flooding of the routing messages throughout the network. This is based on the concept of multipoint relays (called MPRs), which will be described in this section.

The purpose of MPR is to optimize flooding of the link-state updates. In a typical routing protocol routing messages are flooded as follows. Each node that receives a message floods the routing message in all directions (to any nodes within its transmission range). Figure 4.16 shows how messages that node A generates would be flooded through- out the network.7

7_{The figure shows a simplified view of transmitted messages. Messages travel in all directions, including back-}

ward, i.e. towards the sender of the previous message. Those messages are omitted from this figure.

As is clear from the figure, this flooding mechanism is not very efficient since various nodes can receive the same message multiple times. In OLSR a more efficient scheme for propagating routing information has been created. Here each node assigns the task of pro- pagating its LSAs only to a few of its one-hop symmetric neighbors. These special nodes are selected in a way that ensures that the LSAs will reach all of its two-hop neighbors. Those nodes selected for relaying the LSAs are MPRs. For example, as shown in Figure 4.17, when node A transmits a routing update, it broadcasts it to each of its one-hop neighbors. All of those nodes receive and process the message, but only the nodes that are MPRs for node A retransmit the message. This reduces the number of retransmissions and hence the overhead generated by OLSR.

We next discuss the details of the OLSR routing protocol. In OLSR, each node trans- mits hello messages periodically (e.g. every second) over each of the node’s interfaces. The main purpose of the hello message is to enable a node to discover its direct (one-hop) neighbors. Hello messages are only broadcast to the one-hop neighbors and do not get transmitted past the one-hop neighborhood of a node. The hello message con- tains the name of the originating node, the one-hop neighbors that the originating node has discovered so far, and the nodes that the originating node has selected to be its MPRs. Once a node hears a hello message it checks whether the message originated from a new neighbor, and if so, it updates its one-hop neighborhood list.

The hello message is also very important for supporting the MPR concept. Each node checks the hello messages received from its neighbors to see whether it has been selected to be an MPR by any of the neighbors. If so, the node needs to flood the routing updates generated from such neighbors that have selected it to be their MPR. Every node can also figure out which nodes are two hops away from it through the hello message, because each of its one-hop neighbors lists in the hello message all the nodes that are within one hop of them. Each node selects its MPRs based on the two-hop neighborhood so that each of its two-hop neighbors can be reached through the MPRs.

Link-state updates are transmitted through the network via a message that is called a topology control (TC) message. TC messages are flooded throughout the network and every node can then recalculate its own routing table using this information. The flooding process is accomplished through the MPRs, as shown in Figure 4.17. In the case of OLSR it is not required for each node to advertise all its neighbors. It is adequate to advertise only the nodes that a node has selected as its MPRs.

OLSR also includes two additional message types: the host and network association (HNA) messages that are used by nodes for advertising connectivity to external networks, that is, networks that are not participating in the OLSR routing protocol, and the multiple interface declaration (MID) messages that are used only by nodes that have multiple inter- faces that are participating in the OLSR routing protocol so that other nodes can associate the different interfaces with the same node. OLSR has no support for message authentica- tion and is therefore vulnerable to a variety of attacks.

4.5.1 Secure Extension to OLSR

In the literature [62 – 64], schemes have been proposed for extending OLSR to make it secure against attacks. The main idea they propose is to use digital signatures for authen- ticating the OLSR routing messages. Such authentication may be done on a hop-by-hop basis or on an end-to-end basis. Halfslundet al.[62] focus on the hop-by-hop approach, in which each node signs OLSR packets as they are transmitted (such packets may contain multiple OLSR messages originated by a variety of nodes). The next hop verifies the auth- enticity of the message, strips the signature from the previous node, and adds its own sig- nature. Therefore, the signature only verifies that the node that forwarded the traffic is the one that signed the message but does not verify the authenticity of the original message. Authentication of messages is based on symmetric keys that nodes share and the signature is created using some kind of a hash function such as SHA-1. Rafto et al. [63] and Adjih et al. [64] discuss schemes for authenticating OLSR messages on end-to-end

Figure 4.17. OLSR routing protocol.

basis so that nodes receiving OLSR message can authenticate the node that generated the original message rather than just the node forwarding the message. We will discuss both types of schemes in more detail next.

We first discuss the scheme given in [62]. The focus here is on authentication on a hop by hop basis. Figure 4.18 shows the basic signature extension that is attached to each OLSR packet. The scheme and algorithm fields shown in Figure 4.18 specify the algorithm that is used for creating the signature (Halfslundet al.[62] use SHA-1 as an example). The signature is generated by applying the hash function (based on the scheme and algorithm defined in the message) on the OLSR packet header, the OLSR routing messages con- tained in the OLSR packet, the fields in the signature extension shown in Figure 4.18 except for the signature field, and the shared secret key. The timestamp field is needed in this scheme so that malicious nodes cannot launch replay attacks by just moving to a different neighborhood and replaying messages they recorded earlier.

In order for this scheme to work, nodes need to know the current time of their neigh- bors. This does not require that nodes synchronize their clocks. It only requires that the nodes know the approximate time difference between themselves and their neighbors. It is also assumed that clocks move forward at about the same speed. In order for neighbors to discover the relative time of their neighbors, Halfslundet al.[62] propose the following scheme. When node A needs to discover the relative time of its neighbor, it initiates the timestamp exchange process by sending a challenge message as shown in Figure 4.19.

The destination field contains the IP address of the node (say node B) that node A is trying to get the time value for. The random value field contains a random number to avoid replay attacks and the signature is created by applying the hash function as described earlier. The destination node, that is, Node B, then verifies the authenticity of the challenge message and then responds with a challenge-response message with the format shown in Figure 4.20. The challenge-response message contains the IP address of node A, the random number, and its timestamp. The response signature field is created by applying the hash function to the IP address of node B, the random challenge, and the shared key. The sig- nature field is produced by applying the hash function to the entire message and the shared key. When node A receives the challenge-response from node B, it first verifies its

Figure 4.18. Basic signature extension.

authenticity (by applying the hash functions as node B and comparing the results with what is contained in the message). Node A then sends its own timestamp to node B by creating a response message as shown in Figure 4.21.

Raftoet al.[63] propose a scheme for authenticating OLSR messages on end-to-end basis. The key idea of the scheme is as follows. When nodes send out OLSR messages they attach an ADVanced SIGnature (ADVSIG) message as defined in Figure 4.22. Nodes that advertise links sign the messages so that the origins of the message can be auth- enticated. Another key concept in this scheme is that, when nodes advertise a link to another node (e.g. through TC messages), they attach a proof that the link actually exists through a signed hello message from that node. This approach of securing OLSR requires a PKI scheme or some other key management scheme that can be used for verify- ing authenticity of messages. The scheme also requires a timestamp scheme [64] that allows nodes to have consistent timestamps as discussed earlier in this section.

In Figure 4.22, the signature method specifies the functions used for signing the mess- ages. The MSN referrer field specifies the message sequence number the ADVSIG message refers to. The global timestamp message contains the timestamp. The global sig- nature field contains the signature for the OLSR message and the ADVSIG message attached to it. The signatures of Certificates (#1 – #n) are signatures of hello messages that are generated by the node sending the message and for which there are no proofs yet (because a signed hello message has not been received by the other side of the link). The timestamp and signature proof (#1 – #n) contain the time when a signed hello message was received by the other side of the link advertised in the hello or TC message and the signature that was contained in that message (and was generated by the other side of the link).

4.5.2 Secure Link-State Routing Protocol

Secure link-state routing protocol (SLSP) [65] is a proposed scheme for securing link-state routing where security is achieved via the use of asymmetric primitives. SLSP assumes that each node in the network has a public – private key pair. Each node broadcasts its cer- tified key to all nodes within its zone (i.e. all nodes that are withinRhops from it). These broadcasts are periodic or when conditions require it (e.g. when there are substantial changes in the network topology), which enables new nodes entering the zone to discover the key. Certification of public keys can be achieved through a distributed certificate authority (see Chapter 2). We next describe how this scheme works.

Figure 4.20. Challenge-response message.

The first step in any link state routing protocol is neighbor discovery. Neighbor discov- ery in SLSP is achieved through signed hello messages that contain the medium access control MAC address and IP address of the node. This approach attempts to ensure that a single node cannot impersonate multiple nodes, and that duplicate IP addresses can be detected quickly.8 Messages from nodes violating the expected behavior may be dis- carded. This approach also allows nodes running SLSP to calculate the rates at which other nodes generate routing messages. Messages from nodes that are generating too many routing messages can be given lower priority, preventing those nodes from launch- ing DoS attacks by generating too many routing messages.

As is typical in link-state routing protocols, once nodes discover their neighbors they advertise their direct neighbors through link-state update (LSU) messages. In SLSP, LSU messages have the header shown in Figure 4.23. The originator of the LSU specifies

Figure 4.22. ADVSIG message format.

Figure 4.21. Response message.

8_{A node can still take on a different identity by changing both the MAC and IP addresses while using a different}

the radiusRof its zone in theRLSUfield. It then selects a random numberxand applies a

hash function on the numberh(x).h(x) is put in the hops_traversed field andhR(x) in the zone_radius field. Subsequent nodes that forward the LSU apply the hash function on the hops_traversed field and replace that field with the new value. Thus we have hops_traversed¼h(hops_traversed). The SLSP_LUS_SEQ contains a 32-bit sequence number that is increased monotonically with new LSUs generated by the node. The node also appends the signature into the LSU_signature field. The TTL value of the IP packet is set toR21 so that routing advertisements stay within the zone. It is also possible that the certified key is attached by the node to the LSU message itself (rather than in the periodic broadcast of the key). That ensures that the node receiving the LSU will be able to verify the message.

A node that is within the zone of the originator of an LSU most likely has the public key of the originator. When such a node receives the LSU message it can verify the authen- ticity of the message. Authenticity of the message is verified as follows. The node checks the hops_traversed field. The node knows the number of hops the message has already traveled which is the zone radius Rminus the TTL value in the current packet (the TTL value is decreased by one at each hop). Therefore, the node applies the hash func- tion TTL times on the hops_traversed field and compares it with the zone_radius field [which equalshR(x)]. The two values should be equal:

hTTL(hops traversed)¼hTTL½hRTTL(x) ¼hR(x)¼zone radius

If the LSU is validated, the node decrements the TTL, applies the hash function to the hops_traversed field and then rebroadcasts the LSU. The LSU is only kept until an LSU from the other side of the link is also received. When the LSU is confirmed it is used for updating routes on the node, otherwise the LSU is discarded. There is still a possibility that two nodes may collude to advertise a nonexisting link. SLSP can not prevent such attacks.