Security for Internet QoS

ECS 289I Project Presentation

Vincent Law

Outline

• Introduction

• End-to-end security

• Secure QoS

• Security Infrastructure

• Security Management

• Conclusion

• References

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)

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

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 (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

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 (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

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

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

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

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

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

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

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)

Secure QoS

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

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

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

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

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)

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

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

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

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

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

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

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

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

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 X509 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 e-commerce 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 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

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

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

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/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

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

References

• Tsung-Li Wu, S. Felix Wu, Zhi Fu, He Huang, “Securing QoS: Threats to RSVP messages and their Countermeasures”, http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.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/rfc2748.txt?number=2748, RFC 2748, IETF

References

• Yakov Rekhter, Tony Li, “A Border Gateway Protocol 4 (BGP-4)”, http://www.ietf.org/rfc/rfc1771.txt?number=1771, RFC 1771, IETF

• “Security of the MPLS Architecture”, http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mxinf_ds.htm, Cisco Systems White Paper

• Gary Alterson, “Comparing BGP/MPLS and IPSec VPNs”, http://rr.sans.org/encryption/MPLS2.php, SANS Institute Information Security Reading Room, January 9, 2002

References

• Andy Heffernan, “Protection of BGP Sessions via the TCP MD5 Signature Option”, http://www.ietf.org/rfc/rfc2385.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: SQoSH”, 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