1 / 22

Secure Routing in Mobile Ad Hoc Networks

star
Download Presentation

Secure Routing in Mobile Ad Hoc Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Secure Routing in Mobile Ad Hoc Networks //Look at the web page for 4 references.//

    2. 2 What are Wireless Ad-Hoc Networks? Mobile nodes equipped with wireless Interfaces No established Infrastructure Self Organized No Centralized Control Network topology changes dynamically.

    3. 3 How are Wireless Networks different from wired Networks ? Dynamic Changing Topology Physical Vulnerability Power Constraints No Single Line of Defense Key Management is a big problem due to transient nature of the protocol

    4. 4 Attacks on Routing Dissemination of erroneous routing information Non Co-operation in Routing – Refuse to send packets Replay Attacks –Sending the same packet with different IP Addresses Falsely stating broken links

    5. 5 Secure Routing problem We are interested in establishing a route that is free from any malicious or adversarial nodes. Once such a route is established, the problem is pretty much solved. So we focus on topology discovery rather than data forwarding. Once a secure route is established, data forwarding over that route is a simple matter.

    6. 6 Secure Routing problem A malicious node may behave correctly during route discovery phase and may drop packets later. Require continuous monitoring of performance of nodes along routes. Misbehaving nodes are detected. Reports is generated on the nodes. Ratings of nodes is periodically reevaluated. A misbehaving alert dramatically decreases its rating.

    7. 7 A Secure Route Discovery Protocol (By Papadimitratos and Haas.) Assumes the presence of a secret key between the source and destination (Ks,t). A security association with any of the intermediate nodes is not required. Capable of combating several attacks that will disrupt the route discovery process.

    8. 8 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Operation: (Secure Routing Protocol, SRP) Basic operation: The source broadcasts a route discovery message. The packet is forwarded by intermediate nodes to the destination and the route is accumulated in the packets. The destination attaches a message digest for the discovered route and sends it back on the same route in reverse direction. When the source receives this message, it verifies the digest and treats that a potential route.

    9. 9 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol) Each source node S maintains a Query Sequence Number (Qseq) for each destination. A 32 bit number (about 4 billion unique nos.). Initialized at the establishment of SA. Increases monotonically for each route request for the same destination. Allows destination T to detect outdated requests.

    10. 10 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… To each route request, source S attaches a Query Identifier (Qid). A 32 bit random number. Used by intermediate nodes to identify the request. Makes prediction of Qid impossible. Combats an attack where a malicious node broadcasts fabricated requests to cause subsequent legitimate queries to be dropped.

    11. 11 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… SRP header consists of the following information: Qseq (query sequence number). Qid (Query Identifier). A message authentication code (MAC). A 96-bit long field. Generated by a keyed-hash function. Input to the has is information relevant to this search. Destination can verify the integrity of the fields.

    12. 12 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… A route request message looks as follows: {Qs,t; n1,n2,n3,….nk} <> Qs,t denotes the packet header (s source, t dest.) <> ni is the IP address of an intermediate node in the route. <> n1=s and nk=t (when the msg reaches dest. Route reply message also has the similar format: {Rs,t; n1,n2,n3,….nk}

    13. 13 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… SRP Request Handling: An intermediate node extracts Qid and source and destination addresses from the request. An entry for the request is created in the Query Table at the intermediate node. If a similar entry already exists in the Query Table, the incoming request is discarded. //similarity is based on Qid, Source and destination addresses.// <> Otherwise, the node broadcasts the request after appending its ID in the accumulated route list.

    14. 14 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… Route Reply: When the destination node T receives this message, it verifies (using Qseq) if it is an outdated, duplicate, or replayed message. (discard the message if it is.) Otherwise, T computes the keyed hash of appropriate fields in the message. If computed hash matches the SRP header MAC, integrity of the request is verified.

    15. 15 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… Route Reply:... For each valid route request, the destination node T generates a reply message. A route reply message consists of: The accumulated route. Qseq and Qid (so that Source can verify the msg.) A MAC to protect the integrity of the reply msg. //It also offers evidence that the request had reached the destination.//

    16. 16 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… Route Reply Validation: When the source receives the route reply message, it checks the source and destination addresses, Qseq, and Qid. It discards the message if they don’t correspond to the currently pending query. Otherwise, it compares the reverse route in the route reply message with the forward route in its payload.

    17. 17 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Detailed Operation: (Secure Routing Protocol)… Route Reply Validation:… If both route match, then it computes the MAC from appropriate fields in the route reply msg. If MAC matches with the MAC contained in the message, the source is assured that The route reply message has not been tempered on they way. The routing information is correct.

    18. 18 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Foul Play Scenarios: (refer to the figure) Scenario 1: “When M1 receives {Qs,t,;S}, it attempts to mislead S by generating {Qs,t; M1, T}”. <> Such a response will be discarded by S because M1 can not generate is valid MAC for the reply. (It does not have the Ks,t).

    19. 19 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Foul Play Scenarios: (refer to the figure)… Scenario 2: “M1 discards all route request messages”. <> Impossible to prevent such actions. <> Such actions only narrow the topologically view of S. <> M1 is automatically excluded from any route found. <> So, no harm is done to data flow.

    20. 20 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Foul Play Scenarios: (refer to the figure)… Scenario 3: “M1handles the route request message correctly. But when it receives the corresponding route reply message {Rs,t; S,1,M1,5,4,T}, it tampers with its contents and relays {Rs,t; S,1,M1,Y,T}”. (Y is any false, invented sequence of nodes.) <> Impossible to prevent such actions. <> S will discard such a reply message due to MAC violation. <> A valid path is destroyed!

    21. 21 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Foul Play Scenarios: (refer to the figure)… Scenario 4: “When M2 receives {Qs,t; S,2,3}, it corrupts the accumulated route and relays {Qs,t; S,x,3,M2} to the next node.” (x is any false, invented node.) <>Destination node T will not be able to detect this. It will send a route reply message to S. <> When node 3 receives the reply, it will discard the message because it can not find node. <> A valid path is destroyed!

    22. 22 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Foul Play Scenarios: (refer to the figure)… Scenario 5: “To consume network resources, M1 replays old route request messages.” <>Intermediate nodes will be able to discard such messages because they keep query identifiers for the past queries. <>A very old replayed route request may reach dest. T. But it will be detected and discarded. <> Likewise, any fabricated route requests will be discarded by T.

    23. 23 A Secure Route Discovery Protocol (By Papadimitratos and Haas.)… Foul Play Scenarios: (refer to the figure)… Scenario 6: “After M1 has seen few route request messages from S, it fabricates new route request messages by changing query identifier field. The intent is to let intermediate node store these messages and discard genuine route request messages that S will send in the future.” <>This attack will work if S chooses the same query identifiers for future route request messages. <>However, it is impossible because S chooses query identifiers randomly from a large space.

More Related