1 Security and Misbehavior Handling in Wireless Ad Hoc Networks Nitin H. Vaidya University of Illinois at Urbana-Champaign [email protected] nhv

1

Security and Misbehavior Handling inWireless Ad Hoc Networks

Nitin H. Vaidya

University of Illinois at Urbana-Champaign

[email protected]

http://www.crhc.uiuc.edu/~nhv

© 2005 Nitin Vaidya

2

Notes Coverage not exhaustive. Only a few example schemes discussed

Only selected features of various schemes are typically discussed. Not possible to cover all details in this tutorial

Some protocol specs have changed over time, and the slides may not reflect the most current specifications

Jargon used to discuss a scheme may occasionally differ from that used in the original papers

Names in brackets, as in [Xyz00], refer to a document in the list of references

Abbreviation MAC used to mean either Medium Access Control or Message Authentication Code – implied meaning should be clear from context

3

Outline

Introduction to ad hoc networks Selected routing and MAC protocols Key management in wireless ad hoc networks Secure communication in ad hoc networks Misbehavior at the MAC layer Misbehavior at the network layer Anomaly detection

4

Mobile Ad Hoc Networks (MANET)

5

Mobile Ad Hoc Networks

Formed by wireless hosts which may be mobile

Without (necessarily) using a pre-existing infrastructure

Routes between nodes may potentially contain multiple hops

6


May need to traverse multiple links to reach a destination

AB

C

D

7

Mobile Ad Hoc Networks (MANET)

Mobility causes route changes

AB

C D

8

Why Ad Hoc Networks ?

Ease of deployment

Speed of deployment

Decreased dependence on infrastructure

9

Many Applications

Personal area networking cell phone, laptop, ear phone, wrist watch

Military environments soldiers, tanks, planes

Civilian environments taxi cab network meeting rooms sports stadiums boats, small aircraft

Emergency operations search-and-rescue policing and fire fighting

10

Many Variations

Fully Symmetric Environment all nodes have identical capabilities and responsibilities

Asymmetric Capabilities transmission ranges and radios may differ battery life at different nodes may differ processing capacity may be different at different nodes speed of movement

Asymmetric Responsibilities only some nodes may route packets some nodes may act as leaders of nearby nodes (e.g., cluster

head)

11

Many Variations

Traffic characteristics may differ in different ad hoc networks bit rate timeliness constraints reliability requirements unicast / multicast / geocast host-based addressing / content-based addressing /

capability-based addressing

May co-exist (and co-operate) with an infrastructure-based network

12

Many Variations

Mobility patterns may be different people sitting at an airport lounge New York taxi cabs kids playing military movements personal area network

Mobility characteristics speed predictability

• direction of movement

• pattern of movement uniformity (or lack thereof) of mobility characteristics among

different nodes

13

Challenges

Limited wireless transmission range Broadcast nature of the wireless medium

Hidden terminal problem (see next slide)

Packet losses due to transmission errors Mobility-induced route changes Mobility-induced packet losses Battery constraints Potentially frequent network partitions Ease of snooping on wireless transmissions (security

hazard)

14

Hidden Terminal Problem

B CA

Nodes A and C cannot hear each other

Transmissions by nodes A and C can collide at node B

Nodes A and C are hidden from each other

15

Research on Mobile Ad Hoc Networks

Variations in capabilities & responsibilities

X

Variations in traffic characteristics, mobility models, etc.

X

Performance criteria (e.g., throughput, energy, security)

=

Significant research activity

16

The Holy Grail

A one-size-fits-all solution Perhaps using an adaptive/hybrid approach that can adapt

to situation at hand

Difficult problem

Many solutions proposed trying to address a

sub-space of the problem domain

17

Outline


18

Unicast Routingin


19

Why is Routing in MANET different ?

Host mobility link failure/repair due to mobility may have different

characteristics than those due to other causes

Rate of link failure/repair may be high when nodes move fast

New performance criteria may be used route stability despite mobility energy consumption

20

Unicast Routing Protocols

Many protocols have been proposed

Some have been invented specifically for MANET

Others are adapted from previously proposed protocols for wired networks

No single protocol works well in all environments some attempts made to develop adaptive protocols

21

Routing Protocols

Proactive protocols Determine routes independent of traffic pattern Traditional link-state and distance-vector routing protocols

are proactive

Reactive protocols Maintain routes only if needed

Hybrid protocols

22

Trade-Off

Latency of route discovery Proactive protocols may have lower latency since routes are

maintained at all times Reactive protocols may have higher latency because a route from

X to Y may be found only when X attempts to send to Y

Overhead of route discovery/maintenance Reactive protocols may have lower overhead since routes are

determined only if needed Proactive protocols can (but not necessarily) result in higher

overhead due to continuous route updating

Which approach achieves a better trade-off depends on the traffic and mobility patterns

23

Reactive Routing Protocols

24

Routing Protocols

Proactive protocols for ad hoc networks are often derived from link state or distance vector routing protocols

But with some optimizations

We will not discuss proactive protocols in detail

Before discussing an example reactive protocol, let us consider “flooding” as a routing protocol

25

Flooding for Data Delivery

Sender S broadcasts data packet P to all its neighbors

Each node receiving P forwards P to its neighbors

Sequence numbers used to avoid the possibility of forwarding the same packet more than once

Packet P reaches destination D provided that D is reachable from sender S

Node D does not forward the packet

26


B

A

S E

F

H

J

D

C

G

IK

Represents that connected nodes are within each other’s transmission range

Z

Y

Represents a node that has received packet P

M

N

L

27


B

A

S E

F

H

J

D

C

G

IK

Represents transmission of packet P

Represents a node that receives packet P forthe first time

Z

YBroadcast transmission

M

N

L

28


B

A

S E

F

H

J

D

C

G

IK

• Node H receives packet P from two neighbors: potential for collision

Z

Y

M

N

L

29


B

A

S E

F

H

J

D

C

G

IK

• Node C receives packet P from G and H, but does not forward it again, because node C has already forwarded packet P once

Z

Y

M

N

L

30


B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

• Nodes J and K both broadcast packet P to node D• Since nodes J and K are hidden from each other, their transmissions may collide Packet P may not be delivered to node D at all, despite the use of flooding

N

L

31


B

A

S E

F

H

J

D

C

G

IK

Z

Y

• Node D does not forward packet P, because node D is the intended destination of packet P

M

N

L

32


B

A

S E

F

H

J

D

C

G

IK

• Flooding completed

• Nodes unreachable from S do not receive packet P (e.g., node Z)

