Agile Objects: Componentbased Inherent Survivability

1
Agile Objects Component-based Inherent
Survivability

• Andrew A. Chien
• University of California, San Diego
• http//www-csag.ucsd.edu/projects/agileO.html
• DARPA Briefing, OASIS Program
• September 25, 2001

2
Outline

• Team
• Agile Objects
• Location Elusiveness Object Authentication and
  Naming
• Interface Elusiveness
• Using Agile Objects to Resist Denial of Service
• Future Efforts

3
Agile Objects
UCSD
Andrew A. Chien, Principal Investigator Luis
Rivera (UIUC Student) Tony Wang Kay Connelly
(UIUC Student) Alex Olugbile, Research
Programmer Lisa Bodecker, Admin Support

• Chien moved from UIUC -gt UCSD in summer 1998
• Several UIUC PhD students continue to be funded
  thru Illinois, though in residence at UCSD

4
Background/Existing Practice

• Static Distributed Software Architectures
  (nearly)
• Fixed points of access, deployment, resource
  dependence
• System/Firewall/Sandbox/Domain based Security
• Resource and containment oriented
• Security Architecture based on Anticipated
  Deployment Structures
• gt Flexibility and reconfiguration can enhance
  survivability
• Our Focus Flexible Configuration of Distributed
  C3I Systems (Real-time, High Performance,
  Mission-Critical Online systems)
• E.g. Aegis Battle Cruiser, Theatre
  Command/Information system, etc.

5
AO Focus Tolerance and Response

• Resource revocation due to loss
• Physical loss, destruction, crash (failure)
• Resources made undesirable due to changes in
  security status
• Under attack, detected assaults, partially
  compromised, loss of other security critical
  information
• Proactive reconfiguration in response to partial
  loss

6
Traditional Static Distributed System Design and
Config

• Applications Design implicitly assumes
  distribution and security environment, as well as
  Specific Resources (and types)
• Difficult to reconfigure, requalify
• Complex schedulability analysis and resource
  matching
• DARPA Quorum techniques improve situation, but
  require significant application involvement and
  management of environment
• gt High Performance RPC enables

7
Distribution Independent Design

• Identical Application Design can be Deployed in
  Multiple Configurations
• Identical design effort (same performance
  abstractions ensured by the middleware layer)
  rate-based real-time performance at component
  level
• Identical performance experienced by users of the
  applications
• Configurations can be chosen based on many
  criteria survivability, load balance, hardware
  reliability, etc.
• gt Online Migration and Flexible Replication
  enables

8
Location Elusive Applications

• Extend distribution flexibility to runtime
• Transparent online reconfiguration functionality
  and performance invisible to distributed
  application and its users (Location Elusiveness)
• Respond to dynamic changes in runtime environment
  (failures, attack, security)
• Without major additional design effort
• Useful for commodity and existing software

9
Flexible Security Reconfiguration

• Integrated security mechanisms with high
  performance RPC/distributed objects (Elusive
  Interfaces)
• Exploit computer manipulable interfaces and data
  reorganization
• Adaptive security management for Agile, highly
  decentralized applications
• Rapidly and continuously changing environment and
  configurations

10
Elusive Distributed Applications

• Enabled by Agile Objects
• Location Elusiveness
• Seamless boundary between Component and
  Distributed Object applications
• Rate-based real-time framework allows distributed
  reconfiguration in performance transparent
  fashion
• Replication supports fault tolerance, rapid
  reconfiguration, multi-version assurance and
  survivability
• Interface Elusiveness
• Integrates security mechanisms with traditional
  object interface marshalling to achieve high
  performance
• An adaptive security mechanism (there are many)
• Adaptive security required with rapidly changing
  application configuration
• gt also rapidly changing surrounding resource and
  security environment
• Transparent automatic reconfiguration maintains
  performance and security properties
• No major additional application programming
  effort
• Can incorporate commodity software modules
  without major effort
• Response to critical events in short time scales
  (ltlt seconds)

11
Four Questions

• What threats or attacks?
• Any that lead to compromise of nodes, network,
  services.
• Particularly object/component interface based
  attacks and physical resource attacks.
• What assumptions does your project make?
• Only some resources are compromised, detection is
  possible, segregation is possible, noisy warning
  is possible.
• What policies can your project enforce?
• Configuration across resources of appropriate
  security, reconfiguration to maintain this in the
  presence of rapid change.
• What policies can a collection enforce?
• Complementary to many of the other approaches in
  the program.

12
Agile Objects Project Plan
Interface Elusiveness
Location Elusiveness
Agile Objects Application Demonstrations
Elusive Location Demonstration
Elusive Interface Demonstration
Name Service for Elusive Applications
Elusive Interface System
Agile Object Migration (RT)
Dynamic Mutation (online, reactive)

Distrib. Insensitivity
Elusive Interface Prototype
Object Replication
High Performance RPC
Analytical Foundations Case Studies
13
Previous Results

• Location Elusiveness
• Low-latency RPC system (40 microseconds as fast
  as local)
• Multi-DCOM Prototype
• Transparent replication
• Experimentation with Multi-DCOM Prototype
• Basic Real-time Framework
• Interface Elusiveness
• Analysis of interface space for sample
  distributed applications
• Simple systems, 106 1016 configurations
• Elusive Interfaces prototype and evaluation
• Report available from http//www-csag.ucsd.edu/pro
  jects/AgileO.html

14
Recent Progress

• Prototypes
• Architecture
• Location Elusiveness Naming and Object
  Authentication
• Interface Elusiveness
• Using Agile Objects to Resist DoS

15
Application Prototypes

• C3I Prototype
• Sensors, control programs, computers, locations,
  networks
• gt Control interfaces, AO sensor infrastructure
• Replicated Bookmark Server
• Globally accessible services
• Replica selection, data consistency
• Novel storage server technologies (P2P)
• gt Refined Agile Objects architecture and focused
  needs

16
Bookmark Demonstration
Location Elusive Object/Service
Clients
Distributed Persistent Store (Freenet P2P File
Sharing)

• Web browser bookmark service
• Provides global access, shared state
• Location elusive implementations
• Tolerate attack, DoS, failure, etc.
• Flesh out the key access issues (naming,
  tracking)
• Flesh out key backing storage issues (P2P as
  low-cost basis)

17
Agile Objects Architecture
Distributed Application
Agile Distributed Application
Security Policy
Migration Policy
Network Services (1 instance)
Core Svcs (Naming, Communication, File, etc.)
Migration
Migration
Migration
Local Services (1 instance / machine)
Monitoring
Monitoring
Monitoring
. . .
Computing
Computing
Computing
Memory
Memory
Memory
18
Location Elusiveness
19
Location Elusiveness Status

• Fast Migration migrate in 1 RPC time
• Evaluation and set aside of .NET framework
  approach
• Difficulties in infrastructure, tools, platforms,
  completeness, access
• Java based systems (some reset, RPC performance)
• Wont be able to complete in context of contract
  and experiments
• Demonstrations and experiments will depend on
  partial infrastructure
• Naming track fast migrating objects for
  continuous operation
• Object Authentication identified need, designed
  protocol

20
Object Authentication for Location Elusive Objects
21
Outline

• Problem
• Technical Goals
• S/Key Object Authentication
• Status

22
Problem

• Conventional approach uses credentials which are
  assigned on a per machine or per application
  basis, not per object (instance).
• Client-Server authentication typically uses
  certificates signed to node address
• Location elusive objects are not bound to a
  location!

23
Assumptions

• Entities are not fixed to a physical location
  (Location Elusive).
• Migration target node may not be safe.
• A mutually trusted third party may not always be
  available.

24
Object Authentication for AO

• Object authentication using object credentials,
  go with objects
• Mutual authentication.
• Fast re-authentication after migration.
• Decentralized operation.
• Resistance to common hijacking and spoofing
  attacks.

25
Possible Approaches

• X.509 Cert (A.K.A SSL)
• Typically signed to a physical location
• Signing authority must be mutually trusted
• Using PKI is computationally expensive
• Kerberos Shared Secret
• Difficult to scale
• Vulnerable to off-line dictionary attack

26
Possible Solutions (cont.)

• SRP Zero Knowledge Password Proofs
• Very expensive computationally
• S/Key - One Time Passwords
• Initial distribution of one time passwords must
  be secure

27
S/Key Object Authentication Step 1 - Key
Generation

• Each entity will generate a number (N) of
  disposable one time passwords.
• Secret is only needed once
• Passing of Nth password enables N-1 cheap
  reauthentications
• Must execute setup symmetrically

28
Step 2 - Bootstrap
Object A
Signed Cert.
Signed Cert.
Object B
OTP 0..N
OTP 0..N
OTPN(B)
OTPN(A)

• Entities contact each other using SSL.
• Objects swap their respective Nth one-time
  passwords

29
Step 3 - Verification

• S/key system host verifies one-time password by
  single secure hash, comparing the result with the
  previous one- time password.
• Only K-1 password will generate a match at step
  N-K
• Perform symmetrically for reauthentication

30
Secure Session-Key Exchange

• Entities generate a number of one-time passwords
  from 0 to N.
• Entities swap Nth password using a secure
  connection (SSL).
• At session creation server and client perform
  mutual exchange of one-time passwords and a
  unique session key
• Session key is encrypted with the last known one
  time password n
• Password n-1 and session key are sent within the
  same encrypted message.
• Sending password n-1 in the clear would provide
  eavesdropper with access to session keys
  protected by prior password n.
• After authentication, session key is used as the
  shared secure secret for a logical session.

31
Current Status

• Completed
• Design of session key exchange
• Implemented one time password library and testers
• Current activities
• Finish building prototype
• Performance Evaluation
• Integrate with Agile Objects infrastructure

32
Summary

• S/key provides inexpensive authentication using a
  single pass through secure hash.
• Migrating components may use session key to
  restart a logical connection.
• Compromised/broken sessions can be restarted at a
  minimal cost of re-authentication.
• Session management and encryption is left open
  for customization.
• Long lived sessions help amortizes the cost of
  authentication.

33
Naming Services for Location Elusive Applications
34
AO Naming Service

• Goal
• Design and Implementation of a high performance
  naming service for the Agile Object system
• Requirements
• Scalable
• Potentially millions of objects
• Hundreds of agile objects nodes
• Survivable
• Secure
• Resilient
• High Performance
• Should not represent a system bottleneck

35
Naming in Agile Objects

• Agile Objects implies
• Objects migrate frequently
• Random unpredictable migration
• Naming challenges
• Highly dynamic environment
• Resolution shifted to fast-path
• Consistency under high rate of change
• Survivability
• Resilient system (self healing)
• Secure object to object communication
• Performance
• Fast communication time resolution (location)
• Scalable to millions of constantly moving objects

36
Traditional Naming
Name Server
1
2
3
B
A
4

• Component A queries NS to resolve object B
• NS replies with B Address and A caches the
  binding
• A makes RPC call
• The transport protocol uses Bs address to
  establish a communication channel
• B replies to A RPC call

37
Approaches

• Treat Migrations as Failures
• Masking failures increases latency
• Constant retransmissions can be costly for fast
  moving objects
• Speed up name resolution
• Pre-fetching to upgrade caches could reduce
  failures and retransmissions
• Tracking objects using forwarding pointers
• Eliminates retransmissions, increases latency
• Forces an rigid hierarchy on the system to be
  efficient
• Integrate message routing and delivery
• Allowing late binding gives the name server
  freedom to act
• Flexible architecture for the price of increased
  latency

38
Failover to new Location

• Treat migration as failures
• Failures force lookup and retransmission
• Severe impact on latency
• Hard to distinguish migration from failures
• Lack of synchronization may cause endless
  retransmissions

39
Lazy Update

• Track objects using forwarding pointers
• Eliminates direct retransmissions
• Requires a stable structure to be effective
• A hierarchy can help to squash pointers, but adds
  points of failure
• Under constant migration latency can be severely
  impacted

40
Update Protocols

• Updating bindings
• Improve latency
• Does not completely eliminate migration gap
• Updates Server-side updates.
• It has to maintain connections
• Pre-fetching Client-side updates.
• Hard to coordinate with migration.
• Wasted resources if no frequent communication
  takes place

41
AO Approach

• Distributed location/tracking system
• Integration of Location and Routing
• Name Server acting as an RPC exchanger
• Avoids update and invocation gap
• Adaptive self-organizing system
• Adapt to departure and arrival of nodes
• Dynamic structure for scalability

M
Message
R
Reply
AO Middleware
M
R
A
B
R
M
AO Naming System As a Black Box
42
Design Challenges

• Scalable lookup
• Distributed hashing
• Consistent hashing requires knowledge of whole
  network
• CHORD variant fixes this but can partitioned
• Fast redistribution of keys on resource loss
• Tracking
• After first lookup, tracking can help maintain
  bindings updated
• Adapted ad-hoc routing algorithm for
  self-tracking
• Each node has naming capability, they route,
  forward and deliver
• Survivability
• Secure distributed hash table
• Redundancy and replication can be used
• Avoid performance degradation

43
Adaptive Structure
Name Servers Upper Layer
Name Servers Basic Layer

• Self-partitioning as system grows
• Leader selection algorithm
• No redistribution of mappings
• Only routing tables are modified
• No more than two levels to avoid lack of
  flexibility

44
Status

• Progress
• Studied related work extensively
• Naming and location systems (DNS, Globe, GRID,
  Active Naming, Intentional Naming, OceanStore,
  directory services, peer-to-peer systems, mobile
  wireless tracking algorithms)
• Routing and ad-hoc routing systems (IP routing
  protocols, Chord, CAN, OceanStore, RADAR, active
  Badge, BAT, etc)
• Selected flexible location and routing systems
• Analyze them for performance and reliability
• Their adaptability under constant change and
  scalability
• No architecture fully fulfills our needs
• Distributed hashing is best for adaptability and
  performance
• Self adaptation to grow is necessary to avoid a
  rigid architecture

45
Plans

• Working on design based on
• Variant of consistent hashing inspired on (CAN,
  Chord and Plaxton)
• Researching the limits of self-partitioning
• When does it apply
• How to reconfigure routing tables without
  disrupting running applications
• Working on a Java-RMI prototype
• RPC interception is finished
• Will extend it to form a full virtual layer for
  late binding, routing and message delivery
• Paper design 4Q2001
• Working Prototype 1Q2002
• Empirical experiments 2Q2002

46
Interface Elusiveness
47
Interface Elusiveness Status

• Completed analysis of EI complexity
• Focus on information and control flow protection
• Critical elements for security include
• Secure key exchange
• Good random number generation on both ends
• Appears interesting security can be achieved for
  high bandwidth links
• In Progress
• Identification of appropriate high performance
  RPC infrastructure for prototype (DCOM, Manta
  Java RMI, AO implementation)
• Complete writeup of above study

48
Motivation

• High-performance, component applications
• Protect information and control flow
• Incur low-overhead
• Control access

49
Approach

• Interface transformations
• Interface configuration determined by session key
• Change over time
• Make all method invocation messages look similar
  in structure to hide the actual communication
  taking place.
• Transparent to application

50
Design
51
Dynamic Substitution
method offset only!

• Cost per substitution
• one random number
• encryption one lookup and one swap
• decryption two lookups and two swaps

52
Message Permutation
53
Dynamic Transposition

• Criteria
• PRNG isolation
• Maximal Generation
• Uniform Distribution
• Speed
• Random Permutation Algorithms
• Direct enumeration
• SHUFFLE

54
Data Padding
55
Data Padding
EI
PRNG

• Goals
• Protect method identification
• Protect parameter values
• Cost
• 2 random numbers per padded data
• Data Padding module after Message Permutation
  module, so that padding data does not have
  overhead of being permuted

56
Traffic Masking

• Goals
• End-to-end traffic masking to avoid traffic
  analysis attacks
• Approach
• Adaptive traffic masking Timmerman
• Statistical approach is high-speed
• Adapt to current network load and needs

57
Security Analysis

• Theoretical
• N number of methods in interface
• M range of method offsets
• P number of parameters in message
• D number of dummy parameters
• Eavesdropping N(PD1)!/D!
• Active Attack M(PD1)!/D!
• Empirical
• N 41, M256, P8, D8
• Eavesdropping 3.6 x 1011
• Active Attack 2.3 x 1012

58
Attacks

• Linear and Differential cryptanalysis
• No linear relations these attacks dont apply.
• Cracking the PRNG
• EI relies on PRNG must isolate the PRNG output.
• Traffic Analysis
• Padding data protects RPC identification.
• Adaptive Traffic Masking protects communication
  channels.
• Key Generation/Store
• All such attacks apply. Must have secure keys.
• Close Repeats on Dynamic Substitution
• Eliminate repeats in design.

59
Costs

• Random Numbers
• Offset Substitution 1 random number
• Message Permutation 1 to P random numbers
• Data Padding 2D random numbers
• ? Optimization buffer random numbers during idle
  time
• Execution Time
• Offset Substitution O(1)
• Message Permutations O(P)
• Data Padding O(D)
• ? Total O(PD)

60
Prototype
network
client
server

• Berkeleys secure NinjaRMI
• Modified RMI compiler to implement mutations in
  stub and skel files
• Modified transport layer to use secure
  key-exchange, followed by mutated data stream
• ? within 3 of plain-text, 11 - 56x faster than
  Triple-DES, 168b key

61
Full Implementation

• Evaluating needed infrastructure
• High performance RPC
• Manta or custom RPC implementation
• AO Event Monitor
• Proof of correctness and demonstration
• PRNG

62
Status

• Design
• High-level design complete
• Compare speed and security of module algorithms
• Analysis
• Finishing security and complexity analysis
• Implementation
• Prototype complete
• Determining needed infrastructure for final
  implementation

63
Plans

• Complete
• High-level design
• Prototype
• 4Q2001
• Settle on high-performance RPC
• Finish security and complexity analysis
• 1Q2002
• Implement full design
• 2Q2002
• Debug/Test/Optimize implementation
• Writeup results

64
Applying Agile Objects to Resist Distributed DoS
Attacks
65
Agile Object Capabilities

• Distributed Denial of Service Attack
• What can AO to make systems more reliable
• Assumptions?
• Basic OASIS proxy view
• Attackers can compromise a large number of
  machines
• Location elusiveness complete
• Can we build a resilient service based on AO
• Discrimination based on identifiable load and
  evasion
• Analytical studies for whats possible
• Quantitative model of a DOS attack
• Analysis of rate control (QoS approaches)
  benefits
• Approach to Demonstrate AO Resistance to DDoS
  Attack

66
Outline

• DoS Problem Analysis
• Current Approaches for DoS Resistance
• Agile Objects and Proxy Approach
• Current Status and Plans

67
DoS Problem Analysis

• Definition
• A denial of service attack targets diminishing
  the availability of a specific application
  service to some or all legitimate users. In its
  distributed form, a large number of machines in
  the Internet are used to participate a
  distributed denial of service attack.
• Application model
• Publicly accessible application service (for
  example, websites)
• Threat model
• Physical attacks ? attack hosts or network where
  the application resides
• Logical attacks ? abuse the application by floods
  of legitimate requests

68
Metrics for study
Probability Density Function for this users
requests
A
B
pdf
Average Response Time
t
Application
Application Response Time
DoS Attack!!!
Worst Case Response Time
C
pdf
t

• From quality of service point of view
• Distribution of user request delay affected by
  DoS attacks
• Delay distribution in terms of affected area (A
  is less affected than B)
• Delay distribution in terms of duration of the
  effect (how long the effect on a user will last)
• The intensity of the attack, distribution of
  users as parameters

69
Current Approaches for DoS Resistance
Legitimate Users
Application
Attacker
compromise hosts in the Internet
DDoS Attack!!

• Reactive schemes
• Detect and filter out attack traffic
• Trace back to attackers or compromised hosts in
  order to stop them
• Punitive schemes
• The ability to trace back to attackers or
  compromised hosts may deter attackers from
  attacking.

70
Current Approaches for DoS Resistance
Legitimate Users
Application
Attacker
compromise hosts in the Internet
DDoS Attack!!

• Preventive schemes
• Protect machines from being compromised
• These approaches primarily focus on disrupting
  attack mechanisms rather than defeating the
  foundation of attacks

71
Why are DoS attacks possible?

• Publicly accessible application services always
  reside in well-known physical locations
• Physical attacks strike those physical locations
  to break down the services
• Most publicly accessible application services do
  not have fair scheduling, there is unfairness
  among users
• Individual requests from attackers and from
  legitimate users are indistinguishable
• Logical attacks consume significant amount of
  resource on the victim application service by
  asking it to process huge amount or huge
  (legitimate) requests, so that legitimate
  requests have less chance to be processed.

72
Key Ideas of Proposed Solution

• Novel idea -- make application service location
  elusive to defeat direct physical attacks on
  application services
• Location of the application is a secret no users
  know, so that attackers do not know where to
  attack
• Location of the application is changing, so that
  attack on fixed locations can only affect the
  application for a short period of time before it
  moves.
• Novel idea -- separate applications access point
  from the application itself
• Build access points in a highly distributed and
  redundant way to tolerate physical attacks
• Access points (we call them proxy network) act
  as a shield to protect the application. (This is
  fundamentally different to todays proxies, which
  primarily focus on filtering and address
  translation, and are not designed to be shields
  against DoS attacks.)
• Novel idea proxy network performs distributed
  fair schedule on user requests to defeat logical
  attacks

73
Proposed Solution Distributed DoS-Tolerant
Proxy Network

• Shield against physical attacks
• Scheduler to defeat logical attacks

Distributed Location Elusive Application
Proxy
Proxy
User
User
User
User
Proxy
Proxy
User
User
User
User
User
User
74
Requirements of the Proxy Network

• Distributed Fair Schedule
• Provide global fair schedule for users to
  tolerate logical attacks.
• DoS Tolerance on Individual Proxies
• Tolerate compromise/failures of individual
  proxies and balance load across proxies in order
  to tolerate physical attacks.
• Persistent Accessibility to the Application
• Keep track of how to contact the application
  without disclosing such information to un-trusted
  parties.

75
High-level Design

• Distributed fair schedule
• Partitioning users among proxies is one efficient
  way to achieve global fair schedule. (Each proxy
  can run centralized scheduler inside its
  partition without having to contact other
  proxies. This reduces communication cost.)
• DoS tolerance on individual proxies
• Tolerate failures/DoS attacks on individual
  proxies. In case one proxy is under attack (or
  fails), users have chance to use other proxies to
  contact the application. (Need dynamic mapping
  between users and proxies.)
• Solution Virtual Proxy Layer (novel idea)
• Each user is statically assigned to one (and only
  one) virtual proxy
• Virtual proxies are dynamically mapped to
  physical proxies and one virtual proxy is mapped
  to only one physical proxy.

76
Load Balance DoS-Tolerance
Gossip
A Lead
B Lead
Proxy Group A
Proxy Group B
gossip
gossip

• Physical proxies are organized into proxy groups.
  Proxy groups can form larger super-groups to
  construct a hierarchical proxy network
  corresponding to network topology.
• Gossip protocol is used to balance load among
  group members. Virtual proxies (users) may be
  reassigned to other physical proxies. (It can be
  viewed as migration). This load balance is done
  at every level of the hierarchy.
• During a physical DoS attack, an area of network
  may become slow. This load balance scheme can
  transfer most workload (user requests) to faster
  proxies, so that most users can still reach the
  application service.
• FT research uses gossip protocol to sync state.
  We borrow it to balance load.

77
Current Status

• Work completed
• Analysis of DoS problem
• Studied most forms of known DoS attacks
  especially distributed attacks
• Formalized model of DoS attacks
• Formalized the metrics for DoS study
• Survey on research problems in this domain
• Prevent user machines from being compromised
• Intrusion detection
• Source back-tracing
• Fair schedule schemes (scalability and security
  aspect)
• Proposed a novel way to solve DoS problem
• Use location elusiveness proxy network as
  access point to resist physical DoS attacks
• Use distributed fair scheduler to resist logical
  DoS attacks
• Initial design of the proxy network

78
Challenges and Plans

• Fair scheduler requires distinguishing requests
  from different users or machines.
• Should not affect user privacy
• Should not make it inconvenient for users
• Plan study how to distinguish machines or
  instances of OS. From there, we can search for a
  solution for this problem.
• Routing scheme to keep track of the dynamic
  mapping between virtual proxies and physical
  proxies
• Good performance and scalability
• Some initial study has been conducted and there
  is a primitive design
• Plan further study in routing solutions for
  mobile systems, which share a lot of similarity
  with this problem. Enhance current primitive
  design
• How to tolerate the case when some proxies are
  compromised?
• Need to prevent those compromised proxies from
  malicious behavior
• Need to discover the intrusion and properly
  handle it.
• Plan study in the field of intrusion detection
  for candidate solutions

79
Remaining Tasks

• Complete the design of the proxy network (4Q2001)
• Complete/enhance the gossip protocol for load
  balance and DoS-resistance
• Find solutions for the remaining challenges
• Implementation (2Q2002)
• Parametric study (3-4Q2002)
• Build a test-bed to do experiments
• Study how well this scheme can tolerate DoS
  attacks
• Study the performance overhead of this scheme
• Study the scaling property of this scheme
• Comparison with other schemes (4Q2002)

80
Summary

• Identified two important DoS attack models
  physical attacks and logical attacks
• Location elusiveness capability AO provides
  separating access points from applications enable
  us to tolerate physical DoS attacks.
• With the distributed fair schedule network we are
  developing, logical attacks can be tolerated.
• Proposed solution and the capability provided by
  AO system can resist DoS attacks.

81
Overall Summary

• Agile Objects is developing
• Location Elusiveness
• Interface Elusiveness
• To support rapid reconfiguration and increased
  availability
• Progress
• Location Elusiveness Object Authentication and
  Naming
• Interface Elusiveness
• Using AO to resist Distributed Denial of Service