Protecting
Network Quality of Service
Against
Denial of Service Attacks
Douglas S. Reeves  S. Felix Wu
NC State / UC Davis / MCNC
DARPA FTN PI Meeting
August 2, 2001
NC State / UC Davis / MCNC
Timetable and Participants
• Start date = August 1999
• Duration = 36 months (+extension)
• Point of contact = Dr. Kevin Kwiat, AFRL,
kevin.kwiat@rl.af.mil, (315) 330-1692
Douglas Reeves, Peter Wurman
N.C. State University
{reeves,wurman}@csc.ncsu.edu
(919) 515-2044
S. Felix Wu
U.C. Davis
wu@cs.ucdavis.edu
(530) 754-7070
Dan Stephenson,Xiaoyong Wu
MCNC
{stevenso,xwu}@mcnc.org
• No clearances
August 2, 2001 -- FTN PI Meeting
2
Scope of the Project
Category
Control Flow
Protect
Intserv
Detect
Attacks
NC State / UC Davis / MCNC
Data Flow
Protect
Prevention from
Misuse
Detect Attacks
•RSVP
authenticat
ion
•Pricing
•Trust-based
allocation
•Reliable multicast
1.
DiffServ
•Reliable
Queue
Management
multicast
•Packet
dropping
analysis
2.
Security
Policy
Application
level
Traceback
Intrusion •Pricing
detection
IPSec Policy
generation,
correctness
•Watermar
king,
Traffic
August 2, 2001 -- FTN PI Meeting
correlation
3
NC State / UC Davis / MCNC
Results
• Accomplished
– Approximately 15 published papers to date
– 5 students graduated, 7 more in progress
– Software: packet dropping attack analysis,
RSVP authentication, RSVP pricing, trustbased allocation (and more to come)
– Patent and standards submissions
– Collaborations with Nortel
August 2, 2001 -- FTN PI Meeting
4
NC State / UC Davis / MCNC
Disappointments (Failures)
• Failure of QoS to be deployed on a widespread
basis in the Internet
– lack of security / fault tolerance a major reason?
• Pricing
– requirements for adoption
• TCP Packet Dropping attacks
– limitations of neural nets
August 2, 2001 -- FTN PI Meeting
5
NC State / UC Davis / MCNC
1. DiffServ Intrusion Detection
• Work by Xiaoyong Wu of MCNC
August 2, 2001 -- FTN PI Meeting
6
NC State / UC Davis / MCNC
DiffServ Components
H
C
E
C
C
C
H
•Vulnerabilities
E
H
H
E
H
C
E
H
-Packet dropping
-Packet remarking
-Packet delaying
August 2, 2001 -- FTN PI Meeting
7
NC State / UC Davis / MCNC
Intrusion Detection Architecture
• Network monitoring
– DiffServ aggregated flow
monitor
– Micro-flow traffic monitor
• Anomaly (statistical
analysis) detection
• Rule based detection
• Detection and analysis
result correlation
August 2, 2001 -- FTN PI Meeting
Local & Remote
Correlation
Stat
Rule
DSMon TrafMon
Linux Kernel
DiffServ
Implementation
LibPCAP
Fast Packet
Capturing
8
NC State / UC Davis / MCNC
Network Monitors
• Communicate with Statistical Analysis and Rulebased Detection Modules
• Monitor Both Aggregated Flows and Microflows
• DiffServ aggregated flow monitor
– Periodically extract statistical values from Linux
kernel using Traffic Controller Library (libtc)
– Bytes and packets delivered
– Over-limit and dropped packets
• Micro-flow traffic monitor
– Micro-flow is defined by a traffic filter
– Uses Fast Packet Capturing (libpcap)
August 2, 2001 -- FTN PI Meeting
9
NC State / UC Davis / MCNC
NIDES/JiNao Statistical Analysis
(Anomaly-based detection)
• Goodness of Fit Test
– H0: The data follows a "given" distribution
– H1: The data does not follow the specified distribution
• Obtain the Chi-Squared Value
– O = Observed value
– E = Expected value
– c2 = S (((O-E)2)/E)
• Notes
– The range of c2 is from 0 to infinity
August 2, 2001 -- FTN PI Meeting
10
NC State / UC Davis / MCNC
Similarity “Score”
• Counting Measures
– Byte count and packet count
• Score Value - "Normalized" Q Value
– S = F-1(1-(TP/2))
– TP = Pm + Pm+1 + ... + Pmax
 F is the cumulative distribution function of a N(0,1)
