White Oak White Paper JBOSS-IPv6 CND in Depth

White Oak Consulting LLCWhite Paper

Integrating JBOSS and IPv6 with a Defense in Depth Strategy

Prepared by:White Oak Consulting LLC

13 July 2011

This white paper is a published work containing proprietary information of White Oak Consulting LLC regarding the integration strategies employing open source and open standard technologies. The aggregation of the information contained in total is considered proprietary and confidential in nature due to the format, sequence, selection and quantity of content. No part of this document may be reproduced in any form, including photocopying or transmission electronically, mechanically or otherwise, without prior written consent of White Oak Consulting LLC. White Oak Consulting LLC has made every attempt to ensure the accuracy of the content of this document; however, the content is provided as is, without express or implied warranties of any kind. To the extent permitted by law, no liability (including liability to any person by reason of negligence) will be accepted by White Oak Consulting LLC, its subsidiaries or employees for any direct or indirect loss or damage caused by omissions from or inaccuracies in this document.

© 2011 White Oak Consulting LLC All rights reserved.

Trademarks used in this document as are noted in the footnotes, with the exception of trademarks associated with White Oak Consulting LLC; Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. JBOSS is a registered trademark of Red Hat, Inc. in the U.S. and other countries. White Oak Consulting LLC disclaims any proprietary interest in trademarks and trade

names other than its own. All references to technologies originating from the Internet Engineering Task Force

(IETF) are copyrighted to the Internet Society, and are protected under BCP78.


13 July 2011


Authors

Ralph Wallace

Version History

Version Publication Date Author(s) Reviewers Description of Change

WO-WP-V0001-0 13 July 2011 Ralph Wallace Baseline Release

Legend:Title – WO (White Oak Consulting LLC ) White Paper (WP)Draft (D) – Smooth Draft (SD) – Final (F) – Released (V)Major Revision – 0001; Minor Revision – 0

Page 2 of 16

White Oak Consulting LLC Proprietary


13 July 2011


TABLE OF CONTENTS

1. ABSTRACT..............................................................................................................................................4

2. BACKGROUND.......................................................................................................................................4

3. THE APPROACH.....................................................................................................................................6Computer Network Defense in Depth..................................................................................................6JBOSS..................................................................................................................................................8Internet Protocol version 6 (IPv6)........................................................................................................9The System Approach........................................................................................................................10

4. SECURITY, INTEROPERABILITY AND SCALABILITY IN AN INTEGRATED SOA ENTERPRISE..............................................................................................................................................11

Security...............................................................................................................................................11Interoperability and Scalability..........................................................................................................13JBOSS/IPv6 Integration Initiatives in Open Source..........................................................................14

5. CONCLUSION.......................................................................................................................................14

FIGURES

Figure 1: DoD DMZ Extension (Phase 3 planned for 2012)...........................................................5

Figure 2: Carnegie Mellon University IBM Websphere Depiction.................................................6

Figure 3: Notional Defense in Depth...............................................................................................7

Figure 4: CANES Afloat Core Services..........................................................................................8

Figure 5: XML to Non-XML Frameworks......................................................................................9

Figure 6: TCP/IP - OSI Layer Extant Interoperability Opportunities...........................................11

Figure 7: IPv6 Extension Headers.................................................................................................13

Figure 8: Integrated and Secure SOA Enterprise..........................................................................15

Page 3 of 16



13 July 2011


1. ABSTRACT

This paper provides the conceptual approach for systems and security engineering to integrate a Service-Oriented Architecture (SOA) middleware platform operating at OSI layer 7 and an Internet Protocol (IP) operating at OSI layer 3. The objective of the integration is to create an optimized and securely interoperable topology across the OSI model that supports each technology’s inherent functionality in an ontological and synergistic manner. This paper will focus on the JBOSS SOA platform due to the open source development environment, and IP version 6 (IPv6) due to the extant industry employment of the open standard protocol which will sustain the evolution of the Internet beyond 2012 and into the next century. This paper will additionally focus on the systems approach to security engineering due to the paucity of industry effort towards merging the respective software and network engineering paradigms.

2. BACKGROUND