• Nodes for which all paths from S go through the destination D also do not receive packet P (example: node N)

Z

Y

M

N

L

33


B

A

S E

F

H

J

D

C

G

IK

• Flooding may deliver packets to too many nodes (in the worst case, all nodes reachable from sender may receive the packet)

Z

Y

M

N

L

34

Flooding for Data Delivery: Advantages

Simplicity

May be more efficient than other protocols when rate of information transmission is low enough that the overhead of explicit route discovery/maintenance incurred by other protocols is relatively higher this scenario may occur, for instance, when nodes transmit small

data packets relatively infrequently, and many topology changes occur between consecutive packet transmissions

Potentially higher reliability of data delivery Because packets may be delivered to the destination on multiple

paths

35

Flooding for Data Delivery: Disadvantages

Potentially, very high overhead Data packets may be delivered to too many nodes who do

not need to receive them

Potentially lower reliability of data delivery Flooding uses broadcasting -- hard to implement reliable

broadcast delivery without significantly increasing overhead– Broadcasting in IEEE 802.11 MAC is unreliable

In our example, nodes J and K may transmit to node D simultaneously, resulting in loss of the packet

– in this case, destination would not receive the packet at all

36

Flooding of Control Packets

Many protocols perform (potentially limited) flooding of control packets, instead of data packets

The control packets are used to discover routes

Discovered routes are subsequently used to send data packet(s)

Overhead of control packet flooding is amortized over data packets transmitted between consecutive control packet floods

Several protocols based on this (Examples: DSR, AODV)

37

Dynamic Source Routing (DSR) [Johnson96]

When node S wants to send a packet to node D, but does not know a route to D, node S initiates a route discovery

Source node S floods Route Request (RREQ)

Each node appends own identifier when forwarding RREQ

38

Route Discovery in DSR

B

A

S E

F

H

J

D

C

G

IK

Z

Y

Represents a node that has received RREQ for D from S

M

N

L

39


B

A

S E

F

H

J

D

C

G

IK

Represents transmission of RREQ

Z

YBroadcast transmission

M

N

L

[S]

[X,Y] Represents list of identifiers appended to RREQ

40


B

A

S E

F

H

J

D

C

G

IK

• Node H receives packet RREQ from two neighbors: potential for collision

Z

Y

M

N

L

[S,E]

[S,C]

41


B

A

S E

F

H

J

D

C

G

IK

• Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ once

Z

Y

M

N

L

[S,C,G]

[S,E,F]

42


B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

• Nodes J and K both broadcast RREQ to node D• Since nodes J and K are hidden from each other, their transmissions may collide

N

L

[S,C,G,K]

[S,E,F,J]

43


B

A

S E

F

H

J

D

C

G

IK

Z

Y

• Node D does not forward RREQ, because node D is the intended target of the route discovery

M

N

L

[S,E,F,J,M]

44


Destination D on receiving the first RREQ, sends a Route Reply (RREP)

RREP is sent on a route obtained by reversing the route appended to received RREQ

RREP includes the route from S to D on which RREQ was received by node D

45

Route Reply in DSR

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

RREP [S,E,F,J,D]

Represents RREP control message

46

Route Reply in DSR

Route Reply can be sent by reversing the route in Route Request (RREQ) only if links are guaranteed to be bi-directional To ensure this, RREQ should be forwarded only if it received on a link

that is known to be bi-directional

If unidirectional (asymmetric) links are allowed, then RREP may need a route discovery for S from node D Unless node D already knows a route to node S If a route discovery is initiated by D for a route to S, then the Route

Reply is piggybacked on the Route Request from D.

If IEEE 802.11 MAC is used to send data, then links have to be bi-directional (since Ack is used)

47

Dynamic Source Routing (DSR)

Node S on receiving RREP, caches the route included in the RREP

When node S sends a data packet to D, the entire route is included in the packet header hence the name source routing

Intermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded

48

Data Delivery in DSR

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

DATA [S,E,F,J,D]

Packet header size grows with route length

49

When to Perform a Route Discovery

When node S wants to send data to node D, but does not know a valid route node D

50

Route Error (RERR)

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

RERR [J-D]

J sends a route error to S along route J-F-E-S when its attempt to forward the data packet S (with route SEFJD) on J-D fails

Nodes hearing RERR update their route cache to remove link J-D

51

Unicast Routing Protocols

We will use DSR as the example routing protocol in much of our discussion

52

Outline


53

Medium Access Control Protocols

54

Medium Access Control

Wireless channel is a shared medium

Need access control mechanism to avoid interference

MAC protocol design has been an active area of research for many years [Chandra00]

55

MAC: A Simple Classification

WirelessMAC

Centralized Distributed

Guaranteedor

controlledaccess

RandomaccessIEEE 802.11

56

A B C

Hidden Terminal Problem

Node B can communicate with A and C both A and C cannot hear each other

When A transmits to B, C cannot detect the transmission using the carrier sense mechanism

If C transmits, collision will occur at node B

57

MACA Solution for Hidden Terminal Problem [Karn90]

When node A wants to send a packet to node B, node A first sends a Request-to-Send (RTS) to A

On receiving RTS, node A responds by sending Clear-to-Send (CTS), provided node A is able to receive the packet

When a node (such as C) overhears a CTS, it keeps quiet for the duration of the transfer Transfer duration is included in RTS and CTS both

A B C

58

Reliability

Wireless links are prone to errors. High packet loss rate detrimental to transport-layer performance.

Mechanisms needed to reduce packet loss rate experienced by upper layers

59

A Simple Solution to Improve Reliability

When node B receives a data packet from node A, node B sends an Acknowledgement (Ack). This approach adopted in many protocols [Bharghavan94,IEEE 802.11]

If node A fails to receive an Ack, it will retransmit the packet

A B C

60

IEEE 802.11 Wireless MAC

Distributed and centralized MAC components

Distributed Coordination Function (DCF) Point Coordination Function (PCF)

DCF suitable for multi-hop ad hoc networking

DCF is a Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) protocol

61

IEEE 802.11 DCF

Uses RTS-CTS exchange to avoid hidden terminal problem Any node overhearing a CTS cannot transmit for the

duration of the transfer

Uses ACK to achieve reliability

Any node receiving the RTS cannot transmit for the duration of the transfer To prevent collision with ACK when it arrives at the sender When B is sending data to C, node A will keep quite

A B C

62

Collision Avoidance

CSMA/CA: Wireless MAC protocols often use collision avoidance techniques, in conjunction with a (physical or virtual) carrier sense mechanism

