Robust Net-Centric Services

Information Sharing to the Edge

Layer 7 Technologies

White Paper
Robust Net-Centric Services

Contents

Executive Summary....................................................................................................................................... 3
Overview ....................................................................................................................................................... 3
Net-Centric Services at the Tactical Edge ..................................................................................................... 3
Challenges at the Edge .............................................................................................................................. 4
Availability and Robustness of the Network ......................................................................................... 4

Availability of Resources ....................................................................................................................... 5

Information Assurance (IA) ................................................................................................................... 5

Robust Net-Centric Services ..................................................................................................................... 6

The Policy Layer .................................................................................................................................... 6

Web Services Policy Framework ........................................................................................................... 8

Conclusions ................................................................................................................................................... 9
About Layer 7 Technologies ........................................................................................................................ 10
Contact Layer 7 Technologies ................................................................................................................. 10
Legal Information .................................................................................................................................... 10

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 2

 Robust Net-Centric Services

Executive Summary
The “net-centric vision” is based on a consistent architecture that enables information sharing and component re-
use across an organization. In pursuit of this vision, The Department of Defense (DoD) has adopted a Service
Oriented Architecture (SOA) model, which encompasses Extensible Markup Language (XML) and Web services
standards and technologies.
SOAP and REST-based Web Services adequately address how applications get exposed and communicate with each
other in order to exchange information in a platform agnostic way. In real-world applications however, security,
reliability, routing, bandwidth conservation, versioning and other requirements still have to be dealt with. At the
tactical edge, Web services are even more susceptible to these factors, having to operate in an environment where
(for example) bandwidth and connection state are constantly changing. Only Web services that have situational
awareness will be able to adapt to constantly changing conditions.
For example, an edge-based Web service consumer or provider that is initially
Only Web services
connected to DISA’s Net-Centric Enterprise Services (NCES) can become disconnected
that have situational due to a kinetic or cyber attack. With situational awareness, information exchange can
awareness will be continue to flow by redirecting traffic to locally deployed core enterprise services
able to adapt to (machine to machine messaging), and/or potentially a cached business service – all
constantly changing without impacting the tactical user.
conditions This whitepaper proposes the concept of “Robust Net-Centric Services,” which is
defined as Web services that have a high degree of continuity despite multiple internal
application changes and/or external environmental disruptions.
Given the distributed and federated nature of net-centric services, the ability to define robust contingencies in
policy – policies that can be implemented in a distributed fashion; interoperate across implementations; and yet
still remain easy to change – is key to achieving information superiority.

Overview
The IEEE publication entitled “Characterization Framework and Design Patterns for the Disadvantaged User,”
recognized Fixed Center, Mobile Center, Mobile Swarm, and Dismounted as being the most typical tactical
environments. The publication went on to establish a number of dimensions and attributes for each tactical
environment, including:
• The availability and robustness of a network
• The availability of resources to execute a particular function
• Information Assurance (IA)
This paper examines current deficiencies in net-centric enablement at the tactical edge related to the above
dimensions, and proposes that more “robust” services are required for successful net-centric enablement.
A robust net-centric service is capable of assessing its own particular situation, and taking intelligent action based
on its own situational awareness without impacting the consumer or provider of the application themselves.
Action can be taken based on network conditions, availability of resources, security related factors, and even on
the current situation of the user.
The following sections define net-centric services at the tactical edge; draw attention to the inherent challenges;
and propose a policy-oriented approach to decoupling tactical awareness from applications.

Net-Centric Services at the Tactical Edge

Standards and technologies (i.e. XML, SOAP, REST, AJAX, WSDL and UDDI) provide developers and architects with
the tools to implement and deploy net-centric services, which often incorporate other existing services (both
business and infrastructure) to accomplish their particular goals.

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 3

 Robust Net-Centric Services

In order to support the principles of flexibility and loose coupling of system components, net-centric enablement
utilizes basic software engineering principles: flexible systems are achieved by decoupling the variable parts of the
implementation from the invariant parts. The variable layer can then be managed without affecting the system
invariants. This is evident in the government’s adoption of SOA, and their use of supporting technologies, such as
Enterprise Service Buses, Business Activity Monitoring, Complex Event Processing, Policy Enforcement and Decision
Solutions, XML Firewalls, Business Process Management, as well as others.
For net-centric services, the invariant part of an implementation is the business functionality, such as a Global
Combat Support System (GCSS) logistics system query, or a Blue Force Tracking: Situational Awareness (BFTSA)
track request, or a Human Resources personnel request. Everything else, including credential mechanisms, access
control, whether encryption or signatures are used, caching, data format transformations, versioning, routing, etc,
is the variable part of the implementation, and resides in a layer that is declarative, configurable and centrally
managed.
On the Global Information Grid (GIG), service infrastructure is available from DISA NCES, providing an opportunity
for cost savings and reduced time to market through use of services like Machine-to-Machine messaging,
Orchestration, Collaboration, Mediation, Discovery, Enterprise Service Management, etc. In addition, each of the
service branches (Army, Navy, Air Force, and Marine Corp) provide their own core enterprise services to be utilized
in building composite net-centric systems. All of these initiatives are founded on the premise that programs of
record should care first and foremost about the business capability they are looking to provide and not on the
infrastructure necessary to support the requirements of net-centricity, thereby reducing total cost of ownership
for the program.
At the tactical edge, robustness can be achieved by adopting standards to maintain interoperability; creating core
services for use and reuse; and by leveraging commercial off the shelf technologies in order to reduce the overall
cost of the project. In this way, tactical system deployment can be accelerated, while ensuring changes can be
made to the system as required.

