Research Directions in Context-Aware QoS and Security for Wireless Mobile Networks

1. Research Directions inContext-Aware Quality of Service and Security for Wireless, Mobile Networked Systems Dr. Joseph Loyall BBN Technologies Research Directions in Situational-aware Self-managed Proactive Computing in Wireless Ad hoc Networks March 2, 2009

2. Agenda • Trends toward wireless, mobile networked systems • History • Characteristics of wireless, mobile networked systems • Challenges for wireless, mobile networked systems • Infrastructure for wireless, mobile networked systems • Adaptive middleware • Information management • Services-based • Research directions in context-aware quality of service • Research directions in context-aware security • Conclusions

3. App App OS OS Network Protocols Historical Context: Software Infrastructure Enables Application Capabilities 1950s 1960s 1970s 1980s 1990s 2000s Emb. App Emb. App Application App App Application App App LW Middle- ware LW Middle- ware Middle- ware Middle- ware MW Svcs MW Svcs MW Svcs MW Svcs Middle- ware Middle- ware Operating System OS OS Embedded OS Embedded OS OS OS Network Protocols App App Network Protocols Network Protocols Operating System Database Systems System Development Environments Database Systems Information Management Systems Programming Languages 1950s Fifty Years of Distributed Systems Software Architecture Evolution 2009+

4. Common Characteristics of Wireless Ad Hoc Networked Systems Dillingham, Nathan, “Communicating on the Move: Mobile Ad-Hoc Networks,” CrossTalk, The Journal of Defense Software Engineering, July 2007 BBN demonstration (DARPA PCES program), April 2002 • Connectivity is ad hoc and intermittent • Links can be dropped due to range, motion, obstacles, failures, weather, and other factors • Resources are constrained • Network bandwidth • Computing power • Screen real estate • Memory • Secondary storage • Physical limitations • Size • Weight • Power • Devices and platforms are heterogeneous and diverse • Nodes • Communication hardware • Communication protocols, e.g., broadcast and line-of-sight

5. Characteristics of Wireless Ad Hoc Networked Systems Due to Context (Situation) The user can expend only limited and varying attention on the system Location can change, potentially rapidly and frequently Dynamic and unfolding situations imply changing needs Dynamism makes a priori established shared secrets or associations harder to manage (limiting the feasibility of solutions like PKI) Not always time or space to load new applications

6. Need for QoS and Security Management in Wireless Ad Hoc Networked Systems • QoS management • Monitor the limited available resources • Allocate the available resources to the most important communication and processing requirements • Configure critical processing and information dissemination to the resources available • Security • Protect information • Maintain the integrity of the device’s functionality, i.e., resist or tolerate cyber attacks • Mediate the tension between need to share and need to protect in distributed interoperation that might span many administrative domains or federated enclaves • Must be adaptive • As resource availability and contention changes • As the user, device, and system needs and situations change • As security policies and situations change • As the makeup of the interoperating organizations, domains, and participants change

7. Additional Challenges for QoS Management and Security in Wireless Ad Hoc Systems • QoS traditionally involved resources such as CPU, memory, and bandwidth • Now it must consider additional resources • Human attention • Screen real estate • New challenges for security mechanisms • Eavesdropping becomes much easier • Ad hoc discovery and transient connections expose new vulnerabilities and introduce new risks • Increased distraction of the user and frequent changes in situations open up more opportunities for compromise • These new challenges motivate • Proactive and autonomic computing, i.e., reduction in explicit human input • Context-aware computing, i.e., awareness of characteristics of the user and his situation and using it on the user’s behalf • Adaptation, i.e., changing behavior, resource usage, and security settings as the context changes

8. Agenda • Trends toward wireless, mobile networked systems • History • Characteristics of wireless, mobile networked systems • Challenges for wireless, mobile networked systems • Infrastructure for wireless, mobile networked systems • Adaptive middleware • Information management • Services-based • Research directions in context-aware quality of service • Research directions in context-aware security • Conclusions

