1.58k likes | 1.74k Views
Ad Hoc Network Routing. Not in the book. Ad Hoc Network Routing. Each device acts as a router Routing protocol discovers paths through network Nodes have limited resources. A. B. C. On-Demand vs. Periodic. Two types of routing protocols: Periodic (proactive):
E N D
Ad Hoc Network Routing Not in the book
Ad Hoc Network Routing • Each device acts as a router • Routing protocol discovers paths through network • Nodes have limited resources A B C
On-Demand vs. Periodic Two types of routing protocols: • Periodic (proactive): • Most wired routing protocols are periodic • Routing information learnedwithsomedelay • Tradeoff delay and routing overhead • On-demand (reactive): • Discover routing information only when needed • Overhead scales automatically • Better in resource-limited, dynamic networks
A B C Basic Distance Vector Routing • Each device (node) maintains a routing table: Example table at A: • Computed using Distributed Bellman-Ford: • Each node periodically broadcasts its routing table • For each routing table entry received, compare best known route with new information
Improvements to Distance Vector • Triggered updates, incremental updates • Split horizon, poisoned reverse
Improvements to Distance Vector • Triggered updates, incremental updates • Split horizon, poisoned reverse • Sequence numbers for loop-freedom: • Each node maintains a sequence number • Each node increments its sequence number each time it sends an update about itself • An advertised route is “better” if either • It has a higher (more recent) sequence number, or • Sequence numbers equal, and the metric is lower • Special case for propagating broken links faster
Ad Hoc Network Routing: DSR Dynamic Source Routing intuition: • Operate completely on-demand • Cache learned links in a graph data structure • Use source routing for simplicity C A D B E F Route Cache at node A
Ad Hoc Network Routing: DSR Dynamic Source Routing intuition: • Operate completely on-demand • Cache learned links in a graph data structure • Use source routing for simplicity C A D B E F Route Cache at node A
DSR Route Discovery When a node needs a route to a destination: • Broadcast a ROUTE REQUEST with source, target, id When hearing a ROUTE REQUEST for another node: • DropifalreadyseenREQUESTfromsameDiscovery • Else,append address to node list and rebroadcast A, B target=E, id=3 A target=E, id=3 A, B, D target=E, id=3 B A D E C
DSR Route Discovery When hearing a ROUTE REQUEST for this node: • Return a ROUTE REPLY to the initiator E received a REQUEST: target=E, route=A,B,D: A,B,D,E A,B,D,E B A,B,D,E A D E C
ERROR B,C ERROR B,C DSR Route Maintenance When forwarding a packet, a node: • Transmits the packet to the next hop specified in the source route • Confirms reachability of next-hop destination • If next-hop not reachable, send ROUTE ERROR to packet’s source (S,A,B,C,D) (S,A,B,C,D) (S,A,B,C,D) A B C S D
Ad hoc On demand Distance Vector • Ad hoc On demand Distance Vector is: • Stateful routing (based on routing tables) • Loop-freedom through sequence numbers • But state is created on-demand throughRoute Request (RREQ) and Reply (RREP) • RREQ and RREP act as routing updates: • Form paths to original sender of those packets(initiator for RREQ, target for RREP)
B C AODV Route Discovery When a node needs a route to a destination: • Broadcast REQUEST with source, target, id, seq # When hearing a ROUTE REQUEST for another node: • DropifalreadyseenREQUESTfromsameDiscovery • Else,adjust routing table and rebroadcast To A AE, id=3seq=5 AE, id=3seq=5 AE, id=3seq=5 A D E
AODV Route Discovery When hearing ROUTE REQUEST for this node: • Return ROUTE REPLY to initiator with seq numberunless REPLY already returned for this Discovery When forwarding ROUTE REPLY, update routing table E received a REQUEST: target=E, id=3: To A To E EA seq=9 EA seq=9 B EA seq=9 A D E C
AODV Route Maintenance • When AODV receives a packet for forwarding: • If the packet’s destination in routing table, forward to indicated next hop • If forwarding is unsuccessful, or if no route found: • Broadcast a ROUTE ERROR (RERR) • If a node hears an RERR sent by its next-hop, the node rebroadcasts the RERR • Delete routing table entries unless recently used • AODV can also use HELLO packets for periodic Route Maintenance
AODV Route Maintenance • Node detecting error broadcasts a ROUTE ERROR • If A’s next-hop for C is B, A rebroadcasts • If S’s next-hop for C is A, S rebroadcasts • Floods ERROR to all nodes which use broken link Error: C A B C S D
References • David B. Johnson. Routing in Ad Hoc Networks of Mobile Hosts. WMCSA 1994. • Charles E. Perkins and Elizabeth M. Royer. Ad hoc On-Demand Distance Vector Routing. WMCSA 1999.
Broadcast Authentication • Broadcasts data over wireless network • Packet injection usually easy • Each receiver can verify data origin Alice M Sender M Dave M M Bob Carol Adapted from Adrian Perrig
Msg, MAC(K,Msg) Msg, MAC(K,Msg) Forged Msg, MAC(K, Forged Msg) MAC: Message Authentication Code (authentication tag) Authentication Needs Asymmetry Sender K K = shared key Alice K Bob K Adapted from Adrian Perrig
Digital Signatures Do Not Work • Signatures are expensive, e.g., RSA 1024: • High generation cost (~10 milliseconds) • High verification cost (~1 millisecond) • High communication cost (128 bytes/packet) • Very expensive on low-end processors • If we aggregate signature over multiple packets, intolerant to packet loss Adapted from Adrian Perrig
TESLA • Timed Efficient Stream Loss-tolerant Authentication • Uses only symmetric cryptography • Asymmetry via time • Delayed key disclosure • Requires loose time synchronization Adapted from Adrian Perrig
1: Verify K 2: Verify MAC 3: P Authentic! Basic Authentication Mechanism F: public one-way function P F(K) Authentic Commitment K disclosed MAC(K,P) t Adapted from Adrian Perrig
Security Condition • Receiver knows key disclosure schedule • Security condition (for packet P): on arrival of P, receiver is certain that sender did not yet disclose K • If security condition not satisfied, drop packet Adapted from Adrian Perrig
Authentication of P1: MAC(K5, P1 ) Authenticate K5 F F F F K3 K4 Verify MAC P2 K5 TESLA • Keys disclosed 2 time intervals after use • Receiver setup: Authentic K3, key disclosure schedule K5 K5 K6 K7 t Time 3 Time 4 Time 5 Time 6 Time 7 P1 K3 Adapted from Adrian Perrig
Authenticate K5 F F P3 P5 K3 K5 P1 P2 P4 Verify MACs K2 K2 K4 TESLA: Robust to Packet Loss K3 K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7 Adapted from Adrian Perrig
TESLA Summary • Low overhead • Communication (~ 20 bytes) • Computation (~ 1 MAC computation per packet) • Perfect robustness to packet loss • Independent of number of receivers • Delayed authentication • Extensions: • TIK: Instant key disclosure • Heterogeneous receivers • Instant authentication (sender buffers data) Adapted from Adrian Perrig
One-Time Signatures • Challenge: digital signatures expensive for generation and verification • Goal: amortize digital signature Adapted from Adrian Perrig
Use one-way functions without trapdoor Efficient for signature generation and verification Caveat: can only use one time Example: 1-bit one-time signature P0, P1 are public values (public key) S0, S1 are private values (private key) One-Time Signatures S0 P0 S0 S0’ P S1 P1 S1 S1’ Adapted from Adrian Perrig
Lamport’s One-Time Signature • Uses 1-bit signature construction to sign multiple bits S0 S0’ S0’’ S0* Sign 0 Private values P0 P0’ P0’’ P0* … Public values P1 P1’ P1’’ P1* S1 S1’ S1’’ S1* Sign 1 Private values Bit 0 Bit 1 Bit 2 Bit n Adapted from Adrian Perrig
Improved Construction I • Uses 1-bit signature construction to sign multiple bits c0 c0’ c0* S0 S0’ S0’’ S0* … … p0 p0’ p0* P0 P0’ P0’’ P0* Bit 0 Bit 1 Bit 2 Bit n Bit 0 Bit 1 Bit log(n) Sign message Checksum bits: encode # of signature bits = 0 Adapted from Adrian Perrig
Checksum chain C3 C2 C1 C0 P = F( S3 || C0 ) Improved Construction II • Lamport signature has high overhead • Goal: reduce size of public and private key • Approach: use one-way hash chains • S1 = F( S0 ) Sig(0) Sig(1) Sig(2) Sig(3) Signature chain S0 S1 S2 S3 P Adapted from Adrian Perrig
Merkle-Winternitz Construction • Intuition: encode sum of checksum chain Signature Bits 0,1 S0 S1 S2 S3 Signature Bits 2,3 S0’ S1’ S2’ S3’ Signature Bits 4,5 S0’’ S1’’ S2’’ S3’’ P Checksum Bits 0,1 C3 C2 C1 C0 Checksum Bits 2,3 C3’ C2’ C1’ C0’ Adapted from Adrian Perrig
SEAD Protocol Properties SEAD (Secure Efficient Ad hoc Distance vector): • Uses one-way hash chains to authenticate metric and sequence number • Assumes a limit k-1 on metric (as in other distance vector protocols such as RIP, where k=16) • Metric value infinity can be represented as k
SEAD Metric Authenticators • Each node generates a hash chain and distributes the last element (CN+1) to allow verification: • Chain values CN-k+1, …, CN authenticate metrics 0 through k-1 for sequence number 1 • CN-2k+1,…CN-k authenticate metrics 0 through k-1 for sequence number 2 • CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1 for sequence number i C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
SEAD Metric Authenticators • Each node generates a hash chain anddistributes the last element (CN+1) to allow verification: • Chain values CN-k+1, …, CN authenticate metrics 0 through k-1 for sequence number 1 • CN-2k+1,…CN-k authenticate metrics 0 through k-1 for sequence number 2 • CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1 for sequence number i C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
SEAD Metric Authenticators • Each node generates a hash chain and distributes the last element (CN+1) to allow verification: • Chain values CN-k+1, …, CN authenticate metrics 0 through k-1 for sequence number 1 • CN-2k+1,…CN-k authenticate metrics 0 through k-1 for sequence number 2 • CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1 for sequence number i C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
SEAD Metric Authenticators • Each node generates a hash chain and distributes the last element (CN+1) to allow verification: • Chain values CN-k+1, …, CN authenticate metrics 0 through k-1 for sequence number 1 • CN-2k+1,…CN-k authenticate metrics 0 through k-1 for sequence number 2 • CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1 for sequence number i C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
SEAD Metric Authenticators Within a sequence number i: • CN-ik+1 represents metric 0 • CN-ik+2 represents metric 1 • CN-ik+m+1 represents metric m • CN-ik+k represents metric k-1 • When a node receives a routing update: • It first checks the metric authenticator • If the update is to be accepted: • It increments the metric by one • and hashes the authenticator • then adds the metric and authenticator to routing table Metric 0 Metric 1 Metric 2 C9 C10 C11
Metric Authenticator Properties Given any authentic one-way hash chain value Ci: • Can compute later values Cj for j > i • Can authenticate earlier values Cj for j < i Thus, for SEAD metric authenticators: • Given an authenticator for some sequence number and metric, can generate authenticator for a new sequence number and metric if and only if: • The sequence number is lower, or • The sequence number is the same and metric is higher • Can authenticate any valid authenticator
SEAD Neighbor Authentication SEAD needs to know true source of routing updates D A B C
SEAD Neighbor Authentication SEAD needs to know true source of routing updates Simple example using all-pairs O(n2) shared keys: • Each node maintains a neighbor table • Node A adds node B when A hears advertisement directly from B with a fresh sequence number • Triggers A’s advertisement, which B hears directly from A • A and B begin to include symmetric authenticators (e.g., using HMAC) for each other in each update • Stop after missing 3 consecutive sequence numbers
B D A C Additional Optimizations in DSDV Weighted Settling Time: • Track average time (across multiple sequence numbers) between first route and best route • Delay advertisements by that amount • But allows attacker to “rush” routing data • Speeding the spread of broken route information: • Increment the sequence number when reporting an “infinite” metric • But SEAD cannot authenticate it
Loop-Freedom SEAD is loop-free unless anattacker is in the loop Correctness argument: • Suppose there is a loop • The (sequence number, metric) always gets strictly better at the next hop around loop unless: • The next hop is an attacker, or • The attacker forged the next-hop in the routing update • But next-hop in update is always authenticated • Therefore, the loop either terminates or there is an attacker in the loop
Metric 1 Metric 2 C3 C2 Security Properties • SEADisrobustagainstnon-collaboratingattackers: • Attackers cannot make a path longer by more than the number of attackers on the path A B E C C D C4 C3 C2 C1 Metric 0 Metric 1 Metric 2 Metric 3
Metric 0 C4 C4 B D Security Properties • Against collaborating attackers: • The number of hops from the source to the first attacker • plus the number of hops from the last attacker to the destination • cannot exceed length of the longest non-attacking path A B E C D C4 C3 C2 C1 Metric 0 Metric 1 Metric 2 Metric 3
SEAD Summary • SEAD provides practical security with only moderate network overhead and negligible computational requirements • SEAD actually outperforms DSDV-SQ (on some metrics) • SEAD has good loop-freedom properties: • As in DSDV, is loop-free in absence of attackers • Requires attacker to be in the loop to form a loop
Ariadne Overview • Secures DSR • Flexible key setup
Ariadne Authentication Requirements Can use any of three types of authentication: • Pairwise shared keys: • But requires setting up O(n2) keys • Digital signatures and asymmetric key setup: • But uses expensive asymmetric cryptography • Time-delayed broadcast authentication (TESLA): • But requires time synchronization Ariadne requires only one of these types: • Each appropriate for different circumstances
Attacks Secured by Ariadne Ariadne secures most severe attacks on DSR: • Excessive Route Discovery floods • Modifying discovered routes: • By dropping nodes • By altering the node list • Sending bogus ROUTE ERRORs • Failing to forward packets • Failing to send ROUTE ERROR for broken route
ROUTE REQUEST Flooding Attack On-demand protocols discover routes using flooding An attacker can use this to flood the network: • A solution: rate-limit Discoveries when forwarding • But attacker can forge claimed Discovery initiator ROUTE REQUEST “from A” ROUTE REQUEST “from B” ROUTE REQUEST “from C” X ROUTE REQUEST “from D” ROUTE REQUEST “from E”