Context-Aware Quality of Service and Security for Wireless, Mobile Networked Systems

solidseniorServers

Dec 9, 2013 (3 years and 10 months ago)

95 views

1



Research Directions in


Context
-
Aware Quality of Service and Security

for Wireless, Mobile Networked Systems


Dr. Joseph Loyall

BBN 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

Operating

System

App

Operating

System

App

App

OS

App

OS

Network

Protocols

App

OS

App

OS

Network

Protocols

Middle
-

ware

Middle
-

ware

MW

Svcs

MW

Svcs

Embedded

OS

Embedded

OS

Network

Protocols

LW Middle
-

ware

LW Middle
-

ware

MW

Svcs

MW

Svcs

Emb.

App

Emb.

App

Application

1950s

2009+

Fifty Years of Distributed Systems Software Architecture Evolution

1950s

1960s

1970s

1980s

2000s

App

OS

App

OS

Network

Protocols

Database

Systems

Database

Systems

1990s

System
Development
Environments

Programming

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

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

Detect
Attacks
Protect
React
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


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

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
Data
Processing
Network
Manage
-
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 L

ROT R

RESET

LEFT

RIGHT

QUERY

LINE

SYM

OUT

IN

M

HOME

UP

DOWN

PREV

PAGE

NEXT

PAGE

Distributed Object Middleware Used in Avionics
Dynamic Mission Planning


Full Image

Tiled Image

Compressed

Tiles

Collaboration
Client
Expected
Progress
Delegate
Network
Monitor
TAO ORB
Progress
Contract
Measure
d
Progress
get_image()
get_tile(n, q)
adjust_rates()
Collaboration Task
NAV
HUD
Soft Real
-
Time
Tasks
Hard Real
-
Time
Tasks
NAV
NAV
HUD
Soft Real
-
Time
Tasks
Hard Real
-
Time
Tasks
RT Event
Channel
RT
Scheduler
RT Event
Channel
RT
Scheduler
task
event
rates
RMS or MUF scheduling of tasks
VTF tile
Processor
Resource
Manager
QuO Components
TAO components
RT
-
ARM components
QuO Components
TAO components
RT
-
ARM components
A Net
-
meeting like

mission replanning

collaboration between

C2 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, 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
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

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

Common

API

Access

Broker

Match

Subscription

predicate

Query

predicate

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

FalconView

Consumer

COT image

producer

COT image

producer

COT router

Marti
QoS

manager

Shared and constrained

radio links

Dynamic numbers

of users

Changing mission

modes 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

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

Other

svcs

Enterprise

clients

Data Discovery

Service

Service Bus

Propagation

Service

Data Discovery

Service

FE
-
IMS

FE
-
IMS

Data Discovery

Service

Tactical

clients

Tactical

clients

Enterprise Network

Tactical Network

Tactical Network

Enterprise Federate

Tactical Federate

Tactical Federate

Propagation

Service

Propagation

Service

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

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

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


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

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 1

Network
availability

connectivity

Signal strength

Network 2

Signal 1

Signal 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
App
Controller
App
Factory
ILC
App1
App2
Outer Loop
Control
Remote App
policy layer
sensors
actuators
Control
Data
instantiate
Policy DB
Chk
Pt DB
HW/OS
Watchdog
App
Controller
App
Factory
ILC
App1
App2
App2
Outer Loop
Control
Remote App
policy layer
sensors
actuators
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


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

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?