1 mobile ad hoc networks: protocols and security issues nitin h. vaidya university of illinois at...

1

Mobile Ad Hoc Networks: Protocols and Security Issues

Nitin H. VaidyaUniversity of Illinois at Urbana-Champaign

[email protected]://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

Time Constraint

Given the half-day duration of this DSN 2005 tutorial, some of the slides in this set of 300+ slides will not be actually discussed during the presentation The slides are included in the handout as a reference for the

attendees

4

Outline

Introduction to ad hoc networks Selected routing protocols Selected MAC protocol mechanisms Security and misbehavior

Key management in wireless ad hoc networks Secure communication in ad hoc networks MAC layer issues Network layer issues

Related activities References

5

Mobile Ad Hoc Networks (MANET)

6

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

7


May need to traverse multiple links to reach a destination

AB

C

D

8

Mobile Ad Hoc Networks (MANET)

Mobility causes route changes

AB

C D

9

Why Ad Hoc Networks ?

Ease of deployment

Speed of deployment

Decreased dependence on infrastructure

10

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

11

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)

12

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

13

Many Variations

Mobility pattern/characteristics may be different Application domain

– people sitting at an airport lounge– New York taxi cabs– Kids playing– Military movements– personal area network

speed predictability

– direction of movement– pattern of movement

uniformity (or lack thereof) of mobility characteristics among different nodes

14

Challenges

Limited wireless transmission range Broadcast nature of the wireless medium 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)

15

Research on Mobile Ad Hoc Networks

Variations in capabilities & responsibilities XVariations in traffic characteristics, mobility models, etc. XPerformance 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 asub-space of the problem domain

17

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

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 EF

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 EF

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 EF

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 EF

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 EF

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 EF

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 EF

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 EF

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: 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

35

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)

36

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

37

Route Discovery in DSR

B

A

S EF

H

J

D

C

G

IK

Z

Y

Represents a node that has received RREQ for D from S

M

N

L

38


B

A

S EF

H

J

D

C

G

IK

Represents transmission of RREQ

Z


M

N

L

[S]

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

39


B

A

S EF

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]

40


B

A

S EF

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]

41


B

A

S EF

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]

42


B

A

S EF

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]

43


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

44

Route Reply in DSR

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

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

Represents RREP control message

45

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)

46

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

47

Data Delivery in DSR

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

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

Packet header size grows with route length

48

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

49

DSR Optimization: Route Caching

Each node caches a new route it learns by any means When node S finds route [S,E,F,J,D] to node D, node S

also learns route [S,E,F] to node F When node K receives Route Request [S,C,G] destined

for node, node K learns route [K,G,C,S] to node S When node F forwards Route Reply RREP [S,E,F,J,D],

node F learns route [F,J,D] to node D When node E forwards Data [S,E,F,J,D] it learns route

[E,F,J,D] to node D A node may also learn a route when it overhears Data

packets

50

Use of Route Caching

When node S learns that a route to node D is broken, it uses another route from its local cache, if such a route to D exists in its cache. Otherwise, node S initiates route discovery by sending a route request

Node X on receiving a Route Request for some node D can send a Route Reply if node X knows a route to node D

Use of route cache can speed up route discovery can reduce propagation of route requests

51

Use of Route Caching

B

A

S EF

H

J

D

C

G

IK

[P,Q,R] Represents cached route at a node (DSR maintains the cached routes in a tree format)

M

N

L

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

[C,S]

[G,C,S]

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

[J,F,E,S]

Z

52

Use of Route Caching:Can Speed up Route Discovery

B

A

S EF

H

J

D

C

G

IK

Z

M

N

L


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

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

[J,F,E,S]

RREQ

When node Z sends a route requestfor node C, node K sends back a routereply [Z,K,G,C] to node Z using a locallycached route

[K,G,C,S] RREP

53

Use of Route Caching:Can Reduce Propagation of Route Requests

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L


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

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

[J,F,E,S]

RREQ

Assume that there is no link between D and Z.Route Reply (RREP) from node K limits flooding of RREQ.In general, the reduction may be less dramatic.

[K,G,C,S]RREP

54

Route Error (RERR)

B

A

S EF

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

55

Route Caching: Beware!

Stale caches can adversely affect performance

With passage of time and host mobility, cached routes may become invalid

