1 / 24

Protecting Network Quality of Service against Denial of Service Attacks

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.

aleda
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. DiffServ DATA flow SRC1 DST1 SRC2 DST2 Service Agreement and Traffic Agreement

  5. 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

  6. The ARQOS Project • Selective verification of reservation signaling (SVR) • Congestion pricing of scarce resources ($$$) • Monitoring of data flows, and integration with intrusion detection (IDS)

  7. DST SRC SVR: Attacking ADSpec ADSpec = 200M ADSpec = 5M That looks fine to me….. Reserve 200M Reserve 5M

  8. 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

  9. 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

  10. SVR: Our Approach DST SRC ADSpec = 200M ADSpec = 5M Correlation and Verification of the Correctness Properties

  11. 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

  12. SVR: Status • Identified types of possible attacks on RSVP signals • Solutions for detecting the most important types of attacks • Now implementing attacks and solutions

  13. $$$: 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!”

  14. $$$: Influencing Behavior • Disincentives for bad behavior -- users incur costs for resource usage • Incentives for good behavior -- profits for service providers

  15. $$$: 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:

  16. $$$: 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?

  17. $$$: 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

  18. $$$: Status • Pricing method • Integration with RSVP • Integration with DiffServ • Infrastructure

  19. 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

  20. 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

  21. IDS: Intrusion Detection System Security Management Entity SNMPv3 Rule-Based Analyzer Profile-Based Analyzer IDS MIB Decision Module Filtering Engine Network

  22. 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

  23. 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

  24. Conclusions • Started August ‘99 • Implementing RSVP / DiffServ testbed • Exploring collaborations with vendors

More Related