DARPA-BAA-15-10_(EdgeCT)_Amendment_1.pdf

Broad Agency Announcement

Edge‐Directed Cyber Technologies for Reliable Mission

Communication (EDICT EdgeCT)

DARPA‐BAA‐15‐10

December 02, 2014

Amendment 1 (Amended on December 5, 2014)

Defense Advanced Research Projects Agency Information Innovation Office 675 North Randolph Street Arlington, VA 22203‐2114

DARPA-BAA-15-10 EDGECT 2

Table of Contents

PART I: OVERVIEW

PART II: FULL TEXT OF ANNOUNCEMENT

I. FUNDING OPPORTUNITY DESCRIPTION

II. AWARD INFORMATION

A. Awards

B. Fundamental Research

III. ELIGIBILITY INFORMATION

A. Eligible Applicants

B. Procurement Integrity, Standards of Conduct, Ethical Considerations and Organizational

Conflicts of Interest (OCIs)

C. Cost Sharing/Matching

D. Other Eligibility Requirements

IV. APPLICATION AND SUBMISSION INFORMATION

A. Address to Request Application Package

B. Content and Form of Application Submission

C. Submission Date and Time

D. Funding Restrictions

E. Other Submission Requirements

V. APPLICATION REVIEW INFORMATION

A. Evaluation Criteria

B. Review and Selection Process

VI. AWARD ADMINISTRATION INFORMATION

A. Selection Notices

B. Administrative and National Policy Requirements

C. Reporting

VII. AGENCY CONTACTS

VIII. OTHER INFORMATION

A. Frequently Asked Questions (FAQs)

B. Proposers’ Day

C. Submission Checklist

DARPA-BAA-15-10 EDGECT 3

PART I: OVERVIEW

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O)

Funding Opportunity Title: Edge‐Directed Cyber Technologies for Reliable Mission Communication (EdgeCT)

Announcement Type: Initial Announcement

Funding Opportunity Number: DARPA‐BAA‐15‐10

Catalog of Federal Domestic Assistance Numbers (CFDA): 12.910 Research and Technology Development

Dates:

o Posting Date: December 2, 2014 o Proposal Due Date: January 27, 2015, 12:00 noon (ET) o BAA Closing Date: January 27, 2015, 12:00 noon (ET) o Proposers’ Day: December 8, 2014

Anticipated Individual Awards: DARPA anticipates multiple awards for Technical Area 1, and a single award for Technical Area 2. Multiple awards are possible for Technical Area 3.

Types of Instruments that May be Awarded: Procurement contracts, cooperative agreements or other transactions. No grants will be awarded under this solicitation.

Technical POC: Dr. Stuart Wagner, Program Manager, DARPA/I2O

BAA EMail: EdgeCT@darpa.mil

BAA Mailing Address:

DARPA/I2O

ATTN: DARPA‐BAA‐15‐10

I2O Solicitation Website:

http://www.darpa.mil/Opportunities/Solicitations/I2O_Solicitations.aspx

DARPA-BAA-15-10 EDGECT 4

PART II: FULL TEXT OF ANNOUNCEMENT

I. FUNDING OPPORTUNITY DESCRIPTION

DARPA is soliciting innovative research proposals in the area of resilient, mission‐aware computer networking. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

This BAA is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 35.016. Any negotiations and/or FAR based contract awards will use procedures under FAR 15.4 (or 32 CFR 22 for cooperative agreements).

Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

