Protecting network quality of service against denial of service attacks
Sponsored Links
This presentation is the property of its rightful owner.
1 / 24

Protecting Network Quality of Service against Denial of Service Attacks PowerPoint PPT Presentation


  • 130 Views
  • Uploaded on
  • Presentation posted in: General

Protecting Network Quality of Service against Denial of Service Attacks. Douglas S. Reeves S. Felix Wu Chandru Sargor N. C. State University / MCNC October 6, 1999 Tolerant Networks Program BAA99-10 Kickoff Meeting. Quality of Service - a New Capability for Packet-Switching.

Download Presentation

Protecting Network Quality of Service against Denial of Service Attacks

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Protecting Network Quality of Service against Denial of Service Attacks

Douglas S. Reeves S. Felix Wu Chandru Sargor

N. C. State University / MCNC

October 6, 1999

Tolerant Networks Program

BAA99-10 Kickoff Meeting


Quality of Service - a New Capability for Packet-Switching

  • New services

    • Guaranteed minimum bandwidth

    • Guaranteed maximum delay

    • Guaranteed maximum loss rate

  • Guaranteeing QoS for a “flow” requires providing adequate resources


DST

SRC

IntServ / RSVP Operation

PATH messages

RESV messages

Tspec = 5M

Tspec = 5M

ADspec = 5M

ADspec = 4M

ADspec = 3M

That looks fine

to me…..

Reserve

3M

Reserve

3M


DiffServ

DATA flow

SRC1

DST1

SRC2

DST2

Service Agreement

and Traffic Agreement


Quality of Service - A New Vulnerability

  • Normal users will try to get maximum QoS without regard to others

  • Malicious users will try to deny quality of service for others


The ARQOS Project

  • Selective verification of reservation signaling (SVR)

  • Congestion pricing of scarce resources ($$$)

  • Monitoring of data flows, and integration with intrusion detection (IDS)


DST

SRC

SVR: Attacking ADSpec

ADSpec = 200M

ADSpec = 5M

That looks fine

to me…..

Reserve

200M

Reserve

5M


SVR: IETF RSVP SecurityCurrent solution proposed by Fred Baker

  • All routers, even including those not on the path, share the same “key table”

  • Hop-by-hop authentication of messages

    • outsiders tampering with packets will be detected, but corrupted insiders will not be detected


SVR: IETF RSVP Security (cont.)

Sharing a secret key

A

ADSpec

B

A & B trust each other;

If A is compromised and sends a faulty ADSpec,

there is no way for B to know about it


SVR: Our Approach

DST

SRC

ADSpec = 200M

ADSpec = 5M

Correlation and Verification of the Correctness Properties


SVR: Verification of Reservations

  • No need to introduce new features to RSVP, other existing protocols

  • Do not need to install verification agents in every router

  • Capable of detecting insider attacks


SVR: Status

  • Identified types of possible attacks on RSVP signals

  • Solutions for detecting the most important types of attacks

  • Now implementing attacks and solutions


$$$: Competing for Services

"You can have 5M, 2M, or 1M, at no cost; what do you want, and for how long?”

Service Provider:

Network Resources

5M

5M

5M

5M

5M

5M

Users:

“We all want 5M, from now on!”


$$$: Influencing Behavior

  • Disincentives for bad behavior -- users incur costs for resource usage

  • Incentives for good behavior -- profits for service providers


$$$: Competition (cont.)

Service Provider:

“5M costs $3/min, 2M costs $2/min, 1M costs $1/min.”

Network Resources

1M

@$1

5M

@$3

1M

@$1

5M

@$3

5M

@$3

2M

@$2

Users:


$$$: Pricing of Resources

  • Price is right when demand = supply

  • Flexibility

    • combinations of resources and services

    • User endowments for non-monetary goals

  • How are prices set, by whom, and how are they distributed?


$$$: Goals and Assumptions

  • Fairness vs. “maximum aggregate utility”

  • The time and data scales for which this is useful

  • Real money, or play money?

  • Charging senders, or receivers

  • The overhead of billing and accounting


$$$: Status

  • Pricing method

  • Integration with RSVP

  • Integration with DiffServ

  • Infrastructure


IDS: Attacks on the Data Flow

  • From a malicious host (external to network)

    • spoof high priority data flow packets

    • send large amounts of data to ingress router to overload it

  • From a compromised ingress router

    • admit/discard traffic in violation of service agreement

    • inappropriate marking of admitted traffic


IDS: Possible Attacks (cont.)

  • delay/drop packets from selected flows

  • generate additional traffic to degrade overall network QoS

  • From a compromised core router

    • randomly re-mark flows

    • delay/drop packets from selected flows

    • generate additional traffic to degrade overall network QoS


  • IDS: Intrusion Detection System

    Security

    Management

    Entity

    SNMPv3

    Rule-Based

    Analyzer

    Profile-Based

    Analyzer

    IDS MIB

    Decision Module

    Filtering Engine

    Network


    IDS: Detecting Re-marked Packets

    • Downstream IDS will detect anomalous change in IP header

      • raise alarm via SNMP

    • Security management entity will receive alarms from IDS entities and correlate them

    • Security management entity will query other routers on the path to isolate compromised router


    IDS: Status

    • Enhance JiNao implementation to make it protocol independent

      • originally targeted for OSPF attack detection

      • now can be used to detect attacks against any protocol

    • Identification of data flow attacks

    • Preliminary design of IDS system


    Conclusions

    • Started August ‘99

    • Implementing RSVP / DiffServ testbed

    • Exploring collaborations with vendors


  • Login