variable
– Pm is the relative frequency with which c2 belongs to the mth
interval
– M and max are manually selected at present
August 2, 2001 -- FTN PI Meeting
11
NC State / UC Davis / MCNC
Long Term Q Distribution Examples
• Background Traffic
(Poisson)
– 4Mbps
– Byte counts
• Audio Traffic
(Periodic)
– 64Kbps
– Byte counts
August 2, 2001 -- FTN PI Meeting
12
NC State / UC Davis / MCNC
Rule Based Detection
• Meant to Detect Known Attacks and
Vulnerabilities
• Rules from RFC's and Real Deployments
– Expedited Forwarding
• No-Dropping Rule of inlimit traffic
• No-Overlimit Rule, within diffserv network
– Static Traffic Markings (DSCP's)
• Mark Mapping Rule for a microflow
August 2, 2001 -- FTN PI Meeting
13
NC State / UC Davis / MCNC
Attack Implementation
• Linux Kernel Module
– Runs in kernel space
– Uses proc file system to configure
• Emulated Scenarios
– Planned: tunable packet delay distributions
– congestion and background loss – aggregated flow
– bandwidth limitation -- microflow
– Planned: packet reordering / duplication
August 2, 2001 -- FTN PI Meeting
14
NC State / UC Davis / MCNC
Traffic Generation Tools
• tcpTalk
– Audio Traffic
– TCP
• MGEN
– Background Traffic and Attack Traffic
– UDP
– CBR or Poisson
• Thttp (future)
–
–
–
–
Background Traffic
TCP (HTTP, FTP, SMTP, NNTP, etc.)
Emulate the traffic at the Internet core
Generate the packets based on the pre-calculated distributions
August 2, 2001 -- FTN PI Meeting
15
NC State / UC Davis / MCNC
Detection Scenario and Performance
•
•
R1, R2 are 2 DiffServ routers with IDS
running
– R1 and R2 collect long term behaviors for
BE traffics and EF traffics
– R1 is compromised and starts to mark
one BE flow as EF
– Rule detection on R2 notices change of
marking for BE flow
– Accumulated increased EF traffics deviate
from the long term EF behavior
– Stat analysis on R2 notices the deviation
Performance
– With 1% false alarm rate we can get
100% detection rate
August 2, 2001 -- FTN PI Meeting
BE
EF
R1
R2
16
NC State / UC Davis / MCNC
Detection Results
STAT
FLOODING
DROPPING
REMARKING
--STEALING
REMARKING
--SWITCHING
Yes
Yes
Yes
D/S
No
Yes
Yes
RULENo
Based
August 2, 2001 -- FTN PI Meeting
17
NC State / UC Davis / MCNC
Collaboration and Future Work
• Collaboration with Avaya Systems
– Network evaluation for Voice over IP solutions
– Interested in the impact of intrusions on voice traffic
– Interested in monitoring mechanisms
• Local and Remote Correlation
– Bayesian belief networks
August 2, 2001 -- FTN PI Meeting
18
NC State / UC Davis / MCNC
2. IPSec Policy Generation and
Correctness
• “Policy conflicts” for IPSec/VPN:
– what will possibly go wrong?
• Requirement versus Policy
– what are their relationship?
August 2, 2001 -- FTN PI Meeting
19
NC State / UC Davis / MCNC
IPSec Policy:
Implementation Policy
• Policy:
– if <condition> then <action>
• IPSec policy:
– Condition: src,dst,src-port,dst-port, protocol, …
– Action:
Deny | Allow | ipsec (entry, exit, mode, sec-prot, alg)
• Example:
– Condition: src=A, dst=B, port=*, prot=TCP
– Action:
ipsec (Rb, Rd, tun, ESP, 3DES)
Rb,Rd, ESP A, B
A
August 2, 2001 -- FTN PI Meeting
Rb
A, B
Rc
Rd
B
20
NC State / UC Davis / MCNC
Example Conflict #1:
Privacy and Content Examination
X
A
Y
SG-1
SG-2
B
(1.[srcIP=A dstIP=B prot=TCP srcPort=ANY dstPort=ANY] 
IPSec Prot=ESP Mode=Transport
Algorithm=3DES
from=A to=B)
(2.[srcIP=* dstIP=* prot=ESP srcPort=ANY dstPort=ANY]  deny )
August 2, 2001 -- FTN PI Meeting
21
NC State / UC Davis / MCNC
Example Conflict #2:
Selector Confusion
X
A
Y
SG-1
SG-2
B
(1.[srcIP=A dstIP=B prot=ANY srcPort=ANY dstPort=ANY] 
IPSec Prot=AH Mode=Tunnel
Algorithm=HMAC-SHA
from=A to=SG-2)
(2.[srcIP=A dstIP=B prot=ANY srcPort=ANY dstPort=ANY]  allow)
(3.[srcIP=* dstIP=* prot=ANY srcPort=ANY dstPort=ANY]  deny )
August 2, 2001 -- FTN PI Meeting
22
NC State / UC Davis / MCNC
Example Conflict #3:
Tunnel Overlapping
SG-1.1, SG-2
A
A, B
A, B
SG-2
B
SG-1.1
SG-1
SG-1,SG-2.1
SG-1.1, SG-2
SG-2.1
A, B
SG-1.1, SG-2
A, B
(1.[srcIP=A dstIP=B prot=ANY srcPort=ANY dstPort=ANY] 
IPSec Prot=ESP Mode=Tunnel
Algorithm=3DES
from=SG-1.1 to=SG-2 )
(2.[srcIP=* dstIP=* prot=ANY srcPort=ANY dstPort=ANY] 
IPSec Prot=ESP Mode=Tunnel
Algorithm=Blowfish
from=SG-1
to=SG-2.1)
August 2, 2001 -- FTN PI Meeting
23
NC State / UC Davis / MCNC
Policy Conflict
IPSec/VPN Policy
• A set of (implementation) policies does not quite
work well together such that the packets
(information bits) are either dropped or
revealed/sent unsafely.
• Requirement(s): Intention(s) behind the
implementation-level policies:
• e.g., I want to maintain the privacy of certain flows:
– IPSec ESP Tunnels.
• Conflicts:
• a set of policies together does not support the requirements
• requirements conflict among themselves.
August 2, 2001 -- FTN PI Meeting
24
NC State / UC Davis / MCNC
Policy versus Requirement
• Policy: (implementation, low-level)
• How should a network entity or a policy domain handle a
particular flow of packets functionally?
• Currently, the processing is based on the selector (i.e.,
the packet header information).
• Requirement: (intention, high-level)
• How should a particular set/flow of packets (information
bits) be protected and handled from A to B?
• Even if the packet header changes, the information bits
in the payload should still be protected in the same way.
August 2, 2001 -- FTN PI Meeting
25
Policy versus Requirement
NC State / UC Davis / MCNC
a set of policy
a requirement
or
a set of policy
a set of policy
a requirement
a set of policy
August 2, 2001 -- FTN PI Meeting
26
NC State / UC Davis / MCNC
Policy Analysis
a requirement
a requirement
a set of policy
a set of policy
a set of policy
????
a requirement
August 2, 2001 -- FTN PI Meeting
27
NC State / UC Davis / MCNC
IPSec Security Requirements (1)
• Access Control Requirement (ACR)
– Restrict access only to trusted traffic
• E.g. Deny all telnet traffic
• Security Coverage Requirement (SCR)
– Apply security functions to prevent traffic from
being compromised during transmission across
certain area. +who can be trusted?
trusted
H1
Rb
Rd
H2
Encryption or Authentication
August 2, 2001 -- FTN PI Meeting
28
NC State / UC Davis / MCNC
IPSec Security Requirement (2)
• Content Access Requirement (CAR)
– Specify the needs to access content of certain traffic
CMR: modify
CER : examine
I will examine the content for intrusion detection
• Security Association Requirement (SAR)
– Specify trust/distrust relationship in SA setup
X
Can not set up SA
August 2, 2001 -- FTN PI Meeting
29
NC State / UC Davis / MCNC
Security Requirement Satisfaction (1)
• Access Control Requirement - deny or allow
• Security Coverage Requirement
– All the links and nodes in the area will need to be covered
by specified security
No!
H1
Rb
Rc
Rd
H2
Rd
H2
Encryption
Yes!
H1
Rb
Rc
Encryption
August 2, 2001 -- FTN PI Meeting
30
NC State / UC Davis / MCNC
Security Requirement Satisfaction (2)
• Content Access Requirement
– Certain node needs to access the content, Rb? Rc?
Rb: No!
Rc: Yes!
H1
Rb
Rc
Rd
H2
• Security Association Requirement
– Some nodes are not allowed to set up SA
August 2, 2001 -- FTN PI Meeting
31
NC State / UC Davis / MCNC
IPSec Requirement Spec.
• Formal specification:
• ACR-SCR-CAR-SAR
• Conflict Detection in Requirements:
• Requirement Satisfiability Problem (RSP): given a set of
requirements, an algorithm to check whether at all possible to
find a set of policies to satisfy all the requirements.
• Completeness Proof
• Policy Determination:
• Transformation: if possible, an algorithm to find the “optimal”
set of policies.
• Correctness and Efficiency
August 2, 2001 -- FTN PI Meeting
32
NC State / UC Davis / MCNC
Example (per flow):
1
2
SCR#1:
Coverage:
SCR#2:
SCR#3:
Content:
CAR#1:
SAR#1:
SA relation: SAR#2:
SAR#3:
August 2, 2001 -- FTN PI Meeting
3
4
5
ENC 2-4 trusted 3
AUTH 1-4 trusted 3
ENC 3-5 trusted 4
(ENC, AUTH)
by 4
not-ENC
2-5
not-ENC
1-5
not-AUTH
1-4
33
NC State / UC Davis / MCNC
Solution:
ENC
ENC
AUTH
1
AUTH
2
3
SCR#1:
Coverage:
SCR#2:
SCR#3:
Content:
CAR#1:
SAR#1:
SA relation: SAR#2:
SAR#3:
August 2, 2001 -- FTN PI Meeting
4
5
ENC 2-4 trusted 3
AUTH 1-4 trusted 3
ENC 3-5 trusted 4
(ENC, AUTH)
by 4
not-ENC
2-5
not-ENC
1-5
not-AUTH
1-4
34
NC State / UC Davis / MCNC
Policy Generation CPU Time
August 2, 2001 -- FTN PI Meeting
35
NC State / UC Davis / MCNC
Number of Policy Rules Generated
August 2, 2001 -- FTN PI Meeting
36
NC State / UC Davis / MCNC
Results
• Collaboration with Nortel Networks
• For more information:
– Policy’2001: requirement specification language
– DSOM’2001: automatic policy generation algorithms.
August 2, 2001 -- FTN PI Meeting
37