A sender host may try several stale routes (obtained from local cache, or replied from cache by other nodes), before finding a good route

An illustration of the adverse impact on TCP will be discussed later in the tutorial [Holland99]

56

Dynamic Source Routing: Advantages

Routes maintained only between nodes who need to communicate reduces overhead of route maintenance

Route caching can further reduce route discovery overhead

A single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches

57

Dynamic Source Routing: Disadvantages Packet header size grows with route length due to source routing

Flood of route requests may potentially reach all nodes in the network

Care must be taken to avoid collisions between route requests propagated by neighboring nodes insertion of random delays before forwarding RREQ

Increased contention if too many route replies come back due to nodes replying using their local cache Route Reply Storm problem Reply storm may be eased by preventing a node from sending RREP if it

hears another RREP with a shorter route

58

Dynamic Source Routing: Disadvantages

An intermediate node may send Route Reply using a stale cached route, thus polluting other caches

This problem can be eased if some mechanism to purge (potentially) invalid cached routes is incorporated.

For some proposals for cache invalidation, see [Hu00Mobicom] Static timeouts Adaptive timeouts based on link stability

59

Reducing Route Discovery Overhead:Expanding Ring Search

Route Requests are initially sent with smallTime-to-Live (TTL) field, to limit their propagation

If no Route Reply is received, then larger TTL tried

60

Reducing Route Discovery Overhead:Location-Aided Routing (LAR) [Ko98Mobicom]

Exploits location information to limit scope of route request flood Location information may be obtained using GPS

Expected Zone is determined as a region that is expected to hold the current location of the destination Expected region determined based on potentially old location

information, and knowledge of the destination’s speed

Route requests limited to a Request Zone that contains the Expected Zone and location of the sender node

61

Expected Zone in LAR

X

Y

r

X = last known location of node D, at time t0

Y = location of node D at current time t1, unknown to node S

r = (t1 - t0) * estimate of D’s speed

Expected Zone

62

Request Zone in LAR

X

Y

r

S

Request Zone

Network Space

BA

63

LAR

Only nodes within the request zone forward route requests Node A does not forward RREQ, but node B does (see

previous slide)

Request zone explicitly specified in the route request

Each node must know its physical location to determine whether it is within the request zone

64

LAR

Only nodes within the request zone forward route requests

If route discovery using the smaller request zone fails to find a route, the sender initiates another route discovery (after a timeout) using a larger request zone the larger request zone may be the entire network

Rest of route discovery protocol similar to DSR

65

Ad Hoc On-Demand Distance Vector Routing (AODV) [Perkins99Wmcsa]

DSR includes source routes in packet headers

Resulting large headers can sometimes degrade performance particularly when data contents of a packet are small

AODV attempts to improve on DSR by maintaining routing tables at the nodes, so that data packets do not have to contain routes

AODV retains the desirable feature of DSR that routes are maintained only between nodes which need to communicate

66

AODV

Route Requests (RREQ) are forwarded in a manner similar to DSR

When a node re-broadcasts a Route Request, it sets up a reverse path pointing towards the source AODV assumes symmetric (bi-directional) links

When the intended destination receives a Route Request, it replies by sending a Route Reply

Route Reply travels along the reverse path set-up when Route Request is forwarded

67

Route Requests in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

Represents a node that has received RREQ for D from S

M

N

L

68


B

A

S EF

H

J

D

C

G

IK

Represents transmission of RREQ

Z


M

N

L

69


B

A

S EF

H

J

D

C

G

IK

Represents links on Reverse Path

Z

Y

M

N

L

70

Reverse Path Setup in AODV

B

A

S EF

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

71


B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

72


B

A

S EF

H

J

D

C

G

IK

Z

Y

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

M

N

L

73

Route Reply in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

Represents links on path taken by RREP

M

N

L

74

Route Reply in AODV An intermediate node (not the destination) may also send a

Route Reply (RREP) provided that it knows a more recent path than the one previously known to sender S

To determine whether the path known to an intermediate node is more recent, destination sequence numbers are used

The likelihood that an intermediate node will send a Route Reply when using AODV not as high as DSR A new Route Request by node S for a destination is assigned a higher

destination sequence number. An intermediate node which knows a route, but with a smaller sequence number, cannot send Route Reply

75

Forward Path Setup in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

