Securing Aodv
#1

[attachment=7286]
[attachment=371]
Presented by:PREEJESH.B
SECURING AODV



Abstract
Some aspects of ad hoc networks have interesting security problems. Routing is one such aspect. Canned security solutions like IPsec are not applicable. The routing protocol Ad hoc On Demand Vector routing protocol has no security mechanisms. So, to improve the security there are somenew mechanisms like hash chains, double signature are using.

Introduction

1.1 What is an Ad hoc Network
An ad hoc network is a group of wireless mobile computers (or nodes), in which individual nodes cooperate by forwarding packets for each other to allow nodes to communicate beyond direct wireless transmission range. An ad hoc network is also known as an infrastructureless network, meaning a network without the usual routing infrastructure like fixed routers and routing backbones. Several routing protocols for ad hoc networks have been developed. Some of them are Ad hoc On Demand Vector(AODV) Routing protocol, Dynamic Source Routing (DSR) protocol, Cluster based routing protocol, Global state routing protocol, etc. The applications of an ad hoc networks comes in personal area networking, meeting rooms and conferences, disaster relief and rescue operations, battlefield operations, etc. Some aspects of ad hoc networks have interesting security problems. Routing is one such aspect.

1.2 Features of Ad hoe Network
• Infrastructureless network
• Distributed peer-to-peer mode of operation
• Every node functions as a router
• Dynamically changing topology
• Multi-hop communication
2 Security
In routing the primary security service is authorization. There are two types of autorization,
1. Import authorization :- When a routing update is received from the outside, the router needs to decide whether to modify its local routing information base accordingly. Import authorization means that the ultimate authority about routing messages regarding a certain destination node is that node itself. Therefore, we will only authorize route information in our routing table if that route information concerns the node that is sending the information. In this way, if a malicious node lies, the only thing it will cause is that others will not be able to route packets to the malicious node.
2. Export authorization :- Router may carry out export authorization whenever it receives a request for routing information.
Import authorization is the critical service. In traditional routing systems, authorization is a matter of policy. For example, gated, a commonly used routing program, allows the admin¬istrator of a router to set policies about whether and how much to trust routing updates from other routers. In mobile ad hoc networks, such static policies are not sufficient. Authorization may require other security services such as authentication and integrity. Techniques like digital signatures and message authentication codes are used to provide these services.
Source authentication:- We need to be able to verify that the node is the one it claims to
be.
Integrity:- we need to be able to verify that the routing information that it is being sent to us has arrived unaltered.
3 AODV

3.1 An Overview of AODV
The Ad hoc On Demand Distance Vector (AODV) routing protocol is a routing protocol for ad hoc mobile networks. It is capable of both unicast and multicast routing. It builds routes between nodes only when it is required by source nodes and also it maintains these routes as long as they are needed by th ese sources. AODV forms trees which connect multicast group members. The trees are composed of the group members and the nodes needed to connect the members. AODV uses sequence numbers to ensure the freshness of routes. It is loop-free, self-starting, and scales to large numbers of mobile nodes.
AODV builds routes using a route request(RREQ) and route reply(RREP) message cycle. When a source node desires a route to a destination for which it does not already have a route, it broadcasts a route request (RREQ) packet to the network. Nodes receiving this packet update their information for the source node and set up backward pointers to the source node in the routing tables. In addition to the source node's IP address, current sequence number, and broadcast ID, the RREQ also contains the most recent sequence number for the destination of which the source node is aware. A node receiving the RREQ may send a route reply (RREP) if it is either the destination or if it has a route to the destination with corresponding sequence number greater than or equal to that contained in the RREQ. If this is the case, it unicasts a RREP back to the source. Otherwise, it rebroadcasts the RREQ. Nodes keep track of the RREQ's source IP address and broadcast ID. If they receive a RREQ which they have already processed, they discard the RREQ and do not forward it.
As the RREP propagates back to the source, nodes set up forward pointers to the destina¬tion. Once the source node receives the RREP, it may begin to forward data packets to the destination. If the source later receives a RREP containing a greater sequence number or con¬tains the same sequence number with a smaller hopcount, it may update its routing information for that destination and begin using the better route.
As long as the route remains active, it will continue to be maintained. Once the source stops sending data packets, the links will time out and eventually be deleted from the intermediate node routing tables. If a page link break occurs while the route is active, the node upstream of the break propagates a route error (RERR) message to the source node to inform it. After receiving the RERR, if the source node still desires the route, it can restart route discovery.
Multicast routes are set up in a similar manner. A node wishing to join a multicast group broadcasts a RREQ with the destination IP address set to that of the multicast group and with the 'J'(join) flag set to indicate that it would like to join the group. Any node receiving this RREQ that is a member of the multicast tree that has a fresh enough sequence number for the multicast group may send a RREP. As the RREPs propagate back to the source, the nodes forwarding the message set up pointers in their multicast route tables. As the source node receives the RREPs, it keeps track of the route with the freshest sequence number, and beyond that the smallest hop count to the next multicast group member. After the specified period, the source node will unicast a Multicast Activation (MACT) message to its selected next hop. This message serves the purpose of activating the route. A node that does not receive this message that had set up a multicast route pointer will timeout and delete the pointer. If the node receiving the MACT was not already a part of the multicast tree, it will also have been keeping track of the best route from the RREPs it received. Hence it must also unicast a MACT to its next hop, and so on until a node that was previously a member of the multicast tree is reached.
AODV maintains routes for as long as the route is active. This includes maintaining a multicast tree for the life of the multicast group. Because the network nodes are mobile, it is likely that many page link breakages along a route will occur during the lifetime of that route.

