Security for Internet QoS

1. Security for Internet QoS ECS 289I Project Presentation Vincent Law

2. Outline • Introduction • End-to-end security • Secure QoS • Security Infrastructure • Security Management • Conclusion • References

3. Introduction • Why QoS • Support broad range of request for limited resources • Support levels • Packet level, e.g. scheduling, multiplexing, traffic shaping or smoothing, policing, packet dropping, congestion control, etc. • Network connection level, e.g. signaling, admission control, routing, resource reservation, etc. • General QoS types • Integrated Services (IntServ) • Differentiated Services (DiffServ)

4. Introduction • Why security • In terms of QoS, guarantee QoS provision without malicious disruption • Security areas • End-system security: about security entities/products like firewalls etc. • End-to-end security: secure data transmission • Secure QoS: protection/authorization of services and resources to prevent from thefts or hijacks • Secure network infrastructure: protections of network infrastructure from attacks • Last 3 security areas affect Internet QoS

5. End-to-end security • Secure routing • Currently existing routing protocols • can deal with single-network failure only such as links down or node crashing • overlooks tricked data traffic • Routing protocol threats • Intercepting traffic • Replay attack • Spoofing • Traffic analysis

6. End-to-end security • Known attacks • Black hole attack: compromised router misleads, and as a result steals resources, by broadcasting favorable link state, making other routers think this router has the shortest path • Table overflow attack: compromised router sends junk link state advertisements (LSAs) to those routers without validation scheme to crash them • Age field attack (MaxAge attack): compromised router sets LSA age field to MaxAge to prevent LSA update, causing non-optimal resource reservation and incorrect routing • Sequence number attack: LSA’s sequence number is set to a value which is always newer than that of any future LSA

7. End-to-end security • Proposed scheme (by Dr. Felix Wu and others) • Three-model framework • Topology model

8. End-to-end security • Information model

9. End-to-end security • Operation model • Neighboring acquisition: acquiring neighbor info • Neighbor reachability: maintaining relationship with newly acquired neighbor(s) • Routing information exchange: periodic updates of routing info into RIB by exchanging info with neighbors • Route generation and selection: determining what goes to FIB based on route selection algorithm in local RIB • Neighbor relation termination: defining how to terminate a neighbor relationship

10. End-to-end security • Security requirements • Objectives: authenticity, integrity, and confidentiality • Focused areas: accessibility, intended usage, and network connectivity • Cryptography and authentication are suggested • Authentication techniques • Password: weak because of lack of authenticity and integrity checking • Hashed signature: hop-by-hop verification of authenticity and integrity • Public key scheme: end-to-end authentication and integrity, but inefficient

11. End-to-end security • Digital Envelopes • Secret key: encrypt the message • Public key: encrypt the secret key • Results are combined and sent from sender to receiver

12. End-to-end security • Quality of Protection (QoP) (also by Dr. Wu) • Motivation: due to heterogeneous security modules on both ends, security management and coordination is needed for security negotiation and reservation • Inter-Domain Security Management Agent Coordination Protocol (ISCP) • Security Management Agent

13. End-to-end security • Two ISCP phases (soft-state approach, adopted from RSVP scheme) • Discovery phase • Reservation phase

14. End-to-end security • Upon successful SA establishment, those participating nodes will send a Confirmation message to sender • Sender then sends receiver ContextReady message • Receiver responds by sending ContextReadyAct message • Error message will be sent upon transmission error • Refreshing discovery and security message as adaptation and updates of routes and other possible events, including the suspected ones • Teardown message will be sent to free contexts, state info, routes and resources

15. End-to-end security • Advantages • Scalable because only border network devices and end systems need to install the modules, where interior network devices do not need so as their functions are only reserving corresponding resources or just forwarding • Per-flow state has already been handled by RSVP • Ongoing work • Better scalability • Better efficiency: reducing setup overhead, taking advantages of existing SAs, and aggregating refresh messages • Multicast environment: merging reservation messages

16. Secure QoS • Secure QoS Forwarding • Motivation • QoS packets are vulnerable to spoofing and theft of resources • DoS prevention • Security setup process has two stages • Setup • Establish state info to treat subsequent packet stream • Specify how to perform classification • Classification • Match packets into classes

17. Secure QoS • Secure QoS forwarding focuses on setup stage, as an extension to those protocols for setup stage • Add user credentials, known as high-level identification (HLID) like password or other user-specific authorization, as trustworthy assurance info to the setup request • Low-level identification (LLID), also known as cookie, is sometimes also included in the packet for help in specifying classes