Challenges at the Edge

Within the enterprise, it’s possible to create failover strategies, acquire more hardware/software, create custom
code, or even implement human-driven processes to address new challenges. Infrastructure components like DNS,
enterprise services and even the physical network itself can be relied upon and as such, applications can leverage
these resources in order to meet Service Level Agreement (SLA) and Quality of Service (QoS) requirements. At the
tactical edge, however, fewer resources are available; custom development is not possible in a timely fashion;
networks are not stable; and enterprise infrastructure services are not always available.

Availability and Robustness of the Network

The network is the leading factor limiting net-centric operations at the edge. Part of the problem is due to the fact
that the foundational element of net-centricity is XML, which is the de-facto way to disseminate and store data in a
SOA. While it’s true that radios and tactically deployed communication infrastructure are
The network is the improving, and that compression algorithms and binary XML efficiency are allowing
leading factor payloads to become smaller on the wire, XML message size still creates bandwidth issues
limiting net-centric for communications between mobile swarm and dismounted users.
operations at the For enterprise to swarm, swarm-to-swarm, or other tactical communications, network
tactical edge availability and robustness remain challenging, and often result in applications being built
with the worst-case scenario in mind. This equates to a static SLA driven by the worst
network conditions the application may face short of being disconnected. As a result, developers, architects, and
program managers typically end up using this minimum SLA to determine how much functionality their service will
provide. Although this is the safest bet for the service owner (as the service will work extremely well if conditions
are better than the minimum), the service will not be able to take advantage of more bandwidth when it is
available.
For example, consider identical services (providing the same data) deployed at two different Mobile Command
Centers (MCC) designated MCC1 and MCC2. MCC1 is experiencing heat-related issues with its server, and thus is

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 4

 Robust Net-Centric Services

only able to accept 10 requests/second, while MCC2 is effectively processing 200 requests/second. Under
degraded network conditions, you would most likely use the MCC closest to your current position (MCC1).
However, in cases where network conditions are optimal you may determine that your application should
communicate with MCC2, which, while further away, is providing a more appropriate response time.
This type of situational awareness and control is the primary motivation in proposing robust net-centric services. A
robust net-centric service is aware of its particular network’s health, as well as the health of all interrelated
networks, allowing it to determine which service it should use.
Consider another example in which MCC2 processes a request from a caller that requires information from a
tracking service available at the enterprise. In an ideal world, an enterprise-based tracking service should always
be available to MCC2, but if the network becomes disconnected or the tracking service is inoperable, a robust net-
centric service would be capable of determining an alternate route to a backup tracking service (perhaps one
deployed locally, or one that serves cached responses previously stored from the actual enterprise service).

Availability of Resources
The availability of resources is a critical component of any net-centric edge system. According to best practices,
reliance on external resources is to be avoided during tactical system design because consistent response times
are desired, whereas external resource availability cannot be guaranteed. Although this is a valid risk mitigation
approach, it results in increased cost because net-centric infrastructure services must
Robust net-centric be redeployed at the tactical edge rather than leveraging the existing investment at
services can leverage the enterprise.
enterprise services
What’s required is a hybrid approach whereby robust net-centric services leverage
when they are enterprise services when they are available, and take advantage of a fallback position
available, and take when they are not. This is especially true for programs of record, which are
advantage of a increasingly adopting the use of DISA NCES as a necessary component of their
fallback position architecture. Today, DISA NCES primarily leverages verbose XML standards such as
SOAP, WS-Security, etc., and is only available at the GIG enterprise, making NCES
when they are not
incompatible with the majority of edge-based applications.
As an example, consider the ability to publish or subscribe to the DISA NCES SOA Foundation (SOAF) Machine to
Machine Messaging Service. Here, the onus is on the application developer to manage all aspects of publishing
messages to the messaging service. Within the enterprise, where network conditions are consistent, publishing is
not an issue. But in a tactical environment, the developer must account for various network situations and
challenges associated with their disadvantaged state. A robust net-centric service would remove network
connectivity and bandwidth related concerns, allowing developers to focus on their business requirements.