The acceptance of SOA across the private and public sectors is tangible. The most prevalent middleware applications suites are Oracle SOA solutions (formerly BEA Aqualogic), IBM Websphere - both Commercial Off The Shelf (COTS) platforms - and JBOSS (a Professional Open Source (POS) platform)1. The adoption of these product suites to insert the proposed architectural paradigm into an organization's Information Technology (IT) infrastructure is laudable due to the ease of acquisition, modification, installation and operation of the middleware. Observing the evolution of SOA middleware applications over the past 10 years, three significant design “boundaries” emerged as a result of the evolution of the original technologies. One boundary is the employment of an application to achieve “point-to-point” and “one-to-many” connections within an enterprise, partially in order to produce an application layer solution mitigating network inadequacies of Internet Protocol version 4 (IPv4). The second boundary is the design of applications that do not interoperate with the network layer. The third boundary is that the security engineering completed to date is relegated to OSI layer 7, independent of layer 3. However, Moore’s Law applies. Technology has evolved. We now have an opportunity to review the above design boundaries for their validity and to examine viable, mature technologies to significantly enhance an organization’s SOA implementation in the areas of security, interoperability, and scalability.

SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.2 As defined, SOA is an architectural concept. The previously identified software application suites are the de facto accepted implementations of this concept. Unfortunately, these applications are inherently “Network Unaware”. This means that the interoperability required to implement a true SOA across an enterprise between OSI layers 7 and 3 is ill defined and lacks sufficient maturity (e.g. no interface between Quality of Service

1 Oracle, BEA, Aqualogic, IBM, Websphere and JBOSS are registered trademarks of their respective companies.2 E. Marks and M. Bell, Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology (John Wiley and Sons, 2006) 1.

Page 4 of 16



13 July 2011


(QoS) configurations at layer 7and layer 3 and Virtual Private Networks (VPNs) created at the network layer without regard for the bandwidth limitations incurred by the encryption algorithms impacting the ESB’s coordinated service delivery at the application layer). The “loose coupling” prioritization of services communicating across the enterprise are only defined at the application layer and, due to current Internet Protocol technology constraints, are at the mercy of network bandwidth managers who establish the QoS for the IP packets containing the ESB data. The current network protocol technology of IP version 4 (IPv4) impedes the integration due to the pervasive implementation of Network Address Translation (NAT), and the limits of its 32-bit addressing schema. Additionally, IPv4 cannot support “one-to-many” peering relationships required for the loose coupling within an SOA application.

Due to the evolution of the technology base, Information security engineering professionals have created their sub-fields of endeavor due to the focus on the respective OSI layers. So, professionals have been identifying solution sets that defend against threats at the application and the network layer attack surfaces independent from each other. Few, if any, engineers address both attack surfaces and determine interdependent defense architecture. In short, Information Security engineers have not yet defined defense in depth architectures employing appropriate stratification and complementary interoperability schemas corresponding with the respective OSI layers. An Intrusion Detection System (IDS) coupled with an Intrusion Prevention System (IPS) working within a tiered De-Militarized Zone (DMZ) with the appropriate firewalls and Access Control Lists (ACLs) adopts strong security at OSI layer 3 (Figure 1 applies), while at OSI layer 7, SOA middleware access control is delegated to a security-infrastructure application for distributed authentication, fine-grained entitlements and other security services. Socket security has been the de facto security mechanism at the application layer for web services.

RestrictedData

Web Server

Physically Separate

Hosts

PhysicalNetwork

Separation

Firewall

Fire

wal

l

Unrestricted Database

RestrictedDatabase

To DISA DMZ

Front End

RestrictedLAN Switch

UnrestrictedLAN Switch

Physically Separate

Hosts

PhysicalNetwork

Separation

LAN Switch

LAN Switch

UnrestrictedData

Web Server

UnrestrictedWAF

UnrestrictedRWP

UnrestrictedApplication

Server

Physically Separate

Hosts

LogicalNetwork

Separation

LogicalNetwork

Separation

RestrictedApplication

Server

Physically Separate

Hosts

UnrestrictedDatabase

Security Gateway

RestrictedDatabase

Security Gateway

RestrictedRWP

RestrictedWAF

Unrestricted Web Content Filter

Restricted Web Content Filter

PhysicalNetwork

Separation

Unrestricted Web Tier Unrestricted Application/Database Tier

PhysicalNetwork

Separation

Restricted Application/Database TierRestricted Web Tier

Figure 1: DoD DMZ Extension (Phase 3 planned for 2012) 3

A “representative” network architecture employing an IBM SOA implementation provided to Carnegie Mellon University is depicted in Figure 2 in order to illustrate the intricacies of