Forward links are setup when RREP travels alongthe reverse path

Represents a link on the forward path

76

Data Delivery in AODV

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

Routing table entries used to forward data packet.

Route is not included in packet header.

DATA

77

Summary: AODV

Routes need not be included in packet headers

Nodes maintain routing tables containing entries only for routes that are in active use

At most one next-hop per destination maintained at each node DSR may maintain several routes for a single destination

Unused routes expire even if topology does not change

78

Proactive Protocols

79

Proactive Protocols

Most of the schemes discussed so far are reactive

Proactive schemes based on distance-vector and link-state mechanisms have also been proposed

80

Link State Routing [Huitema95]

Each node periodically floods status of its links

Each node re-broadcasts link state information received from its neighbor

Each node keeps track of link state information received from other nodes

Each node uses above information to determine next hop to each destination

81

Optimized Link State Routing (OLSR) [Jacquet00ietf,Jacquet99Inria]

The overhead of flooding link state information is reduced by requiring fewer nodes to forward the information

A broadcast from node X is only forwarded by its multipoint relays

Multipoint relays of node X are its neighbors such that each two-hop neighbor of X is a one-hop neighbor of at least one multipoint relay of X Each node transmits its neighbor list in periodic beacons, so that

all nodes can know their 2-hop neighbors, in order to choose the multipoint relays

82

Optimized Link State Routing (OLSR)

Nodes C and E are multipoint relays of node A

A

B F

C

D

E H

GK

J

Node that has broadcast state information from A

83


Nodes C and E forward information received from A

A

B F

C

D

E H

GK

J


84


Nodes E and K are multipoint relays for node H Node K forwards information received from H

E has already forwarded the same information once

A

B F

C

D

E H

GK

J


85

OLSR

OLSR floods information through the multipoint relays

The flooded itself is fir links connecting nodes to respective multipoint relays

Routes used by OLSR only include multipoint relays as intermediate nodes

86

Destination-Sequenced Distance-Vector (DSDV) [Perkins94Sigcomm]

Each node maintains a routing table which stores next hop towards each destination a cost metric for the path to each destination a destination sequence number that is created by the destination

itself Sequence numbers used to avoid formation of loops

Each node periodically forwards the routing table to its neighbors Each node increments and appends its sequence number when

sending its local routing table This sequence number will be attached to route entries created

for this node

87

Destination-Sequenced Distance-Vector (DSDV)

Assume that node X receives routing information from Y about a route to node Z

Let S(X) and S(Y) denote the destination sequence number for node Z as stored at node X, and as sent by node Y with its routing table to node X, respectively

X Y Z

88

Destination-Sequenced Distance-Vector (DSDV)

Node X takes the following steps:

If S(X) > S(Y), then X ignores the routing information received from Y

If S(X) = S(Y), and cost of going through Y is smaller than the route known to X, then X sets Y as the next hop to Z

If S(X) < S(Y), then X sets Y as the next hop to Z, and S(X) is updated to equal S(Y)

X Y Z

89

Unicast Routing Protocols

MANY other protocols have been proposed

Some use other metrics such as energy efficiency, load balancing, when choosing routes

Hybrid protocols combine reactive and proactive features

90

Outline




91

Medium Access Control Protocols

92

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]

93

MAC: A Simple Classification

WirelessMAC

Centralized Distributed

Guaranteedor

controlledaccess

RandomaccessIEEE 802.11

94

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

95

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

96

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

97

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

98

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

99

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

100

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.

101

C FA B EDRTS

RTS = Request-to-Send

IEEE 802.11

Pretending a circular range

102

C FA B EDRTS

RTS = Request-to-Send

IEEE 802.11

NAV = 10

NAV = remaining duration to keep quiet

103

C FA B EDCTS

CTS = Clear-to-Send

IEEE 802.11

104

C FA B EDCTS

CTS = Clear-to-Send

IEEE 802.11

NAV = 8

105

C FA B EDDATA

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

IEEE 802.11

106

IEEE 802.11

C FA B EDACK

107

C FA B EDACK

IEEE 802.11

Reserved area(not necessarilycircular inpractice)

108

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

109

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

110

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)

111

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

112

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

113

Power Save in IEEE 802.11 Ad Hoc Mode

Time is divided into beacon intervals