Carrier sense: When a node wishes to transmit a packet, it first waits until the channel is idle.

Collision avoidance: Nodes hearing RTS/CTS stay silent for specified duration. Once channel becomes idle, the node waits for a randomly chosen duration before attempting to transmit.

63

C FA B EDRTS

RTS = Request-to-Send

IEEE 802.11

Pretending a circular range

64

C FA B EDRTS

RTS = Request-to-Send

IEEE 802.11

NAV = 10

NAV = remaining duration to keep quiet

65

C FA B EDCTS

CTS = Clear-to-Send

IEEE 802.11

66

C FA B EDCTS

CTS = Clear-to-Send

IEEE 802.11

NAV = 8

67

C FA B EDDATA

•DATA packet follows CTS. Successful data reception acknowledged using ACK.

IEEE 802.11

68

IEEE 802.11

C FA B EDACK

69

C FA B EDACK

IEEE 802.11

Reserved area(not necessarilycircular inpractice)

70

Backoff Interval

Backoff intervals used to reduce collision probability

When transmitting a packet, choose a backoff interval in the range [0,cw] cw is contention window

Count down the backoff interval when medium is idle Count-down is suspended if medium becomes busy

When backoff interval reaches 0, transmit RTS

71

IEEE 802.11 DCF Example

data

waitB1 = 5

B2 = 15

B1 = 25

B2 = 20

data

wait

B1 and B2 are backoff intervalsat nodes 1 and 2cw = 31

B2 = 10

72

Backoff Interval

The time spent counting down backoff intervals is a part of MAC overhead

Choosing a large cw leads to large backoff intervals and can result in larger overhead

Choosing a small cw leads to a larger number of collisions (when two nodes count down to 0 simultaneously)

73

Since the number of nodes attempting to transmit simultaneously may change with time, some mechanism to manage contention is needed

IEEE 802.11 DCF: contention window cw is chosen dynamically depending on collision occurrence

74

Binary Exponential Backoff in DCF

When a node fails to receive CTS in response to its RTS, it increases the contention window cw is doubled (up to an upper bound)

When a node successfully completes a data transfer, it restores cw to Cwmin

cw follows a sawtooth curve

75

Security and Misbehavior

76

Issues

Hosts may be misbehave or try to compromise security at all layers of the protocol stack

77

Transport Layer(End-to-End Communication)

How to secure end-to-end communication?

Need to know keys to be used for secure communication

May want to anonymize the communication

78

Network Layer

Misbehaving hosts may create many hazards

May disrupt route discovery and maintenance:Force use of poor routes (e.g., long routes)

Delay, drop, corrupt, misroute packets

May degrade performance by making good routeslook bad

79

MAC Layer

Disobey protocol specifications for selfish gains

Denial-of-service attacks

80

Scope of this Tutorial

Overview of selected issues at various protocol layers

Not an exhaustive survey of all relevant problems or solutions

81

Outline


82

Key Management

83

Key Management

In “pure” ad hoc networks, access to infrastructure cannot be assumed

Network may also become partitioned

In “hybrid” networks, however, if access to infrastructure is typically available, traditional solutions can be extended with relative ease

84

Certification Authority

Certification Authority (CA) has a public/private key pair, with public key known to all

CA signs certificate binding public keys to other nodes

A single CA may not be enough – unavailability of the CA (due to partitioning, failure or compromise) will make it difficult for nodes to obtain public keys of other hosts

A compromised CA may sign erroneous certificates

85

Distributed Certification Authority [Zhou99]

Use threshold cryptography to implement CA functionality jointly at n nodes. The n CA servers collectively have a public/private key pair

Each CA only knows a part of the private key Can tolerate t compromised servers

Threshold cryptography: (n,t+1) threshold cryptography scheme allows n parties to share the ability to perform a cryptographic operation (e.g., creating a digital signature)

Any (t+1) parties can perform the operation jointly No t or fewer parties can perform the operation

86

Distributed Certification Authority [Zhou99]

Each server knows public key of other servers, so that the servers can communicate with each other securely

To sign a certificate, each server generates a partial signature for the certificate, and submits to a combiner

To protect against a compromised combiner, use t+1 combiners

87

Self-Organized Public Key Management [Capkun03]

Does not rely on availability of CA

Nodes form a “Certificate Graph” each vertex represents a public key

an edge from Ku to Kw exists if there is a certificate signed by the private key of node u that binds Kw to the identity of some node w.

Ku Kw

(w,Kw)Pr Ku

88

Self-Organized Public Key Management [Capkun03]

Four steps of the management scheme

Step 1: Each node creates its own private/public keys.Each node acts independently

89

Self-Organized Public Key Management

Step 2: When a node u believes that key Kw belongs to node w, node u issues a public-key certificate in which Kw is bound to w by the signature of u

u may believe this because u and w may have talked on a dedicated channel previously

Each node also issues a self-signed certificate for its own key

Step 3: Nodes periodically exchange certificates with other nodes they encounter Mobility allows faster dissemination of certificates through the

network

90


Step 4: Each node forms a certificate graph using the certificates known to that node

Authentication: When a node u wants to verify the authenticity of the public key Kv of node v, u tries to find a directed graph from Ku to Kv in the certificate graph. If such a path is found, the key is authentic.

91


Misbehaving hosts may issue incorrect certificates

If there are mismatching certificates, indicates presence of a misbehaving host (unless one of the mismatching certificate has expired) Mismatching certificates may bind same public key for two

different nodes, or same node to two different keys

To resolve the mismatch, a “confidence” level may be calculated for each certificate chain that verifies each of the mismatching certificates Choose the certificate that can be verified with high

confidence – else ignore both certificates

92

TESLA Broadcast Authentication [Perrig]

How to verify authenticity of broadcast packets? Use Message Authentication Code (MAC) for each

message, using a shared secret key But with broadcast, all receivers need to know the shared

key, and any of them can then impersonate the sender

Use digital signature with asymmetric cryptography Computationally expensive

Use asymmetric cryptography to bootstrap symmetric cryptography solution TESLA

93

TESLA

Uses one-way hash chains: Starting with initial value s0, use one-way function F to general a sequence of values s1 = F(s0), s2 = F(s1), … , sn = F(sn-1).

Knowing an earlier value in the chain, a latter value can be determined, but not vice-versa

Use the values in reverse order, starting from sn-1

Order of use opposite the order of generation

Distribute sn to all nodes with verifiable authenticity Use digital signature (this is the “bootstrap” step) Nodes need to know the source’s public key

94

TESLA