DARPA BAAs are posted on the Federal Business Opportunities (FBO) website (http://www.fbo.gov/) and, as applicable, the Grants.gov website (http://www.grants.gov/).

The following information is for those wishing to respond to this BAA.

A. Introduction and Background

The military is heavily dependent on networked communication to fulfill its missions.

Unfortunately, the wide‐area network (WAN) infrastructure that supports this communication is vulnerable to a wide range of failures and cyber attacks that can severely impair connectivity and mission effectiveness at critical junctures. Examples include inadvertent or malicious mis‐ configuration of network devices, hardware and software failures, sabotage, extended delays in Internet Protocol (IP) route convergence, denial of service (DoS) flooding attacks, and a variety of control‐plane and data‐plane attacks resulting from malicious code embedded within network devices. This BAA will henceforth refer to instances of such attacks, failures and other forms of network disruption as “network events.” Rapid recovery from such events is critical for ensuring mission success. In the current art, however, recovery can take anywhere from tens of minutes to several hours or more, depending on the nature of the event(s). Outage durations of this magnitude stand in stark contrast to missions’ tolerance for loss of communication, which is usually minutes or less – a disparity of two to three orders of magnitude.

A closely related problem is that during periods of degraded or denied communication, users may have no cyber situational awareness concerning the nature or extent of the problem, including the knowledge of which users have been affected and what networking capabilities remain available. In military networks, the common use of in‐line encryption devices at the boundaries between user enclaves and the WAN leaves users with no direct visibility into, or control over, WAN infrastructure. This lack of information impedes mission commanders’ ability to assess the impact of network events on the mission, and to adapt mission plans.

DARPA-BAA-15-10 EDGECT 5

In current practice, when users at the network edge experience degraded or denied communication, they typically have no recourse other than to inform WAN administrators of the difficulty. However, the operations support systems that provide fault and performance management in large WANs typically consider only coarse‐grained traffic measurements (in terms of sampling time windows, the overall number of packet flows, or both), due to the enormous traffic volumes flowing over these networks. Consequently, network events that affect small but mission‐critical sets of users, flows, or time periods may go undetected and un‐ diagnosed by these systems, which will further prolong recovery times. Examples of such events are localized failures caused by router mis‐configuration, and network‐based, low‐ volume DoS attacks targeting a particular user enclave. Further impeding WAN administrators’ effective response to network events is the fact that the WAN transports data in encrypted tunnels between enclaves (i.e., the tunnels established between encryption devices at the network edge). The WAN therefore has no detailed knowledge of user, application or mission communication requirements, impeding its ability to respond to network events in a manner that efficiently meets these needs.

The networking research community has invested heavily in hardening network infrastructure to mitigate or prevent network events. Proposed methods include a variety of network‐based DoS detection techniques, Byzantine fault tolerance algorithms, trust‐based routing methodologies, algorithms for discovering configuration errors, and a variety of fast fail‐over mechanisms, among many others. Unfortunately, the specter of human error, malicious insider actions, increasingly sophisticated cyber attacks against network infrastructure, and high WAN complexity (which in turns creates complex failure modes) still constitutes a grave threat to mission communication. Therefore, new approaches to providing reliable communication are needed.

B. Program Description

The objective of the EdgeCT program is to bolster the resilience of communication over IP networks solely by instantiating new capabilities in computing devices within user enclaves at the WAN edge (see Fig. 1).

Figure 1. EdgeCT systems operate within user enclaves at the WAN edge.

DARPA-BAA-15-10 EDGECT 6

EdgeCT will develop systems that incorporate the following three technical components:

Real‐time network analytics that extract useful information about WAN characteristics and events from enclave‐based observation of packet flows into and out of the WAN.

Holistic decision systems that utilize knowledge gained from real‐time network analytics, as well as configurable information concerning mission plans (including tasks, priorities and deadlines, if applicable) to determine actions that mitigate network events, in a fashion that best serves the mission as a whole.

Dynamically configurable protocol stacks that implement these decisions by modifying the manner in which information is handled at the network, transport, and application layers of the five‐layer protocol stack model of Internet operation.

Proposers should assume that each enclave is fronted by one or more in‐line military encryption devices, as shown in Figure 1 (above). EdgeCT systems and all of their functionality will be positioned solely within these (cleartext) enclaves. These systems will have no ability to communicate directly with the WAN control or management planes or with the WAN administrator, and will have no knowledge of WAN architecture except for what EdgeCT systems can infer from edge‐based observation of packet flows into and out of the WAN.

EdgeCT system designs cannot require any changes to the WAN or to the encryption boundaries.

Deployed EdgeCT systems may ultimately have to recognize and support robust communication for a variety of user applications. For purposes of EdgeCT system demonstrations, proposers should initially plan on support of real‐time streaming video, real‐time audio, file transfer, and a transaction‐oriented situational awareness application. It is possible that other military applications may be added as the program proceeds, and EdgeCT systems should permit expansion of this initial list of applications.

Demonstrations may include both unicast and network‐layer multicast versions of the aforementioned real‐time applications running on users’ computing devices. Support of multicast communication is often critical to military operations, but raises unique challenges, such as the efficient, real‐time monitoring and assessment of overall performance across a multicast group. Proposers should clearly explain the extent to which their designs will accommodate multicast operation. Systems that can improve the resilience of multicast communication in the presence of network events will be viewed favorably. At a minimum, systems are expected to “do no harm” to multicast flows.

Proposers may make the following assumptions regarding the WANs of interest in this program:

The WAN is an IP network of global scale with fiber‐optic links between WAN network devices.

Routes through the WAN may be asymmetric. Proposed solutions should not assume route symmetry.

DARPA-BAA-15-10 EDGECT 7

Access links between user enclaves and the WAN will typically be fiber‐based, with transmission rates of at least 100 Mb/s. However, demonstrations and testing will also include cases where access links are SATCOM whose bandwidths may be limited to roughly 1 Mb/s. EdgeCT system(s) within an enclave may be configured to reflect the nature of the access link (fiber versus SATCOM) for that enclave.

The encryption boundaries provide secure tunnels between enclaves, including confidentiality, integrity, and replay protection for inter‐enclave communication.

Tunnels between encryption boundaries have been established in advance, and all enclaves are reachable from one another.

No data may pass “in the clear” between cleartext and ciphertext sides of the encryption boundaries, with the exception of multicast join messages. Proposed solutions should not assume that DiffServ code points placed within cleartext packet headers will result in any type of differentiated services from the WAN.

The WAN may be carrying substantial background traffic that neither originates nor terminates from any of the EdgeCT‐enabled enclaves involved in the mission scenarios to be demonstrated.

C. Program Structure and Technical Areas

The EdgeCT program includes three technical areas (TAs) as described below. Each proposal submitted in response to this BAA shall address only one TA. Organizations may submit multiple proposals to any one technical area, or to multiple technical areas. However, organizations performing in TA1 cannot also be performers in TA2 or TA3.

The overriding objective of the EdgeCT program is to produce the best possible technologies for enabling resilient mission communication. To this end, the Government intends EdgeCT to be a collaborative program in which all performers (both within and across TAs) constructively interact with one another. To facilitate the open exchange of information, performers may have an Associate Contractor Agreement (ACA) clause included in their award. This clause is intended to ensure appropriate coordination and integration of work done by the EdgeCT performers. Once selections have been made, selectees should have their ACAs in place prior to the first program kick‐off meeting.

Prospective proposers are strongly encouraged to read the descriptions of all three TAs, to ensure a full understanding of the program context, structure, and anticipated relationships among performers.

EdgeCT is a three‐year program with two 18‐month phases. Proposals should reflect a three‐ year base program effort with a nominal start date of July 1, 2015. Proposals may include optional efforts that go beyond what is necessary to meet EdgeCT’s baseline goals and requirements, if the efforts are synergistic with the base program; and if the efforts support the overall EdgeCT vision of communications resilience.

DARPA-BAA-15-10 EDGECT 8

No forced down‐selects are anticipated. Individual performer efforts will be evaluated in terms of the viability of their technical approaches, the trend in the performance of their systems over time, and their overall progress toward EdgeCT performance objectives. The Government may decide to continue all performer efforts through the end of the program.

Technical Area 1: EdgeCT Systems

System‐Level Considerations. Each TA1 performer will develop an integrated system comprising real‐time network analytics, holistic decision systems, and dynamically configurable protocol stacks, as well as any other functions that the performer believes are necessary to meet EdgeCT program goals and metrics (see the Program Metrics section on page 14). TA1 proposers must provide an explicit plan, including approach and timeline, that is consistent with the overall program schedule and milestones (see the Program Schedule and Milestones section on page 15), as well as a strategy for how they intend to integrate and test their systems.

It is envisioned that EdgeCT systems will be instantiated as stand‐alone gateways (“bumps in the wire” or “middleboxes”) within user enclaves. Alternative approaches that place EdgeCT functions on users’ hosts instead of, or in addition to, gateways will also be considered.

However, the use of gateways has both prototyping and operational advantages in that it (1) obviates the need to modify users’ existing computing devices, (2) avoids the need to develop versions of software tailored to a diversity of user operating systems, (3) provides a natural location for executing EdgeCT functions for the entire user enclave in a coordinated fashion, and (4) provides an operating environment less susceptible to infection vectors associated with end hosts running common user applications (e.g., rogue email attachments or Web links). TA1 proposers should explicitly state which of these approaches (gateway only, users’ hosts only, or a combination) their EdgeCT designs will follow, and provide a rationale for this design choice.

EdgeCT will combine analytics, decision systems and protocol stacks in a closed loop, capable of fully automated mitigation of network events. However, human operators must also be able to interface with the system, specifically:

1. To provide configuration information concerning mission tasks and communication requirements, which at a minimum should include application and user priorities.

2. To access situational awareness data regarding WAN conditions, the performance of packet flows associated with user applications, utility measures, and prevailing or planned mitigation strategies.

3. To enable manual intervention, including fully manual control of decisions as well as partially automated “human‐on‐the‐loop” operation, in which the operator can modify mitigation strategies prior to their implementation.

These aspects of EdgeCT operation are not yet fully defined, and will be the subject of continuing interactions with prospective military transition partners during Phase 1. Proposers should plan to provide a basic configuration capability such as a configuration file read at runtime, or a graphical user interface. TA1 proposers should also plan to provide a basic real‐ time display of EdgeCT system information (such as inferred situational awareness data and current mitigation strategies) for demonstration purposes. Development of more‐elaborate

DARPA-BAA-15-10 EDGECT 9

interfaces and configuration capabilities are not required in this program and should not distract from the main focus on analytics, decision systems, and novel protocol adaptation.

TA1 performers will have the option of implementing their systems either (1) in software, to be uploaded to the TA2 experimental platform; or (2) in a combination of software and hardware, instantiated on machines that TA1 performers provide for connection to the experimental platform.

TA1 performers’ system designs will be subject to period assessments by TA3 performers with respect to design weaknesses and vulnerabilities. These assessments, as well as program demonstrations, will assume that EdgeCT‐enabled hosts within user enclaves are protected against compromise, and TA1 performers will not be expected to ensure resilience against attacks on these hosts.

Real‐Time Network Analytics. This EdgeCT component will infer important characteristics of WAN state by applying statistical analysis techniques to users’ packet flows passing into and out of the WAN. Active measurement techniques using EdgeCT‐generated probes are also possible, although such probing constitutes an additional network load and should be used sparingly (see the Program Metrics section on page 14).

Examples of useful information that might, in principle, be derived from observation of packet flows and probing include onset of network events, salient features of the events, levels of performance (e.g., latency, throughput) that are achievable both before and during the events, the degree of diversity among possible paths between source and destination enclaves, and the presence of shared WAN bottlenecks that enclaves have in common en route to destinations of interest.

Proposers should consider the following technical challenges when formulating their approaches to EdgeCT analytics:

In light of EdgeCT’s need to provide fast responses to network events, analytics algorithms should be lightweight, scalable, and executable in near real‐time.

Statistical characterization of packet flows will have relatively high dimensionality, with the relevance of each dimension depending on the nature of the network event. For example, attacks could target packets of a specific size, source or destination IP address, or protocol.

In some cases, the precision and accuracy of statistical characterization could be improved through the sharing of measurement data among EdgeCT enabled hosts.

However, this data sharing constitutes network overhead that reduces the capacity available to user application flows (see the Program Metrics section on page 14).

Moreover, network disruptions may severely limit the ability to share such data between enclaves.

Holistic Decision Systems. This component dynamically reconfigures the EdgeCT protocol stack based on a variety of information sources: summarizations of current WAN conditions from the

DARPA-BAA-15-10 EDGECT 10

analytics component, estimates of users’ application and flow performance derived from the protocol stack, pre‐configured knowledge of the mission (e.g., applications and priorities), stored experience from past actions, and information received from other EdgeCT‐enabled hosts. Proposers may assume that all enclaves are configured with a common set of mission knowledge. Information such as priority could be defined at the granularity of applications, enclaves, IP addresses (source or destination), or combinations of these.

The use of highly shared decision systems that attempt to control EdgeCT operation across multiple enclaves from a physically centralized location are not of interest in this program.

The goal of EdgeCT’s holistic decision system is to ensure that the mission derives maximal benefit from whatever WAN capabilities remain following network events. The greedy use of WAN resources among pairs of communicating hosts could easily exacerbate already‐stressed network conditions during events, and will offer relatively little value if low‐priority or non‐ time‐critical tasks receive preferential treatment over tasks that are urgent and mission‐critical.

This program will use a performance metric known as Cumulative Network Utility (CNU) to quantify EdgeCT’s effectiveness in identifying mitigation strategies that yield favorable outcomes from the standpoint of overall mission needs. (See page 14 for a description of this metric.)

Examples of approaches that could be relevant to EdgeCT’s holistic decision‐making include network utility maximization, cooperative gaming, Monte Carlo planning, and partially observable Markov decision processes, among others. Technical challenges that proposers should consider when formulating their approaches include, but are not limited to, the following:

Decision‐making faces several sources of uncertainty, including the partially observable and non‐stationary nature of the WAN, potentially high volumes of unobservable background traffic within the WAN, and the limited ability to exchange information between EdgeCT‐enabled hosts for purposes of coordination and maintenance of shared beliefs about the WAN.

A tradeoff typically exists between response time and accuracy. For example, in response to a network event, EdgeCT could initially execute a set of actions designed to improve its knowledge of WAN state, rather than immediately attempting mitigation.

These initial actions, sometimes referred to as belief state planning, may illuminate more‐effective mitigation strategies but will also extend the response time. Belief state planning could occur proactively, reactively, or both.

Basing decisions on prior outcomes and experiences may have little value in mitigating novel, unforeseen types of network events, and may be counter‐productive in cases where attackers intentionally vary their actions over time.

Deadlines are inherent in many military mission tasks. For example, the value that accrues from receipt of information may be nil if its receipt is delayed beyond the point of relevance. Both hard and soft deadlines can be built into utility functions describing each mission task, but incorporating this deadline information into EdgeCT’s decision

DARPA-BAA-15-10 EDGECT 11

systems complicates the algorithms. The ability to incorporate deadlines into EdgeCT decision‐making will be viewed favorably.

Dynamically Configurable Protocol Stacks. This component implements EdgeCT mitigation decisions by modifying the characteristics of existing protocols, and/or invoking new protocols, involved in information exchange between hosts. EdgeCT’s location in cleartext enclaves at the network edge largely confines operation to the application, transport, and network layers of the five‐layer protocol reference model. Network layer operation only includes those functions that are relevant within and between cleartext enclaves. (IP routing, link‐layer and physical‐ layer functions within the WAN are uncontrollable and only partially observable from these enclaves.) Within this scope, a wide variety of approaches are possible, including but not limited to the formulation of relay functions and overlays at one or more layers, modification of the behavior of individual protocols, swapping of protocols, and reconfiguration of the application‐layer topology (e.g., ad‐hoc formation of peer‐to‐peer topologies). Demonstrations of additional, innovative methods for dynamic protocol manipulation are encouraged.

Approaches that do not require modification of existing user applications are strongly preferred. However, the demonstration of new applications are within program scope, as long as these applications (1) support relevant military communications needs, and (2) incorporate features that provide a significant advance in communications resilience.

Proposers should consider the following challenges when formulating their technical approach to EdgeCT protocol stacks:

EdgeCT should not noticeably impair application performance under normal operating conditions (i.e., in the absence of network events). This consideration is important to the ultimate acceptance of the technology. Proposers should directly address this issue in their submissions.

Heavyweight packet manipulation may have difficulty scaling to the high offered loads that may be found in large deployed enclaves.

A range of possible EdgeCT stack implementations are possible, and might include user‐space or kernel‐space software, programming of graphics processing units, or other alternatives. A minimum throughput of at least 100 Mb/s will be necessary for testing and demonstration purposes, if EdgeCT is implemented as a bump in the wire. Higher throughputs are very desirable, and throughputs of 1 Gb/s or more will be necessary for eventual deployment.

Proposers should explain their envisioned implementations as well as the likely throughput capabilities and latencies that they expect to achieve.

Although some aspects of EdgeCT’s protocol stack operation may be relevant to moving target defense, protocol obfuscation, and similar proactive defenses, these objectives are not within the scope of this solicitation.

TA1 Deliverables. TA1 deliverables include the following: source code, documentation of code and algorithms, copies of published papers that resulted from the research, copies of

DARPA-BAA-15-10 EDGECT 12

presentations made at kickoff and PI meetings, and other reporting deliverables to be specified in the contract.

Technical Area 2: Experimental Lead and Evaluator

Overview. The TA2 performer will be responsible for constructing and maintaining an experimental platform for use by all TA1 performers throughout the course of the program.

The availability of a common, shared experimental environment obviates the need for each TA1 performer to construct a separate, full‐scale test environment for its own use, and also provides the Government with a common reference and context for assessing the progress of each TA1 system.

The TA2 performer must collaborate with the Government and with all other TA1 and TA3 teams with respect to clarifying platform operation, arranging demonstration scenarios (including scenarios that are suggested by TA1 or TA3 performers), and gathering test results specific to each TA1 system.

The experimental platform must have the following properties:

i. Remotely accessible by all performers independently, preferably at all times without restriction. This is particularly important in periods leading up to demonstration milestones, when all TA1 performers may require frequent, sustained access to the platform. The number of TA1 awardees will not be known until the Government’s scientific review of all EdgeCT proposals has been completed. For planning purposes, TA2 proposers should assume that as many as six TA1 performers might require access to the platform.

ii. Ability to emulate a large‐scale WAN consisting of at least 50 routers and with link latencies characteristic of global‐scale communication paths.

iii. Inclusion of realistic background traffic (emulated or real) within the WAN, where background traffic refers to flows that neither originate nor terminate in EdgeCT‐ enabled user enclaves.

iv. Accommodate a variable number of user enclaves up to a maximum of 12, with up to 50 emulated users per enclave. An emulated encryption device should be provided at the boundary between each enclave and the WAN.

v. Generation of realistic user packet flows from each enclave, to include both clients and servers associated with common military applications such as video, email, VoIP, file sharing, database synchronization, and high‐speed file transfer. The platform should preferably have the capability to install additional, military‐specific applications as they become available to the EdgeCT program from potential transition partners, and/or applications that TA1 performers might create within their projects. TA2 proposers should cite their ability to incorporate additional applications as they become available within the program.

vi. Incorporation of EdgeCT software and/or hardware from TA1 performers into the platform to enable testing.

DARPA-BAA-15-10 EDGECT 13

vii. The ability to emulate and verify a variety of network events within WAN infrastructure, including router mis‐configurations, high‐volume DoS attacks, low‐volume targeted DoS attacks (e.g., shrew attacks), targeted packet‐corruption or packet‐dropping attacks in the control plane or user data plane, and failures that deny access to server locations.

Performers in TA1 and TA3 may propose additional network events for demonstration, and TA2 should be sufficiently flexible to incorporate these events.

viii. Layer 3 packet‐level emulation (loss, bandwidth, latency) of SATCOM access links for a selected subset of enclaves.

ix. Instrumentation that enables measurement of EdgeCT system performance with respect to the metrics listed in the Program Metrics section on page 14. This performance should be visible to each EdgeCT performer, with summaries of system‐level performance measures furnished to the Government as well.

TA2 proposers should provide a detailed description of their technical approaches for providing these platform capabilities, as well as any additional capabilities (e.g., additional metrics beyond those described on page 14) that proposers believe would further support EdgeCT TA2 objectives.

TA2 Deliverables. The TA2 performer will be responsible for the following deliverables:

An initial version of platform documentation furnished to all other program performers and to the Government within two months of contract award. Subsequent updates to this documentation should be furnished roughly semi‐annually thereafter, or as necessary to reflect changes to platform interfaces or operation.

An experimental platform with initial operating capabilities (IOC) incorporating properties (i) through (vii) in the above list within three months of contract award, and incorporating properties (i) through (ix) within five months of contract award.

Summaries of the performance of each EdgeCT system, for all system‐level demonstrations beginning in Month 12.

Other reporting deliverables to be specified in the contract.

Technical Area 3: Voice of the Offense

Overview. TA3 performers will be responsible for periodically reviewing TA1 performers’ system designs, and for furnishing assessments to each performer concerning potential design weaknesses and vulnerabilities. TA3 performers will also provide the TA2 performer with recommendations concerning military‐relevant WAN architectures, applications, and demonstration scenarios (to include examples of network usage patterns and network events).

These TA3 responsibilities will require close collaboration with all other EdgeCT performers throughout the program.

TA3 performers should have detailed knowledge of military WANs such as those in use by COCOMs, as well as the operational scenarios that these networks commonly support. TA3 performers should also be familiar with a range of potential WAN failure modes and

DARPA-BAA-15-10 EDGECT 14

vulnerabilities. Of particular interest are those network events that would prove difficult for WAN administrators’ network management systems to diagnose and remediate.

TA3 proposers should provide descriptions of the types of missions, demonstration scenarios and network events that they envision being incorporated into TA2 experimental platforms, as well as a detailed description of the planned methodologies for critically assessing TA1 performers’ system designs during the course of the program.

TA3 Deliverables. TA3 performers will be responsible for the following deliverables:

Assessment summaries of each TA1 performer’s system at six‐month intervals throughout the program.

Summaries of recommended demonstration scenarios.

Other reporting deliverables to be specified in the contract.

D. Program Metrics

The table below summarizes EdgeCT program metrics. The principal performance metric for EdgeCT systems is the Cumulative Network Utility (CNU), which measures EdgeCT’s ability to apply mission awareness to mitigation strategy across all hosts and networked tasks, such that the mission derives maximal benefit from available WAN resources. To compute CNU, tasks (e.g., a file transfer or delivery of streaming video) are assigned utility functions that depend on the speed or quality with which the tasks can be completed. These utility functions are then weighted with priorities that indicate the relative importance of the task to the mission. The sum of all weighted utilities that are achieved during each demonstration scenario provides a raw, un‐normalized measure of CNU. This raw measure is then normalized by the CNU value that is estimated to be maximally achievable, given the nature of network events (such as failure that substantially reduces WAN capacity) that occurred within the scenarios. The CNU measure implicitly includes several factors affecting EdgeCT performance, including the ability of analytics to discern network events, the accuracy and speed with which EdgeCT decision systems can collectively identify favorable mitigation strategies, the effectiveness of actions that are available from the EdgeCT protocol stack, and the impacts of network and processing overheads associated with EdgeCT operation.

The table includes two additional metrics that quantify lower‐level aspects of EdgeCT operation. Network overhead refers to EdgeCT‐generated probes as well as messaging between EdgeCT hosts, with the latter being transmitted for the purpose of sharing

Metric Phase 1 Phase 2

Percent Recovery in Cumulative Network Utility (CNU) compared with what is maximally feasible

60 95

Average Network Overhead per Enclave 10 kb/s or 1%

10 kb/s or 1%

Average Outage Duration 60 sec 10 sec

DARPA-BAA-15-10 EDGECT 15

measurement data, coordinating actions among hosts, or similar functions supporting EdgeCT system operation. The objective is to limit this overhead to no more than either 10 kb/s or 1% of the enclave’s average offered load, whichever is greater. Proposers should provide and substantiate a rough estimate for the network overheads that their systems will generate.

Average outage duration following a network event refers to the period of downtime suffered by applications, as measured by the performance of their associated packet flows (e.g., TCP throughput, or video quality, as inferred roughly from packet‐level measurement).

The precision and accuracy of network event diagnosis is not an explicit goal of this program.

Precise diagnosis might expedite convergence to holistically favorable mitigation strategies, but will be impossible in most circumstances due to the partially observable and non‐stationary nature of the WAN.

E. Program Schedule and Milestones

The table below provides a notional program schedule and milestones.

Proposals should reflect a three‐year base program effort with a nominal start date of 1 July 2015. For planning purposes, proposers may assume that the program kickoff meeting and all PI meetings will be held in the Washington, DC area, with meetings alternating between one‐ day and two‐day events. It is possible that some meeting venues may be moved to other locations once the program begins, depending on physical locations of performers.

The following table indicates the planned scope for EdgeCT demonstrations during each program phase. Tasks refer to mission activities that involve transmission of at least one packet flow, along with specifications for utility functions and priority.

Program Phase Phase 1 Phase 2

Fiscal year 15 16 17 18 Program Month 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Kickoff and PI Meetings

Expt. Platform Documentation

Expt. Platform Capabilities

Component Demonstrations

Voice of Offense Evaluations

System Demos ‐ Single Event

System Demos ‐Multi‐Event

Field Exercises

DARPA-BAA-15-10 EDGECT 16

The program schedule includes field exercises near the end of both phases. The objectives of the field exercises are to expose EdgeCT systems and performers to military operational environments, and to elicit feedback from potential transition partners concerning EdgeCT features, capabilities, and overall concept of operation. The nature and venue for these exercises has not yet been determined, but will nominally require two weeks of on‐site involvement for multiple members of participating teams, for each of the exercises. Security clearances may be required for participation (see Section III.D). Participation by TA3 performers will be mandatory. It is possible that the Government will select only a subset of TA1 teams to participate in these exercises, based on the maturity of the systems and the availability of cleared personnel (if necessary). For responses to this BAA, proposals should include a task comprising, for each exercise (one in Phase 1 and one in Phase 2), two weeks of on‐site work by two project personnel in the San Diego, CA area. TA3 responses should include this task in their base proposals. TA1 responses should include an option covering this work. If necessary, the Government will execute change orders during the program to cover more‐ specific work statements associated with these exercises.

F. Intellectual Property

The program will emphasize creating and leveraging open source technology and architecture.

Intellectual property rights asserted by proposers are strongly encouraged to be aligned with open source regimes.

A key goal of the program is to establish an open, standards‐based, multi‐source, plug‐and‐play architecture that allows for interoperability and integration. This includes the ability to easily add, remove, substitute, and modify software and hardware components. This will facilitate rapid innovation by providing a base for future users or developers of program technologies and deliverables. Therefore, it is desired that all noncommercial software (including source code), software documentation, hardware designs and documentation, and technical data generated by the program be provided as deliverables to the Government, with a minimum of Government Purpose Rights (GPR), as lesser rights may adversely impact the lifecycle costs of affected items, components, or processes. See Section VI.B.1 for more details on intellectual property.

Demonstration Parameters Phase 1 Phase 2

Number of Enclaves 6 12

Number of Flows or Tasks per Scenario 1000 10000

Types of Simultaneous Attacks or Failures single multiple

DARPA-BAA-15-10 EDGECT 17

II. AWARD INFORMATION

A. Awards

Multiple awards are anticipated. The level of funding for individual awards made under this solicitation has not been predetermined and will depend on the quality of the proposals received and the availability of funds. Awards will be made to proposers whose proposals are determined to be the most advantageous and provide the best value to the Government, all factors considered, including the potential contributions of the proposed work, overall funding strategy, and availability of funding. See Section V for further information.

The Government reserves the right to:

select for negotiation all, some, one, or none of the proposals received in response to this solicitation;

make awards without discussions with proposers;

conduct discussions with proposers if it is later determined to be necessary;

segregate portions of resulting awards into pre‐priced options;

accept proposals in their entirety or to select only portions of proposals for award;

fund proposals in increments with options for continued work at the end of one or more phases;

request additional documentation once the award instrument has been determined

(e.g., representations and certifications); and remove proposers from award consideration should the parties fail to reach agreement on award terms within a reasonable time or the proposer fails to provide requested additional information in a timely manner.

Proposals selected for award negotiation may result in a procurement contract, cooperative agreement, or other transaction (OT) depending upon the nature of the work proposed, the required degree of interaction between parties, and other factors. In all cases, the Government contracting officer shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Proposers are advised that, if they propose grants or cooperative agreements, the Government contracting officer may select other award instruments, as appropriate. Publication or other restrictions will be applied, as necessary, if DARPA determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see below.

B. Fundamental Research

It is Department of Defense (DoD) policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 established the national policy for controlling the flow of scientific, DARPA-BAA-15-10 EDGECT 18 technical, and engineering information produced in federally funded fundamental research at colleges, universities, and laboratories. NSDD 189 defines fundamental research as follows:

'Fundamental research' means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this BAA, the Government expects that program goals as described herein either cannot be met by proposers intending to perform fundamental research or else the proposed research is anticipated to present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Therefore, the Government anticipates restrictions on the resultant research that will require the contractor to seek DARPA permission before publishing any information or results relative to the program. Notwithstanding this statement of expectation, the Government recognizes that proposed research solutions could be of a fundamental nature. If fundamental research is performed under this program, the Government does not anticipate applying publication restrictions of any kind on fundamental projects.

Proposers should indicate in their proposal whether they believe the scope of the proposed research is fundamental. For certain research projects, it may be possible that although the research to be performed by the prime proposer is non‐fundamental, a subcontractor’s tasks may be considered fundamental research. In those cases, it is the prime proposer’s responsibility to explain in their proposal why its subcontractor’s effort is fundamental research. While proposers should clearly explain the intended results of their research, DARPA shall have sole discretion to determine whether the project is considered fundamental research. Awards for non‐fundamental research will include the following statement or similar provision:

There shall be no dissemination or publication, except within and between the contractor and any subcontractors, of information developed under this contract or contained in the reports to be furnished pursuant to this contract without prior written approval of DARPA’s Public Release Center (DARPA/PRC). All technical reports will be given proper review by appropriate authority to determine which Distribution Statement is to be applied prior to the initial distribution of these reports by the contractor. With regard to subcontractor proposals for Contracted Fundamental Research, papers resulting from unclassified contracted fundamental research are exempt from prepublication controls and this review requirement, pursuant to DoD Instruction 5230.27 dated October 6, 1987.

When submitting material for written approval for open publication, the contractor/awardee must submit a request for public release to the PRC and include the following information: 1) Document Information: title, author, short plain‐language description of technology discussed in the material (approx. 30 words), number of pages (or minutes of video) and type (e.g., briefing, report, abstract, article, or paper); 2) Event Information: type (e.g., conference, principal investigator meeting, article or paper), date, DARPA-BAA-15-10 EDGECT 19 desired date for DARPA's approval; 3) DARPA Sponsor: DARPA Program Manager, DARPA office, and contract number; and 4) Contractor/Awardee’s Information: POC name, e‐mail address and phone number. Allow four weeks for processing; due dates under four weeks require a justification. Unusual electronic file formats may require additional processing time. Requests may be sent either to prc@darpa.mil or 675 North Randolph Street, Arlington VA 22203‐2114, telephone (571) 218‐4235. See http://www.darpa.mil/NewsEvents/Public_Release_Center/Public_Release_Center.aspx for further information about DARPA’s public release process.