3.2 Security flaws of AODV
AODV has no security mechanisms, so malicious nodes can perform many attacks just by not behaving according to the AODV rules. A malicious node M can carry out the following attacks (among many others) against AODV:
1. Impersonate a node S by forging a RREQ with its address as the originator address.
2. When forwarding a RREQ generated by S to find a route to D, reduce the hop count field to increase the chances of being in the route path between S and D so it can analyze the communication between them. A variant of this is to increment the destination sequence number to make the other nodes believe that this is a 'fresher' route.
3. Impersonate a node D by forging a RREP with its address as a destination address.
4. Impersonate a node by forging a RREP that claims that the node is the destination and, to increase the impact of the attack, claims to be a network leader of the subnet SN with a big sequence number and send it to its neighbors. In this way it will became (locally) a blackhole for the whole subnet SN.
5. Selectively, not forward certain RREQs and RREPs, not reply to certain RREPs and not forward certain data messages. This kind of attack is especially hard to even detect because transmission errors have the same effect.
6. Forge a RERR message pretending it is the node S and send it to its neighbor D. The RERR message has a very high destination sequence number (dsn) for one of the unreachable destinations (U). This might cause D to update the destination sequence number corresponding to U with the value dsn and, therefore, future route finding performed by D to obtain a route to U will fail (because U's destination sequence number will be much smaller than the one stored in D's routing table).
7. The originator of a RREQ can put a much bigger destination sequence number than the real one. In addition, sequence numbers wraparound when they reach the maximum value allowed by the field size. This allows a very easy attack in which an attacker is able to set the sequence number of a node to any desired value by just sending two RREQ messages to the node.

4 Securing AODV
The key management sub-system makes it possible for each ad hoc node to obtain public keys from the other nodes of the network and each ad hoc node is capable of securely verifying the association between the identity of a given ad hoc node and the public key of that node. How this is achieved depends on the key management scheme. Two mechanisms are used to secure the AODV messages:
1. digital signatures to authenticate the non-mutable fields of the messages, and
2. hash chains to secure the hop count information (the only mutable information in the messages).
For the non-mutable information, authentication is perform in an end-to-end manner, but the same kind of techniques cannot be applied to the mutable information. The information relative to the hash chains and the signatures is transmitted with the AODV message as an extension message.

4.1 SAODV hash chains
Hash chains are used in SAODV to authenticate the hop count of the AODV routing messages (RREQ, RREP) by any node that receives one of those messages. This prevents an attack of type 2. A hash chain is formed by applying a one-way hash function repeatedly to a seed.
Every time a node originates a RREQ or a RREP message, it performs the following oper¬ations:
• Generates a random number (seed).
• Sets the Max Hop Count field to the TimeToLive value (from the IP header). Max Hop Count = TimeToLive
• Sets the Hash field to the seed value. Hash = seed
• Sets the Hash Function field to the identifier of the hash function that it is going to use. Hash Function = h
• Calculates Top Hash by hashing seed Max Hop Count times.
Top Hash = ^MaxHopC'ount^^
Where: h is a hash function. h*(x)
is the result of applying the function h to x i times.
In addition, every time a node receives a RREQ or a RREP message, it performs the following operations in order to verify the hop count:
• Applies the hash function h Maximum Hop Count minus Hop Count times to the value in the Hash field, and verifies that the resultant value is equal to the value contained in the Top Hash field.
Top Hash == ^(MaxHopC'ount-HopC'ount)^^
Where:
a == b reads: to verify that a and b are equal.
• Before rebroadcasting a RREQ or forwarding a RREP, a node applies the hash function to the Hash value in the Signature Extension to account for the new hop.
Hash = h(Hash)
The Hash Function field indicates which hash function has to be used to compute the hash. Trying to use a different hash function will just create a wrong hash without giving any ad¬vantage to a malicious node. Hash Function, Max Hop Count, Top Hash, and Hash fields are transmitted with the AODV message, in the Signature Extension. And, all of them but the Hash field are signed to protect its integrity.
4.2 SAODV digital signatures
Digital signatures are used to protect the integrity of the non-mutable data in RREQ and RREP messages. That means that they sign everything but the Hop Count of the AODV message and the Hash from the SAODV extension. AODV allows intermediate nodes to reply RREQ messages if they have a 'fresh enough' route to the destination. While this makes the protocol more efficient it also makes it more complicated to secure. The problem is that a RREP message generated by an intermediate node should be able to sign it on behalf of the final destination. And, it is possible that the route stored in the intermediate node would be created as a reverse route after receiving a RREQ message (which means that it does not have the signature for the RREP). To solve this problem, there are two alternatives. The first is that, if an intermediate node cannot reply to a RREQ message because it cannot properly sign its RREP message, it just behaves as if it didn't have the route and forwards the RREQ message. The second is that, every time a node generates a RREQ message, it also includes the RREP flags, the prefix size and the signature that can be used (by any intermediate node that creates a reverse route to the originator of the RREQ) to reply a RREQ that asks for the node that originated the first RREQ. Moreover, when an intermediate node generates a RREP message, the lifetime of the route has changed from the original one. Therefore, the intermediate node should include both lifetimes (the old one is needed to verify the signature of the route destination) and sign the new lifetime. In this way, the original information of the route is signed by the final destination and the lifetime is signed by the intermediate node. To distinguish the different SAODV extension messages, the ones that have two signatures are called RREQ and RREP Double Signature Extension.
When a node receives a RREQ, it first verifies the signature before creating or updating a reverse route to that host and according to that it will store the route. If the RREQ was received with a Double Signature Extension, then the node will also store the signature for the RREP and the lifetime (which is the 'reverse route lifetime' value) in the route entry. An intermediate node will reply to a RREQ with a RREP only if it fulfills the AODV's requirements to do so and the node has the corresponding signature and old lifetime to put into the Signature and Old Lifetime fields of the RREP Double Signature Extension. Otherwise, it will rebroadcast the RREQ. When a RREQ is received by the destination itself, it will reply with a RREP only. This RREP will be sent with a RREP Single Signature Extension. When a node receives a RREP, it first checks the signature before creating or updating a route to that host and according to that it will store the route with the signature of the RREP and the lifetime. This technique helps to prevent attack scenarios 1 and 3.