Information Assurance (IA)

At the tactical edge, security is a critical requirement; one that severely limits the ability to create a loosely
coupled system. A robust net-centric system would have appropriate security controls, while still maintaining the
ability to adjust to changing network, resource, IA, and user challenges. This is not the
Today, security is case today, where a “one size fits all” approach to security is the norm. Despite the
hard coded into fact that it is difficult to imagine all IA conditions that a tactical net-centric system may
be faced with once deployed, security is hard-coded into applications, and cannot
applications in a “one easily be changed.
size fits all” approach
Because effective security is dependent upon resources like Robust Certificate
despite the fact that
Validation (RCV), Attribute Services, Policy Decision Services, etc., and edge-based
IA conditions can applications cannot depend on these resources being available, effective security
change once a system cannot be maintained. A robust net-centric system is one which provides for real-time
has been deployed changes to be made to the security requirements of the system. For example, a robust
service might adjust to a network latency issue by falling back to using only transport
encryption instead of its previous security configuration which required both transport encryption and message
level encryption.

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 5

 Robust Net-Centric Services

Tactical systems should be built to leverage existing enterprise security infrastructure, such as DoD RCVS, Attribute
Services like JEDS, and Policy Decision Services whenever possible. When these enterprise security services are not
available at the tactical edge, robust net-centric systems would have the ability to determine at run-time what
their fall-back condition should be: either to not use the service, or else to use locally deployed resources without
impacting the service providers and consumers.

Robust Net-Centric Services

In a tactical environment, multiple, conflicting constraints and capabilities need to be reconciled, managed and
constantly monitored. For example, performance and response time requirements need to be weighed against
security, confidentiality and privacy requirements. For this reason, robust net-centric services must adhere to the
fundamental principles of software engineering: flexible systems are achieved by decoupling the variable parts of
the implementation from the invariant parts. The variable layer can then be managed
Robust net-centric without affecting the system invariants.
services employ a
Robust net-centric services employ a policy-driven, intelligent infrastructure that
policy-driven
allows applications to be deployed without knowledge of the requirements they
approach that allows might face. The infrastructure provides a light-weight, federated on-ramp to the GIG’s
them to be deployed enterprise services, while policy facilitates connectivity and integration.
without knowledge of For example, once a troop tracking service is implemented by developers, the policy
the requirements they framework should allow it to be deployed on a variety of servers; under different
might face transports/messaging capabilities; with different access control and credentialing
mechanism; and varying levels of security and availability – all without impacting the
business application itself. And because the configurability around how consumers and services interact is now
controlled by the runtime policy framework, Certification and Accreditation (C&A) is simplified.
Finally, consider messaging, which is one of the key resources net-centric system builders employ, and is therefore
also a key issue for tactical deployments where messaging services may not always be available. The policy
framework of a robust net-centric service provides for situational awareness of the availability of messaging
services. Thus, when one messaging service is unavailable, applications can, in a policy-driven fashion, find the best
method to forward on messages using alternate messaging systems.

The Policy Layer

The policy layer describes how, when and where Web services are to be shared, applied, and enforced. This layer
architecturally is made up of two fundamental concepts: a Policy Enforcement Point (PEP) and a Policy Application
Point (PAP).

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 6

 Robust Net-Centric Services

Figure 1: Policy Enforcement Point

The PEP has been a well known and accepted concept in the IT community well before the advent of SOA,
providing a centralized point of control (i.e., traditional firewalls). When applied to SOA, PEPs allow organizations
to decouple the runtime policy framework from the business application logic, and manage it more easily.
Operators can create and modify policies on the PEP to provide access control; enforce privacy and confidentiality;
perform audit logging, and so on independent of the services themselves. This is the first step towards real-world
implementation of loosely coupled SOA.

A client-side PAP
intercepts requests and
applies policy to
ensure requests
conform to service
provider requirements
applies policy to them. These requests are then intercepted by the PEP, which enforces existing, appropriate
policy.
But the same real-world policy issues that apply to providers also apply to
consumers. In other words, consumers still have to deal with providing credentials,
confidentiality, privacy and other non-business logic-related information, which
should be implemented as part of the same loosely coupled policy framework.
Otherwise, policy conformance and security negotiation will have to be written into
the client-side code base, which will have to be updated when policy changes. A
client-side equivalent to the PEP, commonly called a PAP or Policy Application
Point, can eliminate these drawbacks. A PAP intercepts outgoing requests and

Figure 2: Policy Application Point