18. Secure QoS • Cookie • Acts as a tag for the packet for the routers to reference during QoS decisions • IP datagram has one cookie for mapping use • Duration must comply with security protocol needs, efficiency, and application needs, and it also needs to deal with setup renewal once expired • Should be trustworthy enough • Should be distinct enough for classification • Should be validated regularly on some selected packets • Should be authenticated

19. Secure QoS • Cookie authentication techniques • Digital signature: uses public key and one-way hashing to compute the packet digest; secure but inefficient • Sealing: digital signature minus encryption, making it a seal, plus some value appended as “key”, i.e., routers should have the key to check the authentication; efficient but less secure because any router having the key can forge the seal • Modified technique: different secret between different immediate pair • Still cannot prevent replay attack • Temporary password: uses a short-term secret number as password for all packets with the same cookie; very insecure; one modification: uses sequence number

20. Secure QoS • Resource pricing • Motivation: control-less, unlimited resource reservation, which can also be unauthorized • Budget and a dynamic price per unit, computed based on demand, are allocated to each authorized user for certain resource • Feedback is needed in order to update the price after some time in order to achieve equilibrium • Possible insufficient resource for those resources reserved as long-term due to fluctuated demands

21. Secure QoS • As adaptation, two-price model is adopted • One set of prices based on stable demands • Another set based on fluctuated demands • Allows users to select resources from preferred set of prices • Similar to the DiffServ model of premium and assured services • Can work with RSVP and COPS • Obtain signed policy object from authorization server as affordability proof for the request resource • The signed policy object is included in both RSVP and COPS messages • Supported router acts as policy enforcement point (PEP), based on the admission control decision in policy server, called policy decision point (PDP)

22. Secure QoS • Usual reservation process like RSVP continues, with charges included in the response message to authorization server

23. Secure QoS • Selective Digital Signature/Collision Detection • Motivation: Denial of Quality of Network Service (DoQoNS) like attacks to RSVP or DiffServ, causing DoS, wasted resource reservation, network utilization degradation, and QoS degradation • High-level overview • Uses a detection algorithm with modified end-to-end authentication • Separates target RSVP objects into constant, which are signed by source to prevent tampering, and mutable, which are signed by destination as a commitment • Upon conflicts, local policies determine how to react

24. Secure QoS • Algorithm • Sender digitally signs TSpec(PATH) • Receiver verifies integrity of TSpec(PATH) and dispatches resource requests accordingly • Receiver sends RESV message piggybacked with AdSpec(PATH) (both RSpec(RESV) and AdSpec(PATH) are digitally signed by receiver) • Intermediate routers verify that piggybacked and signed AdSpec(PATH) is at most the same as the AdSpec it forwarded downstream, otherwise PDP decides steps to follow • Upon any RESV message merging, intermediate router picks the RESV message with largest RSpec(RESV) to forward upstream

25. Secure QoS • Upon receiving RESV message by sender, it verifies the valid signature by a valid receiver or otherwise it tears down the reservation • Sender digitally signs RSpec(RESV) and piggybacks it with the next refreshing PATH message • Upon receiving the refresh PATH message by the intermediate router, it checks that the RSpec(RESV) signed by the sender is at least the same as the one signed by the receiver, otherwise PDP makes the decision • Offers hop-by-hop protection • Still cannot handle dropping attacks like malicious decrease in AdSpec(PATH), but at least can identify dropping point if working with IDS and even can prevent these attacks with resource pricing

26. Secure QoS • BGP/MPLS • MPLS • MPLS ingress router, acting as label switch router (LSR), assigns a forwarding equivalency class (FEC) based on access control list (ACL) and then assigns it to a label switched path (LSP) by adding a 32-bit MPLS header to the incoming packet before forwarding it to next hop • Policy-based forwarding • Label has only local significance because it is only relevant to two immediate neighbors • LSP routing uses constraint-based protocols, e.g. Constrained Shortest Path First (CSPF) • LSP Signaling can be based on Label Distribution Protocol (LDP), RSVP, or Constraint-based LDP (CL-LDP)

27. Secure QoS • BGP • Classless inter-domain/inter-autonomous-system (inter-AS), TCP routing protocol • AS: a set of routers under same technical administration • Interior gateway protocol and common metrics handle intra-domain routing • Exterior gateway protocol handles inter-domain routing • BGP speakers advertise neighboring AS speakers about those routes being used • Supports hop-by-hop routing paradigm • Using common set of policies, BGP speakers agree on which routers to serve as entry/exit point for particular destinations outside its AS

