Download Security for Internet QoS

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 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 (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 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 QoS 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
• 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/CCRSecureRP2.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-01discexII.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_iwqos9
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/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/prodl
it/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