Protecting
Network Quality of Service
Against
Denial of Service Attacks
Douglas S. Reeves

S. Felix Wu

Dan Stephenson
NC State / UC Davis / MCNC
DARPA FTN PI Meeting
January 17, 2001
NC State / UC Davis / MCNC
Timetable and Participants
• Start date = August 1999
• Duration = 36 months
• Point of contact = Dr. Kevin Kwiat, AFRL,
kevin.kwiat@rl.af.mil, (315) 330-1692
Douglas Reeves
N.C. State University
reeves@eos.ncsu.edu
(919) 515-2044
S. Felix Wu
U.C. Davis
wu@cs.ucdavis.edu
(530) 754-7070
Dan Stephenson
MCNC
• No clearances
January 17, 2001 -- FTN PI Meeting
2
NC State / UC Davis / MCNC
QoS - A New Vulnerability
• Guaranteeing QoS for a “flow” requires
providing adequate resources
– If you can't get or keep resources, your QoS is denied
• Normal users will try to get maximum QoS
without regard to others
• Malicious users will try to deny quality of
service to others
January 17, 2001 -- FTN PI Meeting
3
NC State / UC Davis / MCNC
The ARQOS Project:
Overview / Basic Strategies
1. Enforceable resource allocation policies, using
pricing
2. Authorization and authentication to protect
QoS signaling
3. Detect QoS attacks (monitor and analyze)
4. Other 8-)
January 17, 2001 -- FTN PI Meeting
4
NC State / UC Davis / MCNC
1.Pricing: Pay as You Go
• Resources are priced, users have to “pay” to
get what they want
• Policies
– "fair" allocations, prioritize users, network
optimization, ...
• Steps
–
–
–
–
Measure demand
Compute prices
Distribute prices
Adjust demand
• “Appropriate" timescale / resource granularity
for pricing?
January 17, 2001 -- FTN PI Meeting
5
NC State / UC Davis / MCNC
(1a. Pricing) Fixed or Variable Prices?
• Some users want lowest price (greatest
resource amount)
• Some users want predictability (fixed resource
amount)
• Goal: support both types of users
January 17, 2001 -- FTN PI Meeting
6
NC State / UC Davis / MCNC
Combining the Two Markets
• Split each resource into "available" and
"reservable" portions
• Users specify their preferences for price vs.
predictability
• Compute prices separately for available and
reservable parts
January 17, 2001 -- FTN PI Meeting
11
NC State / UC Davis / MCNC
User Preferences
January 17, 2001 -- FTN PI Meeting
12
NC State / UC Davis / MCNC
Reservation Market Example
January 17, 2001 -- FTN PI Meeting
13
NC State / UC Davis / MCNC
Results
• Ability to trade off risk (unpredictability) for
reward (low prices) very flexibly
– No other system combines reservations and dynamic
pricing
• Independent of the mechanism for computing
reserved prices
– We predicted future demand from past demand for
demonstration purposes
January 17, 2001 -- FTN PI Meeting
14
NC State / UC Davis / MCNC
(1b. Pricing) Implementation
• Conventional Resource Reservation (no pricing)
January 17, 2001 -- FTN PI Meeting
15
NC State / UC Davis / MCNC
Implementation with pricing (now)
January 17, 2001 -- FTN PI Meeting
16
NC State / UC Davis / MCNC
Implementation with pricing and
authorization (next)
January 17, 2001 -- FTN PI Meeting
17
NC State / UC Davis / MCNC
2. Authorizing Resource Allocation
• Setting up connections
– Control plane: Authenticate, authorize, and manage
requests for services
– Bearer plane: Admission control and resource
reservation
– These have to be coordinated!
• Who does what?
– Hosts request the services
– Session management servers implement the control
plane
– Policy servers and routers implement the bearer
plane
January 17, 2001 -- FTN PI Meeting
18
NC State / UC Davis / MCNC
Network Relationships
January 17, 2001 -- FTN PI Meeting
19
NC State / UC Davis / MCNC
The Evolving Network Model
• Bearer path (even the first hop) highly
changeable
– E.g., mobility
• No one institution owns the whole network any
more
– Multiple carriers
– Multiple service providers
• Businesses will partner, but don't want to share
secrets or relinquish control
– E.g., reluctant to divulge network topology
information
January 17, 2001 -- FTN PI Meeting
20
NC State / UC Davis / MCNC
Our Solution
1. Session Manager authorizes resource allocation
and issues a "ticket" to the Host
2. Ticket is propagated to Policy Servers
3. Policy Server uses ticket to verify request is
authorized
January 17, 2001 -- FTN PI Meeting
21
NC State / UC Davis / MCNC
Solution Example
January 17, 2001 -- FTN PI Meeting
22
NC State / UC Davis / MCNC
Contents of the Ticket (Example)
• Originating party IP address/port #
• Terminating party IP address/port #
• Session identifier
• Media stream characteristics being authorized
• Authorization lifetime (no stockpiling of
tickets!)
• Identity of Session Manager (issuing this ticket)
• Signature of Session Manager
– Prevents tampering with ticket contents
January 17, 2001 -- FTN PI Meeting
23
NC State / UC Davis / MCNC
Authentication of Ticket
• Must not be possible to forge, modify, or reuse
a ticket
• Assume Key Exchange Server (KES) exists and is
trusted
• Signature based on Session Manager's key
• Policy Server requests key of Session Manager
from Key Exchange Server for decryption
– key can be cached to reduce overhead
January 17, 2001 -- FTN PI Meeting
24
NC State / UC Davis / MCNC
Protocol Impacts
• RSVP "Identity Representation"
– Existing proposal for inserting authorization objects
into RSVP messages
• COPS
– Already contains authorization “object”
• Session Description Protocol (SDP)
– a few new fields added to SDP (carried by SIP)
January 17, 2001 -- FTN PI Meeting
25
NC State / UC Davis / MCNC
Discussion
• Compatible with mobile IP networks, appears
attractive for 3G wireless
• Session Manager oblivious to the topology of the
bearer path
• Integrate authorization / authentication with
allocation
– Establish trust before allocating resources
– Introduce "credential" methods to ensure trust
• Topic #1, BAA01-22!
January 17, 2001 -- FTN PI Meeting
26
NC State / UC Davis / MCNC
Results
• Reeves and Christie (Nortel): patent
application, October 2000
• Hamer and Gage (Nortel): IETF submission
draft-hamer-sip-session-auth-00.txt, November
2000
• Prototypes being implemented by Nortel and
N.C. State
January 17, 2001 -- FTN PI Meeting
27
NC State / UC Davis / MCNC
3. Packet Dropping Attacks
• Maliciously cause packets to be dropped
– All packets? Too obvious
– Some random packets
– Some important packets, e.g., retransmission packet
• Hard to detect
– Packet loss might be due to normal network
congestion
January 17, 2001 -- FTN PI Meeting
28
NC State / UC Davis / MCNC
Ways to Implement Dropping Attacks
• Compromise intermediate routers
– Easy to manipulate the victim's traffic
– Hard to detect
– Difficult to accomplish
• Congest intermediate routers
– Hard to accurately control the dropping
– Easier to detect
– Easy to accomplish, e.g., Tribe Flood Network
January 17, 2001 -- FTN PI Meeting
29
NC State / UC Davis / MCNC
Experiment Setting
• 4 FTP Servers
across the Internet
FTP Client on Linux
FTP
FTP
Server
xyz.zip
5.5M
Attack
Agent
Divert
Socket
Data
Packets
January 17, 2001 -- FTN PI Meeting
Interne
t
• FTP client runs
Linux 2.0.36 in
SHANG lab
• Size of downloaded
file is 5.5MB
• Attack Agent
 runs on the same