9. Research Directions in Infrastructure for Wireless Ad Hoc Networking • Do MANET’s have infrastructure? • Ad hoc and P2P often considered “infrastructure-less” • Each node has infrastructure • Palm OS, Pocket PC, Embedded Linux • Perhaps there is no overarching infrastructure (i.e., servers, global location) • However, they need middleware infrastructure • Abstract platform and communication heterogeneity • Encapsulate common services • Avoid application stovepipes • QoS management and security should be in an adaptive middleware layer • Reduce memory and processing footprint of every application • Enable aggregation of behaviors • Should be context aware • Reduce the cognitive burden on the user • Should be provided as services or components • Separate the QoS and security management separate from the functional behavior of the system • Enable separate development and evolution • What are the fixed points, assumptions? • Microsoft, Linux, Java • Driven by educational and industry trends, as much as by technology • SOA • Is there ever going to be SOA for embedded platforms • Service-oriented versus service-based apps hardware OS Middleware

10. Trends in Adaptive Middleware for Tactical Networked Systems • Component middleware • CORBA component model • QoS components (Qoskets) • Model integrated computing • Information management systems (pub-sub) • Joint BattlespaceInfosphere (JBI) • Data Distribution Service (DDS) • Service-based and Service-oriented systems • Information management services • QoS and security services Ferguson and Stockton, Service-oriented architecture: Programming model and produce architecture, IBM Systems Journal, 2005. • Distributed objects • CORBA • Quality Objects (QuO) • CORBA event service and notification service

11. Full Image Tiled Image Compressed Tiles A Net-meeting like mission replanning collaboration between C2 and fighter aircraft over Link-16 ROT L ROT R RESET HOME PREV OUT PAGE NEXT IN PAGE UP DOWN M LEFT RIGHT QUERY LINE SYM Distributed Object Middleware Used in Avionics Dynamic Mission Planning Flight Demonstration in Missouri (St. Louis to Hannibal) December 2002 (BBN, Boeing, WuStL, Honeywell) • QuO adaptive object middleware providing application and information QoS management • TAO event service providing CPU scheduling • TAO pluggable protocol enabling communication via Link-16 • CORBA (TAO and ORBExpress)

12. Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) ATD Demonstrated at CECOM HQ, Ft. Monmouth, NJ, June 19-20, 2002 UAV OEP Software was used to demonstrate QoS network performance for the MOSAIC airborne platform A helicopter-based “airborne node” used QuO adaptive distributed object middleware to dynamically modify DiffServCodePoints. BBN’s Portable Switching Software (PSS) gave priority to coded datagrams in the MOSAIC wireless network. “The results were easily distinguished on the display screens as higher quality video.” Adaptive Distributed Object Middleware for QoS Management in an Airborne Ad Hoc Network US Army CECOM MOSAIC Demonstration Area

13. Adaptive Component Middleware for End-to-End QoS Management in a Multi-UAV Flight Demonstration Adaptive component middleware manages dynamic, real-time QoS for ISR and C2 information in a multi-UAV time-sensitive targeting system • BBN’s Qosket adaptive QoS components • CIAO CORBA Component Model distribution middleware • PICML model integrated computing for component assembly • Flight Demonstration at WSMR, April 2005 (BBN, Boeing, Lockheed Martin) • End to end QoS management of surveillance and command and control data • Two live flight UAVs (Scan Eagles) and additional simulated UAVs • Live fire HIMARS missile launcher QoS middleware shapes application behavior and network traffic to fit allocated resources QoS middleware dynamically adjusts resource allocation and QoS policy based on mission conditions QoS middleware controls access to resources based on QoS policy

14. Evolution of the Concept of Information-Centricity System-centric • Stovepiped systems with limited interoperability • Lacked means for standard interoperability Interface-centric • Interoperability based on point-to-point addressing • Locate “who” you want to talk to (e.g., through a URI or node discovery), then access through its exposed interface • Interoperation based on address and operations, not the information provided or needed Information-centric A Copernican Revolution with information at the center of many interactions • A user has information to make available or needs information • The type/properties of the information are more important than the source (attributes of the source are properties of the info) • If I need a map or directions, it is important that they be accurate, timely, and trusted, more so than from a particular source • Interoperation based on active management to locate, broker, and administer information