Messages sent during period i include Message Authentication Code (MAC) computed using another one-way function of si

The key si is revealed after a key disclosure delay of d intervals

On receiving a message in interval i, a node X waits for d-1 additional intervals for the key to be revealed)

When si is revealed, node X can verify that si+1 = F(si) to determine authenticity of si

95

TESLA

Authenticity of si can be determined so long as node X knows some sk with k>i Allows for loss of revealed keys during broadcast operation

Once a key is revealed, anyone can try to impersonate the sender using that key

To avoid this, TESLA assumes loose time synchronization Each receiver can place an upper bound on the sender’s clock The error needs to be small compared to key disclosure delay

96

TESLA

If impersonator I receives key si from source S first, and sends a packet to R impersonating S, R will find the packet valid only if The packet timestamp is smaller than the upper bound R

places on the time at S, and

Now, the upper bound when S sends key si will be at least i+d (since the key is not released until interval i+d)

So if R only accepts packets sent with timestamp i but received when the upper bound on S’s clock < i+d, there is no way an impersonator can pass above conditions (provided clock error small compared to d)

SR

I

97

TESLA

Advantage: Use of asymmetric cryptography required only initially (to distribute initial key using signatures)

Further communication uses MAC

Disadvantage: Messages can only be authenticated after delay d

98

Outline


99

Secure Communication

100


With the previously discussed mechanisms for key distribution, it is possible to authenticate the assignment of a public key to a node

This key can then be used for secure communication The public key can be used to set up a symmetric key

between a given node pair as well TESLA provides a mechanism for broadcast authentication

when a single source must broadcast packets to multiple receivers

101


Sometimes security requirement may include anonymity

Availability of an authentic key is not enough to prevent traffic analysis

We may want to hide the source or the destination of a packet, or simply the amount of traffic between a given pair of nodes

102

Traffic Analysis

Traditional approaches for anonymous communication, for instance, based on MIX nodes or dummy traffic insertion, can be used in wireless ad hoc networks as well

However, it is possible to develop new approaches considering the broadcast nature of the wireless channel

103

Mix Nodes [Chaum]

Mix nodes can reorder packets from different flows, insert dummy packets, or delay packets, to reduce correlation between packets in and packets out

M1 B M2 E

A

M3C

DG

F

104

Mix Nodes

Node A wants to send message M to node G. Node A chooses 2 Mix nodes (in general n mix nodes), say, M1 and M2

M1 B M2 E

A

M3C

DG

F

105

Mix Nodes

Node A transmits to M1message K1(R1, K2(R2, M)) where Ki() denotes encryption using public key Ki of Mix i, and Ri is a random number

M1 B M2 E

A

M3C

DG

F

106

Mix Nodes

M1 recovers K2(R2,M) and send to M2

M1 B M2 E

A

M3C

DG

F

107

Mix Nodes

M2 recovers M and sends to G

M1 B M2 E

A

M3C

DG

F

108

Mix Nodes

If M is encrypted by a secret key, no one other than G or A can know M

Since M1 and M2 “mix” traffic, observers cannot determine the source-destination pair without compromising M1 and M2 both

109

Alternative Mix Nodes

Suppose A uses M2 and M3 (not M1 and M2)

Need to take fewer hops

Choice of mix nodes affects overhead

M1 B M2 E

A

M3C

DG

F

110

Mix Node Selection

Intelligent selection of mix nodes can reduce overhead [Jiang04]

With mobility, the choice of mix nodes may have to be modified to reduce cost

However, change of mix selection has the potential for divulging more information

111

Traffic Mode Detection

Consider a node pair A and D. Depending on the “mode” of operation, the traffic rate from A to D is either R1 or R2.

To avoid detection of the mode, node A may always send at rate max (R1, R2) inserting dummy traffic if necessary [Venkatraman93]

This is an end-to-end approach, since it can be implemented entirely at source & destination of a flow

112


Now consider two flow A-D and E-F Mode 1: A-D rate R1 E-F rate R2

Mode 2: A-D rate R2 E-F rate R1 End-to-end cover: A-D and E-F both at rate max (R1,R2) Link BC carries traffic 2*max (R1,R2)

A B C D

E

F

Max(R1,R2)

Max(R1,R2) 2 * Max(R1,R2)

113


If we can encrypt link layer traffic in ad hoc networks, then a “link” cover mode can be used, such that each link carries fixed traffic independent of traffic mode

Reduces resource usage

A B C D

E

F

Max(R1,R2) on each link except BCR1+ R2 on link BC

114


Insertion of dummy traffic on a per-link basis “cheaper” than end-to-end [Radosavljevic92,Jiang01]

But need to take into account rates of different flows to determine suitable level of padding

Also, need link layer encryption to disallow differentiation of different flows at the link layer

115


Mode 1: A-D rate R1 E-F rate R2Mode 2: A-D rate R2 E-F rate R1

Need Max(R1,R2) on all links, since the two flows do not share links

Node B transmits 2 * Max(R1,R2) traffic

A B D

E

F

116


Node-level dummy packet insertion cheaper, if we can hide link-level receiver of the packets

Without the dummy traffic, node B forwards traffic R1+R2 independent of the mode

Node-level insertion: Maintain rates Max(R1,R2) at nodes A and E, and rate R1+R2 at node B

A B D

E

F

117


Node B needs to be able to remove dummy packets

Recipient of traffic from node B needs to be hidden

Additional mechanisms can be designed for this [Jiang05]

118

Outline


119

Misbehavior at the MAC Layer

120

MAC Layer Misbehavior

Wireless

channel

Wireless

channel

Access Point

A B

Nodes are required to follow Medium Access Control (MAC) rules

Misbehaving nodes may violate MAC rules

Wireless

channel

Wireless

channel

Access Point

C D

121

Example

We will illustrate MAC layer misbehavior with example misbehaviors that can occur with IEEE 802.11 DCF protocol

For ease of discussion, we sometimes refer to nodes communicating with an “access point”, but the discussion applies equally to nodes transmitting to any node in an ad hoc network acting as their receiver

122

Some Possible Misbehaviors

Causing collisions with other hosts’ RTS or CTS [Raya]

Those hosts will exponentially backoff on packet loss, giving free channel to the misbehaving host

123

Possible Misbehaviors:“Impatient” Transmitters

Smaller backoff intervals [Kyasanur]

Shorter Interframe Spacings [Raya]

124

“Impatient” Transmitters

Backoff from biased distribution

Example: Always select a small backoff value

Transmit

wait

B1 = 1

B2 = 20

Transmit

wait

B2 = 19

