Ad Hoc Network Routing

1
Ad Hoc Network Routing

• Not in the book

2
Ad Hoc Network Routing

• Each device acts as a router
• Routing protocol discovers paths through network
• Nodes have limited resources

A
B
C
3
On-Demand vs. Periodic

• Two types of routing protocols
• Periodic (proactive)
• Most wired routing protocols are periodic
• Routing information learned with some delay
• Tradeoff delay and routing overhead
• On-demand (reactive)
• Discover routing information only when needed
• Overhead scales automatically
• Better in resource-limited, dynamic networks

4
Basic Distance Vector Routing

• Each device (node) maintains a routing table

Example table at A
Destination Metric Next Hop
A 0 N/A
B 1 B
C 2 B

• Computed using Distributed Bellman-Ford
• Each node periodically broadcasts its routing
  table
• For each routing table entry received, compare
  best known route with new information

5
Improvements to Distance Vector

• Triggered updates, incremental updates
• Split horizon, poisoned reverse

6
Improvements to Distance Vector

• Triggered updates, incremental updates
• Split horizon, poisoned reverse
• Sequence numbers for loop-freedom
• Each node maintains a sequence number
• Each node increments its sequence number each
  time it sends an update about itself
• An advertised route is better if either
• It has a higher (more recent) sequence number, or
• Sequence numbers equal, and the metric is lower
• Special case for propagating broken links faster

7
Ad Hoc Network Routing DSR

• Dynamic Source Routing intuition
• Operate completely on-demand
• Cache learned links in a graph data structure
• Use source routing for simplicity

C
A
D
B
E
F
Route Cache at node A
8
Ad Hoc Network Routing DSR

• Dynamic Source Routing intuition
• Operate completely on-demand
• Cache learned links in a graph data structure
• Use source routing for simplicity

C
A
D
B
E
F
Route Cache at node A
9
DSR Route Discovery

• When a node needs a route to a destination
• Broadcast a ROUTE REQUEST with source, target, id
• When hearing a ROUTE REQUEST for another node
• Drop if already seen REQUEST from same Discovery
• Else, append address to node list and rebroadcast

A, B targetE, id3
A targetE, id3
A, B, D targetE, id3
B
A
D
E
C
10
DSR Route Discovery

• When hearing a ROUTE REQUEST for this node
• Return a ROUTE REPLY to the initiator
• E received a REQUEST targetE, routeA,B,D

A,B,D,E
A,B,D,E
B
A,B,D,E
A
D
E
C
11
DSR Route Maintenance

• When forwarding a packet, a node
• Transmits the packet to the next hop specified in
  the source route
• Confirms reachability of next-hop destination
• If next-hop not reachable, send ROUTE ERROR to
  packets source

(S,A,B,C,D)
(S,A,B,C,D)
(S,A,B,C,D)
S
A
B
D
C
12
Ad hoc On demand Distance Vector

• Ad hoc On demand Distance Vector is
• Stateful routing (based on routing tables)
• Loop-freedom through sequence numbers
• But state is created on-demand throughRoute
  Request (RREQ) and Reply (RREP)
• RREQ and RREP act as routing updates
• Form paths to original sender of those
  packets(initiator for RREQ, target for RREP)

13
AODV Route Discovery

• When a node needs a route to a destination
• Broadcast REQUEST with source, target, id, seq
• When hearing a ROUTE REQUEST for another node
• Drop if already seen REQUEST from same Discovery
• Else, adjust routing table and rebroadcast

To A
A?E, id3seq5
A?E, id3seq5
A?E, id3seq5
A
D
E
14
AODV Route Discovery

• When hearing ROUTE REQUEST for this node
• Return ROUTE REPLY to initiator with seq
  numberunless REPLY already returned for this
  Discovery
• When forwarding ROUTE REPLY, update routing table
• E received a REQUEST targetE, id3

To A To E
E?A seq9
E?A seq9
B
E?A seq9
A
D
E
C
15
AODV Route Maintenance

• When AODV receives a packet for forwarding
• If the packets destination in routing table,
  forward to indicated next hop
• If forwarding is unsuccessful, or if no route
  found
• Broadcast a ROUTE ERROR (RERR)
• If a node hears an RERR sent by its next-hop, the
  node rebroadcasts the RERR
• Delete routing table entries unless recently used
• AODV can also use HELLO packets for periodic
  Route Maintenance

16
AODV Route Maintenance

• Node detecting error broadcasts a ROUTE ERROR
• If As next-hop for C is B, A rebroadcasts
• If Ss next-hop for C is A, S rebroadcasts
• Floods ERROR to all nodes which use broken link

Error C
D
C
B
A
S
17
References

• David B. Johnson. Routing in Ad Hoc Networks of
  Mobile Hosts. WMCSA 1994.
• Charles E. Perkins and Elizabeth M. Royer. Ad
  hoc On-Demand Distance Vector Routing. WMCSA 1999.

18
Broadcast Authentication

• Broadcasts data over wireless network
• Packet injection usually easy
• Each receiver can verify data origin

Sender
Dave
Alice
M
M
M
M
Bob
Carol
19
Authentication Needs Asymmetry
Sender K
K shared key
Alice K
Bob K
20
Digital Signatures Do Not Work

• Signatures are expensive, e.g., RSA 1024
• High generation cost (10 milliseconds)
• High verification cost (1 millisecond)
• High communication cost (128 bytes/packet)
• Very expensive on low-end processors
• If we aggregate signature over multiple packets,
  intolerant to packet loss

