Protecting Network Quality of Service Against Denial of Service Attacks

Protecting Protecting Network Quality of Service Network Quality of Service

Against Against Denial of Service AttacksDenial of Service Attacks

Douglas S. Reeves S. Felix Wu

DARPA FTN PI Meeting August 2, 2001

NC State / UC Davis / MCNC

August 2, 2001 -- FTN PI Meeting

2


Timetable and ParticipantsTimetable and Participants• Start date = August 1999

• Duration = 36 months (+extension)

• Point of contact = Dr. Kevin Kwiat, AFRL, [email protected], (315) 330-1692

• No clearances

Douglas Reeves, Peter Wurman

N.C. State University{reeves,wurman}@csc.ncsu.edu(919) 515-2044

S. Felix Wu U.C. [email protected](530) 754-7070

Dan Stephenson,Xiaoyong Wu

MCNC{stevenso,xwu}@mcnc.org


3


Scope of the ProjectScope of the ProjectCategory Control Flow Data Flow Prevention from

Misuse

Protect Detect Attacks

Protect

Detect Attacks

Intserv •RSVP authentication

•Pricing

•Trust-based allocation

•Reliable multicast

DiffServ 1. Intrusion detection

•Pricing

Queue Management

•Reliable multicast

•Packet dropping analysis

Security Policy

2. IPSec Policy generation, correctness

Application level Traceback

•Watermarking, Traffic correlation


4


ResultsResults

• Accomplished– Approximately 15 published papers to

date– 5 students graduated, 7 more in progress– Software: packet dropping attack

analysis, RSVP authentication, RSVP pricing, trust-based allocation (and more to come)

– Patent and standards submissions– Collaborations with Nortel


5


Disappointments (Failures)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


6


1. DiffServ Intrusion Detection1. DiffServ Intrusion Detection

• Work by Xiaoyong Wu of MCNC


7


DiffServ ComponentsDiffServ Components

H

HH

H

HH

CE

EE

E C

CC

C

•Vulnerabilities-Packet dropping-Packet remarking-Packet delaying


8


Intrusion Detection ArchitectureIntrusion Detection Architecture

• Network monitoring– DiffServ aggregated

flow monitor– Micro-flow traffic

monitor

• Anomaly (statistical analysis) detection

• Rule based detection• Detection and analysis

result correlation

DSMon TrafMon

Stat Rule

Linux KernelDiffServ

Implementation

LibPCAPFast Packet Capturing

Local & RemoteCorrelation


9


Network MonitorsNetwork Monitors

• Communicate with Statistical Analysis and Rule-based 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)


10


• 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– 2 = (((O-E)2)/E)

• Notes– The range of is from 0 to infinity

NIDES/JiNao Statistical Analysis NIDES/JiNao Statistical Analysis (Anomaly-based detection(Anomaly-based detection))


11


Similarity “Score”Similarity “Score”

• Counting Measures– Byte count and packet count

• Score Value - "Normalized" Q Value– S = -1(1-(TP/2))

– TP = Pm + Pm+1 + ... + Pmax

is the cumulative distribution function of a N(0,1) variable

– Pm is the relative frequency with which 2 belongs to the mth

interval

– M and max are manually selected at present


12


Long Term Q Distribution ExamplesLong Term Q Distribution Examples

• Background Traffic (Poisson)– 4Mbps– Byte counts

• Audio Traffic (Periodic)– 64Kbps– Byte counts


13


Rule Based DetectionRule 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


14


Attack ImplementationAttack 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


15


Traffic Generation ToolsTraffic 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


16


Detection Scenario and Detection Scenario and PerformancePerformance• 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

R1

R2

BEEF


17


Detection ResultsDetection Results

FLOODING DROPPING REMARKING --STEALING

REMARKING --SWITCHING

STAT Yes Yes Yes D/ S

RULE-Based

No No Yes Yes


18


Collaboration and Future WorkCollaboration 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


19


2. IPSec Policy Generation 2. IPSec Policy Generation and Correctnessand Correctness

• “Policy conflicts” for IPSec/VPN:– what will possibly go wrong?

• Requirement versus Policy– what are their relationship?


20


IPSec Policy:IPSec Policy:Implementation PolicyImplementation 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)

BA RcRb Rd

Rb,Rd, ESP A, B A, B


21


A SG-1 SG-2 B

X Y

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

Example Conflict #1:Example Conflict #1:Privacy and Content ExaminationPrivacy and Content Examination


22


A SG-1 SG-2 B

X Y

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

Example Conflict #2:Example Conflict #2:Selector ConfusionSelector Confusion


23


SG-1.1, SG-2 A, B A, B

B

SG-2

SG-1 SG-2.1

SG-1,SG-2.1

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

SG-1.1, SG-2 A, B

SG-1.1

SG-1.1, SG-2 A, B

A

Example Conflict #3:Example Conflict #3:Tunnel OverlappingTunnel Overlapping


24


Policy ConflictPolicy ConflictIPSec/VPN PolicyIPSec/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.


25


Policy versus RequirementPolicy 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.


26


Policy versus RequirementPolicy versus Requirement

a requirement

a set of policy

a set of policy

a set of policy

or

a requirement

a set of policy


27


Policy AnalysisPolicy Analysis

a set of policya set of policy

a set of policy

a requirement a requirement

a requirement

????


28


IPSec Security Requirements IPSec Security Requirements (1)(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?

H2H1 Rb Rd

Encryption or Authentication

trusted


29


IPSec Security Requirement IPSec Security Requirement (2)(2)• Content Access Requirement (CAR)

– Specify the needs to access content of certain traffic

I will examine the content for intrusion detection

• Security Association Requirement (SAR)– Specify trust/distrust relationship in SA setup

XCan not set up SA

CMR: modifyCER : examine


30


Security Requirement Satisfaction Security Requirement Satisfaction (1)(1)

H2H1 RcRb Rd

H2H1 RcRb Rd

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

Yes!

Encryption

Encryption


31


Security Requirement Satisfaction Security Requirement Satisfaction (2)(2)

H2H1 RcRb Rd

• Content Access Requirement – Certain node needs to access the content, Rb? Rc?

Rb: No!Rc: Yes!

• Security Association Requirement – Some nodes are not allowed to set up SA


32


IPSec Requirement Spec.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


33


Example (per flow):Example (per flow):

1 2 3 4 5

SCR#1: ENC 2-4 trusted 3SCR#2: AUTH 1-4 trusted 3SCR#3: ENC 3-5 trusted 4CAR#1: (ENC, AUTH) by 4SAR#1: not-ENC 2-5SAR#2: not-ENC 1-5SAR#3: not-AUTH 1-4

Coverage:

Content:

SA relation:


34


Solution:Solution:

1 2 3 4 5

ENC ENC

AUTHAUTH

SCR#1: ENC 2-4 trusted 3SCR#2: AUTH 1-4 trusted 3SCR#3: ENC 3-5 trusted 4CAR#1: (ENC, AUTH) by 4SAR#1: not-ENC 2-5SAR#2: not-ENC 1-5SAR#3: not-AUTH 1-4

Coverage:

Content:

SA relation:


35


Policy Generation CPU TimePolicy Generation CPU Time


36


Number of Policy Rules Number of Policy Rules GeneratedGenerated


37


ResultsResults

• Collaboration with Nortel Networks

• For more information:– Policy’2001: requirement specification

language– DSOM’2001: automatic policy generation

algorithms.

Documents

Protecting Network Quality of Service Against Denial of Service Attacks