Each beacon interval begins with an ATIM window ATIM =

Beacon interval

ATIMwindow

114


If host A has a packet to transmit to B, A must send an ATIM Request to B during an ATIM Window

On receipt of ATIM Request from A, B will reply by sending an ATIM Ack, and stay up during the rest of the beacon interval

If a host does not receive an ATIM Request during an ATIM window, and has no pending packets to transmit, it may sleep during rest of the beacon interval

115


ATIMReq

ATIMAck

AckData

Sleep

Node A

Node C

Node B

116


Size of ATIM window and beacon interval affects performance [Woesner98]

If ATIM window is too large, reduction in energy consumption reduced Energy consumed during ATIM window

If ATIM window is too small, not enough time to send ATIM request

117


How to choose ATIM window dynamically? Based on observed load [Jung02infocom]

How to synchronize hosts? If two hosts’ ATIM windows do not overlap in time, they

cannot exchange ATIM requests Coordination requires that each host stay awake long

enough (at least periodically) to discover out-of-sync neighbors [Tseng02infocom]

ATIM

ATIM

118

Impact on Upper Layers

If each node uses the 802.11 power-save mechanism, each hop will require one beacon interval This delay could be intolerable

Allow upper layers to dictate whether a node should enter the power save mode or not [Chen01mobicom]

119

Adaptive Modulation

120

Adaptive Modulation

Channel conditions are time-varying

Received signal-to-noise ratio changes with time

A B

121

Adaptive Modulation

Multi-rate radios are capable of transmitting at several rates, using different modulation schemes

Choose modulation scheme as a function of channel conditions

Distance

Throughput

Modulation schemes providea trade-off betweenthroughput and range

122

Adaptive Modulation

If physical layer chooses the modulation scheme transparent to MAC MAC cannot know the time duration required for the transfer

Must involve MAC protocol in deciding the modulation scheme Some implementations use a sender-based scheme for this

purpose [Kamerman97] Receiver-based schemes can perform better

123

Sender-Based “Autorate Fallback” [Kamerman97]

Probing mechanisms

Sender decreases bit rate after X consecutive transmission attempts fail

Sender increases bit rate after Y consecutive transmission attempt succeed

124

Autorate Fallback

Advantage Can be implemented at the sender, without making any

changes to the 802.11 standard specification

Disadvantage Probing mechanism does not accurately detect channel

state Channel state detected more accurately at the receiver Performance can suffer

• Since the sender will periodically try to send at a rate higher than optimal

• Also, when channel conditions improve, the rate is not increased immediately

125

Receiver-Based Autorate MAC [Holland01mobicom]

Sender sends RTS containing its best rate estimate

Receiver chooses best rate for the conditions and sends it in the CTS

Sender transmits DATA packet at new rate

Information in data packet header implicitly updates nodes that heard old rate

126

Receiver-Based Autorate MAC Protocol

D

C

BACTS (1 Mbps)

RTS (2 Mbps)

Data (1 Mbps)

NAV updated using rate

specified in the data packet

127

TCP Performancein


128

Performance of TCP

Several factors affect TCP performance in MANET:

Wireless transmission errors

Multi-hop routes on shared wireless medium For instance, adjacent hops typically cannot transmit

simultaneously

Route failures due to mobility

129

This Tutorial

This tutorial does not consider techniques to improve TCP performance in presence of transmission errors

Please refer to the Tutorial on TCP for Wireless and Mobile Hosts presented by Vaidya at MobiCom 1999, Seattle

The tutorial slides are presently available from http://www.crhc.uiuc.edu/wireless/ (follow the link to Tutorials)

[Montenegro00-RFC2757] discusses related issues

130

This Tutorial

This tutorial considers impact of multi-hop routes and route failures due to mobility

131


May need to traverse multiple links to reach a destination

132


Mobility causes route changes

133

Throughput over Multi-Hop Wireless Paths [Gerla99]

Connections over multiple hops are at a disadvantage compared to shorter connections, because they have to contend for wireless access at each hop

134

Impact of Multi-Hop Wireless Paths [Holland99]

0200400600800

1000120014001600

1 2 3 4 5 6 7 8 9 10

Number of hops

TCPThroughtput(Kbps)

TCP Throughput using 2 Mbps 802.11 MAC

135