21
TESLA

• Timed Efficient Stream Loss-tolerant
  Authentication
• Uses only symmetric cryptography
• Asymmetry via time
• Delayed key disclosure
• Requires loose time synchronization

22
Basic Authentication Mechanism

• F public one-way function

P
F(K) Authentic Commitment
K disclosed
MAC(K,P)
t
23
Security Condition

• Receiver knows key disclosure schedule
• Security condition (for packet P) on arrival of
  P, receiver is certain that sender did not yet
  disclose K
• If security condition not satisfied, drop packet

24
TESLA

• Keys disclosed 2 time intervals after use
• Receiver setup Authentic K3, key disclosure
  schedule

K5
K6
K7
K5
t
Time 4
Time 5
Time 6
Time 7
Time 3
P1
K3
25
TESLA Robust to Packet Loss
K4
K5
K6
K7
K3
t
Time 4
Time 5
Time 6
Time 7
26
TESLA Summary

• Low overhead
• Communication ( 20 bytes)
• Computation ( 1 MAC computation per packet)
• Perfect robustness to packet loss
• Independent of number of receivers
• Delayed authentication
• Extensions
• TIK Instant key disclosure
• Heterogeneous receivers
• Instant authentication (sender buffers data)

27
One-Time Signatures

• Challenge digital signatures expensive for
  generation and verification
• Goal amortize digital signature

28
One-Time Signatures

• Use one-way functions without trapdoor
• Efficient for signature generation and
  verification
• Caveat can only use one time
• Example 1-bit one-time signature
• P0, P1 are public values (public key)
• S0, S1 are private values (private key)

S0
P0
S0
S0
P
S1
P1
S1
S1
29
Lamports One-Time Signature

• Uses 1-bit signature construction to sign
  multiple bits

S0
S0
S0
S0
Private values
Sign 0
P0
P0
P0
P0

Public values
P1
P1
P1
P1
S1
S1
S1
S1
Private values
Sign 1
Bit 0
Bit 1
Bit 2
Bit n
30
Improved Construction I

• Uses 1-bit signature construction to sign
  multiple bits

c0
c0
c0
S0
S0
S0
S0


p0
p0
p0
P0
P0
P0
P0
Bit 0
Bit 1
Bit 2
Bit n
Bit 0
Bit 1
Bit log(n)
Sign message
Checksum bits encode of signature bits 0
31
Improved Construction II

• Lamport signature has high overhead
• Goal reduce size of public and private key
• Approach use one-way hash chains
• S1 F( S0 )

Sig(0)
Sig(1)
Sig(2)
Sig(3)
Signature chain
S2
P
S3
S0
S1
32
Merkle-Winternitz Construction

• Intuition encode sum of checksum chain

Signature Bits 0,1
S2
S3
S0
S1
Signature Bits 2,3
S2
S3
S0
S1
Signature Bits 4,5
S2
P
S3
S0
S1
Checksum Bits 0,1
C1
C0
C3
C2
Checksum Bits 2,3
C1
C0
C3
C2
33
SEAD Protocol Properties

• SEAD (Secure Efficient Ad hoc Distance vector)
• Uses one-way hash chains to authenticate metric
  and sequence number
• Assumes a limit k-1 on metric (as in other
  distance vector protocols such as RIP, where
  k16)
• Metric value infinity can be represented as k

34
SEAD Metric Authenticators

• Each node generates a hash chain and distributes
  the last element (CN1) to allow verification
• Chain values CN-k1, , CN authenticate metrics
  0 through k-1 for sequence number 1
• CN-2k1,CN-k authenticate metrics 0 through k-1
  for sequence number 2
• CN-ik1,CN-(i-1)k authenticate metrics 0 through
  k-1 for sequence number i

C0
C1
C3
C2
C5
C4
C6
C7
C9
C8
C10
C12
C11
35
SEAD Metric Authenticators

• Each node generates a hash chain anddistributes
  the last element (CN1) to allow verification
• Chain values CN-k1, , CN authenticate metrics
  0 through k-1 for sequence number 1
• CN-2k1,CN-k authenticate metrics 0 through k-1
  for sequence number 2
• CN-ik1,CN-(i-1)k authenticate metrics 0 through
  k-1 for sequence number i

C0
C1
C3
C2
C5
C4
C6
C7
C9
C8
C10
C12
C11
36
SEAD Metric Authenticators

• Each node generates a hash chain and distributes
  the last element (CN1) to allow verification
• Chain values CN-k1, , CN authenticate metrics
  0 through k-1 for sequence number 1
• CN-2k1,CN-k authenticate metrics 0 through k-1
  for sequence number 2
• CN-ik1,CN-(i-1)k authenticate metrics 0 through
  k-1 for sequence number i

C0
C1
C3
C2
C5
C4
C6
C7
C9
C8
C10
C12
C11
37
SEAD Metric Authenticators

• Each node generates a hash chain and distributes
  the last element (CN1) to allow verification
• Chain values CN-k1, , CN authenticate metrics
  0 through k-1 for sequence number 1
• CN-2k1,CN-k authenticate metrics 0 through k-1
  for sequence number 2
• CN-ik1,CN-(i-1)k authenticate metrics 0 through
  k-1 for sequence number i

