Draft ietf manet aodv 08 txt

Anyway, there is one issue that has to be taken into account when using such systems for AODV networks: When distributing a public key, with the public key it also should come the IP address of the node of course and the netmask in the case the node is a network leader. This would avoid the attack in which a malicious node becomes a black hole for a whole subnet by claiming that it is their network leader. If no certificates are used only private and public keys it will be assumed that the hash algorithm is SHA [ 4 ] and the encryption method is RSA [ 5 ].

If certificates are used they already include which algorithms should be used. Overview The solution presented in this paper is an extension of the AODV protocol mainly by using new extension messages. In these extension messages there is a signature created by digesting the AODV packet using the private key of the original sender of the Routing message not of the intermediate nodes that just forward it.

In the first one, when a RREQ is sent, the sender signs the message. Intermediate nodes verify the signature before creating or updating a reverse route to that host.

And only if the signature is fine they store the reverse route. The final destination node signs the RREP with its private key. Intermediate and final nodes, again verify the signature before creating or updating a route to that host, also storing the signature with the route entry.

In the second one, when a RREQ is sent, the sender signs the message. And, again, only if the signature is fine they store the reverse route. But the difference is that the RREQ message has also a second signature that is always stored with the reverse route.

An intermediate node that wants to reply a RREQ needs not only the correct route, but also the signature corresponding to that route to add it in the RREP and the lifetime that came in the same message tha the signature. When this happens, it generates the RREP, adding the stored signature and lifetime signs the actual lifetime and sends it.

All the nodes that receive the RREP and that update the route store the signature and lifetime with that route. Hello messages are RREP messages, so they are signed in the same way. Extension messages that include a second signature also include the RREP fields flags and prefix size that are not derivable from the RREQ but not zeroed when computing the signature.

RREP-ACK messages may be authentified by using a digital signature, that might be verified by any one that receives them. Every node, generating or forwarding a RERR message, uses digital signatures to sign the whole message and any neigbour that receives verifies the signature. Top Hash The top hash for the hop count authentication. This field has variable length, but it must be bits aligned. Hash The hash corresponding to the actual hop count. Sent as 0; ignored on reception.

Both signatures are generated by the requesting node. This signature is the one that was generated by the final destination. Signature of the new Lifetime The signature of the RREP with the actual lifetime the lifetime of the route in the intermediate node.

The destination sequence number is created by the destination to be included along with any route information it sends to requesting nodes. Using destination sequence numbers ensures loop freedom and is simple to program. Given the choice between two routes to a destination, a requesting node is required to select the one with the greatest sequence number.

So, for instance, the requesting node is expected to use its IP address as the Originator IP address for the messages. For broadcast messages, the IP limited broadcast address This means that such messages are not blindly forwarded.

However, AODV operation does require certain messages e. Fragmentation is typically not required. As long as the endpoints of a communication connection have valid routes to each other, AODV does not play any role. When a route to a new destination is needed, the node broadcasts a RREQ to find a route to the destination. A route can be determined when the RREQ reaches either the destination itself, or an intermediate node with a 'fresh enough' route to the destination.

A 'fresh enough' route is a valid route entry for the destination whose associated sequence number is at least as great as that contained in the RREQ. Each node receiving the request caches a route back to the originator of the request, so that the RREP can be unicast from the destination along a path to that originator, or likewise from any intermediate node that is able to satisfy the request.

Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations possibly subnets which are no longer reachable by way of the broken link. The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in a precursor list see section 6.

In this document, full processing for such messages is not specified. However, it is important to enable correct multicast operation by intermediate nodes that are not enabled as originating or destination nodes for IP multicast addresses, and likewise are not equipped for any special multicast protocol processing.

AODV is a routing protocol, and it deals with route table management. Route table information must be kept even for short-lived routes, such as are created to temporarily store reverse paths towards nodes originating RREQs.

A destination becomes unreachable when a link breaks or is deactivated. When these conditions occur, the route is invalidated by operations involving the sequence number and marking the route table entry state as invalid. See section 6. This section defines other terminology used with AODV that is not already defined in [ 3 ]. Only active routes can be used to forward data packets. A broadcast packet may not be blindly forwarded, but broadcasting is useful to enable dissemination of AODV messages throughout the ad hoc network.

Same as "destination node". A node knows it is the destination node for a typical data packet when its address appears in the appropriate field of the IP header. An invalid route is used to store previously valid route information for an extended period of time. An invalid route cannot be used to forward data packets, but it can provide information useful for route repairs, and also for future RREQ messages. In AODV routing protocol messages, it is used by other nodes to determine the freshness of the information contained from the originating node.