Throughput Degradations withIncreasing Number of Hops

Packet transmission can occur on at most one hop among three consecutive hops Increasing the number of hops from 1 to 2, 3 results in increased

delay, and decreased throughput

Increasing number of hops beyond 3 allows simultaneous transmissions on more than one link, however, degradation continues due to contention between TCP Data and Acks traveling in opposite directions

When number of hops is large enough, the throughput stabilizes due to effective pipelining

136

Ideal Throughput

f(i) = fraction of time for which shortest path length between sender and destination is I

T(i) = Throughput when path length is I From previous figure

Ideal throughput = f(i) * T(i)

137

Impact of MobilityTCP Throughput

Ideal throughput (Kbps)

Act

ual t

hrou

ghpu

t

2 m/s 10 m/s

138

Impact of Mobility

Ideal throughput

Act

ual t

hrou

ghpu

t

20 m/s 30 m/s

139

Throughput generally degrades with increasing speed …

Speed (m/s)

AverageThroughputOver 50 runs

Ideal

Actual

140

But not always …

Mobility pattern #

Actualthroughput

20 m/s

30 m/s

141

mobility causeslink breakage,resulting in routefailure

TCP data and acksen route discarded

Why Does Throughput Degrade?

TCP sender times out.Starts sending packets again

Route isrepaired

No throughput

No throughputdespite route repair

142

mobility causeslink breakage,resulting in routefailure

TCP data and acksen route discarded

Why Does Throughput Degrade?

TCP sendertimes out.Backs off timer.

Route isrepaired

TCP sendertimes out.Resumessending

Larger route repair delaysespecially harmful

No throughputNo throughput

despite route repair

143

Why Does Throughput Improve?Low Speed Scenario

C

B

D

A

C

B

D

A

C

B

D

A

1.5 second route failure

Route from A to D is broken for ~1.5 second.

When TCP sender times after 1 second, route still broken.

TCP times out after another 2 seconds, and only then resumes.

144

Why Does Throughput Improve?Higher (double) Speed Scenario

C

B

D

A

C

B

D

A

C

B

D

A

0.75 second route failure

Route from A to D is broken for ~ 0.75 second.

When TCP sender times after 1 second, route is repaired.

145

Why Does Throughput Improve?General Principle

The previous two slides show a plausible cause for improved throughput

TCP timeout interval somewhat (not entirely) independent of speed

Network state at higher speed, when timeout occurs, may be more favorable than at lower speed

Network state Link/route status Route caches Congestion

146

How to Improve Throughput(Bring Closer to Ideal)

Network feedback

Inform TCP of route failure by explicit message

Let TCP know when route is repaired Probing Explicit notification

Reduces repeated TCP timeouts and backoff

147

Performance Improvement

Without networkfeedback

Ideal throughput 2 m/s speed

With feedback

Act

ual t

hrou

ghpu

t

148

Performance Improvement

Without networkfeedback

With feedback

Ideal throughput 30 m/s speed

Act

ual t

hrou

ghpu

t

149

Performance with Explicit Notification[Holland99]

0

0.2

0.4

0.6

0.8

1

2 10 20 30

mean speed (m/s)

thro

ughp

ut a

s a

frac

tion

of

idea

l Base TCP

With explicitnotification

150

IssuesNetwork Feedback

Network knows best (why packets are lost)

+ Network feedback beneficial- Need to modify transport & network layer to receive/send

feedback

Need mechanisms for information exchange between layers

[Holland99] discusses alternatives for providing feedback (when routes break and repair) [Chandran98] also presents a feedback scheme

151

Impact of Caching

Route caching has been suggested as a mechanism to reduce route discovery overhead [Broch98]

Each node may cache one or more routes to a given destination

When a route from S to D is detected as broken, node S may: Use another cached route from local cache, or Obtain a new route using cached route at another node

152

To Cache or Not to Cache

Average speed (m/s)Ac t

ual t

hro u

g hp u

t (as

frac

t ion

o f e

xpec

t ed

thro

u gh p

u t)

153

Why Performance Degrades With Caching

When a route is broken, route discovery returns a cached route from local cache or from a nearby node

After a time-out, TCP sender transmits a packet on the new route.However, the cached route has also broken after it was cached

Another route discovery, and TCP time-out interval Process repeats until a good route is found

timeout dueto route failure