host as FTP client
 act as a
compromised
router
30
NC State / UC Davis / MCNC
Experiments over the Internet
FTP Client
NCSU
FTP Servers
Heidelberg
NCU
SingNet
UIUC
January 17, 2001 -- FTN PI Meeting
31
NC State / UC Davis / MCNC
Results: Impact on Average Pkt. Delay
300
260.3
250.9
250
Session Delay (s)
218.4
200
183.9
150
Normal
Random
Periodical
Retrans.
125.8
108.2
98.6
86.9
100
77.1
56
63.4
66
62.6
44.6
50
23.6 26.5
0
Heidelberg
NCU
SingNet
UIUC
7 packets are dropped among more than
4000 packets in a connection
January 17, 2001 -- FTN PI Meeting
32
NC State / UC Davis / MCNC
Q-Test Detection Mechanism
• Based on ideas from NIDES-STAT (SRI)
– Collect data on “normal” behavior
– Compare expected distribution vs observed
distribution
– Is the deviation significant?
• Implementation: TDSAM
January 17, 2001 -- FTN PI Meeting
33
NC State / UC Davis / MCNC
Q-Distribution for Position of Dropped Packets
0.2
0.2
0.16
0.16
0.14
0.14
0.12
0.12
0.1
0.08
0.1
0.08
0.06
0.06
0.04
0.04
0.02
0.02
0
0
0
5
10
15
20
Q bins
25
30
0
35
0.2
5
10
15
20
Q bins
25
30
35
0.2
SingNet
0.18
UIUC
0.18
0.16
0.16
0.14
0.14
0.12
0.12
Probability
Probability
NCU
0.18
Heidelberg
Probability
Probability
0.18
0.1
0.08
0.1
0.08
0.06
0.06
0.04
0.04
0.02
0.02
0
0
0
5
10
15
20
Q bins
January 17, 2001 -- FTN PI Meeting
25
30
35
0
5
10
15
20
Q bins
25
30
35
35
NC State / UC Davis / MCNC
Results
• Performance
– False alarm rate: 1.1% ~ 5.8%
– Detection rate: high on most cases except for those
causing very minor damage
• Best results: use combined metrics
January 17, 2001 -- FTN PI Meeting
37
NC State / UC Davis / MCNC
Results: Position Measure
Position
nbin=5
Heidelberg
NCU
SingNet
UIUC
DR
MR
DR
MR
DR
MR
DR
4.0%
-
5.4%
-
3.5%
-
6.5%
Normal*
-
PerPD
(10, 4, 5)
99.7% 0.3% 100%
(20, 4, 5)
100%
(40, 4, 5)
96.6% 3.4% 100%
(20, 20, 5) 100%
0%
0%
-
100% 0.0% 100%
0%
98.1% 1.9% 99.2% 0.8% 100%
0%
100%
0%
MR
0%
100%
0%
98.5% 1.5%
0%
100%
0%
100%
0%
(20, 100, 5) 98.9% 1.1%. 99.2% 0.8% 99.6% 0.4% 99.1% 0.9%
(20, 200, 5)
0%
100% 76.5% 23.5% 1.5% 98.5% 98.3% 1.7%
(100, 40, 5) 0.2% 99.8%
0%
100%
0%
100% 100%
0%
RetPD
(5, 5)
RanPD
10
0%
100% 42.3% 57.7%
0%
100%
0%
100%
40
0%
100%
0%
100%
0%
100%
Intermittent
(10, 4, 5)
84.9% 15.1% 81.1% 18.9% 94.3% 5.7% 97.4% 2.6%
0%
100%
5
98.6% 1.4% 100%
50
34.1% 65.9% 11.8% 88.2% 89.4% 10.6% 94.9% 5.1%
January 17, 2001 -- FTN PI Meeting
0%
98.2% 1.8% 100%
0%
38
NC State / UC Davis / MCNC
Results: Delay Measure
Delay
Heidelberg
NCU
SingNet
UIUC
nbin=3
DR
MR
DR
MR
DR
MR
DR
MR
Normal*
-
1.6%
-
7.5%
-
2.1%
-
7.9%
-
PerPD
(10, 4, 5)
97.4%
2.6%
95.2%
4.8%
94.5%
5.5%
99.2%
0.8%
(20, 4, 5)
99.2%
0.8%
98.5%
1.5%
100%
0%
100%
0%
(40, 4, 5)
100%
0%
100%
0%
100%
0%
100%
0%
(20, 20, 5)
96.3%
3.7%
100%
0%
92.6%
7.4%
98.9%
1.1%
(20, 100, 5)
100%
0%
95.3%
4.7%
98.7%
1.3%
100%
0%
(20, 200, 5)
98.6%
1.4%
99%
1%
97.1%
2.9%
100%
0%
(100, 40, 5)
100%
0%
100%
0%
100%
0%
100%
0%
RetPD
(5, 5)
100%
0%
100%
0%
100%
0%
100%
0%
RanPD
10
74.5%
25.5%
26.8%
73.2%
67.9%
32.1%
99.5%
0.5%
40
100%
0%
100%
0%
100%
0%
100%
0%
Intermittent
5
25.6%
74.4%
0%
100%
0%
100%
97.3%
2.7%
(10, 4, 5)
50
0%
100%
24.9%
75.1%
0%
100%
3.7%
96.3%
January 17, 2001 -- FTN PI Meeting
39
NC State / UC Davis / MCNC
Results: Packet Loss Rate Measure
NPR
Heidelberg
nbin=2
NCU
SingNet
UIUC
DR
MR
DR
MR
DR
MR
DR
MR
Normal*
-
4.5%
-
5.8%
-
8.2%
-
2.9%
-
PerPD
(10, 4, 5)
0%
100%
14.4%
85.6%
29.1%
70.9%
100%
0%
(20, 4, 5)
83.1%
16.9%
94.2%
5.8%
95.2%
4.8%
100%
0%
(40, 4, 5)
100%
0%
97.4%
2.6%
100%
0%
100%
0%
(20, 20, 5)
91.6%
8.4%
92%
8%
93.5%
6.5%
100%
0%
(20, 100, 5)
94.3%
5.7%
92.2%
7.8%
96.4%
3.6%
100%
0%
(20, 200, 5)
0%
100%
96.5%
3.5%
94.8%
5.2%
100%
0%
(100, 40, 5)
100%
0%
100%
0%
100%
0%
100%
0%
RetPD
(5, 5)
0%
100%
84.7%
15.3%
23.9%
76.1%
46.5%
53.5%
RanPD
10
0%
100%
0%
100%
100%
0%
100%
0%
40
100%
0%
100%
0%
100%
0%
100%
0%
Intermittent
5
0%
100%
0%
100%
82.2%
17.8%
100%
0%
(10, 4, 5)
50
0%
100%
1%
99%
40%
60%
64.8%
35.2%
January 17, 2001 -- FTN PI Meeting
40
NC State / UC Davis / MCNC
4. Policy Consistency Checking
• IPSec policies are created by administrators to
establish VPNs
• The set of policies is supposed to implement a
set of high-level requirements
– Ex. policy 1 + policy 2 + policy 3 = no data
transmitted in the clear between site A and site B
• How can you tell if set of policies conflicts?
January 17, 2001 -- FTN PI Meeting
41
NC State / UC Davis / MCNC
Example of a Policy Conflict
H1
FW1
SW2
H2
• Security policies
– P1 = all packets from H1 to H2 must be authenticated
to SW2
– P2 = all packets from H1 to H2 must be encrypted from
FW1 to SW2
• Result
– P1 changes src/dest of packets from H1/H2 to H1/SW2
– P2 is not invoked on these packets, which are therefore
not encrypted
– Security breach!
January 17, 2001 -- FTN PI Meeting
42
NC State / UC Davis / MCNC
Status
 Define language to specify high-level
requirements
 Define what consistency checking of policies
means
Create polynomial algorithm to check for
conflicts
Resolve policy conflicts if they are found
• Tech transfer opportunity with Nortel
January 17, 2001 -- FTN PI Meeting
43
NC State / UC Davis / MCNC
Deliverables
• Accomplished
– Congestion pricing system papers
– Papers: iwqos, icnp (3 times), net2k, policy 2001, ...
– Software: packet dropping attack analysis, RSVP
authentication
– Patents, standards submissions, implementation:
tech transfer to Nortel
• Future
– Software: RSVP / policy server / COPS,
Authorization, TCP with pricing, DiffServ attack
analysis
– Final report
January 17, 2001 -- FTN PI Meeting
44