15. Core Concepts of Pub-Sub-Query Information Management Services Consumers Query predicate Subscription predicate API Control Common Broker Access Producers Match Archive Data store MIO Managed Information Object (MIO) <metadata> <baseObject> <InfoObjectType> <Name>Image</Name> </InfoObjectType> <Publisher>Intel COI </Publisher> <Latitude>28.2.3 </Latitude> <Longitude>54.3.46 </Longitude> </baseObject> </metadata> • Standardized connections for clients (users of the information management services) • Publication to make information available • Subscribe to request future information • Query to request past information • Requests are made using predicates over information attributes (metadata) • Using a rich, standards-based predicate language, XPath and XQuery • Information is encapsulated into an organized MIO structure • Metadata describing the information to facilitate brokering • Payload, the original data • Access control and web-based administration

16. Information Brokering and QoS Services for Beyond LOS Tactical Information Exchange COT router Marti QoS manager Shared and constrained radio links Dynamic numbers of users Marti QoS manager COT image producer Marti QoS manager Changing mission modes and roles COT image producer Raven GS FalconView Consumer • Marti QoS management provides • End-to-end higher quality of service from publisher to CoT router to each subscriber • Predictable and controllable network usage and performance • Automatic adjustment to changing radio conditions and mission priorities • Information broker for moving information between mobile nodes (UAVs and tactical users) beyond line of sight • Information broker at ~85,000 feet (AFRL Apollo JBI) • Scan Eagle and Raven UAVs publishing imagery • Micro Hard and Wave Relay radios • Marti QoS management • Dynamically allocates bandwidth among users • Automatically adjusts as bandwidth changes, e.g., as the distance between radios changes • Shapes data to fit the allocated bandwidth • Changes rate, compression, scaling, and cropping of data to provide highest quality information possible within available bandwidth • Provides mission-driven control of QoS management • Mission modes dictate the order and limits of information shaping • Clients’ mission modes can change dynamically; the QoS manager automatically adjusts

17. Federation Services for Combining Tactical and Enterprise Configurations Tactical Federate Tactical Network Data Discovery Service Tactical clients • Federation services can be used to bridge enterprise and tactical configurations. • The configuration must keep the resource richness of the enterprise environment from overwhelming the resource limitations of the tactical environment. • Single entry point on the enterprise network to which all events from the tactical network can be sent. • QoS management is important so events from the enterprise network don’t overload the resources on the tactical network. Enterprise Federate Other svcs Propagation Service FE-IMS CAPI Svc FE-IMS Propagation Service Service Bus Propagation Service Data Discovery Service FE-IMS Enterprise clients Tactical clients Data Discovery Service Enterprise Network Tactical Federate Tactical Network

18. Agenda • Trends toward wireless, mobile networked systems • History • Characteristics of wireless, mobile networked systems • Challenges for wireless, mobile networked systems • Infrastructure for wireless, mobile networked systems • Adaptive middleware • Information management • Services-based • Research directions in context-aware quality of service • Research directions in context-aware security • Conclusions

19. Context Information Can Be Used to Improve the QoS of Information Delivery • A context aware QoS system uses information about the environment in QoS decisions and enforcement • Context that affects QoS requirements • Context that changes how quality is perceived • Context that affects the ability to deliver QoS • Context information should be automatically gathered, not part of an explicit request • Tactical networks cannot bear all useful (or even relevant) information, we must send information in order of importance • Context information can be used to improve the quality of information management • Prioritize information discovery, matching, and delivery A change in context can affect the QoS desired A change in context can affect the ability to deliver QoS

20. Problem Space • Tactical users face a challenge in crafting requests for information: • Requests that are too specific might result in no results • Requests that are too broad can overwhelm the user with information, burying the most useful • Consider requesting information during route planning through an area • What is needed is information (e.g., imagery, intel) about the route • The user’s context is useful to determine the information that is most useful • Most recent, most trusted, closest, etc. of the information available

21. Incorporating Context into Information Requests • Using context information for predicate matching and information discovery • Define a set of context information elements that can be useful in information management, information management operations that can utilize the context elements, and the enhanced capabilities realized by the use of context information • Define a set of metrics for evaluating the benefit of utilizing context information in information management • Evaluate and gather metrics to show the relative benefit of using context information over a baseline that does not utilize context information. • Investigate the use of contextual information as part of the predicate matching process to influence delivery order.

22. Context-Aware Predicate Matching Experiments Baseline delivers results with no consideration of context • We conducted a set of experiments evaluating using context information to supplement explicit requests • To prioritize, order, and prune responses • Experiments concentrated on three context elements • Location • Time • Affiliation • Experiments investigated three techniques for incorporating context into requests • Post-processing results from a request • Transforming a request into a set of requests, each with a range of context values • Transforming a request into a more complex request with extended predicates • Additional experiments • Combinations of context elements • Metrics for combining context elements