B1 = 1Misbehaving node

Well-behaved node

125

Impatient Transmitters

We will discuss the case of hosts that choose “too small” backoff intervals

But other cases of hosts waiting too little before talking can be handled analogously

126

Goals [Kyasanur03]

Diagnose node misbehavior Catch misbehaving nodes

Discourage misbehavior Punish misbehaving nodes

127

Potential Approaches

Watch idle times on the channel to detect when hosts wait too little

Design protocols that improve the ability to detect misbehavior

Protocols that discourage misbehavior [Konorski]

• Certain game-theoretic approaches

128

Passive Observation [Kyasanur03](Conceptually Simplest Solution)

802.11 dictates that each host must be idle for a certain duration between transmissions

The duration can be expressed as(K + v) where K is a constant, and v is chosen probabilistically from a certain distribution

K due to inter-frame spacing

v due to randomly chosen backoff intervals

129

Passive Observation

The observer can measure the idle time on the channel and determine whether the idle time is drawn from the above distribution

If the observed idle time is smaller than expected, then misbehavior can be detected [Kyasanur03]

[Cagalj05] presents an implementation based on this approach

130

Passive Observation

With this approach, a receiver can try to diagnose behavior of nodes trying to send packets to the receiver

Wireless channel

Wireless channel

Access Point

A

131

Issues

Wireless channel introduces uncertainties

Not all hosts see channel idle at the same time

AP1 sees channel busy, but A sees it as idle

Wireless channel

Wireless channel

AP 1

AWireless channel

Wireless channel

AP 2

B

132

Issues

Spatial channel variations bound the efficacy of misbehavior detection mechanisms

Many existing proposals ignore channel variation when performing evaluations, making the evaluations less reliable

133

Issues

Receiver does not know exact backoff value chosen by sender Sender chooses random backoff

Hard to distinguish between maliciously chosen small values and a legitimate value

134

Potential Solution:Use long-term statistics [Kyasanur]

Observe backoffs chosen by sender over multiple packets

Selecting right observation interval difficult

135

An Alternative Approach

Remove the non-determinism

136

An Alternative Approach

Receiver provides backoff values to sender Receiver specifies backoff for next packet in ACK for current

packet

Modification does not significantly change 802.11 behavior Backoffs of different nodes still independent

Uncertainty of sender’s backoff eliminated

137

Modifications to 802.11

• R provides backoff B to S in ACK

B selected from [0,CWmin]

DA

T

A

Sender S

Receiver R

CTS

AC

K(B

)

RTS

• S uses B for backoff

RTS

B

138

Protocol steps

Step 1: For each transmission: Detect deviations: Decide if sender backed off for less than

required number of slots Penalize deviations: Penalty is added, if the sender appears to

have deviated

Goal: Identify and penalize suspected misbehavior Reacting to individual transmission makes it harder for the

cheater to adapt to the protocol

139

Protocol steps

Step 2: Based on last W transmissions: Diagnose misbehavior: Identify misbehaving nodes

Goal: Identify misbehaving nodes with high probability Reduce impact of channel uncertainties Filter out misbehaving nodes from well-behaved nodes

140

Detecting deviations

Receiver counts number of idle slots Bobsr

Condition for detecting deviations: Bobsr < B (0 < <= 1)

Sender S

Receiver R

AC

K(B

) RTS

Backoff

Bobsr

141

Penalizing Misbehavior

When Bobsr < B, penalty P added

P proportional to B– Bobsr

AC

K(B

+P

)

CTS D

ATA

Total backoff assigned = B + P

Bobsr

Sender S

Receiver R

AC

K(B

)

RTS

Actual backoff < B

142

Penalty Scheme issues

Misbehaving sender has two options Ignore assigned penalty Easier to detect Follow assigned penalty No throughput gain

With penalty, sender has to misbehave more for same throughput gain

143

Diagnosing Misbehavior

Total deviation for last W packets used Deviation per packet is B – Bobsr

If total deviation > THRESH then sender is designated as misbehaving

Higher layers / administrator can be informed of misbehavior

144

Summary of Performance Results

Persistent misbehavior detected with high accuracy• Accuracy increases with misbehavior

Accuracy depends on channel conditions

Accuracy not 100% due to channel variations

145

Variations – Multiple Observers

In an ad hoc networks, a node can only diagnose, on its own, misbehavior by senders in its vicinity

Potential for error due to channel variations

Different hosts can cooperate to improve accuracy

Open problem: How to cooperate? How to “merge” information to arrive at a diagnosis?

146

Other Approaches

Game theory

Incentive-based mechanisms

147

MAC Selfishness: Game-Theoretic Approach

[MacKenzie] addresses selfish misbehavior in Aloha networks Nodes can choose arbitrary access probabilities Assign cost c for a transmission attempt

• Utility of a successful transmission = 1-c

• Utility of an unsuccessful transmission = -c

• Utility of no attempt = 0

MacKenzie’s contribution is to show that there exists a Nash equilibrium strategy

148

MAC: Selfishness

Others have also attempted game-theoretic solutions [Konorski,Cagalj05]

Limitation: Game-theoretic solutions (so far) assume that all hosts see identical channel state Not realistic Limits usefulness of solutions

149

Use payment schemes, charging per packet

Misbehaving hosts can get more throughput, but at a higher cost

• This solution does not ensure fairness

• Also, misbehaving node can achieve lower delay at no extra cost

• This suggests that per-packet payment is not enough

• Need to factor delay as well (harder)

Incentive-Based Mechanisms [Zhong02]

150

Outline


151

Network Layer Misbehavior

152

Network Layer Misbehavior

Many potential misbehaviors have been identified in various papers

We will discuss selected misbehaviors, and plausible solutions

153

Drop/Corrupt/Misroute

A node “agrees” to join a route(for instance, by forwarding route request in DSR)

but fails to forward packets correctly

A node may do so to conserve energy, or to launch a denial-of-service attack, due to failure of some sort, or because of overload

154

Watchdog Approach [Marti]

Verify whether a node has forwarded a packet or not

B DC EA

B sends packet to C

155

Watchdog Approach [Marti]

Verify whether a node has forwarded a packet or not B can learn whether C has forwarded packet or not B can also know whether packet is tampered with if no

per-link encryption

B DC EA

C forwards packet to D

B overhears CForwarding the packet

156

Watchdog Approach:Buffering & Failure Detection

Forwarding by C may not be immediate: B must buffer packets for some time, and compare them with overheard packets

• Buffered packet can be removed on a match

If packet stays in buffer at B too long, a “failure tally” for node C is incremented