timeout, cachedroute is broken

timeout, second cachedroute also broken

154

IssuesTo Cache or Not to Cache

Caching can result in faster route “repair”

Faster does not necessarily mean correct

If incorrect repairs occur often enough, caching performs poorly

Need mechanisms for determining when cached routes are stale

155

Caching and TCP performance

Caching can reduce overhead of route discovery even if cache accuracy is not very high

But if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs

156

TCP Performance

Two factors result in degraded throughput in presence of mobility:

Loss of throughput that occurs while waiting for TCP sender to timeout (as seen earlier) This factor can be mitigated by using explicit notifications

and better route caching mechanisms

Poor choice of congestion window and RTO values after a new route has been found How to choose cwnd and RTO after a route change?

157

Issues Window Size After Route Repair

Same as before route break: may be too optimistic

Same as startup: may be too conservative

Better be conservative than overly optimistic Reset window to small value after route repair Let TCP figure out the suitable window size Impact low on paths with small delay-bw product

158

IssuesRTO After Route Repair

Same as before route break If new route long, this RTO may be too small, leading to timeouts

Same as TCP start-up (6 second) May be too large May result in slow response to next packet loss

Another plausible approach: new RTO = function of old RTO, old route length, and new route length Example: new RTO = old RTO * new route length / old route length Not evaluated yet Pitfall: RTT is not just a function of route length

159

Out-of-Order Packet Delivery

Out-of-order (OOO) delivery may occur due to: Route changes Link layer retransmissions schemes that deliver OOO

Significantly OOO delivery confuses TCP, triggering fast retransmit

Potential solutions: Deterministically prefer one route over others, even if multiple

routes are known Reduce OOO delivery by re-ordering received packets

• can result in unnecessary delay in presence of packet loss Turn off fast retransmit

• can result in poor performance in presence of congestion

160

Impact of Acknowledgements

TCP Acks (and link layer acks) share the wireless bandwidth with TCP data packets

Data and Acks travel in opposite directions

In addition to bandwidth usage, acks require additional receive-send turnarounds, which also incur time penalty

To reduce frequency of send-receive turnaround and contention between acks and data

161

Impact of Acks: Mitigation [Balakrishnan97]

Piggybacking link layer acks with data

Sending fewer TCP acks - ack every d-th packet (d may be chosen dynamically)

• but need to use rate control at sender to reduce burstiness (for large d)

Ack filtering - Gateway may drop an older ack in the queue, if a new ack arrives reduces number of acks that need to be delivered to the

sender

162

Outline




163

Security and Misbehavior

164

Issues

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

165

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

166

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

167

MAC Layer

Disobey protocol specifications for selfish gains

Denial-of-service attacks

168

Scope of this Tutorial

Overview of selected issues at various protocol layers

Not an exhaustive survey of all relevant problems or solutions

169

Outline


170

Key Management

171

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

172

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

173

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

174

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

175

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

176

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

177

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

178


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.

179


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

180

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

181

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

182

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

183

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

184

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

185

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

186

Outline


187

Secure Communication

188


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

189


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

190

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

191

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

192

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

193

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

194

Mix Nodes

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

M1 B M2 E

A

M3C

DG

F

195

Mix Nodes

M2 recovers M and sends to G

M1 B M2 E

A

M3C

DG

F

196

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

197

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

198

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

199

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

200


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)

201


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

202


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

203


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

204


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

205


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]

206

Outline




207

Misbehavior at the MAC Layer

208

MAC Layer Misbehavior

Wireless

channel

Access Point

A B

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

Misbehaving nodes may violate MAC rules

Wireless

channel

Access Point

C D

209

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

210

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

211

Possible Misbehaviors:“Impatient” Transmitters

Smaller backoff intervals [Kyasanur]

Shorter Interframe Spacings [Raya]

212

“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

213

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

214

Goals [Kyasanur03]

Diagnose node misbehavior Catch misbehaving nodes

Discourage misbehavior Punish misbehaving nodes

215

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

216

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

217

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

218

Passive Observation

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

Wireless channel

Access Point

A

219

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

AP 1

A

Wireless channel

AP 2

B

220

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

221

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

222

Potential Solution:Use long-term statistics [Kyasanur]

Observe backoffs chosen by sender over multiple packets

