Tracing

1
Tracing Traceability
S. Felix Wu UC Davis http//www.cs.ucdavis.edu/wu
wu_at_cs.ucdavis.edu
2
Traceability

• spoofing/hiding the origin
• network/host/process identities
• distributed network/system level information
• security (worm), fault (routing), performance

3
What is the problem?

• Egress/ingress filtering possible??
• Locating the slaves (compromized hosts in
  Universities, e.g.) is a good first step.
• Probably easiest to find.
• Cut them off to help.
• Further track down masters and the attacker.
• Recent Proposed Solutions
• discovery the route paths from Slaves to the
  victim.
• Information sometimes useful to distinguish
  malicious DDoS attacks (from a few slaves) versus
  Internet traffic hot spots.

4
Each slave emits a relatively small amount of
attack packets
Slaves
Victim
Masters
Attackers
src random dst victim

.com
...
ISP
.
This will be a problem for any static
probabilistic schemes.
5
Example An Attack Path
12
1
6
11
14
attacker
2
4
10
0
13
3
target
7
15
5
8
9
6
Attack Path Traceback Problem

• An attack path is an ordered list of nodes along
  which the attack packets traveled between Ai and
  vt .
• The traceback problem is to find the attack path
  and the associated attack origin for each
  attacker.

7
Probabilistic Marking and Sampling

• Savage and others an encoding algorithm (by
  overloading 16-bit IP Identification field used
  for fragmentation) such that all the intermediate
  routers will probabilistically mark in-flight
  packets with partial path information. Each
  marked packet will represent asample of the
  path it has traveled.
• Node sampling 32-bit router address
• The probability of receiving a marked packet from
  a router d hops away is p(1-p)(d-1).
• Ranking each router by the number of samples it
  contributes will tend to produce the accurate
  attack path.
• However, producing the path from the sample
  distribution is a slow process and possibly
  incorrect.
• Not robust under DDoS with multiple attackers
  from the same distance.

8
Packet Marking
Slaves
Victim
Masters
Attackers
src random dst victim

.com
...
ISP
.
9
Probabilistic Edge Marking and Sampling
Marking procedure at router R for each
packet w let x be a random number
from 0..1) if x lt p then
write R into w.start and 0 into
w.distance else if
w.distance 0 then
write R into w.end increment
w.distance
Path reconstruction procedure at victim v
let G be a tree with root v let edges in
G be tuples (start, end, distance) for
each packet w from attacker if
w.distance 0 then insert edge
(w.start, v, 0) into G else
insert edge (w.start, w.end, w.distance )
into G remove any edge (x, y,d) with d
! distance from x to v in G extract
path (Ri.Rj) by enumerating acyclic paths in G
10
Encoding edge fragments into the IP
identification field

• IP ID field should not be changed if
  fragmentation is necessary.

• Song, Franklin proposed improved advance
  marking schemes for IP ID field.

11
Probabilistic Marking???
Reflectors
Slaves
Find a special honey-pot reflectors???
???
Victim
???
Masters
Attackers
src victim dst reflector

.com
...
ISP
.
src reflector dst victim
12
portscan Honeypot
portscan 128.3X.XX.XXX Port 21 ("ftp" service)
connection ... open. Port 23 ("telnet"
service) connection ... open. Port 25 ("smtp"
service) connection ... open.
The hackers will not know which IP addresses have
been aggregated into a honey-pot. If a good
portion of the reflectors for a particular slave
belongs to a single portscan Honeypot.
13
ICMP Traceback

• For a very few packets (about 1 in 20,000), each
  router will send the destination a new ICMP
  message indicating the previous hop for that
  packet.
• Net traffic increase at endpoint is about .1 --
  probably acceptable.
• Issues authentication, loss of traceback
  packets, load on routers.

14
Probabilistic ICMP Traceback Sampling

• bellovin When forwarding packets, router can
  randomly generate a new ICMP traceback message
  (ITRACE) with a low probability (e.g., 1/20,000)
  along the path and sent to the destination. The
  information in samples can then be chained
  together to construct the path.