If the failure rate is above a threshold, C is determined as misbehaving, and source node informed

157

Impact of Collisions

If A transmits while C is forwarding to D, A will not know

Failure tally at C is not reliable. Include a margin for such errors (which may be exploited by misbehaving hosts)

B DC EA


158

Reliability of Reception Not Known

Even if B sees the transmission from C, it cannot always tell whether D received the packet reliably

Misbehaving C may reduce power such that B can receive from C, but D does not (provided path loss to D is higher)

B DC EA


159

Channel Variations May Cause False Detection

If channel quality between B and C changes often, B may not overhear packets forwarded by C

This will increase C’s failure tally at B May cause false misbehavior accusation

B DC EA

160

Malicious Reporting

Host D may be a good node, but C may report that D is misbehaving

Source cannot tell whether this report is accurate

If the destination sends acknowledgement to source for the received packets, and if the forward-reverse routes are disjoint, this misbehavior (by C) may be caught

161

Collusion

If C forwards packets to D, but fails to report when D does not forward packets, the source node cannot determine who is misbehaving

B DC EA

Collusion hard to detect in many other schemes as well

162

Misdirection of Packets

C forwards packets, but to the wrong node! With DSR, B knows the next hop after C, so this

misbehavior may be detected

With other hop-by-hop forwarding protocols, B cannot detect this

B DC EA

F

163

Directional Transmissions

Directional transmissions make it difficult to use Watchdog

Power control for improved capacity or energy efficiency can create difficulties as well

B DC EA

B cannot hearC’s transmission to D

164

Watchdog + Pathrater [Marti]

“Pathrater” is run by each node. Each node assigns a rating to each known node Previously unknown nodes assigned “neutral” rating of 0.5 Rating assigned to nodes suspected of misbehaving are set

to large negative value Other nodes have positive ratings (between 0 and 0.8)

Ratings of well-behaved nodes increase over time up to a maximum So a temporary misbehavior can be overcome by sustained

good behavior

Routes with larger cumulative node ratings preferred

165

Watchdog: Summary

Can detect misbehaving hosts, although not always; false detection possible as well

Misbehaving hosts not punished

Effectively rewarded, by not sending any more traffic through them

Potential modification: Punishment could be to not forward any traffic from the misbehaving hosts

166

Hosts Bearing Grudges:CONFIDANT Protocol [Buchegger]

Motivated by “The Selfish Gene” by Dawkins (1976)

Consider three types of birds “Suckers” – Birds that always groom parasites off other

birds’ heads “Cheats” – Birds that never help other birds “Grudgers” – Birds that do not help known cheaters

If bird population starts out with only suckers and cheats, both categories become extinct over time

If bird population contains grudgers, eventually they dominate the population, and others become extinct

167

Hosts Bearing Grudges

Applying the “grudgers” concept to ad hoc networks

Each node determines whether its neighbor is misbehaving

• Similar to the previous scheme

A node ALARMs its “friends” when a misbehaving hosts is detected

Each node maintains reputation ratings for other nodes that are reduced on receipt of ALARMs

Ratings improve with time – a cheater can rehabilitate itself

168

Hosts Bearing Grudges: Issues

How to decide on friends?

What if “friends” cheat?

169

Hosts Bearing Grudges: Summary

Reputation-based scheme

Nodes prefer to route through & for nodes with higher reputation

Interesting concept, but cannot circumvent the difficulties in diagnosing misbehavior accurately

170

Exploiting Path Redundancy [Xue04]

Design routing algorithms that can deliver data despite misbehaving nodes

“Tolerate” misbehavior by using disjoint routes

Prefer routes that deliver packets at a higher “delivery ratio”

171

Exploiting Path Redundancy

Alternate routes: AFGE, ABCDE, ABFGE, ABCGE

B D

GE

A

F

C

172

Exploiting Path Redundancy

Misbehaving host F drops packets Delivery ratio poor on routes AFGE, ABFGE,

better on ABCDE, ABCGE

B D

GE

A

F

C

173

Best-Effort Fault Tolerant Routing (BFTR)– Modified DSR [Xue04]

The target of a route discovery is required to send multiple route replies (RREP)

The source can discover multiple routes (all are deemed feasible initially)

(1) The source chooses a feasible route based on the “shortest path” metric

(2) The source uses this route until its delivery ratio falls below a threshold (making the route infeasible)

(3) If existing route is deemed infeasible, go to (1)

174

BFTR: Issues

A route may look infeasible due to temporary overload on that route

The source may settle on a poorer (but feasible) route

No direct mechanism to differentiate misbehavior from lower capacity routes

This is both an advantage, and a potential shortcoming

175

Information Dispersal [Rabin89]

Map the N bit information F to n pieces, each N/m in size, such that any m pieces suffice to reconstruct original information

• Total size = n/m * N

Divide information F into N/m sequences of length m

S1 = (b1, …, bm)

S2 = (bm+1, …, b2m)

…

176

Information Dispersal

Choose n vectors ai = (ai1, …, aim)

Such that any set of m different vectors arelinearly independent

Let Fi = (ci1, ci2, …, ciN/m) 1<= i <= n

where cik = ai . Sk

Example: ci1 = ai.b1 + ai2.b2 + … + aim . bm

177

Information Dispersal [Rabin89]

Given m pieces, say, F1, …, Fm, we can reconstruct F as follows

Let A = (aij) 1<=i,j<= m

A . Sk’ = (c11, c21, …, cm1)’ ’ denotes transpose

Thus, knowing A and Fi= (ci1, ci2, …, ciN/m),we can recover S

178

Information Dispersal to Tolerate Misbehavior [Papadimitratos03]

Choose n node-disjoint paths to send the n pieces of information

Use a route rating scheme (based on delivery ratios) to select the routes

Acknowledgements for received pieces are sent

The missing pieces retransmitted on other routes

Need to be able to detect whether packets are tampered with

179

Route Tampering Attack

A node may make a route appear too long or too short by tampering with RREQ in DSR

By making a route appear too long, the node may avoid the route from being used This would happen if the destination replies to multiple

RREQ in DSR

By making a route appear too short, the node may make the source use that route, and then drop data packets (denial of service)

180

Node Insertion

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

[S,E,P,Q,F]

[S,E]

181

Node Deletion

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

[S,G,K][S,C,G]

182

Route Tampering Attack

Useful to allow detection of route tampering

Solution:

Protect route accumulated in RREQ from tampering

Removal or insertion of nodes should both be detected

183

Ariadne [Hu]: Detecting Route Tampering

