1. 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. 2 Quality of Service - a New Capability for Packet-Switching n New services  Guaranteed minimum bandwidth  Guaranteed maximum delay  Guaranteed maximum loss rate n Guaranteeing QoS for a “flow” requires providing adequate resources

3. 3 SRC DST Tspec = 5M ADspec = 5M Reserve 3M Reserve 3M That looks fine to me ….. ADspec = 4MADspec = 3M PATH PATH messages RESV messages IntServ / RSVP Operation

4. 4 DiffServ SRC1DST1 DST2 SRC2 Service Agreement and Traffic Agreement DATA flow

5. 5 Quality of Service - A New Vulnerability n Normal users will try to get maximum QoS without regard to others n Malicious users will try to deny quality of service for others

6. 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. 7 SVR: Attacking ADSpec Reserve 200M Reserve 5M That looks fine to me ….. SRC DST ADSpec = 5M ADSpec = 200M

8. 8 SVR: IETF RSVP Security Current solution proposed by Fred Baker n All routers, even including those not on the path, share the same “key table” n Hop-by-hop authentication of messages –outsiders tampering with packets will be detected, but corrupted insiders will not be detected

9. 9 A & B trust each other; If A is compromised and sends a faulty ADSpec, there is no way for B to know about it Sharing a secret key SVR: IETF RSVP Security (cont.) B A ADSpec

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

11. 11 SVR: Our Approach Response Protocol Properties Observed Messages Verification

12. 12 SVR: Verification of Reservations n No need to introduce new features to RSVP, other existing protocols n Do not need to install verification agents in every router n Capable of detecting insider attacks

13. 13 SVR vs. IETF Proposal (hop-by-hop) SVR vs. IETF Proposal (hop-by-hop) Countermeasures Hop-by-Hop SVR detects detects Attack 1-1 Outsider on-path Insider RSVP Attack 1-2 Outsider on-path Insider RSVP Attack 2-1 Outsider on-path Insider RSVP Attack 2-2 Outsider on-path Insider RSVP Attack 3-1 Outsider on-path Insider RSVP Attack 3-2 Outsider off-path Insider RSVP Attack 4 Outsider on-path Insider RSVP

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

15. 15 $$$: Competing for Services Network Resources "You can have 5M, 2M, or 1M, at no cost; what do you want, and for how long?” 5M “We all want 5M, from now on!” Users: Service Provider: 5M

16. 16 $$$: Providing Adequate Resources n Service provider: "I don't know if it will pay to increase the available resources" < wait until it's clearly absolutely necessary?

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

18. 18 $$$: Competition (cont.) “5M costs $3/min, 2M costs $2/min, 1M costs $1/min.” Users: Service Provider: 5M @$3 2M @$2 5M @$3 1M @$1 5M @$3 1M @$1 Network Resources

19. 19 $$$: Pricing of Resources n Price is right when demand = supply n Flexibility –combinations of resources and services –User endowments for non-monetary goals n How are prices set, by whom, and how are they distributed?

20. 20 $$$: Goals n Fairness, or maximization of utility & revenue? n The time and data scales for which this is useful

21. 21 $$$: Goals and Assumptions n Fairness vs. “maximum aggregate utility” n The time and data scales for which this is useful n Real money, or play money? n Charging senders, or receivers n The overhead of billing and accounting

22. 22 $$$: Status n Pricing method n Integration with RSVP n Integration with DiffServ n Infrastructure

23. 23 IDS: Attacks on the Data Flow n From a malicious host (external to network) –spoof high priority data flow packets –send large amounts of data to ingress router to overload it n From a compromised ingress router –admit/discard traffic in violation of service agreement –inappropriate marking of admitted traffic

24. 24 IDS: Possible Attacks (cont.) –delay/drop packets from selected flows –generate additional traffic to degrade overall network QoS n From a compromised core router –randomly re-mark flows –delay/drop packets from selected flows –generate additional traffic to degrade overall network QoS

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

26. 26 IDS: Detecting Re-marked Packets n Downstream IDS will detect anomalous change in IP header –raise alarm via SNMP n Security management entity will receive alarms from IDS entities and correlate them n Security management entity will query other routers on the path to isolate compromised router

27. 27 IDS: Status n Enhance JiNao implementation to make it protocol independent –originally targeted for OSPF attack detection –now can be used to detect attacks against any protocol n Identification of data flow attacks n Preliminary design of IDS system

28. 28 Conclusions n Started August ‘99 n Implementing RSVP / DiffServ testbed n Exploring collaborations with vendors