C0
C1
C3
C2
C5
C4
C6
C7
C9
C8
C10
C12
C11
38
SEAD Metric Authenticators

• Within a sequence number i
• CN-ik1 represents metric 0
• CN-ik2 represents metric 1
• CN-ikm1 represents metric m
• CN-ikk represents metric k-1

• When a node receives a routing update
• It first checks the metric authenticator
• If the update is to be accepted
• It increments the metric by one
• and hashes the authenticator
• then adds the metric and authenticator to routing
  table

Metric 0
Metric 1
Metric 2
C9
C10
C11
39
Metric Authenticator Properties

• Given any authentic one-way hash chain value Ci
• Can compute later values Cj for j gt i
• Can authenticate earlier values Cj for j lt i
• Thus, for SEAD metric authenticators
• Given an authenticator for some sequence number
  and metric, can generate authenticator for a new
  sequence number and metric if and only if
• The sequence number is lower, or
• The sequence number is the same and metric is
  higher
• Can authenticate any valid authenticator

40
SEAD Neighbor Authentication

• SEAD needs to know true source of routing updates

Destination Metric
A 0
B 1
C 2
D
A
B
C
41
SEAD Neighbor Authentication

• SEAD needs to know true source of routing updates
• Simple example using all-pairs O(n2) shared keys
• Each node maintains a neighbor table
• Node A adds node B when A hears advertisement
  directly from B with a fresh sequence number
• Triggers As advertisement, which B hears
  directly from A
• A and B begin to include symmetric authenticators
  (e.g., using HMAC) for each other in each update
• Stop after missing 3 consecutive sequence numbers

42
Additional Optimizations in DSDV

• Weighted Settling Time
• Track average time (across multiple sequence
  numbers) between first route and best route
• Delay advertisements by that amount
• But allows attacker to rush routing data

• Speeding the spread of broken route information
• Increment the sequence number when reporting an
  infinite metric
• But SEAD cannot authenticate it

43
Loop-Freedom

• SEAD is loop-free unless an attacker is in the
  loop
• Correctness argument
• Suppose there is a loop
• The (sequence number, metric) always gets
  strictly better at the next hop around loop
  unless
• The next hop is an attacker, or
• The attacker forged the next-hop in the routing
  update
• But next-hop in update is always authenticated
• Therefore, the loop either terminates or there is
  an attacker in the loop

44
Security Properties

• SEAD is robust against non-collaborating
  attackers
• Attackers cannot make a path longer by more than
  the number of attackers on the path

A
B
E
C
D
C
C1
C2
C3
C4
Metric 0
Metric 1
Metric 2
Metric 3
45
Security Properties

• Against collaborating attackers
• The number of hops from the source to the first
  attacker
• plus the number of hops from the last attacker to
  the destination
• cannot exceed length of the longest non-attacking
  path

A
B
E
C
D
C1
C2
C3
C4
Metric 0
Metric 1
Metric 2
Metric 3
46
SEAD Summary

• SEAD provides practical security with only
  moderate network overhead and negligible
  computational requirements
• SEAD actually outperforms DSDV-SQ (on some
  metrics)
• SEAD has good loop-freedom properties
• As in DSDV, is loop-free in absence of attackers
• Requires attacker to be in the loop to form a
  loop

47
Ariadne Overview

• Secures DSR
• Flexible key setup

48
Ariadne Authentication Requirements

• Can use any of three types of authentication
• Pairwise shared keys
• But requires setting up O(n2) keys
• Digital signatures and asymmetric key setup
• But uses expensive asymmetric cryptography
• Time-delayed broadcast authentication (TESLA)
• But requires time synchronization
• Ariadne requires only one of these types
• Each appropriate for different circumstances

49
Attacks Secured by Ariadne

• Ariadne secures most severe attacks on DSR
• Excessive Route Discovery floods
• Modifying discovered routes
• By dropping nodes
• By altering the node list
• Sending bogus ROUTE ERRORs
• Failing to forward packets
• Failing to send ROUTE ERROR for broken route

50
ROUTE REQUEST Flooding Attack

• On-demand protocols discover routes using
  flooding
• An attacker can use this to flood the network
• A solution rate-limit Discoveries when
  forwarding
• But attacker can forge claimed Discovery initiator

ROUTE REQUEST from A
ROUTE REQUEST from B
ROUTE REQUEST from C
X
ROUTE REQUEST from D
ROUTE REQUEST from E
51
Excessive ROUTE REQUEST Floods

• Our Solution Node uses a one-way hash chain
• Authenticates the true source of ROUTE REQUEST
• Disclose a new element per Discovery
• Each element can be used only once
• An Active-x-y attacker can initiate Route
  Discoveries at only x times the maximum rate
  allowed for any single node

52
Hop Drop Attack

• As in DSR, Ariadne accumulates in the
• ROUTE REQUEST packet the list of hops traversed
• Attacker can drop or alter nodes on this list
• Can prevent discovery of a correct route

S
S, A
S, B
S, B, C
S
A
B
D
C
53
Preventing Hop Drop

• Initiator S and Target D share (or generate) KSD
• S adds Message Authentication Codeh0 MAC(KSD,
  request id) to ROUTE REQUEST
• MAC can only be computed by S and D

h0
S
A
B
D
C
54
Preventing Hop Drop

• Initiator S and Target D share (or generate) KSD
• S adds Message Authentication Codeh0 MAC(KSD,
  request id) to ROUTE REQUEST