• Each ITRACE contains
• back link on the previous hop
• forward link on the next hop
• timestamp
• traced packet
• authentication for preventing fake traceback
  messages.

15
iTrace Packets
12
1
6
11
14
iTrace
2
4
10
0
13
iTrace
3
target
7
15
5
8
slave
9
16
Original iTrace
Slaves
Victim
Masters
Attackers
src random dst victim

.com
...
ISP
.
17
iTrace in Reflective DDOS
Reflectors
Slaves
Victim
Masters
Attackers
src victim dst reflector

.com
...
ISP
.
src reflector dst victim
18
ICMP Traceback

• For a very small probability (about 1 in 20,000),
  each router will send the destination (and/or the
  source) a new ICMP message indicating the
  previous hop for that packet.
• Net traffic increase at endpoint is probably
  acceptable.

iTrace it or not??
19
Each slave emits a relatively small amount of
attack packets
Slaves
Victim
Masters
Attackers
src random dst victim

.com
...
ISP
.
This will be a problem for any static
probabilistic schemes.
20
Reflector

• Use a legitimate network server/client as the
  reflector to avoid being traced. (stepping stone).

Reflector
Service Reply Packet src Reflector
dst Victim
Service Request Packet src Victim dst Reflector
Victim
Slave
21
Who has spoofed me??
Reflector
Service Request Packet src Victim dst Reflector
Service Reply Packet src Reflector
dst Victim
source Traceback Messages
Victim
Slave
22
Improved iTrace
Reflectors
Slaves
Victim
Masters
Attackers
src victim dst reflector

.com
...
ISP
.
src reflector dst victim
23
iTrace Probability 1/20,000
Attack traffic
Background traffic
For a router with lots of background traffic,
it will take a long time before we really
generate a useful iTrace.
24
Usefulness of iTrace messages

• finding the right attack paths.
• attack packets

