Security for Internet Qo S ECS 289 I

Security for Internet Qo. S ECS 289 I Project Presentation Vincent Law

Outline • • Introduction End-to-end security Secure Qo. S Security Infrastructure Security Management Conclusion References

Introduction • Why Qo. S – 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 Qo. S types – Integrated Services (Int. Serv) – Differentiated Services (Diff. Serv)

Introduction • Why security – In terms of Qo. S, guarantee Qo. S provision without malicious disruption • Security areas – End-system security: about security entities/products like firewalls etc. – End-to-end security: secure data transmission – Secure Qo. S: 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 Qo. S

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

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 (Max. Age attack): compromised router sets LSA age field to Max. Age to prevent LSA update, causing nonoptimal 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

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

End-to-end security – Information model

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

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

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

End-to-end security • Quality of Protection (Qo. P) (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

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

End-to-end security – Upon successful SA establishment, those participating nodes will send a Confirmation message to sender – Sender then sends receiver Context. Ready message – Receiver responds by sending Context. Ready. Act 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

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

Secure Qo. S • Secure Qo. S Forwarding – Motivation • Qo. S packets are vulnerable to spoofing and theft of resources • Do. S 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

Secure Qo. S – Secure Qo. S 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

Secure Qo. S – Cookie • Acts as a tag for the packet for the routers to reference during Qo. S 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

Secure Qo. S • 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

Secure Qo. S • 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

Secure Qo. S – 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 Diff. Serv 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)

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

Secure Qo. S • Selective Digital Signature/Collision Detection – Motivation: Denial of Quality of Network Service (Do. Qo. NS) like attacks to RSVP or Diff. Serv, causing Do. S, wasted resource reservation, network utilization degradation, and Qo. S 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

Secure Qo. S – Algorithm • Sender digitally signs TSpec(PATH) • Receiver verifies integrity of TSpec(PATH) and dispatches resource requests accordingly • Receiver sends RESV message piggybacked with Ad. Spec(PATH) (both RSpec(RESV) and Ad. Spec(PATH) are digitally signed by receiver) • Intermediate routers verify that piggybacked and signed Ad. Spec(PATH) is at most the same as the Ad. Spec 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

Secure Qo. S • 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 Ad. Spec(PATH), but at least can identify dropping point if working with IDS and even can prevent these attacks with resource pricing

Secure Qo. S • 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)

Secure Qo. S – 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

Secure Qo. S • 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

Secure Qo. S – Opensent: upon completion of transport connection, send an OPEN message – Open. Confirm: 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

Secure Qo. S – 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, Do. S, 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 MD 5 or SHA-1

Security Infrastructure • Secure Quality of Service Handling (SQo. SH) – 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

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

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

Security Infrastructure • Full-scale SQo. SH 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 SQo. SH system to be the manager of interrupts, buffering and status polling etc. and protecting it from device-initiated attacks

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

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

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

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

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

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

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 X 509 certificates, on resource access – Therefore, access control policies and role policies can be assigned by different authorities

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

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 Qo. S and security – In many cases, management policies are specified in a script language • Policy Definition Language by Lucent, an event-conditionbased language based on obligation policies using has two simple main constructs – Policy rule corresponds to the obligation policy – Event-triggering rule

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 • Qo. S Policy Information Model (QPIM): further extended from PCIM by IETF – contains a set of Int. Serv-specific or Diff. Serv-specific management

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

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

Conclusion • A general view of different security areas for Internet Qo. S • Shows how end-to-end security helps make Qo. S routing secure • Describes several secure Qo. S proposals 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 Qo. S

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

References • Feiyi Wang, Brian Vetter, Shyhtsun Felix Wu, “Secure Routing Protocols Theory and Practice”, http: //shang. csc. ncsu. edu/papers/CCRSecure. RP 2. 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

References • Bob Braden, David Clark, Steve Crocker, Christian Huitema, “Secure Qo. S Forwarding”, http: //zvon. org/tm. RFC/RFC 1636/Output/chapter 4. 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 discex. II. pdf, Proceedings of DISCEX II, 2001

References • Tsung-Li Wu, S. Felix Wu, Zhi Fu, He Huang, “Securing Qo. S: Threats to RSVP messages and their Countermeasures”, http: //arqos. csc. ncsu. edu/papers/1999_10_iwqos 9 9. pdf, Proceedings of IWQOS 1999 • David Durham, Jim Boyle, Ron Cohen, Shai Herzog, Raju Rajan, Arun Sastry, “The COPS (Common Open Policy Service) Protocol”, http: //www. ietf. org/rfc 2748. txt? number=2748, RFC 2748, IETF

References • Yakov Rekhter, Tony Li, “A Border Gateway Protocol 4 (BGP-4)”, http: //www. ietf. org/rfc 1771. txt? number=1771, RFC 1771, IETF • “Security of the MPLS Architecture”, http: //www. cisco. com/warp/public/cc/pd/iosw/prodl it/mxinf_ds. htm, Cisco Systems White Paper • Gary Alterson, “Comparing BGP/MPLS and IPSec VPNs”, http: //rr. sans. org/encryption/MPLS 2. php, SANS Institute Information Security Reading Room, January 9, 2002

References • Andy Heffernan, “Protection of BGP Sessions via the TCP MD 5 Signature Option”, http: //www. ietf. org/rfc 2385. txt? number=2385, RFC 2385, IETF • D. Scott Alexander, William A. Arbaugh, Angelos D. Keromytis, Steve Muir, Jonathan M. Smith, “Secure Quality of Service Handling: SQo. SH”, http: //www. cs. umd. edu/~waa/pubs/sqosh. pdf, IEEE Communications Magazine, April 2000

References • Morris Sloman, Emil Lupu, “Security and Management Policy Specification”, http: //www. comsoc. org/livepubs/ni/private/2002/ mar/sloman. html, IEEE Network, March/April 2002, page 10 to page 19