1 research directions in context-aware quality of service and security for wireless, mobile...

1

Research Directions in Context-Aware Quality of Service and Security

for Wireless, Mobile Networked Systems

Dr. Joseph LoyallBBN Technologies

March 2, 2009

Research Directions in Situational-aware Self-managed Proactive Computing in Wireless Ad hoc Networks

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

Historical Context: Software Infrastructure Enables Application Capabilities

Application

OperatingSystem

App

OperatingSystem

App

App

OS

App

OS

NetworkProtocols

App

OS

App

OS

NetworkProtocols

Middle-ware

Middle-ware

MWSvcs

MWSvcs

EmbeddedOS

EmbeddedOS

NetworkProtocols

LW Middle-ware

LW Middle-ware

MWSvcs

MWSvcs

Emb.App

Emb.App

Application

1950s 2009+Fifty Years of Distributed Systems Software Architecture Evolution

1950s 1960s 1970s 1980s 2000s

App

OS

App

OS

NetworkProtocols

DatabaseSystems

DatabaseSystems

1990s

System Development EnvironmentsProgramming

Languages

Information Management

Systems

Middle-ware

Middle-ware

4

Common Characteristics of Wireless Ad Hoc Networked Systems

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

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

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

FEMA

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

DetectAttacks

ProtectReact

Resources

Utility

“Working Range”

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




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

hardware

OS Middleware

apps

10

Trends in Adaptive Middleware for Tactical Networked Systems

Distributed objects– CORBA

– Quality Objects (QuO)

– CORBA event service and notification service

Com-pression

DataProcessing

NetworkManage-

ment

Ferguson and Stockton, Service-oriented architecture: Programming model and produce architecture, IBM Systems Journal, 2005.

Component middleware– CORBA component model– QoS components (Qoskets)– Model integrated computing

Service-based and Service-oriented systems– Information management services

– QoS and security services

Information management systems (pub-sub)– Joint Battlespace Infosphere (JBI)

– Data Distribution Service (DDS)

11

ROT LROT RRESET

LEFT RIGHTQUERYLINE SYM

OUT

IN

M

HOME

UP

DOWN

PREVPAGE

NEXTPAGE

Distributed Object Middleware Used in Avionics Dynamic Mission Planning

Full Image Tiled Image CompressedTiles

CollaborationClient Expected

Progress

Delegate

NetworkMonitorTAO ORB

ProgressContract

Measured

Progress

get_image()

get_tile(n, q)

adjust_rates()

Collaboration Task

NAVHUD

Soft Real-TimeTasks

Hard Real-TimeTasks

NAVNAVHUD

Soft Real-TimeTasks

Hard Real-TimeTasks

RT EventChannel

RTScheduler

RT EventChannel

RTSchedulertask

eventrates

RMS or MUF scheduling of tasks

VTF tile

ProcessorResourceManager

QuO Components

TAO components

RT-ARM components

QuO Components

TAO components

RT-ARM components

A Net-meeting likemission replanningcollaboration betweenC2 and fighter aircraft over Link-16

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

Flight Demonstration in Missouri (St. Louis to Hannibal)

December 2002

(BBN, Boeing, WuStL, Honeywell)

12

Adaptive Distributed Object Middleware for QoS Management in an Airborne Ad Hoc Network

Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) ATD Demonstrated at CECOM HQ, Ft. Monmouth, NJ, June 19-20, 2002UAV OEP Software was used to demonstrate QoS network performance for the MOSAIC airborne platformA helicopter-based “airborne node” used QuO adaptive distributed object middleware to dynamically modify DiffServ CodePoints. 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.”

MOSAIC Demonstration Area US Army CECOM

13

Adaptive component middleware manages dynamic, real-time QoS for ISR and C2 information in a multi-UAV time-sensitive targeting system

C2

• BBN’s Qosket adaptive QoS components

• CIAO CORBA Component Model distribution middleware

• PICML model integrated computing for component assembly

QoS middleware shapes application behavior and network traffic to fit allocated resources

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 controls access to resources based on QoS policy

Adaptive Component Middleware for End-to-End QoS Management in a Multi-UAV Flight Demonstration

CPUBrokerQosket

CPUBrokerQosket

DiffservQosketDiffservQosket

LocalResourceManager



qosket attributes

images

policy

missionmode

changes

ReceiverReceiverReceiverReceiverReceiverReceiverReceiverReceiverReceiverReceiver

SystemResourceManager

SystemResourceManager

IntegratedDisplay

C4ISIM

Blue Controller

UAVSensorUAV

SensorCroppingQosket

CroppingQosket