• MAC can only be computed by S and D
• Each hop computes hi H(node address hi-1)

h0
h1
S
A
B
D
C
55
Preventing Hop Drop

• Initiator S and Target D share (or generate) KSD
• S adds Message Authentication Codeh0 MAC(KSD,
  request id) to ROUTE REQUEST
• MAC can only be computed by S and D
• Each hop computes hi H(node address hi-1)
• B needs h0 to drop A but cant derive from h1

h0
h1
h2
S
A
B
D
C
56
Preventing Hop Drop

• Initiator S and Target D share (or generate) KSD
• S adds Message Authentication Codeh0 MAC(KSD,
  request id) to ROUTE REQUEST
• MAC can only be computed by S and D
• Each hop computes hi H(node address hi-1)
• B needs h0 to drop A but cant derive from h1

h0
h1
h2
h3
S
A
B
D
C
57
Preventing Hop Drop

• In an Ariadne ROUTE REQUEST
• h0 MAC(KSD, request id)
• Target can compute h0
• hi H(node address hi-1)
• Target can reconstruct each hi
• Target can thus detect hop drop

h0
h1
h2
h3
S
A
B
D
C
58
Node List Corruption

• Attacker can insert arbitrary nodes into node
  list
• Instead of attackers node address
• Or in addition to attackers node address
• Can prevent discovery of a correct route

S
S,A
S,A,Z
S,A,Z,C
A
B
C
S
D
59
Route Authentication using Shared Keys

• When using shared keys between all node pairs
• Each node F forwarding a REQUEST packet p
• Computes a MAC over p using the key it shares
  with the target
• Includes it in hi as hi H(F MAC(KFD,p)
  hi-1)
• Only that F and the target can compute this

h0
S
A
B
D
C
60
Route Authentication using Shared Keys

• When using shared keys between all node pairs
• Each node F forwarding a REQUEST packet p
• Computes a MAC over p using the key it shares
  with the target
• Includes it in hi as hi H(F MAC(KFD,p)
  hi-1)
• Only that F and the target can compute this

h0
h1
S
A
B
D
C
61
Route Authentication using Shared Keys

• When using shared keys between all node pairs
• Each node F forwarding a REQUEST packet p
• Computes a MAC over p using the key it shares
  with the target
• Includes it in hi as hi H(F MAC(KFD,p)
  hi-1)
• Only that F and the target can compute this

h0
h1
h2
S
A
B
D
C
62
Route Authentication using Shared Keys

• When using shared keys between all node pairs
• Each node F forwarding a REQUEST packet p
• Computes a MAC over p using the key it shares
  with the target
• Includes it in hi as hi H(F MAC(KFD,p)
  hi-1)
• Only that F and the target can compute this

h0
h1
h2
h3
S
A
B
D
C
63
Route Authentication using Shared Keys

• In an Ariadne ROUTE REQUEST
• As before, target can recompute h0
• hi H(F MAC(KFD,p) hi-1)
• Target can reconstruct each hi
• Target can detect bogus nodes in node list
• If received hi is valid, return authenticated
  REPLY

h0
h1
h2
h3
S
A
B
D
C
64
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)

h0
A
B
C
S
D
65
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)

h0
h1
A
B
C
S
D
66
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)

h0
h1
h2
A
B
C
S
D
67
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)

h0
h1
h2
h3
A
B
C
S
D
68
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)
• Target verifies that TESLA keys not yet
  disclosed, authenticates hi and node list,
  returns REPLY
• Forwarding node buffers REPLY until it can reveal
  the key used to authenticate REQUEST

A
B
C
S
D
h3
69
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)
• Target verifies that TESLA keys not yet
  disclosed, authenticates hi and node list,
  returns REPLY
• Forwarding node buffers REPLY until it can reveal
  the key used to authenticate REQUEST

A
B
C
S
D
h3,KC
h3
70
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)
• Target verifies that TESLA keys not yet
  disclosed, authenticates hi and node list,
  returns REPLY
• Forwarding node buffers REPLY until it can reveal
  the key used to authenticate REQUEST

A
B
C
S
D
h3,KC,KB
h3,KC
h3
71
Route Authentication using TESLA

• When using TESLA for broadcast authentication
• Compute MAC using current (secret) TESLA keyhi
  H(F MAC(KF,p) hi-1)
• Target verifies that TESLA keys not yet
  disclosed, authenticates hi and node list,
  returns REPLY
• Forwarding node buffers REPLY until it can reveal
  the key used to authenticate REQUEST

A
B
C
S
D
h3,KC,KB,KA
h3,KC,KB
h3,KC
h3
72
Route Authentication using TESLA

• On receiving the REPLY, initiator
• Recomputes h0
• Authenticates each KF using TESLA
• Verifies and checks authentication on hi
• Initiator can detect bogus node in node list

A
B
C
S
D
h3,KC,KB,KA
h3,KC,KB
h3,KC
h3
73
Ariadne Key Distribution

• Avoids circular dependency between routing and
  key setup
• Key Distribution Center (KDC) shares keys with
  all other nodes
• KDC periodically floods ROUTE REQUEST
• All nodes send a ROUTE REPLY
• Each node that wants to establish a key
  piggybacks a key request on that ROUTE REPLY
• KDC generates and sends an encrypted key to each
  endpoint

74
ROUTE ERROR Authorization

• Attacker could send forged ROUTE ERRORs to break
  good routes that are in use