3 RDML Simpson, N6 Enterprise Initiatives; OPNAV/CARS Updates on Initiatives, 9 June 2009Page 5 of 16



13 July 2011


employing existing network protocol IPv4 with the IBM SOA COTS middleware4. Note the difference in views between figure 1 and 2. The DMZ in figure 1 is detailed and not associated with an SOA deployment, whereas figure 2’s focus is a SOA deployment, and not a DMZ.

Internet

ExternalUser Access External

Proxy

Business Partners

(Universities, Fed. Govt. etc.)

Services Gateway

InternalUser Access

(Choreography)Applications

(SIS, Blackboard, etc.)

Enterprise Information System

(Oracle Financial, HR etc.)

Security Policy

S

ProtocolFirewall

Domain Firewall

Management &Security

SecurityServices

ServiceRegistry

Information Services

Data Warehouse/Business Intelligence

Databases

Firewall

InternalProxy

Web ApplicationServer

ESB

PortalProcessServices

Service Consumer

Service Provider

Service Consumer

Service Provider

Service Consumer

Service Provider

Service Provider Service Provider

Figure 2: Carnegie Mellon University IBM Websphere Depiction

3. THE APPROACH

Computer Network Defense in Depth

Technology advances have provided a shift in the evolution and maturity of two of the SOA components enabling system architects to conduct security engineering per ISO 27001. For DoD applications, this affords the adoption of a Computer Network Defense in Depth architecture per the National Security Agency’s (NSA) Information Assurance Technical Framework (IATF)5. The IATF defines the four strata of depth as:

1. Defend the Network and Infrastructure, including a. Availability of backbone networks,b. Wireless networks security framework,c. System high interconnections and

4 Carnegie Mellon University, Masters of Science in Information Systems course 95-843 Service Oriented Architecture, (CMU, 11 October 2006)5 National Security Agency Information Assurance Directorate Technical Directors, Information Assurance Technical Framework (IATF) version 3.1, (NSA, September 2002)

Page 6 of 16



13 July 2011


d. Virtual private networks (VPN); 2. Defend the Enclave Boundary, including

a. Protection for network access, b. Remote access, and c. Multilevel security;

3. Defend the Computing Environment, includinga. End-user environment, and b. Security for system applications,

4. Supporting Infrastructures, including a. Key Management Infrastructure/Public Key Infrastructure (KMI/PKI), andb. Detect and respond

Figure 3 provides a notional view of the respective functions that would be part of the defense in depth architecture supported by these two SOA components.

Figure 3: Notional Defense in Depth

With this architectural objective in mind for future DoD enterprise designs, the embedded system requirements specifications and subsequent design will afford each system the ability to be produced through the corresponding system development life cycle. This helps ensure that each

Page 7 of 16



13 July 2011


instantiation will meet the DoD Information Assurance Certification and Accreditation Process (DIACAP) criteria for Authority To Operate (ATO) at delivery (instead of conducting the process after delivery as a “bolt-on” security effort, with corresponding risks to operational effectiveness due to inadequate planning and engineering).

DIACAP criteria stipulate the specific knowledge of “boundary controls” which in systems engineering vernacular is normally associated with system interfaces. Past security engineering efforts focused only on the respective OSI layers, and their respective security apparatus to protect the elements within that OSI construct. An articulated defense in depth architecture establishes interdependence across the layers with well defined security controls at each boundary point while enhancing interoperability and scalability. The two platforms enabling this security engineering are the JBOSS POS platform and the next generation Internet Protocol, IPv6.

JBOSS

JBOSS has emerged as a platform of choice for DoD SOA applications, including the adoption of the platform within the US Navy’s approach to the Consolidated Afloat Networks and Enterprise Services (CANES). Figure 4 depicts the notional architecture for the future view of adoption within this program of record.

Figure 4: CANES Afloat Core Services6

The US Navy has invested in establishing a technology base within which JBOSS has emerged, removing the proprietary licensing constraints inherent to the other COTS platforms from Oracle and IBM. As an open source application, innovation is supported and J2EE programmers are encouraged to explore creative alternatives within their design environments. The security framework is well known and, at the application layer, well represented by Web Services Security (WS-Security). WS-Security is arguably the most important WS-* specification and is used with virtually all of the other WS-* specifications. WS-Security specifies Simple Object Access