Selecting right observation interval difficult

223

An Alternative Approach

Remove the non-determinism

224

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

225

Modifications to 802.11

• R provides backoff B to S in ACK B selected from [0,CWmin]

DATA

Sender S

Receiver R

CTS

ACK(

B)RTS

• S uses B for backoff

RTS

B

226

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

227

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

228

Detecting deviations

Receiver counts number of idle slots Bobsr

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

Sender S

Receiver R

ACK(

B) RTS

Backoff

Bobsr

229

Penalizing Misbehavior

When Bobsr < B, penalty P added P proportional to B– Bobsr

ACK(

B+P

)

CTS DATA

Total backoff assigned = B + P

Bobsr

Sender SReceiver R

ACK(

B) RTS

Actual backoff < B

230

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

231

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

232

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

233

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?

234

Other Approaches

Game theory

Incentive-based mechanisms

235

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

236

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

237

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]

238

Some Other MAC Layer Issues

239

MAC Layer Anonymous Broadcast

How to broadcast anonymously at the MAC layer? To maintain anonymity from “external” attackers

One possible solution: Encrypt the source address using secret key (attacker cannot determine the packet’s contents)

Source may be encrypted, but the signal energy will be highest closest to the transmitter

This may give away the identity of the source

240

MAC Layer Anonymous Broadcast

Alternate (expensive) solution: Require all hosts in a “broadcast domain” to periodically broadcast packets

Hosts may transmit dummy packets when no real packets need to be transmitted

Observer cannot determine which hosts are sending real packets (due to encryption)

Source cannot be determined uniquely, but overhead high

241

Link Layer Encryption

Link layer encryption provides protection for wireless transmissions on a per-hop basis.

Need mechanisms for agreeing on suitable keys for this purpose

IEEE 802.11 specifies one such approach

242

Outline




243

Network Layer Misbehavior

244

Network Layer Misbehavior

Many potential misbehaviors have been identified in various papers

We will discuss selected misbehaviors, and plausible solutions

245

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

246

Watchdog Approach [Marti]

Verify whether a node has forwarded a packet or not

B DC EA

B sends packet to C

247

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

248

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

249

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


250

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


251

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

252

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

253

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

254

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

255

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

256

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

257

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

258

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

259

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

260

Hosts Bearing Grudges: Issues

How to decide on friends?

What if “friends” cheat?

261

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

262

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”

263

Exploiting Path Redundancy

Alternate routes: AFGE, ABCDE, ABFGE, ABCGE

B D

GE

A

F

C

264

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

265

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)

266

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

267

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)

…

268

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

269

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

270

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

271

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)

272

Node Insertion

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L[S,E,P,Q,F]

[S,E]

273

Node Deletion

B

A

S EF

H

J

D

C

G

IK

Z

Y

M

N

L

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

274

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

275

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

276

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)

277

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-list

Not 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

278

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

279

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

280

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!)

281

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

282


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

283


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

284


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

285


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

B D

XE

A

F

C

286

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

287


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

288


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

289


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

290

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

291

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

292

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)

293

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

294

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

295

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

296

Anomaly Detection

297

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

298

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

299

Anomaly Detection

We limit our discussion here

Wireless harder than wired networks due to spatial and temporal variations

300

Attacks on Sensor Networks

Compromised sensors may provide erroneous sensor readings

Need to protect from spurious data, by exploiting redundancy offered by dense sensor deployment

Take “vote” among nearby sensors to determine appropriate value

Nearby sensors (even if all good) may not yield identical readings

The “vote” needs to account for this

301

Attacks on Sensor Networks

Intruder may gain access to sensor data transmitted over wireless channel Use encryption

How to set up keys at various sensors? Static assignment

• Example:– Each sensor pre-loaded with a private key

Dynamic assignment• Example:

– Each sensor pre-loaded with a set of public-private key pairs

– Adjacent sensors use a key that both are aware of

302

Outline



Conclusion & Related activities References

303

Conclusions

304

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)

305

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

306

Related Standards Activities

IETF MANET Working group IEEE 802.11 IEEE 802.16

307

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.

308

Thanks!

www.crhc.uiuc.edu/[email protected]

309

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

310

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

311

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.

312

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

1 mobile ad hoc networks: protocols and security issues nitin h. vaidya university of illinois at...

Documents