28. Secure QoS • BGP messages • OPEN: establish a connection • UPDATE: update route info including disconnection • KEEPALIVE: respond successful OPEN message and keep route fresh • NOTIFICATION: send error message and tear down connection • BGP states: • Idle: initial state, no BGP connection, refuse incoming BGP connection • Connect: set as a result of connection request from outside node in Active state • Active: request a connection

29. Secure QoS • Opensent: upon completion of transport connection, send an OPEN message • OpenConfirm: upon successful receiving and checking the OPEN message, send a KEEPALIVE message • Established: upon successful receiving and checking the KEEPALIVE message, is not ready for data and exchange UPDATE, KEEPALIVE, and NOTIFICATION messages • Security requirements • Unique destination from a given address to avoid packets going to another host other than the intended one • Core networks have to be hidden from outsiders • Work with labels instead of IP addresses in order to hide addresses, and labels have to be able to prevent spoofing

30. Secure QoS • Security advantages • Addressing and routing information are separated • Router’s only relevant info is next hop’s address, so prevents attackers from getting core info to achieve attacks like spoofing, DoS, or session hijack, as long as addressing and routing separation are properly configured • Scalable enough for multicast • Ease of troubleshooting inter-domain routing • Ease of deployment of latency sensitive applications like video-conferencing • Challenges • Vulnerability in TCP connection spoofing during BGP establishment results in false connection • Suggested solution: hashing like MD5 or SHA-1

31. Security Infrastructure • Secure Quality of Service Handling (SQoSH) • Motivation: networks become more programmable, and therefore active networks are emerging, but that also introduces more vulnerabilities due to increased exposure of infrastructure resources • Secure Active Network Environment (SANE) • Secure bootstrapping and component recovery • Cryptographic primitives: associated by SANE for loading based on two kinds of certificate, administrative allowing any customized loading and regular permitting only selected module loadings under specified usage patterns • Packet encryption and authentication

32. Security Infrastructure • Secret key creation and exchange to provide trustworthy with neighbors in sharing infrastructure info and resources • Has administrative domains to enforce security restrictions and have border elements act as firewalls • Naming service for secure module identification • Design principles for SANE elements • Dynamic checks have to be fast because of its being frequent • Static checks are allowably expensive because of rareness • If possible, have static checks during compilations to save the dynamic checks during operations

33. Security Infrastructure • Architecture • Main goal: to protect against admission failures and policing failures • Admission failures: unauthorized access of resources • Policing failures: consequences of vulnerable security policies • SANE has to be front-loaded over OS to perform front-end cryptographic operations to ensure authentications and access controls, allowing OS to concentrate on resource allocations • OS provides packet delivery operations for SANE like multiplexing and demultiplexing

34. Security Infrastructure • Full-scale SQoSH system also has multiprocessor with OS instance on each device-managing processor so that the OS for the processor can manage all I/O devices and schedules resources upon responding to device interrupt, allowing the OS in SQoSH system to be the manager of interrupts, buffering and status polling etc. and protecting it from device-initiated attacks

35. Security Infrastructure • Simulation • Environment: about 85 Mb/s of bandwidth • User 1: stealing unlimited resource between 5s and 21s • User 2: 40 Mb/s between 1s and 16s • User 3: 10 Mb/s between 9s and 30s

36. Security Infrastructure • Applications • Capturing complex auction decisions • Military environments: mapping hierarchical command responsibility to multiple service and security classes, SQoSH OS resources have been preserved for critical actions • Integrated admission control and policing

37. Security Management • Motivations: codes may contain malicious or inadvertent bugs that can damage the components, so instead of allowing freely adaptive component behavior, policies are needed for suitable restrictions • Policies: persistent rules governing system behavior choices derived from business goals, service level agreements, or trust relationships within or among enterprises

38. Security Management • Network policy model • Obligation policies • event-triggered condition-action rules defining the network conditions usually for resource reservation, queuing strategies, router code-loading or reconfiguration etc. • user- or application-specific, but not involving error correction • Authorization policies • define accessibilities to service and resource • more desirable to update policies dynamically based on the distributed entities • more practical to specify group-related, instead of individual-based, policies with so many individual users and resources