To better understand the role of a PAP, think of a Virtual Private Network (VPN)
PEPs intercept security solution. When a VPN is deployed server-side, a VPN client is always
requests and apply deployed on the client-side machine in order to ensure applications like email clients
policy against them to and Web browsers don’t have to implement security and policy in their code base. In
this way, VPN clients provide security for any and all applications, no matter whether
ensure they conform
they’re located inside or outside the organization’s LAN and firewall.
to predefined
requirements In much the same way, PEPs and PAPs allow applications to share information
independent of location and project-specific requirements.

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 7

Robust Net-Centric Services

Figure 3: Policy Enforcement and Application across the War Fighting Domain

Web Services Policy Framework

The Web Services Policy (WS-Policy) Framework allows service providers to express the capabilities, requirements,
and characteristics of their Web Services in a machine executable policy vocabulary. WS-Policy contains a number
of WS* standard assertions, but custom assertions can be added to address unique requirements.
WS-Policy generally includes the following expressions:
• All: Must adhere to all of the required operations
• Exactly One: Must adhere to one and only one of the required operations

This level of flexibility allows granular policies to be written that specify how service consumers must interact with
service providers based on unique situational factors. Logic operations can be used to place requirements on
service consumers to provide their organizational attributes, roles, and/or situational status.
An example “Security/QoS/SLA” policy could be written as follows:
• Do Threat Protection (Virus Detection, Denial of Service, Code Injection)
• Authenticate Entity Based on WS-Security (X.509 and Attribute Retrieval)

o [Exactly One ]

[All]
 Attribute: Location=IRAQ
 Require Transport Encryption: SSL/TLS
 Require Digital Signature: Message (Entire)
 Require XML Encryption: Message (Portion)

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 8

Robust Net-Centric Services

 Require Message Sanitization (Sensitive Portion Removed)

 Enforce Service Level Agreement (10 Requests/Hour/Requester)

[All]
 Attribute: Location=CONUS
 Require SSL/TLS
 Require Schema Validation: Entire Message

[All]
 Attribute: Location=ANY OTHER
 Issue Audit Record and Notify Operations of Unexpected Location

Another example where “situation based routing” is performed based on bandwidth could be written as follows:
o [Exactly One ]

[All]
 Bandwidth: [Average roundtrip time for last 10 transactions] >=1MB/Sec
 Use HTTP (No Compression)

[All]

 Bandwidth: [Average roundtrip time for last 10 transactions] >256KB/Sec and <1MB/Sec
 Use Efficient XML (EFX) Compression

[All]
 Bandwidth: [Average roundtrip time for last 10 transactions] <=256KB/Sec
 Require Message Transformation (Attachment Removed)
 Use Efficient XML (EFX) Compression

These are simple examples of the types of policies that can be created using WS-Policy. However, they serve to
show how requirements can be bound into a single policy that can subsequently be shared in a machine
consumable fashion.

Conclusions
Given a policy framework and SOA infrastructure services, robust net-centric systems can be deployed out to the
tactical edge. The PEP/PAP model outlined in this paper allows requirements to be enforced and applied in a highly
configurable, centrally managed, and dynamically updatable fashion, while still meeting the goals of just-in-time
integration, flexible system design (via loose-coupling), and reuse of software components across diverse business
processes.
The suite of policy enforcement and application point products available from Layer 7 Technologies is a direct
response to the set of problems acknowledged in this document. Layer 7 also provides guidance to organizations
through onsite professional services engagements and best practices discussions around building a robust policy
layer between service consumers and service providers.

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 9

Robust Net-Centric Services

About Layer 7 Technologies

With more than 150 customers across 6 continents, and successful partnerships with some of the largest ISVs and
resellers in the industry, Layer 7 Technologies is the leader in SOA and cloud security and governance. Our award-
winning SecureSpan™ family of XML Gateways feature sophisticated runtime governance, enterprise-scale
management and industry-leading XML security. Our CloudSpan™ family enables enterprises and service providers
to securely consume cloud services, as well as protect and control their own applications deployed in public and
private clouds. Founded in 2002, Layer 7 has a history of helping organizations address their security, visibility and
governance issues by enabling them to control, manage and adapt their Web services, no matter the deployment
model – in the enterprise or in the cloud.

Contact Layer 7 Technologies

Layer 7 Technologies welcomes your questions, comments, and general feedback.

Email:
info@layer7tech.com

Web Site:
www.layer7tech.com

Phone:
(+1) 604-681-9377
1-800-681-9377 (toll free within North America)

Fax:
604-681-9387

Address:
Layer 7 Technologies
1200 G Street, NW, Suite 800
Washington, DC 20005

Layer 7 Technologies
Suite 405-1100 Melville Street
Vancouver, BC
V6E 4A6 Canada

Legal Information
Copyright © 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
trademarks are the property of their respective owners.

© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com) 10