Applicability Statement The AODV routing protocol is designed for mobile ad hoc networks with populations of tens to thousands of mobile nodes. AODV can handle low, moderate, and relatively high mobility rates, as well as a variety of data traffic levels. AODV is designed for use in networks where the nodes can all trust each other, either by use of preconfigured keys, or because it is known that there are no malicious intruder nodes. AODV has been designed to reduce the dissemination of control traffic and eliminate overhead on data traffic, in order to improve scalability and performance.

Message Formats 5. R Repair flag; reserved for multicast. U Unknown sequence number; indicates the destination sequence number is unknown see section 6. Reserved Sent as 0; ignored on reception. Destination Sequence Number The latest sequence number received in the past by the originator for any route towards the destination. Originator Sequence Number The current sequence number to be used in the route entry pointing towards the originator of the route request.

A Acknowledgment required; see sections 5. Prefix Size If nonzero, the 5-bit Prefix Size specifies that the indicated next hop may be used for any nodes with the same routing prefix as defined by the Prefix Size as the requested destination. For multicast route requests this indicates the number of hops to the multicast tree member sending the RREP. Destination Sequence Number The destination sequence number associated to the route. Note that the Prefix Size allows a subnet router to supply a route for every host in the subnet defined by the routing prefix, which is determined by the IP address of the subnet router and the Prefix Size.

In order to make use of this feature, the subnet router has to guarantee reachability to all the hosts sharing the indicated subnet prefix.

See section 7 for details. When the prefix size is nonzero, any routing information and precursor data MUST be kept with respect to the subnet route, not the individual destination IP address on that subnet. The 'A' bit is used when the link over which the RREP message is sent may be unreliable or unidirectional. Unreachable Destination Sequence Number The sequence number in the route table entry for the destination listed in the previous Unreachable Destination IP Address field.

The RERR message is sent whenever a link break causes one or more destinations to become unreachable from some of the node's neighbors. This is typically done when there is danger of unidirectional links preventing the completion of a Route Discovery cycle see section 6.

In order to process the messages correctly, certain state information has to be maintained in the route table entries for the destinations of interest. Maintaining Sequence Numbers Every route table entry at every node MUST include the latest information available about the sequence number for the IP address of the destination node for which the route table entry is maintained.

This sequence number is called the "destination sequence number". It is updated whenever a node receives new i. AODV depends on each node in the network to own and maintain its destination sequence number to guarantee the loop-freedom of all routes towards that node. A destination node increments its own sequence number in two circumstances: - Immediately before a node originates a route discovery, it MUST increment its own sequence number.

This prevents conflicts with previously established reverse routes towards the originator of a RREQ. When the destination increments its sequence number, it MUST do so by treating the sequence number value as if it were an unsigned number. To accomplish sequence number rollover, if the sequence number has already been assigned to be the largest possible number representable as a bit unsigned integer i. On the other hand, if the sequence number currently has the value , which is the largest possible positive integer if 2's complement arithmetic is in use with bit integers, the next value will be , which is the most negative possible integer in the same numbering system.

The representation of negative numbers is not relevant to the increment of AODV sequence numbers. This is in contrast to the manner in which the result of comparing two AODV sequence numbers is to be treated see below. In order to ascertain that information about a destination is not stale, the node compares its current numerical value for the sequence number with that obtained from the incoming AODV message. This comparison MUST be done using signed bit arithmetic, this is necessary to accomplish sequence number rollover.

If the result of subtracting the currently stored sequence number from the value of the incoming sequence number is less than zero, then the information related to that destination in the AODV message MUST be discarded, since that information is stale compared to the node's currently stored information. AODV Terminology 3 4.

Node Operation - Unicast 7 6. Maintaining Route Utilization Records. Forwarding Route Requests. Maintaining Local Connectivity. Node Operation - Multicast 13 8. Maintaining Multicast Tree Utilization Records. Forwarding Multicast Route Requests. Generating Multicast Route Replies. Forwarding Route Replies. Route Deletion and Multicast Tree Pruning. Repairing Link Breakages. Initiating Triggered Route Replies. Quality of Service 20 Extensions 21 Hello Interval Extension Format. Multicast Group Leader Extension Format.

Multicast Group Information Extension Format. Maximum Delay Extension Format. Minimum Bandwidth Extension Format. Configuration Parameters 25 Security Considerations 26 1. Introduction The Ad Hoc On-Demand Distance Vector AODV algorithm enables dynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network.