39. Security Management • Security policy model • Common model: Role-Based Access Control (RBAC), i.e., role-based instead of user-based, mapping users’ role assignments to access permissions • Multiple users can be assigned to the same role and multiple roles can be assigned to the same user • Constraints may be applied between users and roles, between roles and permissions, or between roles themselves

40. Security Management • Goal: to simplify permission management in large organizations using structural, hierarchical, reusable, and inheritable approaches • Similar to object-oriented approach in programming • Preferred to be capability-based • Responsibilities for inherited permission collections are delegated to the end-user’s system prior to access control check to remote systems during remote invocation • Reduces the network overhead due to the complexity of possible multiple remote invocations required by role checking

41. Security Management • Trust policy model • supports sophisticated authorization policy specification and implementation using public key certificates as credentials to authenticate identities or group memberships • Trust Policy assigns client to a group similar to a role • Group is assigned authorization rules, in the form of X509 certificates, on resource access • Therefore, access control policies and role policies can be assigned by different authorities

42. Security Management • Script language • Mostly XML-like • Popular choice to define trust policies, especially in e-commerce and Internet applications because they need flexible authorization policies • Does not support inheritance

43. Security Management • Management policy specification • Service level goals can be integrated with policies to support multiple-level adaptability in a network both at hardware, and within network-aware applications and application-aware networks like active networks • Offers interoperability between QoS and security • In many cases, management policies are specified in a script language • Policy Definition Language by Lucent, an event-condition-based language based on obligation policies using has two simple main constructs • Policy rule corresponds to the obligation policy • Event-triggering rule

44. Security Management • Policy CIM (PCIM): a policy information model defined by DMTF and IETF as an extension to the Common Information Model (CIM) • Can work with both Lightweight Directory Access Protocol (LDAP) directory and COPS • Policies as objects • Does not distinguish between authorization and obligation models • QoS Policy Information Model (QPIM): further extended from PCIM by IETF • contains a set of IntServ-specific or DiffServ-specific management

45. Security Management • An extension of the Unified Modeling Language (UML): uses the concept of system abstraction within a defined environment in terms of the system’s purpose, scope, and policies that both applying to the system and are defined within the system • Authorization policy can be expressed as a set of objects • Obligation policy can be realized by the implementation of a particular activity collaboration • The Ponder language: used by Imperial College in their projects • Declarative object-oriented language • Specifies security policies by mapping them onto various access control mechanisms for firewalls, OSs, databases, and even Java • Supports inheritance and element overloading • Supports event-triggered condition-action obligation policies for network and distributed systems management

46. Security Management • Requirements • Consistency • Completeness • Avoid conflicts: conflicts analysis • Negative authorizations have higher priorities than positive ones in general • Specific policies may need to override the general ones • Future research • Define interfaces for policy exchange among different levels to provide better efficiency than adaptation within the network • Obstacle is to map different policy semantics among different levels

47. Conclusion • A general view of different security areas for Internet QoS • Shows how end-to-end security helps make QoS routing secure • Describes several secure QoS proposals for forwarding, RSVP security, and BGP/MPLS • Gives some details on security infrastructure based on active networks to prevent misuse of resources • Emphasizes the importance of security management in making security effectively offered for QoS

48. Conclusion • Continuing research work • Require interoperability in order to prevent attacks effectively • Improve the efficiencies

49. References • Feiyi Wang, Brian Vetter, Shyhtsun Felix Wu, “Secure Routing Protocols Theory and Practice”, http://shang.csc.ncsu.edu/papers/CCR-SecureRP2.ps.gz, May 1997 • Z. Fu, H. Huang, T. Wu, S. F. Wu, F. Gong, C. Xu, I. Baldine, “ISCP: Design and Implementation of an Inter-Domain Security Management Agent (SMA) Coordination Protocol”, http://www.cs.ucdavis.edu/~wu/publications/14_1.PDF,IEEE NOMS 2000, page 565 to page 578

50. References • Bob Braden, David Clark, Steve Crocker, Christian Huitema, “Secure QoS Forwarding”, http://zvon.org/tmRFC/RFC1636/Output/chapter4.html, RFC-1636: Chapter 4, Report of IAB Workshop on Security in the Internet Architecture February 8-10, 1994 • Errin Fulp, Zhi Fu, Douglass S. Reeves, S. Felix Wu, Xiaobing Zhang, “Preventing Denial of Service Attacks on Quality of Service”, http://seclab.cs.ucdavis.edu/papers/2001-01-discexII.pdf, Proceedings of DISCEX II, 2001