25
Value(iTrace) (Attack(iTrace)
Intention(dst-ID) hopCount(rtr-ID ? dst-ID)
Received(ID ? dst-ID)
Generated(rtr-ID)
1th useful itrace
26
iTrace Probability 1/20,000
A high-rate attack flow from the slave
A low-rate attack flow from the slave
Aggregation of lower-rate flows at routers near
the victims
For routers closer to the victim, valid iTrace
messages will be produced very frequently. But,
for routers closer to a slave with a low packet
rate, it can take a long time, statistically, for
the right iTrace messages to be generated.
27
Intention-driven iTracedistribute the Internet
tracing resources

• Different destination hosts, networks,
  domains/ASs have different intention levels in
  receiving iTrace packets.
• Some of them might not care about iTrace, and
  some of them might not be under DDoS attacks, for
  example.

28
iTrace ?Intention iTrace

• Tracing Resources
• Fixed, 1/20,000 packets
• Stateless
• Edge/Core coordination
• Practical Consideration
• Internet-wide Scalability
• Partial Deployment
• Minimum Changes to the Routing Infrastructure

29
A simple design
iTrace Process
BGP table packet T(I) iTrace
count flag bit
Compute traffic distribution for every 20,000
packets (roughly the size of the BGP table --
when a route entry in the BGP table is
referenced, add one to that counter.).
Then, for each BGP entry, compute the iTrace
message probability PiTrace(I). Finally, get a
random number between 0 and 1 to determine which
entry should receive an iTrace message.
30
Intention-Driven iTrace architecture
(draft-ietf-itrace-intention-01.txt)
BGP routing table
iTrace generation module
intention iTrace trigger?? P
Intention selection module
iTrace intention bits
intention iTrace trigger
copy
copy
User (firmware)
Kernel (hardware)
iTrace Execution bit
1/20K iTrace selection
packet- forwarding table
31
Processing Overhead
1/20K iTrace message trigger occurs 1. Select
and Set one iTrace Intention bit from the BGP
table.
Processing for each data packet 1. if the iTrace
Execution bit is 1, (1). Copy this packet to the
iTrace daemon. (2). reset the iTrace Execution
bit to 0.
32
I(n) iTrace bit
152.1.23.0/24
0
(1). Before iTrace trigger
169.20.3.0/24
0
192.1.0.0/16
0
207.3.4.183/20
0
152.1.0.0/16
0
155.0.0.0/16
0
152.1.23.0/24
0
(2). After iTrace trigger
169.20.3.0/24
0
192.1.0.0/16
0
207.3.4.183/20
0
152.1.0.0/16
1
155.0.0.0/16
0
33
I(n) iTrace bit
152.1.23.0/24
(3). After iTrace sent
0
169.20.3.0/24
0
192.1.0.0/16
0
207.3.4.183/20
0
152.1.0.0/16
0
155.0.0.0/16
0
34
Schemes 1 2
35
FRiTrace

• Edge Passive Tracing
• ISP and Router Venders resistance
• Lets start using iTrace as end users
• Intention is just a downloadable configuration
  file

36
Signaling (BGP extension)
AS800
AS 100
Intention-bit update request
AS200
IDS
AS 120
AS900
AS250
AS300
BGP update prefix 900 attribute Intend to
receive iTrace
AS500
AS600
AS700
37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
IETF iTrace has been killed!!

• No killer application!
• The victim would know, hopefully, where the
  attack sources are.
• But, why would this be ever useful?

43
But, why was iTrace proposed

• In the inter-domain Internet, we have very
  limited mechanisms to monitor and analyze the
  traffic/application behavior.
• distributed network/system management information
• a bunch of SNMP/MIBs (scattered and they are not
  forming a global view effectively).
• ICMP is all we have..

44
Example iTrace

• the FRiTrace software package
• running against your LAN and send out iTrace
  messages statistically
• router X has seen this packet (of yours) at
  1135 p.m. today.
• I could have added BTW, the BGP route path
  toward you is or the rate of packets toward
  your network has been.
• A few iTrace applications are considered
  initially, but the list is extensible via a
  controlled and moderated open source
  development process.
• Intention registry
• http//www.itrace.org/intention.txt

45
IETF iTrace has been killed!!

• No killer application!
• The victim would know, hopefully, where the
  attack sources are.
• But, why would this be ever useful?

46
Wrong or Incomplete Information Economics

• The information is given to the entity (the
  victim) that can do probably nothing about the
  source of the problem (foreign domains).
• We dont really need iTrace information to do
  local defense.
• The foreign domains/ISPs have very little
  incentive to provide iTrace information.
• To get sued?
• How to recover the cost?

47
SUITScaleable Universal Internet Tagging

• One entity observes a piece of original
  information, and it adds a special tag
  representing a query.
• A query regarding this piece of information.
• The tagged information is received by another
  entity
• Between here and the victim.
• The other entity interprets the tag, and provides
  the answer to the query.

48
iTrace ? SUITScaleable Universal Internet Tagging

• An AS picks one data packet with Prob(1/20K)
• iTrace (a Router) ? SUIT (an AS)
• Generate a tag
• This tag might be just a 1024-bit secure random
  .
• Send an SUIT message toward the destination IP
  address
• Global universal query about the packet (or the
  destinations) might be attached
• Example Is this packet part of a DDoS flooding

49
SUIT
Resource Contention
Dynamic Horizontal Separation
IDS
50
Better Information Economics

• The information is given to the entity (the
  foreign domain or ISP) that can do something
  about the source of the problem.
• Example Unwanted Traffic Filtering
• Everybody has some reasonable incentive to
  collaborate (as an example)
• ISP I spend resources to generate a SUIT, but
  hopefully, I will be able to get some IDS results
  from somewhere else to allow me to perform better
  local defense.
• Victim I am under attacks and I hope that the
  attacks could be filtered much earlier.

51
Remarks

• We do have technical solutions to solve the
  tracing problem, but the economic model is not
  clear in general.
• 50 academic papers ? probably no real impact
• For tracing in the Internet,
• User community sharing based on FRiTrace
• SUIT a better information economics
• Something else?