• Solution authorization and authentication
• A node N is authorized to report an error for a
  link from N to any other node
• N could report a bogus error, but then, N could
  just refuse to forward packets on that link

75
ROUTE ERROR Authentication

• If using pairwise shared keys
• Authenticate ERROR to original source of packet
• If using TESLA delayed broadcast authentication
• Include authentication in ERROR using your
  current TESLA key
• Also include latest TESLA key you can disclose
• Receiver buffers ERROR until key is disclosed

76
Secure Route Maintenance

• ROUTE ERRORs can be only an optimization
• Malicious nodes might refuse to send them
• To ensure Ariadne does not persistently use
  non-working routes
• Sources may use multipath routing
• Each packet is acknowledged end-to-end,preferably
  using the reverse path
• Sender should more often choose routes that
  successfully deliver packets
• Never fully stop using an apparently good route
• Short-term Denial-of-Service would otherwise
  result in permanent crippling of that route

77
Ariadne Summary

• Ariadne has three important properties
• It is efficient low CPU and network overhead
• It is secure resilient to compromised nodes
• It operates entirely on-demand
• Source routing makes security easier
• Source can avoid a potentially malicious node
• Source can authenticate each forwarding node
• Relative to all previous work, Ariadne is
• More secure, more efficient, or more general

78
Authenticated Routing (ARAN)

• Authenticated Routing for Ad hoc Networks (ARAN)
  secures AODV using public key crypto
• ARAN secures Route Discovery and ROUTE ERRORs,
  but not against failure to forward packets

79
ARAN Route Discovery Overview

• ARAN Route Discovery similar to AODV, except
• REQUEST packet is signed by the initiator and the
  previous forwarding nodeAllows recipient to
  authenticate previous hop, which it uses in the
  routing table update.

80
ARAN Route Discovery Overview

• ARAN Route Discovery similar to AODV, except
• REQUEST packet is signed by the initiator and the
  previous forwarding node
• REQUEST packet does not contain a metric rather,
  faster paths are preferredThis allows all
  fields of the REQUEST to be immutable, so the
  signature can be made over the entire REQUEST.

81
ARAN Route Discovery Overview

• ARAN Route Discovery similar to AODV, except
• REQUEST packet is signed by the initiator and the
  previous forwarding node
• REQUEST packet does not contain a metric rather,
  faster paths are preferred
• Duplicate suppression and replay prevention uses
  a nonce and a timestampRequires loose time
  synchronization

82
ARAN Route Discovery Overview

• ARAN Route Discovery similar to AODV, except
• REQUEST packet is signed by the initiator and the
  previous forwarding node
• REQUEST packet does not contain a metric rather,
  faster paths are preferred
• Duplicate suppression and replay prevention uses
  a nonce and a timestamp
• Before forwarding a REQUEST
• Check both signatures
• Update routing table to the initiator
• Remove outer signature sign resulting packet

83
ARAN Route Discovery

• Initiator S signs the ROUTE REQUEST

SS
S
A
B
D
C
84
ARAN Route Discovery

• Initiator S signs the ROUTE REQUEST
• First forwarding node remembers the previous hop
  and signs the REQUEST

SS
SS,SA
S
A
B
D
C
REPLY path
85
ARAN Route Discovery

• Initiator S signs the ROUTE REQUEST
• First forwarding node remembers the previous hop
  and signs the REQUEST
• Each subsequent forwarding node
• Removes previous signature, adds its own
• Remembers previous hop (for Route Setup)

SS
SS,SA
SS,SB
S
A
B
D
C
REPLY path
86
ARAN Route Discovery

• Initiator S signs the ROUTE REQUEST
• First forwarding node remembers the previous hop
  and signs the REQUEST
• Each subsequent forwarding node
• Removes previous signature, adds its own
• Remembers previous hop (for Route Setup)

SS
SS,SA
SS,SB
SS,SC
S
A
B
D
C
REPLY path
87
ARAN Route Discovery

• When first ROUTE REQUEST from a Route Discovery
  reaches the target
• Target returns signed REPLY packet along reverse
  path
• Each node forwards REPLY to stored previous hop
• Each node also updates routing table to D

SD,g0
SD,g1
A
B
C
S
D
REPLY path To D
88
ARAN Route Discovery

• When first ROUTE REQUEST from a Route Discovery
  reaches the target
• Target returns signed REPLY packet along reverse
  path
• Each node forwards REPLY to stored previous hop
• Each node also updates routing table to D

SD,g0
SD,g1
SD,g2
A
B
C
S
D
REPLY path To D
89
ARAN Route Discovery

• When first ROUTE REQUEST from a Route Discovery
  reaches the target
• Target returns signed REPLY packet along reverse
  path
• Each node forwards REPLY to stored previous hop
• Each node also updates routing table to D

SD,g0
SD,g2
SD,g1
SD,g3
A
B
C
S
D
REPLY path To D
90
ARAN Route Discovery

• When first ROUTE REQUEST from a Route Discovery
  reaches the target
• Target returns signed REPLY packet along reverse
  path
• Each node forwards REPLY to stored previous hop
• Each node also updates routing table to D

SD,g0
SD,g2
SD,g1
SD,g3
A
B
C
S
D
REPLY path To D
91
ARAN Route Maintenance

• ROUTE ERROR includes source, destination, nonce,
  timestamp, and is signed by intermediate node
• ERROR is forwarded unchanged, thus authorization
  cannot be determined