DARPA-BAA-15-10 EDGECT 20

III. ELIGIBILITY INFORMATION

A. Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA.

1. Federally Funded Research and Development Centers (FFRDCs) and Government Entities

FFRDCs and Government entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations and cannot propose to this solicitation in any capacity unless the following conditions are met.

FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector and must provide a letter on official letterhead from their sponsoring organization citing the specific authority establishing the FFRDC’s eligibility to propose to Government solicitations and compete with industry, and compliance with the terms and conditions in the associated FFRDC sponsor agreement. This information is required for FFRDCs proposing as either prime contractors or subcontractors.

Government entities must clearly demonstrate that the proposed work is not otherwise available from the private sector and provide documentation citing the specific statutory authority (and contractual authority, if relevant) establishing their eligibility to propose to Government solicitations.

At the present time, DARPA does not consider 15 USC § 3710a to be sufficient legal authority to show eligibility. For some entities, 10 USC § 2539b may be the appropriate statutory starting point; however, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility.

DARPA will consider eligibility submissions on a case‐by‐case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

2. Foreign Participation

Non‐U.S. organizations and/or individuals may participate to the extent that such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

B. Procurement Integrity, Standards of Conduct, Ethical Considerations and Organizational Conflicts of Interest (OCIs)

Current Federal employees are prohibited from participating in particular matters involving conflicting financial, employment, and representational interests (18 USC §§ 203, 205, and 208).

Prior to the start of proposal evaluation, the Government will assess potential COIs and will promptly notify the proposer if any appear to exist. The Government assessment does not

DARPA-BAA-15-10 EDGECT 21

affect, offset, or mitigate the proposer’s responsibility to give full notice and planned mitigation for all potential organizational conflicts, as discussed below.

In accordance with FAR 9.5 and without prior approval or a waiver from the DARPA Director, a contractor cannot simultaneously provide scientific, engineering, and technical assistance (SETA) or similar support and be a technical performer. As part of the proposal submission, all members of a proposed team (prime proposers, proposed subcontractors and consultants) must affirm whether they (individuals and organizations) are providing SETA or similar support to any DARPA technical office(s) through an active contract or subcontract. Affirmations must state which office(s) the proposer and/or proposed subcontractor/consultant supports and must provide prime contract number(s).