AODV allows mobile nodes to obtain routes quickly for new destinations, and does not require nodes to maintain routes to destinations that are not in active communication. Additionally, AODV allows for the formation of multicast groups whose membership is free to change during the lifetime of the network. AODV allows mobile nodes to respond quickly to link breakages and changes in network topology.

One distinguishing feature of AODV is its use of a destination sequence number for each route entry. The destination sequence number is created by the destination or the multicast group leader for any usable route information it sends to requesting nodes. Using destination sequence numbers ensures loop freedom and is simple to program. Given the choice between two routes to a destination, a requesting node always selects the one with the greatest sequence number.

Another feature of AODV is that link breakages cause immediate notifications to be sent to the affected set of nodes, but only that set of nodes. So, for instance, the requesting node is expected to use its IP address as the source IP address for the messages. Fragmentation is typically not required. When a route to a new destination either a single node or a multicast group is needed, the node uses a broadcast RREQ to find a route to the destination.

A route can be determined when the RREQ reaches either the destination itself, or an intermediate node with a fresh enough route to the destination. Since each node receiving the request caches a route back to the source of the request, the RREP can be unicast back from the destination to the source, or from any intermediate node that is able to satisfy the request back to the source. RREQs are also used when a node wishes to join a multicast group. A join flag in the RREQ informs nodes that when receiving the RREP, they are not just setting route pointers but are also setting multicast route pointers, which will be used if the route is selected to be added onto the tree.

The message carries multicast group and corresponding group leader IP addresses. This information is used for repairing multicast trees after a previously disconnected portion of the network containing part of the multicast tree becomes reachable once again.

Since AODV is a routing protocol, it deals with route table management. Route table information must be kept even for ephemeral routes, such as are created to temporarily keep track of reverse paths towards nodes originating RREQs. This section defines other terminology used with AODV that is not already defined in [ 2 ]. This node is responsible for initializing and maintaining the multicast group destination sequence number.

Perkins, Royer Expires 20 April [Page 3] Internet Draft AODV 20 November subnet leader A node which is a member of the subnet defined by a specific routing prefix, and which offers reachability to every other node with the same routing prefix. The subnet leader is responsible for initializing and maintaining the destination sequence number for every node on the subnet.

R Repair flag; set when a node wants to initiate a repair to connect two previously disconnected portions of the multicast tree. Reserved Sent as 0; ignored on reception. Destination Sequence Number The last sequence number received in the past by the source for any route towards the destination. Source Sequence Number The current sequence number to be used for route entries pointing to and generated by the source of the route request.

This active-list of neighbors will receive notifications from the node in the event of detection of a link breakage. Generating Route Requests A node broadcasts a RREQ when it determines that it needs a route to a destination and does not have one available.

This can happen if the destination is previously unknown to the node, or if a previously valid route to the destination expires. Routes can become invalid if they time out the Lifetime associated with the route expires , or else if a link breakage results in an infinite metric being associated with the route.

After the expiration time, the route MAY be expunged from the node's route table. Each rebroadcast has to increment the Broadcast ID field.

Otherwise, the node checks to see whether it has a route to the destination. The Hop Count field in the broadcast RREQ message is incremented by one, to account to the new hop through the intermediate node.

If the node has a route to the destination, and the node's existing dest-seqno is greater than or equal to the Destination Sequence Number of the RREQ, then the node generates a RREP as discussed further in section 6.

First, the node copies over its destination sequence number from the entry in its route table, or if the generating node is the node itself, it uses a destination sequence number at least equal to a sequence number generated after the last detected change in its neighbor set.

If the node has not detected any change in its set of neighbors since it last incremented it destination sequence number, it may use the same destination sequence number. As part of the process of generating the RREP, the generating node creates or updates an entry in its routing table for the Source IP Address, if necessary as described in section 6. If the generating node is not the destination node, then the generating node calculates the Hop Count between the Source IP Address and the Destination IP Address by adding together the Hop Count from the RREQ and the hop count stored in the route table entry for the destination node.

If the generating node is not the node indicated by the Destination IP Address, then it puts the next hop towards the destination in the active-list for the reverse path route entry. Initiating Triggered Route Replies A node can trigger an unsolicited RREP if either it detects a link breakage for a next hop along an active route in its route table, or if it receives a RREP from a neighbor with an infinite metric for an active route i. Detecting Link Breakage A node can detect a link breakage by listening for "hello" messages from its set of neighbors.

When this happens, the node should assume that its link with the former neighbor has been broken, and proceed as in Section 6. A node should assume that a hello message has been missed if it is not received within 1.