• Avoid nodes that send excessive ROUTE ERRORs

92
Attacks Specific to ARAN

• Since REQUEST contains two nested signature
• Attacker can remove outer signature and replay
  the REQUEST, which looks like it came directly
  from the initiator.
• Limited benefit since attacker must be on fastest
  path to subvert Discovery, in which case it could
  also act as a repeater.
• Replay attacks are especially dangerous
• Normal nodes must verify and sign REQUEST
• Replaying is much faster, and ARAN finds
  minimum-latency paths

93
Secure AODV (SAODV)

• SAODV, like ARAN, secures AODV using public-key
  cryptography
• SAODV Route Discovery similar to AODV except
• Immutable fields of REQUEST signed by initiator
• Metric authenticated using a hash chain
• Hash chain anchor included in signature

94
SAODV Route Discovery

• Initiator S signs the ROUTE REQUEST
• Signature includes anchor of hash chain
• Also includes best hash chain value (metric 0)

SS,h0
S
A
B
D
C
To S
95
SAODV Route Discovery

• Initiator S signs the ROUTE REQUEST
• Signature includes anchor of hash chain
• Also includes best hash chain value (metric 0)
• Each forwarding node verifies signature, then
• Updates routing table
• Hashes received metric authenticator

SS,h0
SS,h1
S
A
B
D
C
To S
96
SAODV Route Discovery

• Initiator S signs the ROUTE REQUEST
• Signature includes anchor of hash chain
• Also includes best hash chain value (metric 0)
• Each forwarding node verifies signature, then
• Updates routing table
• Hashes received metric authenticator

SS,h0
SS,h1
SS,h2
S
A
B
D
C
To S
97
SAODV Route Discovery

• Initiator S signs the ROUTE REQUEST
• Signature includes anchor of hash chain
• Also includes best hash chain value (metric 0)
• Each forwarding node verifies signature, then
• Updates routing table
• Hashes received metric authenticator

SS,h0
SS,h1
SS,h2
SS,h3
S
A
B
D
C
To S
98
SAODV Route Discovery

• SAODV ROUTE REPLY is a unicast REQUEST
• Uses reverse path established by REQUEST
• New hash chain (generated by target)
  authenticates distance to target
• Forwarding node updates routing table and hashes
  metric authenticator

SD,g0
A
B
C
S
D
To S
99
SAODV Route Discovery

• SAODV ROUTE REPLY is a unicast REQUEST
• Uses reverse path established by REQUEST
• New hash chain (generated by target)
  authenticates distance to target

SD,g0
SD,g1
A
B
C
S
D
To S To D
100
SAODV Route Discovery

• SAODV ROUTE REPLY is a unicast REQUEST
• Uses reverse path established by REQUEST
• New hash chain (generated by target)
  authenticates distance to target

SD,g0
SD,g1
SD,g2
A
B
C
S
D
To S To D
101
SAODV Route Discovery

• SAODV ROUTE REPLY is a unicast REQUEST
• Uses reverse path established by REQUEST
• New hash chain (generated by target)
  authenticates distance to target

SD,g0
SD,g2
SD,g1
SD,g3
A
B
C
S
D
To S To D
102
SAODV Route Discovery

• SAODV ROUTE REPLY is a unicast REQUEST
• Uses reverse path established by REQUEST
• New hash chain (generated by target)
  authenticates distance to target
• Initiator now has a route to the target

SD,g0
SD,g2
SD,g1
SD,g3
A
B
C
S
D
To S To D
103
SAODV Route Maintenance

• SAODV Route Maintenance is like AODV, except
• ROUTE ERRORs are signed by transmitting nodeIn
  AODV, any node is authorized to send a ROUTE
  ERROR another node will act on it only if the
  transmitting node is in fact on its path.

104
Chapter 26 Network Security

• Introduction to the Drib
• Policy Development
• Network Organization
• Availability
• Anticipating Attacks

105
Introduction

• Goal apply concepts, principles, mechanisms
  discussed earlier to a particular situation
• Focus here is on securing network
• Begin with description of company
• Proceed to define policy
• Show how policy drives organization

106
The Drib

• Builds and sells dribbles
• Developing network infrastructure allowing it to
  connect to Internet to provide mail, web presence
  for consumers, suppliers, other partners

107
Specific Problems

• Internet presence required
• E-commerce, suppliers, partners
• Drib developers need access
• External users cannot access development sites
• Hostile takeover by competitor in progress
• Lawyers, corporate officers need access to
  development data
• Developers cannot have access to some corporate
  data

108
Goals of Security Policy

• Data related to company plans to be kept secret
• Corporate data such as what new products are
  being developed is known on a need-to-know basis
  only
• When customer supplies data to buy a dribble,
  only folks who fill the order can access that
  information
• Company analysts may obtain statistics for
  planning
• Lawyers, company officials must approve release
  of any sensitive data

109
Policy Development

• Policy minimize threat of data being leaked to
  unauthorized entities
• Environment 3 internal organizations
• Customer Service Group (CSG)
• Maintains customer data
• Interface between clients, other internal
  organizations
• Development Group (DG)
• Develops, modifies, maintains products
• Relies on CSG for customer feedback
• Corporate Group (CG)
• Handles patents, lawsuits, etc.

110
Nature of Information Flow