Source-Destination S-D pairs share secret keys Ksd and Kds for each direction of communication

One-way hash function H available

MAC = Message Authentication Code (MAC) computed using MAC keys

184

Ariadne [Hu]: Detecting Route Tampering

Let RREQ’ denote the RREQ that would have been sent in unmodified DSR

Source S broadcasts RREQ = RREQ’,h0,[]where h0 = HMACKsd(RREQ’)

When a node X receives anRREQ = (RREQ’, hi, [m list])

it broadcasts RREQ, mi+1

where RREQ = (RREQ’, hi+1, [m list]), mi+1

where hi+1 = H(X, hi) and mi+1=HMACKx(RREQ)

185

Ariadne

If D receives an RREQ that came via route S, A, B, C, then D should have receivedh = H(C, H(B, H(A, HMACKsd(initial RREQ’))))

Knowing H and Ksd, and the node identifiers appended in the RREQ, D can verify accuracy of received h

Relies on the inability to invert function H

A mismatch indicates tampering with h or node list

A match indicates that the h value corresponds to the node-listNot enough to know whether the node-list is accurate

If no tampering detected in h, send RREP including node-list and m-list, and HMAC for this information

186

Ariadne

Node D sends the RREP to node C (first node on reverse route)

Node C forwards to the next node towards the source, but also appends its key Kc to the message One key used per route discovery (TESLA mechanism).

S can verify authenticity of this key Alternate mechanisms: Use pair-wise shared secret keys, or

signatures using authentic public keys

Node S receives all the keys, and also the m-list in RREP

S can verify that all m values in the m-list are accurate, in addition to the HMAC computed by D

If all check out, then no tampering, else discard RREP

187

Ariadne

If HMAC checks, then no one tampered with the node-list and m-list in the RREP

If m-list checks, then the m values were computed by legitimate nodes when RREQ forwarded

If all OK, accept RREP

Use of m-list ensures that a host cannot tamper with the RREP Route in RREP is the route taken by RREQ and RREP

188

Ariadne: Issues

Ensuring that RREQ and RREP follow the known route does not ensure that the nodes on the route will deliver packets correctly

So this is not a sufficient solution (and some might argue, not necessary!)

189

Wormhole Attack [Hu]

In this attack, the attacker makes a wireless “link” appear in the network when there isn’t one

The attacker may achieve this by using an out-of-band channel, or a channel that cannot be detected by other hosts

Not necessarily detrimental, since the additional link can improve performance

But the attacker may cause the network to funnel traffic through this link, giving the attacker control on the fate of the traffic

190


Host X can forward packets from F and E unaltered Hosts F and E will seem “adjacent” to each other

B D

XE

A

F

C

191


With DSR, RREQ via AFXE will likely arrive at E soonest The RREQ will contain route AFE

When RREP from E reaches A, it will start using AFE The fact that AFE really is AFXE will not be detected

B D

XE

A

F

C

192


With DSR, RREQ via AFXE will likely arrive at E soonest The RREQ will contain route AFE

When RREP from E reaches A, it will start using AFE The fact that AFE really is AFXE will not be detected

B D

XE

A

F

C

193


Subsequently when A sends data along AFE, node X will not forward the data to E

B D

XE

A

F

C

194

Wormhole Attack: Issues

Not that simple to launch an undetected wormhole attack

If node F can “see” someone else sending packets with F specified as sender, the attack is detected Transmissions from X must be invisible to F

B D

XE

A

F

C

195


Transmissions from X must be invisible to F Use directional transmissions at X to forward packets Difficult for X to guarantee that F will not see its

transmissions (depends on beamforms, multipath)

B D

XE

A

F

C

196


Transmissions from X must be invisible to F Out-of-band collusion between two attackers X and Y Difficult for Y to guarantee that F will not see its

transmissions

B D

XE

A

F

C

Y

197


Timing: F may expect an “immediate ACK” In the absence of authentication, X can ACK packets

to F without having delivered them to E With authentication, this is difficult

B D

XE

A

F

C

198

Timing Issue

Alternatively, the attacker must be able to forward bits as soon as it starts receiving them from F X transmits to E while receiving from F on the same channel

If no delays introduced, E and F may not detect the attack

B D

XE

A

F

C

199

Detected Attack

If timing issue cannot be resolved by the attacker ….

If X cannot deliver a timely ACK, the link E F will appear broken to E (because no ACK when expected)

Thus, even though E appears to receive RREQ from F, it cannot deliver packets to F

The attack will make the link F-E seem unidirectional (unreliable broadcast from F to E works, but not reliable unicast from E to F).

Mechanisms to handle unidirectional links (“blacklist”) can potentially suffice

200

Other Detection Mechanisms:Geographical Leashes

Geographical Leashes: Each transmission from a host should be allowed to propagate over a limited distance

If E and F are too far, F should reject packets that seem to be transmitted by E, even if received reliably

Need an estimate of distance between E and F (GPS locations + mobility during packet transmission)

201

Geographical Leashes [Hu]

Difficulty: Packets may travel along non line-of-sight paths Hard to predict the actual “distance” traveled by the

transmissions

Difficulty: A related problem is that physically close hosts may not be able to communicate directly (because of obstacles) The attacker may still introduce a tunnel (wormhole)

between these hosts However, the attacker needs the information that the two

hosts cannot see each other – difficult to get this information

202

Temporal Leashes

Assume tight clock synchronization (e.g., GPS)

Sender timestamps the packet, and receiver determines the delay since the packet was sent

If delay too large, reject the packet

The timestamps must be protected by some authentication mechanism or signature

203

Wormhole Attack: Summary

Not clear that this attack is easy to launch undetected

• The attacker needs knowledge of propagation to be sure of avoiding detection

Solutions dealing with unidirectional links may suffice in some cases

204

Outline


205

Anomaly Detection

206

Anomaly Detection

Anomaly detection: Detect deviation from “normal” behavior Need to characterize “normal” Normal behavior hard to characterize accurately Need to be able to determine when observed behavior

departs significantly from the norm Avoid false positives

The MAC layer approach for detecting deviation from “normal” distribution of contention window parameters can be considered an “anomaly detection” scheme

207

Anomaly Detection in Ad Hoc Networks [Zhang00]

Anomaly detection may also be useful at other layers, particularly, network layer

How to characterize “normal” routing protocol behavior?

Some of the routing mechanisms we discussed earlier do detect specific forms of abnormal behavior, but a more generic approach is desired

Can we design a protocol-independent anomaly detection mechanism? Not clear

208

Anomaly Detection

We limit our discussion here

