Presented by: Poonam Munshi

1. SECURITY-AWARE AD-HOC ROUTING FOR WIRELESS NETWORKSSeung Yi, Prasad Naldurg, Robin KravetsDepartment of Computer ScienceUniversity of Illinois at Urbana-ChampaignAugust, 2001 Presented by: Poonam Munshi

2. SECURITY-AWARE AD-HOC ROUTING (SAR) • Need for Secure Routing - Motivation • SAR – Protocol and Behavior • Protocol Metrics • Protection in SAR • Implementation of SAR • Performance Evaluation & Conclusion

3. NEED FOR SECURE ROUTING - MOTIVATION • Problems in ad-hoc wireless networks • Lack of fixed infrastructure support • Frequent changes to network topology • Poor protection to protocol packets at physical layer • Network layer routing protocols are “cooperative” by nature • Based on implicit ‘trust-your-neighbor’ relationships • Susceptible to erroneous routing updates, replay attacks etc. • SAR - Approach • Use different security attributes to improve the quality of the security of an ad-hoc route • Incorporate security levels of nodes into traditional routing metrics • Goal : • Quantify the notion of trust • Represent trust relationships explicitly by defining a suitable hierarchy of trust values • Integrate the trust value of a node and the security attributes of a route to provide an “integrated security metric”

4. NEED FOR SECURE ROUTING - MOTIVATION • Challenges • Ensuring data is routed through a secure route composed of trusted nodes • Security of the information in the routing protocol messages • Example Scenario – Battlefield communication Secure route Private Officer General Shortest route Transmission range

5. SAR – PROTOCOL OVERVIEW • Similar to policy-based routing protocols for QoS • Protocol: • Basic protocol : On-demand protocol AODV • Embed security metric into the RREQ packet itself and change the forwarding behavior of the protocol w.r.t. RREQs • Source node : • Specify desired level of security in the RREQ • Broadcast the packet • Intermediate node : • Process/forward the packet only if it can provide the required security or has the required authorization or trust level ; • Otherwise drop the RREQ • If an end-to-end path with the required security found, the intermediate node or eventual destination sends a suitably modified RREP

6. SAR – BEHAVIOR OVERVIEW • Route discovered by SAR may not be the shortest route in terms of hop-count • SAR finds a route with a ‘quantifiable guarantee of security’ • If one or more routes satisfying the required security attributes exists, SAR finds the shortest such route • Optimal route: All nodes on the shortest path (in terms of hop-count) satisfy the security requirements • Drawback: • If no path with nodes that meet the RREQ’s security requirements exists, SAR fails to find a route even though the network may be connected

7. SAR – PROTOCOL METRICS • Explicit representation of trust levels using a simple hierarchy that reflects organizational privileges • Trust hierarchy • Associate a number with each privilege level • Numbers reflect security/importance/capabilities of mobile nodes and also of the paths • QoP (Quality of Protection) bit vector • Trust level or protection should be immutable • Keys can be distributed a priori, or a key agreement can be reached by some form of authentication • Encrypt the portion of the RREQ and RREP headers that contain the trust level.

8. SAR – PROTOCOL METRICS • Secure Ad Hoc Routing – Properties and Techniques used to guarantee these properties

9. PROTECTION IN SAR PROTOCOL AAA • Trust Hierarchy • Protocol User Trust Level User Identity • Nodes and users can be forced to respect trust hierarchy using cryptographic techniques, e.g., encryption, public key certificates, shared secrets • Outsider attacks • Threshold cryptography, key sharing, etc. can be used • SAR uses simple shared secret to generate a symmetric encryption/decryption key per trust level. • Insider Attacks • Compromised users within a protection domain or trust level • Secure transient associations, tamper proofing etc. can be used

10. PROTECTION IN SAR PROTOCOL • Threats to Information in Transit • Interruption • Interception and Subversion • Modification • Fabrication • Replay Attacks: • SAR uses sequence numbers and timestamps • Passive Attacks: • Examples: covert channels, traffic analysis, sniffing to compromise keys • Using a suitable MAC layer encryption protocol for protection against sniffing/eavesdropping

11. SAR - IMPLEMENTATION • SAODV ( Security-aware AODV): • on-demand route discovery using flooding, reverse path maintenance in intermediate nodes, and forward path setup via RREP messages • RREQ (Route REQuest) packet: • RQ_SEC_REQUIREMENT : the security requirement • Set by the sender; does not change during route discovery phase • Simple integer values or bit vector • RQ_SEC_GUARANTEE : the security guarantee • Indicates the maximum level of security afforded by all nodes on the discovered path • Updated at every hop during the route discovery phase • If the application requested integrity support, a new field to store the computed digital signatures added to the RREQ • RREP (Route REPly) packet : • RQ_SEC_GUARANTEE : the security guarantee • Copied from RREQ and sent back to sender to indicate security level over whole path

12. SAR - IMPLEMENTATION • SAODV Route Discovery • Source node : • Set the RQ_SEC_REQUIREMENT field in the RREQ packet • Broadcast the packet just as in AODV • When an intermediate node receives an RREQ • First check if the node can satisfy the security requirement indicated in the packet • If yes, update the RQ_SEC_GUARANTEE field; forward to its neighbors • If no, drop the RREQ packet • When RREQ arrives at the destination • Indicates the presence of a path from the sender to the receiver that satisfies the security requirement specified by the sender • Copy RQ_SEC_GUARANTEE from RREQ into RREP • Send the RREP back to sender as in AODV

13. SAR - IMPLEMENTATION • When an intermediate node receives an RREP • The RREP packet arrives at an intermediate node in the reverse path • Update its routing table • Record the new RQ_SEC_GUARANTEE value • This value indicates the maximum security available on the cached forward path. • When a trusted intermediate node answers a RREQ query using cached information • Compare RQ_SEC_GUARANTEE of the cached route to the security requirement in the RREQ packet • Sent back RREP containing cached path information only if the forward path can guarantee enough security

14. EXAMPLE SCENARIO - REVISITED • Example Scenario – Battlefield communication • Embed the rank of the node as a metric in route negotiation (establish routes that avoid all privates) • If no route found, the generals may decide to set up a route that can support 128-bit encryption Secure route through officers only Private Officer General Transmission range Shortest route through private

15. PERFORMANCE EVALUATION & CONCLUSION • SAR enables the discovery of secure routes in a mobile ad hoc environment. • Though not optimal, routes discovered by SAR come with “quality of protection" guarantees. • The processing overheads in SAR are offset by restricting the scope of the flooding for more relevant routes, providing comparable price/performance benefits. • Its integrated security metrics allow applications to explicitly capture and enforce explicit cooperative trust relationships. • SAR also provides customizable security (e.g., encryption for confidentiality etc.) to the flow of routing protocol messages themselves • The techniques enabled by SAR can be easily incorporated into generic ad hoc routing protocols