• Public
• Specs of current products, marketing literature
• CG, DG share info for planning purposes
• Problems, patent applications, budgets, etc.
• Private
• CSG customer info like credit card numbers
• CG corporate info protected by attorney
  privilege
• DG plans, prototypes for new products to
  determine if production is feasible before
  proposing them to CG

111
Data Classes

• Public data (PD) available to all
• Development data for existing products (DDEP)
  available to CG, DG only
• Development data for future products (DDFP)
  available to DG only
• Corporate data (CpD) available to CG only
• Customer data (CuD) available to CSG only

112
Data Class Changes

• DDFP ? DDEP as products implemented
• DDEP ? PD when deemed advantageous to publicize
  some development details
• For marketing purposes, for example
• CpD ? PD as privileged info becomes public
  through mergers, lawsiut filings, etc.
• Note no provision for revealing CuD directly
• This protects privacy of Dribs customers

113
User Classes

• Outsiders (O) members of public
• Access to public data
• Can also order, download drivers, send email to
  company
• Developers (D) access to DDEP, DDFP
• Cannot alter development data for existing
  products
• Corporate executives (C) access to CD
• Can read DDEP, DDFP, CuD but not alter them
• Sometimes can make sensitive data public
• Employees (E) access to CuD only

114
Access Control Matrix for Policy
O D C E
PD r r r r
DDEP r r
DDFP r, w r
CpD r, w
CuD w r r, w
r is read right, w is write right
115
Type of Policy

• Mandatory policy
• Members of O, D, C, E cannot change permissions
  to allow members of another user class to access
  data
• Discretionary component
• Within each class, individuals may have control
  over access to files they own
• View this as an issue internal to each group and
  not of concern at corporate policy level
• At corporate level, discretionary component is
  allow always

116
Reclassification of Data

• Who must agree for each?
• C, D must agree for DDFP ? DDEP
• C, E must agree for DDEP ? PD
• C can do CpD ? PD
• But two members of C must agree to this
• Separation of privilege met
• At least two different people must agree to the
  reclassification
• When appropriate, the two must come from
  different user classes

117
Availability

• Drib world-wide multinational corp
• Does business on all continents
• Imperative anyone be able to contact Drib at any
  time
• Drib places very high emphasis on customer
  service
• Requirement Dribs systems be available 99 of
  the time
• 1 allowed for planned maintenance, unexpected
  downtime

118
Consistency Check Goal 1

• Goal 1 keep sensitive info confidential
• Developers
• Need to read DDEP, DDFP, and to alter DDFP
• No need to access CpD, CuD as dont deal with
  customers or decide which products to market
• Corporate executives
• Need to read, alter CpD, and read DDEP
• This matches access permissions

119
Consistency Check Goal 2

• Goal 2 only employees who handle purchases can
  access customer data, and only they and customer
  can alter it
• Outsiders
• Need to alter CuD, do not need to read it
• Customer support
• Need to read, alter CuD
• This matches access permissions

120
Consistency Check Goal 3

• Goal 3 releasing sensitive info requires
  corporate approval
• Corporate executives
• Must approve any reclassification
• No-one can write to PD, except through
  reclassification
• This matches reclassification constraints

121
Consistency CheckTransitive Closure
O D C E
PD r r r r
DDEP r r
DDFP r, w r
CpD w r, w w
CuD w r r, w
r is read right, w is write right
122
Interpretation

• From transitive closure
• Only way for data to flow into PD is by
  reclassification
• Key point of trust members of C
• By rules for moving data out of DDEP, DDFP,
  someone other than member of C must also approve
• Satisfies separation of privilege
• Conclusion policy is consistent

123
Network Organization

• Partition network into several subnets
• Guards between them prevent leaks

124
DMZ

• Portion of network separating purely internal
  network from external network
• Allows control of accesses to some trusted
  systems inside the corporate perimeter
• If DMZ systems breached, internal systems still
  safe
• Can perform different types of checks at boundary
  of internal,DMZ networks and DMZ,Internet network

125
Firewalls

• Host that mediates access to a network
• Allows, disallows accesses based on configuration
  and type of access
• Example block Back Orifice
• BO allows external users to control systems
• Requires commands to be sent to a particular port
  (say, 25345)
• Firewall can block all traffic to or from that
  port
• So even if BO installed, outsiders cant use it

126
Filtering Firewalls

• Access control based on attributes of packets and
  packet headers
• Such as destination address, port numbers,
  options, etc.
• Also called a packet filtering firewall
• Does not control access based on content
• Examples routers, other infrastructure systems

127
Proxy

• Intermediate agent or server acting on behalf of
  endpoint without allowing a direct connection
  between the two endpoints
• So each endpoint talks to proxy, thinking it is
  talking to other endpoint
• Proxy decides whether to forward messages, and
  whether to alter them

128
Proxy Firewall

• Access control done with proxies
• Usually bases access control on content as well
  as source, destination addresses, etc.
• Also called an applications level or application
  level firewall
• Example virus checking in electronic mail
• Incoming mail goes to proxy firewall
• Proxy firewall receives mail, scans it
• If no virus, mail forwarded to destination
• If virus, mail rejected or disinfected before
  forwarding

129
Views of a Firewall

• Access control mechanism
• Determines which traffic goes into, out of
  network
• Audit mechanism
• Analyzes packets that enter
• Takes action based upon the analysis
• Leads to traffic shaping, intrusion response, etc.

130
Analysis of Drib Network

• Security policy public entities on outside but
  may need to access corporate resources