6 J. Livingstone, Consolidated Afloat Networks and Enterprise Services (CANES) Program and Acquisition Overview (SPAWAR-LANT; 23 April 2009)

Page 8 of 16



13 July 2011


Protocol (SOAP) security extensions that provide confidentiality using XML Encryption and data integrity using XML Signatures. WS-Security also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes:

• Username with Password (defines how a web service consumer can supply a username as a credential for authentication).• X.509 Certificate (a signed data structure designed to send a public key to a receiving party).• Kerberos ticket (a binary authentication and session token).• Security Assertion Markup Language (SAML) assertion• (Rights Expression Language (REL) document (license tokens inserted in WS-Security headers are used for authorization).

The most prevalent security tokens used with WS-Security are Username, X.509 Certificates, SAML assertions, and Kerberos tickets. Figure 5 provides the respective relationships between the XML and Internet Protocol frameworks.

Figure 5: XML to Non-XML Frameworks

Internet Protocol version 6 (IPv6)

IPv67, as the next generation Internet Protocol, is a required element in all future enterprises, and is mandated in the system requirements specification for CANES (as well as the Navy Next Generation Network, NGEN). This white paper is neither intended to act as a tutorial nor a banner attempting to “sell” IPv6 virtues. Rather, the objective of this paper is to effectively present to the reader an implementation of this technology in a fashion which offers a number of solutions to the complex functionality required of future enterprises. Since this technology is a requirement

7 IPv6, and all associated complements generated within the Internet Engineering Task Force (IETF) and documented with Request For Comments (RFCs) are protected under copyright by The Internet Society.

Page 9 of 16



13 July 2011


for the CANES system, as is the JBOSS platform, a merger of the technologies in an engineered fashion with a security defense in depth architecture objective constitutes a logical approach. Unfortunately, most federal civilian and DoD agencies are just beginning to conduct engineering surveys to prove the efficacy of IPv6 within their respective enterprises. Of note, a November 2008 NSA factsheet on IPv6 unequivocally states “In short, IPv6 is not a 'stop gap' protocol whose only function is to fix the IPv4 address space problem.”

IPv6 has been designed to correct both the security and scaling inadequacies of IPv4. With features such as stateless address autoconfiguration and mandatory support for IPSec, IPv6 deals with several of the problems currently encountered by network administrators and security professionals. The following are applicable elements of either IPv6, Internet Engineering Task Force (IETF) specifications or DoD network security devices:

Larger (128 bit) IP address space Stateless and stateful host autoconfiguration mechanisms Mandatory implementation of IPsec Opportunity for enhanced QoS (globally unique addresses and Flow Label) Multicast and Anycast routing Fully supported ad-hoc networking (or "zeroconf") Removal of in-transit packet fragmentation Enhanced flexibility/extensibility (Extension Headers) Internet Key Exchange (IKE) version 2 X.509 Digital Certificates Kerberos High Assurance Internet Protocol Encryptor (HAIPE) 8 devices.

The reader should note synchronicities between elements contained in the security apparatus of JBOSS and IPv6, namely X.509 certificates and Kerberos. Also, the security guidelines for DoD should be noted regarding setting the security demarcation between black and red networks. These can only be established today via hardware such as HAIPE devices. Version 3.1.2 of the HAIPE operating systems developed by the three prime contractors producing the devices will shortly receive NSA common criteria certification for operating with IPv6.

The System Approach

Figures 1 and 2 identify hardware and software architectural tenets that are specific to the enterprises deploying SOA, and each is appropriate for their sub-system component of the enterprise system to be developed. DoD applications are accepting JBOSS as the de facto platform of choice, and the federal government has mandated the adoption of IPv6 across all enterprises, and are the established technical standards which constitute the development platforms. The systems development life cycle approach defined by ISO 15288 is our over-

8 Committee on National Security Systems (CNSS) Policy No. 19, National Policy Governing the Use of High Assurance Internet Protocol Encryptor (HAIPE) Products, NSA, February 2007

Page 10 of 16



13 July 2011


arching methodology, coupled with the ISO 27001 security engineering methodology. Our objective is to create a secure enterprise level integrated SOA system.

4. SECURITY, INTEROPERABILITY AND SCALABILITY IN AN INTEGRATED SOA ENTERPRISE

Security

Implementing the security services as defined by a given security policy is the crux of the problem. As previously noted, a variety of mechanisms exist which need to be considered. The following services are primarily used to implement the properties of confidentiality, integrity, accountability and availability:

Authentication is the process of verifying the claimed identity of a device, user and/or application trying to access the resources.

Authorization is the rights and permission granted to a user or application that enables them the access to network or computing resources.

Access control is the means by which an authorized user has access to resources. Encryption is the mechanism by which information is kept confidential from

unauthorized users. Auditing is the process that keeps track of what an authorized or unauthorized

user or application is doing.

The problem is further complicated in that these services can be applied at varying levels of the TCP/IP model (which differs from the OSI model in several ways, none of which are significant for our purpose herein). Figure 6 depicts an effort to provide confidentiality by encrypting a web-based transaction, similar to a web service operating within a SOA.

Page 11 of 16



13 July 2011


Figure 6: TCP/IP - OSI Layer Extant Interoperability Opportunities

Encryption can be performed at the application layer, the network layer or the link layer. Note that encryption can also be performed at the transport layer although for visual simplicity, this case was not shown in the figure. As you go up the stack the security service - in this case encryption - is performed with greater granularity with respect to data tied to a specific service. Additionally, the security services can be provided on the end-hosts that are participating in the communication or by intermediate network devices. Effective security architecture will ensure that the security services are applied in an efficient manner to avoid duplication of effort and unnecessary processing cycles. Security services will always be required at varying layers of the stack due to varying policies and the need to integrate easy deployment with the appropriate granularity to offer the required security protection. When specifically dealing with the network layer, all security service considerations required to protect networked communication are enhanced with the implementation of IPv6.

The approach must encompass all identified defense in depth layers. This entails identifying the element at each layer which best meets the defense in depth objectives. This is a significant shift in the deployment of networks across the enterprise. The two significant changes impacting network layer access controls are the changing of the default assumption of one address per interface and the change in the subnet model/”on-link assumption”.

Regarding the shift from one address per interface to many addresses per interface, IPv4 assumes one IP address per interface – For IPv6, the default assumption is that in almost all cases the interface will have multiple addresses. The impact of this change is that each identified service within a SOA may have its own unique network subnet operating across the enterprise, and be capable of authentication, authorization, access control, encryption, and auditing at the network layer versus application layer. This includes Quality of Service

Page 12 of 16



13 July 2011


implications per subnet, flagged at the routing infrastructure in accordance with the addressing plan, and established per service via network APIs which are integrated with the ESB.

Regarding the change in the subnet model/“on-link assumption”, IPv6 assumes no hosts are on the same link, and has an explicit “on-link” flag to indicate that another prefix is on-link. To further explain the process, the Host gets an IPv6 address (per the addressing plan) from a Router Advertisement (RA) … the host does not automatically assume that everything within that address prefix is on-link. Typically, the router would set a flag when providing a prefix indicating that it is on-link. But if that flag isn’t set, the host should assume nothing else is on-link. The impact of this change is in that the explicit announcement of multiple addresses “on link” for IPv6, versus only one address with no on-link governance for IPv4, allows for auditing of unique services per each subnet, and the opportunity for SOA specific service access controls set by router Access Control Lists (ACLs).

With the ability for multiple addresses per host, and the functionality of applications to contain network Application Programmer Interfaces (APIs), the requirement for an ESB to conduct service coordination across the enterprise may now be shared at the network layer. Elements of an IPv6 logical network topology employed in a defense in depth network architecture supporting authentication, authorization, access control, encryption, and auditing are, in order of priority first to last:

1. IPv6 Addressing Plan (e.g., Stateless/Stateful, link local, privacy, extension headers)2. SeND/CGA (Secure Neighbor Discovery and Cryptographic Generated Addressing)3. IPsec 4. IKEv2 (Internet Key Exchange version 2; employed with X.509 certificates)5. CALIPSO (Common Architecture Label IPv6 Security Option; Employing XML tags

which are an integration point within a SOA deployment with WS-Security)6. ORCHID (Overlay Routable Cryptographic Hash Identifiers; encrypted endpoint

identifiers for application programmer interfaces deployed with IPv6)7. HAIPE (High Assurance Internet Protocol Encryptors. Although implemented as a

hardware appliance, the approved dual stack implementation must be included in any logical topology effort)

Interoperability and Scalability

IPv6 design includes elements to enhance “scalability and interoperability.” In addition to the benefits of the 128 bit address itself and the opportunity for globally resolvable and link-local (non-routable) addresses, another key element for scalability and interoperability is the employment of flexible routing extensions without imposing overhead to intermediate routers. Figure 7 provides a clear comparison between what was available in IPv4, and what is now available within IPv6.

Page 13 of 16



13 July 2011


Figure 7: IPv6 Extension Headers

Extension headers, as established, actually provide two functions. First, since IPsec was developed in concert with IPv6, specific extension headers have been designated for the two components of IPsec, the Authentication Header, and the Encapsulating Security Payload. This is in contrast to the IPv4 implementation of IPsec, which is a reverse engineered arrangement allowing IPsec to operate with IPv4. Second, the extension headers allow for specific and granular routing, which, when established within the addressing plan, can refine the routing within the enterprise per subnet without changing the address prefix or router ACLs. Therefore, a SOA can be assigned to a geospatial and temporal construct with the employment of extension headers, and without impacting other subnet point to point connectivity.

JBOSS/IPv6 Integration Initiatives in Open Source

Within the JBOSS Online Community, an example of JBOSS/IPv6 integration is provided by “System property handling and IPv4 versus IPv6.”9, In regards to the processing of addresses, the developers indicate that “After the initial property processing, a next phase ensues, which attempts to determine the type of stack (IPv4 versus IPv6) and sets correct defaults.” Further, “If [the service] didn't find any addresses, and has both stacks available, we default to IPv6.”

Although there is no documented rationale in the online discussion for these design decisions, the statements in the community demonstrate the acceptance of operating JBOSS in an IPv4 only, an IPv6 only, and an integrated IPv4/v6 environment. The fact that the default

9 http://community.jboss.org/wiki/SystempropertyhandlingandIPv4versusIPv6Page 14 of 16



13 July 2011


condition is set for IPv6 when both stacks are available lends some credibility to acceptance within the open source community for IPv6 functionality.

5. CONCLUSION

White Oak Consulting LLC has the corporate experience in achieving results based on the above concepts. Our senior engineering staff was engaged in a US Navy system design effort which integrated JBOSS and IPv6 technologies to employ a security engineering architecture based on the concepts depicted. In the system requirements definition stage of the system development life cycle, our staff participated as the subject matter expert in all enterprise architecture meetings, creating the technology standards profile (DoDAF style TV-1)10 for the system enterprise architecture incorporating all security, SOA and IPv6 technical standards. As the designated security architect, our staff created the system security plan11,12 for the system under development, including the security controls for the associated integration laboratory, in order to achieve a DIACAP ATO upon system completion. In short, through our senior staff’s experience, White Oak Consulting LLC was involved in the process of producing an integrated JBOSS/IPv6 platform for a command and control system implementing a Computer Network Defense in Depth concept.

The approach was employed to ensure the architecture complies with the industry best practices for integrating the two technologies of SOA and network engineering within a secure computer network defense in depth (CNDiD) architecture, as depicted in figure 8.

Figure 8: Integrated and Secure SOA Enterprise

10 Department of Defense Architecture Framework (DODAF) version 2.0, (28 May 2009)11 MIL-HDBK- 1785, System Security Engineering Program Management Requirements, (1 August 1995)12 DoDI 8510.01, DoD Information Assurance Certification and Accreditation Process (DIACAP), (28 November 2007

Page 15 of 16



13 July 2011


This paper provided the conceptual approach for systems and security engineering to integrate a Service-Oriented Architecture (SOA) middleware platform operating at OSI layer 7 and an Internet Protocol (IP) operating at OSI layer 3. The objective of the integration is to create an optimized and securely interoperable topology across the OSI model that supports each technology’s inherent functionality in an ontological and synergistic manner. This paper focused on the JBOSS SOA platform due to the open source development environment and IP version 6 (IPv6) due to the extant industry employment of the open standard protocol which will sustain the evolution of the Internet beyond 2012 and into the next century. This paper additionally focused on the systems approach to security engineering due to the paucity of industry effort towards merging the respective software and network engineering paradigms. In short, this paper has stated that the opportunity to securely integrate a SOA platform with a robust network protocol is now.

Page 16 of 16


White Oak White Paper JBOSS-IPv6 CND in Depth

Documents

carnegie mellon

securely interoperable

consolidated

physical network

technologys

open standard

physically

network engineering