23. Optimal Ordering by Context Provided by Post-Processing Most recent Closest to the requestor Most trusted • Post-processing of the results can get an optimal order for the delivery of MIOs in any single context dimension • 25 seconds to process the request • Not counting the post-processing to sort the results (performed manually) • The full set of results consumed 614.94 MB of memory • The memory would be required to store the results for post-processing. • 0.5 MB of this is metadata • The remainder is the simulated imagery payload. • Not necessarily suited to tactical environments • Where does post-processing occur without requiring delivery of all MIOs • Requires a large amount of memory • Possibly a large amount of bandwidth • Potentially a large amount of time

24. Automated Request Expansion Technique The set of location-aware requests starts at the requestor and makes 13 total requests, each one lat-lon minute farther from the requestor. • An explicit request for information is translated into a set of requests, each adding context clauses from best to worst • Time in months and half months (most recent to least recent) • Location in lat-lon minutes from the location of the requestor (see diagram to right) • Affiliation in order of most trust to least • Granularity of the ranges has a accuracy/performance tradeoff • Finer grained granularity improves the order of the results, • But results in a larger set of requests and therefore takes longer to process

25. Request Expansion Results • Request expansion improves over the baseline, but provides only an approximate order • More useful are generally provided earlier (overall trend in the graph) • But the most useful is not necessarily provided first (no total order) • Granularity affects both the order and performance • A finer granularity (e.g., weeks, days in time; lat-lon seconds in distance) improves order, but expands to more requests

26. Performance of Request Expansion Approach • The maximum MIOs that must be kept in memory is the number returned by any of the individual requests • This results in significant potential memory savings • Request expansion adds some execution time due to more requests being processed • Extra time to execute is more than offset by increased control (see next slide)

27. Request Expansion Produces Meaningful Results Much More Quickly The first 200 (most recent, closest, most trusted) are available within about 5 seconds The baseline request retrieves all 1000 responses within about 25 seconds Additional time is required to post-process to extract the most useful In contrast, the request expansion approach can retrieve the most useful 200 responses in about 5 seconds Once the most useful are received, the rest need not be

28. Technical Challenge: How to Combine Different Types of Context Information Delivered in order of combined, normalized quality Intersection of sets delivered in order of individual context attributes • Users are likely to frequently need the best combination of several context attributes • An information object that is the right combination of recentness, proximity, and trust is likely a better choice than an information object that is best in one dimension and poor in others • Request expansion offers an approach to combining dimensions • Expand the request in all dimensions • Service the first in each dimension in a round-robin fashion • When enough responses are received from each, compare to extract the intersections of the result sets • We have looked at a weighted summation metric • Each context attribute is normalized and assigned a weight. The values are multiplied by their weights and summed. • Additive: The attributes have equal weight. • Exponential: By choosing weights that are orders of magnitude different, the weighted method can represent combinations in which some attributes dominate the others. • This investigation is ongoing

29. Agenda • Trends toward wireless, mobile networked systems • History • Characteristics of wireless, mobile networked systems • Challenges for wireless, mobile networked systems • Infrastructure for wireless, mobile networked systems • Adaptive middleware • Information management • Services-based • Research directions in context-aware quality of service • Research directions in context-aware security • Conclusions

30. Security in Wireless Ad Hoc Environments Security in MANETs are a challenging task…. • In 66% of data breaches the organization did not know that the data existed on the system, 27% did not know that a network connection was there (2008 Data Breach Investigation Report, Verizon) • This report was derived from wired and enterprise systems • The proliferation and ubiquity of computing nodes that can communicate wirelessly is expected to make the situation worse • 65% of attacks exploit misconfigured systems – 30% exploit known vulnerabilities for which there is a patch out (Gartner, 2007) • Mobility, spontaneity, ubiquity, lack of attention from human users, and resource constraints increase the risk of misconfiguration and make variance in patch latency higher..