• Those resources provided in DMZ
• No internal system communicates directly with
  systems on Internet
• Restricts flow of data to public
• For data to flow out, must pass through DMZ
• Firewalls, DMZ are pump

131
Implementation

• Conceal all internal addresses
• Make them all on 10., 172., or 192.168. subnets
• Inner firewall uses NAT to map addresses to
  firewalls address
• Give each host a non-private IP address
• Inner firewall never allows those addresses to
  leave internal network
• Easy as all services are proxied by outer
  firewall
• Email is a bit tricky

132
Email

• Problem DMZ mail server must know address in
  order to send mail to internal destination
• Could simply be distinguished address that causes
  inner firewall to forward mail to internal mail
  server
• Internal mail server needs to know DMZ mail
  server address
• Same comment

133
DMZ Web Server

• In DMZ so external customers can access it
  without going onto internal network
• If data needs to be sent to internal network
  (such as for an order), transmission is made
  separately and not as part of transaction

134
Application of Principles

• Least privilege
• Containment of internal addresses
• Complete mediation
• Inner firewall mediates every access to DMZ
• Separation of privilege
• Going to Internet must pass through inner, outer
  firewalls and DMZ servers

135
Application of Principles

• Least common mechanism
• Inner, outer firewalls distinct DMZ servers
  separate from inner servers
• DMZ DNS violates this principle
• If it fails, multiple systems affected
• Inner, outer firewall addresses fixed, so they do
  not depend on DMZ DNS

136
Outer Firewall Configuration

• Goals restrict public access to corporate
  network restrict corporate access to Internet
• Required public needs to send, receive email
  access web services
• So outer firewall allows SMTP, HTTP, HTTPS
• Outer firewall uses its address for those of
  mail, web servers

137
Details

• Proxy firewall
• SMTP mail assembled on firewall
• Scanned for malicious logic dropped if found
• Otherwise forwarded to DMZ mail server
• HTTP, HTTPS messages checked
• Checked for suspicious components like very long
  lines dropped if found
• Otherwise, forwarded to DMZ web server
• Note web, mail servers different systems
• Neither same as firewall

138
Attack Analysis

• Three points of entry for attackers
• Web server ports proxy checks for invalid,
  illegal HTTP, HTTPS requests, rejects them
• Mail server port proxy checks email for invalid,
  illegal SMTP requests, rejects them
• Bypass low-level firewall checks by exploiting
  vulnerabilities in software, hardware
• Firewall designed to be as simple as possible
• Defense in depth

139
Defense in Depth

• Form of separation of privilege
• To attack system in DMZ by bypassing firewall
  checks, attacker must know internal addresses
• Then can try to piggyback unauthorized messages
  onto authorized packets
• But the rewriting of DMZ addresses prevents this

140
Inner Firewall Configuration

• Goals restrict access to corporate internal
  network
• Rule block all traffic except for that
  specifically authorized to enter
• Principle of fail-safe defaults
• Example Drib uses NFS on some internal systems
• Outer firewall disallows NFS packets crossing
• Inner firewall disallows NFS packets crossing,
  too
• DMZ does not need access to this information
  (least privilege)
• If inner firewall fails, outer one will stop
  leaks, and vice versa (separation of privilege)

141
More Configuration

• Internal folks require email
• SMTP proxy required
• Administrators for DMZ need login access
• So, allow SSH through provided
• Destination is a DMZ server
• Originates at specific internal host
  (administrative host)
• Violates least privilege, but ameliorated by
  above
• DMZ DNS needs to know address of administrative
  host
• More on this later

142
DMZ

• Look at servers separately
• Web server handles web requests with Internet
• May have to send information to internal network
• Email server handles email with Internet
• Must forward email to internal mail server
• DNS
• Used to provide addresses for systems DMZ servers
  talk to
• Log server
• DMZ systems log info here

143
DMZ Mail Server

• Performs address, content checking on all email
• Goal is to hide internal information from
  outside, but be transparent to inside
• Receives email from Internet, forwards it to
  internal network
• Receives email from internal network, forwards it
  to Internet

144
Mail from Internet

• Reassemble messages into header, letter,
  attachments as files
• Scan header, letter, attachments looking for
  bad content
• Bad known malicious logic
• If none, scan original letter (including
  attachments and header) for violation of SMTP
  spec
• Scan recipient address lines
• Address rewritten to direct mail to internal mail
  server
• Forward letter there

145
Mail to Internet

• Like mail from Internet with 2 changes
• Step 2 also scan for sensitive data (like
  proprietary markings or content, etc.)
• Step 3 changed to rewrite all header lines
  containing host names, email addresses, and IP
  addresses of internal network
• All are replaced by drib.org or IP address of
  external firewall

146
Administrative Support

• Runs SSH server
• Configured to accept connections only from
  trusted administrative host in internal network
• All public keys for that host fixed no
  negotiation to obtain those keys allowed
• Allows administrators to configure, maintain DMZ
  mail host remotely while minimizing exposure of
  host to compromise

147
DMZ Web Server

• Accepts, services requests from Internet
• Never contacts servers, information sources in
  internal network
• CGI scripts checked for potential attacks
• Hardened to prevent attacks from succeeding
• Server itself contains no confidential data
• Server is www.drib.org and uses IP address of
  outer firewall when it must supply one

148
Updating DMZ Web Server

• Clone of web server kept on internal network