Wireless harder than wired networks due to spatial and temporal variations

209

Conclusions

210

Conclusion

Security an important consideration for widespread deployment of wireless ad hoc networks

We discussed a sampling of topics in security and misbehavior in ad hoc networks

Some issues are similar to those in wired networks

The differences from wired network arise due to Shared nature of the wireless channel with variations over

space/time Inability to rely on access to “infrastructure” Ease of intrusion (relative to wired networks)

211

Conclusion

A lot of interesting research ongoing

One concern is that not all attacks are equally likely Attackers will typically go after the weakest feature

Nevertheless an important area of research with potential for future applications

212

Some Relevant Conferences/Workshops

ACM Wireless Security Workshop (WiSe) – held at ACM MobiCom last few years

Traditional security conferences (Security and Privacy, DSN, etc.)

Networking conferences: ACM MobiCom, ACM MobiHoc, IEEE INFOCOM, etc.

213

Thanks!

www.crhc.uiuc.edu/wireless

[email protected]

214

References

[Bharghavan94] MACAW: A Media Access Protocol for Wireless LANs, Vaduvur Bharghavan, Alan Demers, Scott Shenker, Lixia Zhang, SIGCOMM, 1994

[Buchegger] S. Buchegger and J. Le Boudec, Nodes Bearing Grudges: Towards Routing, Security, Fairness, and Robustness in Mobile Ad Hoc Networks,' in Proceedings of the Tenth Euromicro Workshop on Parallel, Distributed and Network-based Processing, IEEE Computer Society, January 2002.

[Cagalj05] M. Cagalj, S. Ganeriwal, I. Aad, and J. P. Hubaux : On Selfish Behavior in CSMA/CA Ad Hoc Networks, to appear at Infocom 20

[Capkun93] S. Capkun, L. Buttyan, and J. P. Hubaux, "Self-Organized Public-Key Management for Mobile Ad Hoc Networks“ IEEE Transactions on Mobile Computing, Vol. 2, Nr. 1 (January - March 2003)

[Chandra00] A. Chandra, V. Gummalla, and J. O. Limb, "Wireless Medium Access Control Protocols," IEEE Commun. Surveys [online], available at: http://www.comsoc.org/pubs/surveys, 2nd Quarter 2000.

[Chandra00] A. Chandra, V. Gummalla, and J. O. Limb, "Wireless Medium Access Control Protocols," IEEE Commun. Surveys [online], available at: http://www.comsoc.org/pubs/surveys, 2nd Quarter 2000.

[Chaum] D. Chaum, Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", Communications of the ACM, 1981.

[IEEE 802.11] IEEE 802.11 Specification, IEEE

215

References

[Hu02] Y. Hu, A. Perrig, and D. Johnson, ``Ariadne: A secure on-demand routing protocol for ad hoc networks,'' in The 8th ACM International Conference on Mobile Computing and Networking, MobiCom 2002, pp.~12--23, September 2002.

[Hu03] Y.-C. Hu, A. Perrig, and D. B. Johnson, ``Packet leashes: A defense against wormhole attacks in wireless networks,'' in Proceedings of IEEE INFOCOM'03, (San Francisco, CA), April 2003.

[Jiang04] S. Jiang, N. H. Vaidya and W. Zhao, A Mix Route Algorithm for Mix-Net in Wireless Ad Hoc Networks, IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS), October 2004.

[Jiang01] S. Jiang, N. H. Vaidya, W. Zhao, Preventing traffic analysis in packet radio networks, DISCEX 2001.

[Jiang05] S. Jiang, N. H. Vaidya, W. Zhao, in preparation, 2005 [Johnson] David B. Johnson and David A. Maltz. Protocols for Adaptive Wireless

and Mobile Networking, IEEE Personal Communications, 3(1):34-42, February 1996.

[Karn90] MACA - A New Channel Access Method for Packet Radio. Appeared in the proceedings of the 9th ARRL Computer Networking Conference, London, Ontario, Canada, 1990

[Konorski] J. Konorski, Multiple access in ad-hoc wireless LANs with noncooperative stations, NETWORKING 2002

216

References

[Kyasanur], Pradeep Kyasanur and N. H. Vaidya, Selfish MAC Layer Misbehavior in Wireless Networks, to appear in the IEEE Transactions on Mobile Computing.

[Kyasanur03] P. Kyasanur and N. H. Vaidya, Detection and Handling of MAC Layer Misbehavior in Wireless Networks, Dependable Computing and Communications Symposium (DCC) at the International Conference on Dependable Systems and Networks (DSN) , June 2003.

[Papadimitratos03] Papadimitratos and Haas, Secure message transmission in mobile ad hoc networks, Ad Hoc Networks journal, 2003.

[Perrig] A. Perrig, TESLA Project, http://www.ece.cmu.edu/~adrian/tesla.html. [Rabin89] M. O. Rabin, Efficient dispersal of information for security, load

balancing, and fault tolerance, J. ACM 38, 335-348 (1989) [Marti00] S. Marti, T. J. Giuli, K. Lai, and M. Baker, ``Mitigating routing

misbehavior in mobile ad hoc networks,'' in ACM International Conference on Mobile Computing and Networking (MobiCom), pp. 255--265, 2000.

[Radosavljevic92] B. Radosavljevic, B. Hajek, Hiding traffic flow in communication networks, MILCOM 1992.

217

References

[Raya] M. Raya, J.-P. Hubaux, and I. Aad, `DOMINO: A System to Detect Greedy Behavior in IEEE 802.11 Hotspots.,'' in Proceedings of ACM MobiSys, Boston - MA, 2004

[Venkatraman93] B. R. Venkatraman and N. E. Newman-Wolfe, Transmission schedules to prevent traffic analysis, Ninth Annual Computer Security and Applications Conferences, 1993.

[Xue04] Yuan Xue and Klara Nahrstedt, "Providing Fault-Tolerant Ad-hoc Routing Service in Adversarial Environments," in Wireless Personal Communications, Special Issue on Security for Next Generation Communications, Kluwer Academic Publishers, vol 29, no 3-4, pp 367-388, 2004

[Zhong02] Sprite: A Simple, Cheat-Proof, Credit-Based System for Mobile Ad-Hoc Networks, Infocom 2003

[Zhou99] Securing Ad Hoc Networks, Lidong Zhou, Zygmunt J. Haas, IEEE Network, 1999

Documents

1 Security and Misbehavior Handling in Wireless Ad Hoc Networks Nitin H. Vaidya University of Illinois at Urbana-Champaign [email protected] nhv