NC State / UC Davis / MCNC Protecting Network Quality of Service Against Denial of Service Attacks...

NC State / UC Davis / MCNC

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 Dan Stephenson

DARPA FTN PI Meeting January 17, 2001

January 17, 2001 -- FTN PI Meeting

2


Timetable and ParticipantsTimetable and Participants• Start date = August 1999

• Duration = 36 months

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

• No clearances

Douglas Reeves N.C. State [email protected](919) 515-2044

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

Dan Stephenson MCNC


3


QoS - A New QoS - A New VulnerabilityVulnerability

• 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


4


The ARQOS Project:The ARQOS Project:Overview / Basic StrategiesOverview / 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-)


5


1.Pricing: Pay as You Go1.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?


6


(1a. Pricing) Fixed or Variable (1a. Pricing) Fixed or Variable Prices?Prices?

• Some users want lowest price (greatest resource amount)

• Some users want predictability (fixed resource amount)

• Goal: support both types of users


11


Combining the Two MarketsCombining 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


12


User User PreferencesPreferences


13


Reservation Market ExampleReservation Market Example


14


ResultsResults

• 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


15


(1b. Pricing) Implementation(1b. Pricing) Implementation

• Conventional Resource Reservation (no pricing)


16


Implementation with pricing Implementation with pricing (now)(now)


17


Implementation with pricing Implementation with pricing and authorization (next)and authorization (next)


18


2. Authorizing Resource 2. Authorizing Resource AllocationAllocation

• 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


19


Network RelationshipsNetwork Relationships


20


The Evolving Network ModelThe 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


21


Our SolutionOur 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


22


Solution ExampleSolution Example


23


Contents of the Ticket Contents of the Ticket (Example)(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


24


Authentication of TicketAuthentication 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


25


Protocol ImpactsProtocol 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)


26


DiscussionDiscussion

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


27


ResultsResults

• 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


28


3. Packet Dropping Attacks3. 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


29


Ways to Implement Dropping Ways to Implement Dropping AttacksAttacks• 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


30


Experiment SettingExperiment Setting

• 4 FTP Servers across the Internet

• 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

FTP

Internet

Divert Socket

FTP Client on Linux

xyz.zip 5.5M

FTP

Server

Attack Agent

Data Packets


31


Experiments over the InternetExperiments over the Internet

FTP Client

NCSU

FTP Servers

Heidelberg

NCU

SingNet

UIUC


32


Results: Impact on Average Results: Impact on Average Pkt. DelayPkt. Delay

5663.4 66

218.4

98.6108.2

125.8

250.9

62.6

77.186.9

260.3

23.6 26.5

44.6

183.9

0

50

100

150

200

250

300

Ses

sio

n D

elay

(s)

Heidelberg NCU SingNet UIUC

NormalRandomPeriodicalRetrans.

7 packets are dropped among more than 4000 packets in a connection


33


Q-Test Detection MechanismQ-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


35


Q-Distribution for Position of Dropped Q-Distribution for Position of Dropped PacketsPackets

Heidelberg

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 5 10 15 20 25 30 35Q bins

Prob

abilit

y

NCU

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 5 10 15 20 25 30 35Q bins

Prob

abilit

y

SingNet

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 5 10 15 20 25 30 35Q bins

Prob

abilit

y

UIUC

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 5 10 15 20 25 30 35Q bins

Prob

abilit

y


37


ResultsResults

• 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


38


Heidelberg NCU SingNet UIUC Position

nbin=5

DR MR DR MR DR MR DR MR

Normal* - 4.0% - 5.4% - 3.5% - 6.5% -

(10, 4, 5) 99.7% 0.3% 100% 0% 100% 0.0% 100% 0%

(20, 4, 5) 100% 0% 98.1% 1.9% 99.2% 0.8% 100% 0%

(40, 4, 5) 96.6% 3.4% 100% 0% 100% 0% 98.5% 1.5%

(20, 20, 5) 100% 0% 100% 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%

PerPD

(100, 40, 5) 0.2% 99.8% 0% 100% 0% 100% 100% 0%

RetPD (5, 5) 84.9% 15.1% 81.1% 18.9% 94.3% 5.7% 97.4% 2.6%

10 0% 100% 42.3% 57.7% 0% 100% 0% 100% RanPD

40 0% 100% 0% 100% 0% 100% 0% 100%

5 98.6% 1.4% 100% 0% 98.2% 1.8% 100% 0% Intermittent

(10, 4, 5) 50 34.1% 65.9% 11.8% 88.2% 89.4% 10.6% 94.9% 5.1%

Results: Position MeasureResults: Position Measure


39


Results: Delay MeasureResults: Delay Measure

Heidelberg NCU SingNet UIUC Delay

nbin=3


Normal* - 1.6% - 7.5% - 2.1% - 7.9% -

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

PerPD

(100, 40, 5) 100% 0% 100% 0% 100% 0% 100% 0%

RetPD (5, 5) 100% 0% 100% 0% 100% 0% 100% 0%

10 74.5% 25.5% 26.8% 73.2% 67.9% 32.1% 99.5% 0.5% RanPD

40 100% 0% 100% 0% 100% 0% 100% 0%

5 25.6% 74.4% 0% 100% 0% 100% 97.3% 2.7% Intermittent

(10, 4, 5) 50 0% 100% 24.9% 75.1% 0% 100% 3.7% 96.3%


40


Results: Packet Loss Rate MeasureResults: Packet Loss Rate Measure

Heidelberg NCU SingNet UIUC NPR

nbin=2


Normal* - 4.5% - 5.8% - 8.2% - 2.9% -

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

PerPD

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

10 0% 100% 0% 100% 100% 0% 100% 0% RanPD

40 100% 0% 100% 0% 100% 0% 100% 0%

5 0% 100% 0% 100% 82.2% 17.8% 100% 0% Intermittent

(10, 4, 5) 50 0% 100% 1% 99% 40% 60% 64.8% 35.2%


41


4. Policy Consistency Checking4. 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?


42


H1 FW1 SW2 H2

Example of a Policy ConflictExample of a Policy Conflict

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


43


StatusStatus

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


44


DeliverablesDeliverables

• 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

NC State / UC Davis / MCNC Protecting Network Quality of Service Against Denial of Service Attacks...

Documents

Transcript of NC State / UC Davis / MCNC Protecting Network Quality of Service Against Denial of Service Attacks...