ScalingQosketScalingQosket

CompressionQosket

CompressionQosket

PacingQosketPacingQosket

QoS middleware dynamically adjusts resource allocation and QoS policy based on mission conditions

14

Evolution of the Concept of Information-Centricity

System-centric

Interface-centric

Information-centric

• Stovepiped systems with limited interoperability• Lacked means for standard interoperability

• 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

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

<metadata> <baseObject> <InfoObjectType> <Name>Image</Name> </InfoObjectType> <Publisher>Intel COI </Publisher> <Latitude>28.2.3 </Latitude> <Longitude>54.3.46 </Longitude> </baseObject></metadata>

Managed Information Object (MIO)

Archive

Consumers

Producers

MIO

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

Data store

Control

Com

mon

API

Acce

ss

Broker

Match

Subscriptionpredicate

Querypredicate

16

Information Brokering and QoS Services for Beyond LOS Tactical Information Exchange

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

Marti QoS manager

Marti QoS manager

Raven GS

FalconViewConsumer

COT imageproducer COT image

producer

COT router

Marti QoS manager

Shared and constrained radio links

Dynamic numbersof users

Changing missionmodes and roles

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

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

17

Federation Services for Combining Tactical and Enterprise Configurations

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.

CAPI Svc FE-IMSOthersvcs

Enterpriseclients

Data DiscoveryService

Service Bus PropagationService


FE-IMS

FE-IMS


Tacticalclients

Tacticalclients

Enterprise Network

Tactical Network

Tactical Network

Enterprise Federate

Tactical Federate

Tactical Federate

PropagationService

PropagationService

18

Agenda




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

21

Problem Space

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

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

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

22

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.

23

Context-Aware Predicate Matching Experiments

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

Baseline delivers results with no consideration of context

24

Optimal Ordering by Context Provided by Post-Processing

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

Most recent

Closest to the requestor

Most trusted

25

Automated Request Expansion Technique

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 The set of location-aware requests starts at the

requestor and makes 13 total requests, each one lat-lon minute farther from the requestor.

26

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

27

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)

Xpath request Execution time (seconds)

% over baseline

Baseline 24.98

Time, months 25.39 1.63%

Time, half-mos. 30.09 20.45%

Location 27.91 11.70%

Affiliation 25.33 1.38%

Xpath request Maximum memory used (MB)

% improvement

Post-processing 614.94

Time, months 184.48 70.00%

Time, half-mos. 122.99 80.00%

Location 114.99 81.30%

Affiliation 122.99 80.00%

28

Request Expansion Produces Meaningful Results Much More Quickly

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

The first 200 (most recent, closest, most trusted) are available within about 5 seconds

29

Technical Challenge: How to Combine Different Types of Context Information

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

Delivered in order of combined, normalized quality

Intersection of sets delivered in order of individual context attributes

30

Agenda




31

Security in Wireless Ad Hoc Environments

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

Security in MANETs are a challenging task….

32

Basic Protection of Data and Access

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)

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

33

Issues and Hard Problems in Context Aware Security

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)

hardware

OS Middleware

apps

34

Dealing with Misconfigurations

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?

hardware

OS

Context-awareness

Invariants about applications and environment Invariants

hardware and OS

Invariants about applications, hardware and OS

35

Context Driven Security Adaptation

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

Network 1Network availability

connectivity

Signal strength

Network 2

Signal 1Signal 2

Poke to app

Context-awareness

PDA OS

Antenna, ports

Control of devices

36

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

37

Current Work

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

Redundancy/Diversity

VPN Firewall Switches

JVM

ADF

CSA/SELinux

App.Application

Process

Host

Network

System

Redundancy/Diversity

VPN Firewall Switches

JVM

ADF

CSA/SELinux

App.Application

Process

Host

Network

System

Policy DB

Chk Pt DB

HW/OS Watchdog

AppController

AppFactory

ILC

App1

App2

Outer Loop ControlRemote App

policy layer

sensorsactuators

Control Data

instantiate

Policy DB

Chk Pt DB

HW/OS Watchdog

AppController

AppFactory

ILC

App1

App2App2

Outer Loop ControlRemote App

policy layer

sensorsactuators

Control Data

instantiate

DARPA Oasis Dem/Val architecture (DPASA survivability architecture)

DARPA SRS Host Level Autonomic Security Agent (CSISM ILC)

CAIDA visualization of Code Red Worm

38

Agenda




39

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?

1 research directions in context-aware quality of service and security for wireless, mobile...

Documents

networked systems connectivity

app application

app emb

security management

resources available

mobile ad

historical context

context situation