4.3 SAODV error messages
Route error messages are protected in a different manner because they have a big amount of mutable information. In addition, it is not relevant which node started the route error and which nodes are just forwarding it. The only relevant information is that a neighbor node is informing to another node that it is not going to be able to route messages to certain destinations anymore.
Therefore, every node (generating or forwarding a route error message) uses digital signa¬tures to sign the whole message and that any neighbour that receives verifies the signature.
Although nodes will not trust destination sequence numbers in a RERR message, they will use them to decide whether they should invalidate a route or not. This does not give any extra advantage to a malicious node.

4.4 When a node reboots
The attack type 7 was based on the fact that the originator of the RREQ can set the sequence number of the destination. So if it set the destination sequence number to OxFFFFFFFF (the maximum value that fits in the 32-bits field). Then, the originator of the RREP and all the intermediate nodes will have that as sequence number for the route. The next time the node increments the sequence number, its sequence number counter will overflow. This might cause unexpected results.
The fact that the originator of the RREQ can set the sequence number of the destination is because it is going to be needed if the destination node has rebooted. After rebooting, a node does not remember its sequence number anymore and trusts anybody that sends to it a RREQ with the number. But this cannot be allowed. Therefore, all the AODV-enabled nodes should have a way to keep their destination sequence number even after rebooting. In addition, in the case that the destination sequence number in the RREQ is bigger than the destination sequence number of the destination node, the destination node should not take into account the value in the RREQ. Instead, it will realize that the originator of the RREQ is misbehaving and will send the RREP with the right sequence number.

Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: aodv advantages, algorith of aodv for vanets in java, aodv example, aodv draft, aodv project in java, securing the internet connection, latarey sanbad,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  PERFORMANCE COMPARISON OF AODV AND DSR ROUTING PROTOCOLS IN MANETs project report helper 1 2,527 15-03-2011, 09:54 AM
Last Post: talaash_143some_one
  Securing Passive Objects in Mobile Ad-Hoc Peer-to-Peer Networks project report tiger 1 1,094 20-09-2010, 04:26 PM
Last Post: project report helper
  Performance Evaluation of AODV, DSDV & DSR Routing Protocol in Grid Environment project topics 0 5,593 25-04-2010, 11:25 AM
Last Post: project topics
  Semnar report on DNSSEC : A Protocol towards securing super 0 1,846 17-06-2009, 11:31 AM
Last Post: super
  SEMINAR REPORT ON MODEL CHECKING FOR SECURING E-COMMERCE TRANSACTIONS Computer Science Clay 0 2,409 14-06-2009, 01:03 AM
Last Post: Computer Science Clay
  DNSSEC (A Protocol towards securing the Internet Infrastructure) Computer Science Clay 0 3,749 14-06-2009, 12:51 AM
Last Post: Computer Science Clay
  Securing the Network Routing Algorithms ( Download Full Seminar Report ) computer science crazy 0 2,406 09-04-2009, 12:58 PM
Last Post: computer science crazy

Forum Jump: