View
219
Download
3
Tags:
Embed Size (px)
Citation preview
Policy Management and Policy-Guided Interactions in Ubiquitous Computing
Environments
V. Ramakrishna
PhD DissertationComputer Science Department, UCLA
September 19th, 2008
2
Thesis Statement
Automated negotiation for generation of service access agreements in ubiquitous computing environment can be achieved through a generic protocol guided by the participants’ policies.
3
Research Contributions General purpose negotiation protocol for exchange of
information through speech acts Modeling negotiation as a distributed/decentralized
policy resolution procedure for agreement generation Implementation of negotiation within a policy
management subsystem for ubiquitous devices and groups
Dynamic context-sensitive access control through negotiation
Building of a test case generator and large scale performance comparisons between centralized and decentralized policy resolutions
4
Outline
Introduction and Motivation Solution Model and Procedures System Design and Implementation Analysis and Testing Related Work Future Work and Conclusion
5
The Ubiquitous Computing Scene Goal: automated unobtrusive service access
anywhere and at any time (Weiser 1991) Where are we?
• Standardized seamless networking technologies• Mobile devices and agents• Smart spaces aware of occupants identities and
needs What is lacking?
• Automated configuration and facilitation of interactions between mutually unknown computers or agents
• Balancing automation with security and privacy concerns
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
6
Ubiquitous Computing Characteristics
Internet
Home Network
Coffee ShopPHYSICAL INTEGRATION: DEVICES, NETWORKS & SERVICES
SPONTANEOUS INTEROPERATION
Characteristics
Decentralized controlHeterogeneityAd hoc interactions
Personal Network
News / Game / StreamingVideo (WEB services)
Accessing Services
Intertwined processes of discovery and access control Blurred distinction between
producer and consumer No guarantee of prior trust
relationships or shared protocols
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
7
Our View of Interoperation
A top-down approach: abstract common features from different scenarios
Incorporate safety and privacy bottom-up Achieve service access agreements across
security and administrative domains while• Preserving autonomy of intent and action
• Limiting or eliminating manual intervention
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
8
A Smart Ubiquitous Conference Room
PDA – CELL PHONE(Possessed by a
conference attendee)PRIVILEGED ACCESS
CONFERENCE ATTENDEE(an ACM member)
(Already a member of the network)
Internet
Requires: Web access, Projector display, Printer.
Possession: UCLA credentials.Privacy Concern: Release of
credential
Services Offered: Internet, printer, display.Access Control: Only conference officials may access the
projector display.Policy: No sound permitted during conference hours.Possession: NSF credentials.
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
9
Guarding Network Perimeters
Service Offered: Network connectivity.Access Control: Based on device’s configuration.Security Constraint: Members may run only safe networked applications.Policy: Prospective client must reveal configuration information.
Firewalled Local Network
Requires: Network Access, Run network apps.Privacy concern: Releasing configuration info.Compromise: Stop vulnerable services.Access Control: Will run arbitrary code only from trusted source.
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
10
Roadblocks and Challenges
Cannot prepare for every interaction context Cannot identify, or have pre-arranged trust
relationships with, everyone else Heterogeneity of device characteristics,
service types and grades Difference in policies (goals and constraints) Interdependence of resources, entities, and
constraints within a domain
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
11
Solutions That Don’t Work Existing interaction procedures
• Too open and lacking security, OR• Secure but too inflexible
Centralized or third party control• Loss of privacy and autonomy• Does not scale; e.g., Smart Spaces
Separate protocols for each scenario• Contexts * Service types and access modes *
Interacting entities Combinatorial explosion• We should be able to control our domains through
policies rather than inventing new mechanisms
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
12
Service or application layer agreements
Based on policy Through a process of negotiation
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
13
Platform and Assumptions
TCP/IP
MAC LAYER
PHYSICAL LAYER
APPLICATION APPLICATION
NEGOTIATION FOR SERVICE
ACCESS
NEGOTIATION FOR SERVICE
ACCESS
OUR
PROTOCOL
NETWORK
Internet /World Wide Web
URI / HTTP
NAMESPACES / XML
ONTOLOGY / RDF
PROOF / LOGIC / RULES
TRUST
Semantic Web
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
14
All Interacting Devices Share Low level n/w mechanisms, like TCP/IP Secure communication protocols, like TLS Some common understanding of higher
(application layer) objects• Popularity of Semantic Web technologies
(RDF/XML) validate this assumption
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
15
Autonomous Domains
Classes:• Single computing device
• Networked group of computing devices
• Devices affiliated to an organization
Defined administrative boundary with independent policies
Capable of autonomous computing and communication
Offer services and run applications
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
16
Domain Policies Represents desired system behavior, goals and
choices Collection of facts, invariants and rules
• Specified by users
• Changes based on observations Knowledge of policies is private by default Minimum common abstraction necessary for
interaction• Policy is the only domain-dependent variable
Enables control over domain behavior of the scope and flexibility required in ubiquitous computing
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
17
Policy Classes and Ontology
Actions and Events
Attributes: Characteristics,
Metadata
Relationships among Data and
Resources
Autonomous Entities (Including
Agents)
Constraints: Deontic, Limits,
Precedence
Contextual Parameters:
Location, Time, etc.
Mechanisms and Protocols: Sensors,
Networking, Cryptography
Resources and Data
POLICY ONTOLOGYResource UsageSecurity and Access
ControlContext Awareness
POLICY CLASSES
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
18
Negotiation Model
D1 D2
G1
S1
P1
S2
G2
P2
Goals/Requirements Resources and Services Policies
Decentralized policy resolution
Bidirectional protocol
Multiple simultaneous objectives
Grant access to service set Q1
Grant access to service set Q2
Q1 G1 S2
Q2 G2 S1
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
19
Scenario – Conference Room
PDA – CELL PHONE
PRIVILEGED ACCESS
CONFERENCE ATTENDEEC1 (an ACM member)
Internet
Membership PolicyMembership will be granted if you are certified by ACM or an ACM affiliated organization; AND if you are running a trusted OS version; AND if you are willing to shut off port 25; AND if you are willing to turn off sound.
REQUEST: (1) Membership (2) Printer access(3) Projector display access
OFFER: (4) YES [NSF voucher object]
RequiresMembership for web access; AND Projector display access; AND Printer access.
OFFER: (1) YES [voucher], (2) YES, (3) NOOFFER: Journal membership for privileged access
REQUEST(Counter): (1) Valid ACM voucher?(2) Valid ACM Official voucher? (3) What OS do you run?
(4) Close port 25 (5) Turn off sound
REQUEST(Counter): (4) Valid NSF accreditation?
OFFER: (1) NO (2) NO (3) ‘2.6.17.1’(4) YES [Port 25 closed] (5) YES
OFFER: (6) YES [UCLA voucher object]
REQUEST(Counter): (6) Valid accreditation fromACM-affiliated school?
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
20
Negotiation: Who?
Two-party negotiation• A wants something from B and vice-versa,
within A’s and B’s policy constraints
• Bilateral one-to-one (concurrent) negotiations supported
Multi-party negotiation left for future work• Much harder to analyze theoretical properties
like completeness
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
21
Negotiation: What?
What do they negotiate for?• Resource access
• Information and data transfer
• Imposition of obligations
• Permissions to perform actions (typically, running operating system and network services)
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
22
Domain Policy Model
Individual policy statements specified in a declarative logical manner
Policies collectively comprise a database• Logically consistent statements
• Permits both examination and modification operations Policies can be related to each other Offer an interface to return answers to suitably
framed logical queries• Return unambiguous answer to a query
• Return satisfied and unsatisfied conditions
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
23
Policy Language Prolog syntax and semantics
• Facts and rules
• Predicates and arguments
• Logical reasoning mechanisms for querying: backward chaining, unification
• Negation-by-failure
• Sound, and efficient for our purposescertificate(‘UCLA’).
certificate(‘NSF’),possess(‘NSF’).
file(‘song.mp3’,audio), possess(‘song.mp3’).
member(X) :- candidate(X), possess(X,V), validCredential(V).
validCredential(V) :- certificate(V).
validCredential(V) :- certifiedBy(V,’ACM’).
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
FACTS
RULES
24
Policy Language (Continued)
action(closePort,Po) :- atom_concat(‘iptables –A INPUT –j DROP –p tcp –dport’,Po,C1),atom_concat(C1,’-i eth1’,C),shell(C).
door(X), partyMember(X).
Local predicates vs global predicates
System policies vs User policies
certificate(X), printer(X).
access(S,V) :- certificate(V), possess(S,’NSF’).
Helper Functionsaction(prohibit,sound) :-shell('amixer set Master mute',0).
Generality vs specificityaccess(E,R) :- someConstraint(E,R). access(entity,resource).
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
25
Basis of Negotiation
Units: messages representing speech acts• Utterances that express intent to perform an action
Categories:
A negotiation is a conversation• Sequence of speech acts
• Illocutionary logic describes rules for appropriate responses
Utility: capture wide range of scenarios
Speech Acts Directive Commissive Assertive Declarative
Message Type REQUEST OFFER POLICY TERMINATE
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
26
Message Types and Contents Requests
• Action <Do A>• Action <Allow me to do A>• Possession <Give me P>• State <Let me change to state S>• Question <Tell me …>
Policies• Obligation <Promise to abide by O>
Offers• Agreement <Yes, I agree to do what you ask>• Refusal <No, I will not do what you ask>• Rejection <I cannot accept your offer>• Answer <Here is what you asked/inquired about>
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
Each message can contain multiple requests/offers
27
Protocol State Machine
START
EXPECT
INITIATE
SERVICE
PROCESS
STOP
Trigger/Event toStart Negotiation
Send REQUESTS / POLICIES / OFFERS
ReceiveREQUESTS / POLICIES
ReceiveREQUESTS / POLICIES
Send REQUESTS / POLICIES / OFFERS Send REQUESTS /
OFFERS / POLICIES
Receive OFFERS
ReceiveTERMINATE / TIMEOUT
Send TERMINATE
SendTERMINATEReceive OFFERS
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
28
GENERATE COUNTER-REQUESTS AND POLICIES
GRANT REQUEST?
START
PUSH REQ/POL ontoREQUESTS-MADE STACK
LOOKUP OFFER toSEND
POP REQ fromREQUESTS-RECEIVED STACK
SEND SET of <REQ/POL>
RECEIVE MESSAGE
INITIATE NEGOTIATION?
Yes
No
More Requests
SAVE OFFER toSEND
More OffersMESSAGE TYPE?
Request / Policy
Other
PUSH REQ/POL ontoREQUESTS-RECEIVED STACK
More Requests
Yes
No
More Requests
PROCESS
OFFERS to SEND?
No
Yes
INITIATE
SAVE OFFER toSEND
PUSH REQ/POL ontoREQUESTS-MADE STACK
SAVE ALTERNATIVES = COUNTER-REQUESTS SET - <REQ/POL>:
<RECEIVED REQ/POL ALTERNATIVE SET of COUNTER_REQ>
COUNTER-REQUESTS
AVAILABLE?
Yes
<REQ/POL> = SELECT from COUNTER-REQUESTS SET
No GENERATE MATCHING ALTERNATIVE OFFERS
ALTERNATIVE OFFERS
AVAILABLE?
NoGENERATE FALSE
OFFER
SEND OFFER
SEND SET of <REQ/POL>
More Requests
No More Requests
COUNTER-REQUESTS GENERATE
D?
No More Requests
Yes
NoMore Satisfied
Offers
SERVICE
EXPECT
Yes SELECT OFFER and SAVE the REST
VERIFY OFFER VERACITY
OFFER ACCEPTABLE
?
ALTERNATIVE REQUEST AVAILABLE?
REQUESTS-RECEIVED
STACK EMPTY?
SEND OFFER
Yes
No
No
OFFER = AFFIRMATIVE / NEGATIVE /
ALTERNATIVE?
Negative
Alternative
SEND TERMINATION
<REQ/POL> = SELECT and REMOVE from ALTERNATIVES
SET
ALTERNATIVE OFFER OK?
Yes
Yes
RE-EVALUATE REQUESTS in REQUESTS-RECEIVED STACK
SAVE OFFER to REJECT
REMOVE INVALIDATED ALTERNATIVES
OFFER-SUBTYPE ==
REJECT?
Yes OFFER INTEGRIT
Y VERIFIED
?SAVE OFFER to
SENDLOOKUP OFFER from STORED
ALTERNATIVES
ALTERNATIVE OFFERS
AVAILABLE?
GENERATE FALSE OFFER
Yes
More Offers
POP REQ fromREQUESTS-MADE STACK
REGISTER CHANGES in POLICY DATABASE
No
No
More Requests
PUSH REQ/POL ontoREQUESTS-MADE STACK
AffirmativeNo
Yes
Yes
No More Offers COUNTER-REQUESTS GENERATE
D?
SEND SET of <REQ/POL>
Yes
No
More Requests
No
RECEIVE MESSAGE
PROCESS
LOOKUP OFFER toSEND
More Satisfied Offers
STOP
MESSAGE-TYPE == OFFER
MESSAGE-TYPE == TERMINATE
EXPECT
PROCESS
No
29
Negotiation Protocol Series of REQUESTs and OFFERs Reply to a REQUEST could be
• An OFFER (positive/negative)
• A set of Counter-REQUESTS Each side maintains two REQUEST lists
• Requests received, and Requests posed
• Lists grow with additional counter-REQs
• Lists shrink with OFFERs (rollback) Termination: both lists become empty
An agreement has been achieved Typical requests tested: credentials, attributes and state
queries
R15
R14
R13
R12
R11
R15
R14
R13
R12
R11
R24
R23
R21
R24
R23
R21
D1
D2
POSEDD1→D2
POSEDD2→D1
RECEIVEDD2→D1
RECEIVEDD1→D2
OFFER: R24
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
30
Generation of Counter-Requests A constraint-extraction algorithm Request: {member} Formatted predicate
• {member(S)} → INPUT Relevant facts
• possess(‘HP7200’); printer(‘HP7200’); groupSize(5); trustedDomain(‘ACM’); trustedDomain(‘UCLA’)
Relevant policy• member(S) :- sound(S,prohibit,1000,1500), groupSize(G),
G>4, closedPort(S,25), possess(S,V), voucher(V,M), trustedDomain(M).
Extracted request set alternatives → OUTPUT• {sound(prohibit,1000,1500); action(order,closePort,25);
possess(V), voucher(V,’ACM’)} • {sound(prohibit,1000,1500); action(S,order,closePort,25);
possess(S,V), voucher(V,’UCLA’)}
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
31
Negotiation Model: Distributed Policy Resolution
Goals + Policies + Logical Queries Agreement
High-level goal: policies must not be violated Agreement fits within the consistent parts of
the negotiators’ policies (disregarding incompatible policies)
Negotiation has the same effect as running a query through a union of the negotiators’ databases
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
32
Protocol as a Distributed Derivation Tree
Centralized resolution generates a tree• Root represents goal
• Node children relation represents a rule
• Leaves represent facts
Negotiation generates a similar tree• Difference: nodes distributed amongst negotiators
• Node children relation represents rules and requests
• Children parent relations represents offers
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
33
Ubiquitous Policy Manager: Design and Implementation
Prerequisite: an environment/platform that supports collections of devices and offers services• PANOPLY: a middleware
that manages devices clustered in spheres of influence
Policies mediate interactions among devices and collections of devices
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
PANOPLY MIDDLEWARE
SPHERE MANAGER
APPLICATIONS
OPERATING SYSTEM
NETWORK
POLICY MANAGER
EVENT PROCESSOR
34
Policy Management in Panoply
Primary task: negotiation between spheres for membership and service access• Support for renegotiating agreements
Arbitrate access to resources through negotiation
Event-action triggers
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
35
Concurrent Negotiations in Panoply
SPHERE MANAGER
APPLICATIONS
OPERATING SYSTEM
POLICY MANAGER
EVENT PROCESSOR
NETWORK
SPHERE MANAGER
APPLICATIONS
OPERATING SYSTEM
POLICY MANAGER
EVENT PROCESSOR
NETWORK
SPHERE MANAGER
APPLICATIONS
OPERATING SYSTEM
POLICY MANAGER
EVENT PROCESSOR
NETWORK
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
36
Policy Manager - Functional ViewMessaging Interface (To other system components, remote computers)
Policy Database
FRONT END
CONTROLLER
POLICY ENGINE
Logical Knowledge Engineering Mechanisms
Security/Trust Model
Formulation and Semantic
Interpretation of Messages
Protocol State Machine
Multi-Threading and Message Switching Observer/Event
ListenerFault Tolerance
Request Queue Management
Negotiation Heuristics
Interfacing with Helper Functions
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
Interfacing with Helper Functions
Non-logical operationsProcessing of objects (say Java objects)Operating system operations
Example: sign and verify a voucher
Fault ToleranceHandle node/network failure and race conditionsUse timeouts and unique timestamps per thread
37
Applications
Group- and context-driven Panoply apps• Interactive Narrative
• Smart Party Smart conference room Peer-to-peer file sharing Secure flexible perimeters Opportunistic configuration
• Credential/key
• Printer access/command
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
38
Dynamic Access Control
SPHERE MANAGER
APPLICATIONS
OPERATING SYSTEM
NETWORK
POLICY MANAGER
EVENT PROCESSOR
External
Sphere
External
Sphere
...........
Events
Events
RUN QUERYPASSDROP
NEGOTIATE
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
39
Application: The Smart Party
Users bring mobile devices carrying music and musical preferences
Each room builds custom play-list based on user presence and preferences
Dynamically streams music from attendees
Cooperative music application deployed in a multi-room environment
Smart Party
Living Room
Dining Room
Family Room
Rock
Rap
Jazz
Folk
R&B
[Eustice2008: PhD Thesis]
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
40
Access Control in a Smart Party
Guest tries to force the room to play his favorite song
Query made to Policy Engine
Negotiation:• Do you have a valid
host voucher?
• YES Update playlist
• NO Nothing changes
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
41
Sample Performance Results
0
1000
2000
3000
4000
5000
6000
7000
8000
Time in milliseconds
I II III IV
Negotiation Scenario
Negotiator N1
Wait
Process
Case I: R(N1) AO(N2) T(N1)Case II: R(N1) NO(N2) T(N1)Case III: R(N1) 3 C-R(N2) 3 AO(N1) AO(N2) T(N1)Case IV: R(N1) C-R(N2) NO(N1) 3 C-R(N2) (alternative) 3 AO(N1) 1 AO(N2) T(N1)
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
Time in milliseconds
I II III IV
Negotiation Scenario
Negotiator N2
Wait
Process
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
N1802.11b
TLSN2
Initiator
R(N1) == Request for membership
42
Analysis: System Perspective
Assumptions
• Finite policy database
• Finite length of each policy statement
• No cycles within a database Protocol termination
• Counter-Request generation procedure terminates
• Running time complexity = O(R(R+F)2FS2A)
• Deadlock-free
• Livelocks possible• Cycles between negotiators result in duplicate requests
• Can be avoided with checks for duplicates (adds overhead)
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
43
“Success” of Negotiation Primary negotiation aim: given goals and policies,
generate a result• Set of results ranging from none to full satisfaction of goals• Collection of such results are consistent with policies
An oracle (centralized policy resolution) can generate an optimal solution• Knows <G1,P1,S1> and <G2,P2,S2>, and uses a centralized
resolution algorithm to determine the best result• Complexity is still exponential
Negotiation is a decentralized policy resolution• Need to keep local policies private• Must work with partial knowledge• Ideal: achieve the oracular result
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
44
Grades of Success Correctness:
• Result (set of goal satisfactions) is an improper subset of the oracular result
• Only criteria: consistency with policy Completeness:
• Negotiation protocol delivers oracular result Optimality:
• Negotiation protocol delivers oracular result in fewest number of steps
Correctness < Completeness < Optimality
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
45
Analysis: Theoretical Perspective Correctness and Completeness?: YES, with Exception
• Guaranteed to terminate in a finite number of steps• Database has finite number of policies• Each policy is of finite length
• Trivially correct in all cases• End result of negotiation guaranteed to be consistent with policy, as Prolog
query semantics are known to be correct
• Exhaustive search ensures that a solution will be found Exception
• Intermediate negotiation steps involve non-logical operations• Database state modification may cause negotiation failure even
when success is possible• FIX: keep track of modifications and undo them
Optimality?: NO GUARANTEE• Negotiation time and #steps depend on alternative selection
ordering
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
46
Optimality Testing
Statistical comparison of actual and optimal negotiations
Primary metric: number of steps• Oracle can estimate optimal (least) number of steps
• Negotiation is sub-optimal
• #steps depends on alternative selection heuristic
Other metrics (time, tree coverage) also measured Counter-Request selection heuristic used
• Size of request set
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
47
Testing Tools Negotiation Protocol (decentralized PR) Centralized Policy Resolver: Oracle
• Inputs• Two policy databases and an initial goal (request)
• Process• Combine two policy databases into a centralized one
• Outputs• Full (centralized) derivation tree• Total number of policies examined• Number of steps taken by an optimal negotiation
Test case generator
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
48
Generation of Test Cases
Pair of policy databases and goal sets • One for each negotiator
Variations based on size of tree• Number of nodes in a tree = O(bd)
• Control parameters
• bmax: maximum branching factor
• Indicates length or complexity of policies
• dmax: maximum depth
• Indicates interdependency of policies
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
49
Negotiation Length Variation (Optimal Steps)
-1.0, 3.7 3.0, 3.0
5.0, 6.3
7.0, 9.8
9.0, 13.5
11.0, 17.7
13.0, 22.0
15.0, 27.6
17.0, 32.7
0
5
10
15
20
25
30
35
40
-2 0 2 4 6 8 10 12 14 16 18Optimal Number of Steps
Neg
oti
ati
on
Ste
ps
Mean
Median
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
50
Negotiation Length Variation (Branching Factor)
2
2.5
3
3.5
4
4.5
5
5.5
6
0 2 4 6 8 10 12Database Branching Factor
Nu
mb
er
of
Ste
ps
Oracle
Negotiation
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
51
Processing Time
-20000
0
20000
40000
60000
80000
100000
120000
140000
-2 0 2 4 6 8 10 12 14 16 18
Number of Optimal Steps
Tim
e i
n M
illi
se
co
nd
s
Oracular Tree
Negotiation Tree
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
52
Processing Time Per Step
-1000
0
1000
2000
3000
4000
5000
6000
-2 0 2 4 6 8 10 12 14 16 18Number of Optimal Steps
Tim
e in
Milliseco
nd
s
Oracular Tree
Negotiation Tree
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
53
Results Summary Actual negotiation increases linearly with the optimal
negotiation length• Average length of failed negotiations < 4 steps
Negotiation processing time dominates oracular processing time, but not the average time per step
Increase in policy complexity results in significant increase in processing cost (but mainly for bmax >= 6)
Fraction of intermediate requests granted and alternatives examined show small variations but are significantly lower than unity on average
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
54
Related Work Negotiation Protocols
• Automated Trust Negotiation• Protune, PeerTrust, TrustBuilder [BYU,UIUC]• Goal: client-server transactions on the Web• Does not support alternatives or multiple goals• No comparison with centralized model
• Web services negotiation (WS-Agreement) Policy Languages
• Rei pervasive computing language• Cross-domain semantics
• Web services: WS-Policy, XACML: non-logical• Ponder: non-logical• Ontology: SOUPA, DAML+OIL, OWL
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
55
Related Work (Continued) Middleware for open systems
• Ubicomp active space middleware – Hyperglue [MIT], Cerberus [UIUC]
• Service discovery – JINI, UPnP• Limited security features
Access Control• Generalized RBAC• Dynamic RBAC• Secure Context-sensitive Authorization [Minami and Kotz]
• Distributed Proof• Test Case Generation
Trust frameworks• SECURE project
• Dynamic notion of trust• Trust evolution based on interaction history
• Reputation frameworks
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
56
Future Work Enhancements to the negotiation protocol
• Other heuristics: expected time to finish, partial ordering based on privacy and trust
• Multi-party collective negotiation• Avoiding DoS attacks
Policy Manager• Running on resource-constrained devices• Porting to other middleware; e.g., GAIA
User Interaction• More control and feedback• Post-negotiation analysis• User-friendly policies
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
57
Conclusion Service-level interoperation in ubicomp requires
• Flexible solutions• Minimal user intervention
Generic policy-guided negotiation enables interoperation
Negotiation is modeled as a distributed policy resolution procedure
Proof-of-concept was demonstrated through a working implementation and practical applications
Negotiation can be used as a tool for dynamic context-sensitive access control
Large-scale optimality tests indicate feasibility of negotiation in practical situations
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
58
Thank You V. Ramakrishna, Kevin Eustice, and Peter Reiher, “Negotiating Agreements
Using Policies in Ubiquitous Computing Scenarios,” In the Proceedings of the IEEE International Conference on Service-Oriented Computing and Applications (SOCA'07), June 19-20, 2007, Newport Beach, California.
Venkatraman Ramakrishna, Peter Reiher, and Leonard Kleinrock, “Distributed Policy Resolution Through Negotiation in Ubiquitous Computing Environments,” In submission to the 7th Annual IEEE International Conference on Pervasive Computing and Communications (PerCom 2009).
Kevin Eustice, Leonard Kleinrock, Shane Markstrum, Gerald Popek, Venkatraman Ramakrishna, Peter Reiher, “Enabling Secure Ubiquitous Interactions,” In the Proceedings of the 1st International Workshop on Middleware for Pervasive and Ad-Hoc Computing (Co-located with Middleware 2003), 17 June 2003 in Rio de Janeiro, Brazil.
Kevin Eustice, V. Ramakrishna, Alison Walker, Matthew Schnaider, Nam Nguyen and Peter Reiher, "nan0sphere: Location-Driven Fiction for Groups of Users," In the Proceedings of the 12th International Conference on Human-Computer Interaction (HCII 2007), 22-27 July 2007, Beijing, P.R.China.
Kevin Eustice, V. Ramakrishna, Nam Nguyen, and Peter Reiher, "The Smart Party: A Personalized Location-aware Multimedia Experience," In the Proceedings of the Fifth IEEE Consumer Communications and Networking Conference (CCNC 2008), Las Vegas, NV, January 10-12, 2008.
59
Case Study: Secure Perimeters
Firewalled Local Network
OFFER: (1) NO
REQUEST: (1) Membership REQUEST (Counter): (1) Are you running Ubuntu?
OFFER: (2) YES (3) NO
REQUEST (Counter): (2) Are you running Redhat? (3) v2.6.20 or higher?
REQUEST (Counter): (4) Upgrade Kernel
REQUEST (Counter): (2) Credentialed by UCLA? (3) Let me run networked applications
OFFER: (2) YES [UCLA Voucher] (3) YES
REQUEST (Counter): (5) Close port 25
OFFER: (5) YESOFFER: (4) YES [Result] OFFER: (1) YES
Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
60
Case Study: Interactive Narrative
Team-, location- and action-driven fiction deployed in UCLA
Purposes of negotiation• Membership within location and
team spheres
• Obtain location voucher
• Variations• Dynamic role change
Policy manager roles• Hints based on context and location
changes
61
possess(VAR),door(VAR)action(order,play,VAR),door(VAR),directory(VAR,VAR1)action(order,closePort,VAR),door(VAR),type(VAR,VAR1)action(order,prohibit,VAR),printer(VAR),brand(VAR,VAR1)
Sample Test Case
storage(px6).voucher(ht).type(zp,bw).voucher(vk).printerName(pjf).disp(l).group(py,acm).tim(gh).brand(o,hp7100).parentName(htm).possess(diskSpace,0).displayName(ck).directory(ec,v).file(fi1).type(xz1,color).voucher(c).
Facts
obey(X,open) :- printer(VAR),displayName(X, VAR001723).accessInfo(X,(tim(VAR01213))) :- possess(X, VAR0683),voucher(VAR0683),type(VAR0683, VAR1684).access(X,diskSpace,VAR) :- childName(X, VAR023638).obey(X,run) :- voucher(VAR),type(VAR,VAR1),possess(X, diskSpace, VAR1610).obey(X,open) :- printer(VAR),memberIn(X).obey(X,open) :- printer(VAR),childName(X, VAR023592).accessInfo(X,(tim(VAR01213))) :- possess(X, diskSpace, VAR1573).accessInfo(X,(tim(VAR01011))) :- action(X, order, open, VAR0554),printer(VAR0554).accessInfo(X,(childName(VAR023))) :- memberIn(X).obey(X,open) :- printer(VAR),possess(X, diskSpace, VAR1481).accessInfo(X,(childName(VAR023))) :- displayName(X, VAR001382).access(X,VAR) :- voucher(VAR),type(VAR,VAR1),childName(X, VAR023354).obey(X,run) :- voucher(VAR),type(VAR,VAR1),action(X, order, open, VAR0144),printer(VAR0144).
Rules
Sample Goals