31. Basic Protection of Data and Access Encrypt all data on disk will imply every operation that reads or writes will need some password or biometric input Deny network access will require users to deal with the dialog boxes • It is possible to encrypt/decrypt files on the fly • Truecrypt even offers hidden volumes for deniability (captured device, extortion to reveal password) • It is also possible to control who can access which files, and which network connections are allowed • SELinux policies, local firewalls • But, a strict “deny by default” policy will not work – encrypting every stored file is costly, user clicks needed to grant permission • Not only autonomic & proactive (i.e., without explicit external and user input), enforcement needs to be adaptive and context aware • Policies need to change based on context (frequently)

32. Issues and Hard Problems in Context Aware Security apps hardware OS Middleware • Hard problems • Devices encountered may not be authenticated using PKI • May not have a common root of trust, revocation issue is bigger problem (overrun devices) • Gaining context information: environment, user’s behavior pattern, mission roles, etc. is not easy • Making “provably” correct or optimum or effective decisions is hard, but is critical • At the same time, the solution must work in a limited footprint and remain non-intrusive to the user’s experience • Context-aware security middleware can be an extension to the OS of the mobile and ad-hoc devices • Dynamically coordinates security policies, system services and resources • Mediates applications access of system services (including remote)

33. Dealing with Misconfigurations Invariants about applications, hardware and OS Invariants about applications and environment hardware Invariants hardware and OS OS Context-awareness • Examples: • A laptop plugged into the wall with its Wi-Fi connection still on • A handheld connected to one wireless network while its Bluetooth is interacting with other devices • Solution approaches: • Policy enforcement • Invariants like “only one of network stacks active at a time” • The real issue is to derive the “acceptable” base policy, and how to resolve conflicts (e.g., which one to turn off w/o explicitly involving the user) • Closely tied to context • Lightweight cognitive decision making?

34. Context Driven Security Adaptation Poke to app Control of devices Context-awareness connectivity Network availability Network 2 Network 1 PDA OS Signal 2 Signal strength Antenna, ports Signal 1 • Examples: • 802.11 to Bluetooth: how should the application level security change? • Application was relying on LOS, user mobility enables Wi-Fi– now broadcasting in the clear • Solution approaches: • In addition to “invariants”, need “preferences” at lower level (e.g., prefer Wi-Fi over Bluetooth) • Preferences can change based on context • Most importantly, changing network stack should not disrupt the application, yet cannot be totally transparent • Middleware will absorb the transition – letting applications communicate transparently, and at the same time coordinate application behavior and other security mechanisms

35. Dealing with Spontaneity • Problem • Ad hoc and mobility require beaconing and response, but discloses location, network or device id, etc. • Solution approaches • Layered access: even if you are in you get minimal rights • Adaptive beaconing (time slot, duration…)

36. Current Work DARPA Oasis Dem/Val architecture (DPASA survivability architecture) • Survivable systems: architecture to combine protection, detection and adaptive response • Defense mechanisms at the macro (system) level as well as micro (within a host) level • Existing micro architectures • Agents like DPASA LC, CSISM ILC along with local security mechanisms (policy enforcement, firewalls etc) • Situation and context awareness in security • Mostly focusing on system state and intrusion CAIDA visualization of Code Red Worm DARPA SRS Host Level Autonomic Security Agent (CSISM ILC)

37. Agenda • Trends toward wireless, mobile networked systems • History • Characteristics of wireless, mobile networked systems • Challenges for wireless, mobile networked systems • Infrastructure for wireless, mobile networked systems • Adaptive middleware • Information management • Services-based • Research directions in context-aware quality of service • Research directions in context-aware security • Conclusions

38. Conclusions and Open Research Questions • QoS and Security are necessary capabilities in wireless ad hoc networks • Situation (context) awareness can be a powerful attribute of QoS and Security management, however hard problems remain • How to implicitly collect context information • Combination of context attributes • Using context without increasing communication and processing overhead • Proactive and/or autonomic computing is necessary in wireless ad hoc networks • Human attention will be limited and vary widely (according to situation) • Effective decision making – control systems or cognition? • Much of these capabilities should be provided in middleware • Provide reusable capabilities, avoiding needing to code anew in each application • Avoid new stovepipes • Infrastructure must be thin, efficient, configurable, and adaptive • Will they follow current trends, e.g., Java and SOA? • Must they (e.g., to be accepted by developers)? • Can they, i.e., are enterprise and tactical destined to always be different?