DARPA-BAA-15-56_(XD3_BAA)_Amendment_0002.pdf

Broad Agency Announcement

Extreme DDoS Defense (XD3)

DARPA‐BAA‐15‐56

August 14, 2015

Amendment 2 (Amended on October 8, 2015)

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

DARPA-BAA-15-56 XD3 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. Associate Contractor Agreement Clause

D. Submission Checklist

DARPA-BAA-15-56 XD3 3

PART I: OVERVIEW

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

Funding Opportunity Title: Extreme DDoS Defense (XD3)

Announcement Type: Initial Announcement

Funding Opportunity Number: DARPA‐BAA‐15‐56

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

Dates:

o Posting Date: August 14, 2015 o Proposal Due Date: October 13, 2015, 12:00 noon (ET) o BAA Closing Date: October 13, 2015, 12:00 noon (ET) o Proposers Day: September 2, 2015

Anticipated Individual Awards: DARPA anticipates multiple awards for Technical Areas 1, 2, and 3. Multiple awards are possible for Technical Area 5. Technical Area 4 awards, if any, will occur for Phase 2 of the program.

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: XD3@darpa.mil

BAA Mailing Address:

DARPA/I2O

ATTN: DARPA‐BAA‐15‐56

675 North Randolph Street Arlington, VA 22203‐2114

DARPA Solicitation Website:

http://www.darpa.mil/work-with-us/opportunities

DARPA-BAA-15-56 XD3 4

PART II: FULL TEXT OF ANNOUNCEMENT

I. FUNDING OPPORTUNITY DESCRIPTION

DARPA is soliciting innovative research proposals in the area of resilient defenses against distributed denial of service (DDoS) attacks on computer networks. 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 (https://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 threat of DDoS attacks has been well‐recognized in the data networking world for two decades. Such attacks are orchestrated by sets of networked hosts that collectively act to disrupt or deny access to information, communications, or computing capabilities, generally by exhausting targets’ critical resources such as bandwidth, processor capacity, or memory.

Typical victims of these attacks include information storage and computing facilities; servers associated with content distribution, message forwarding, or command and control (C2); and portions of network infrastructure (e.g., link flooding, or resource exhaustion within network elements). The nature of DDoS attacks can span a wide range. Botnet‐induced volumetric attacks, which can generate hundreds of Gb/s of malicious traffic, are perhaps the best‐known form of DDoS. However, low‐volume DDoS attacks can be even more pernicious and problematic from a defensive standpoint. Such attacks target specific applications, protocols, or state‐machine behaviors while relying on traffic sparseness (or seemingly innocuous message transmission) to thwart traditional intrusion‐detection techniques.

The current art in DDoS defense generally relies on combinations of network‐based filtering, traffic diversion and ”scrubbing,” or replication of stored data (or the logical points of connectivity used to access the data) to dilute volumetric attacks and/or to provide diverse access for legitimate users. In general, these existing approaches fall well short of desired capabilities in several respects:

Responses to DDoS attacks are too slow and manually driven, with diagnosis and formulation of filtering rules often taking hours to formulate and instantiate. In contrast, DARPA-BAA-15-56 XD3 5 military communication often demands that disruptions be limited to minutes or less.

Low‐volume DDoS attacks remain exceedingly difficult to identify and block with in‐line detection techniques. Even for volumetric DDoS attacks, in‐line filtering can present daunting tradeoffs between the desire for complete blockage of malicious traffic and the need to “do no harm” to legitimate communication (i.e., maximizing true positives while minimizing false positives).

Mechanisms that rely on in‐line inspection of data flows may be problematic for handling encrypted tunnels, and pose scalability challenges as network bandwidths continue to increase.

Defensive methods must be applicable to real‐time, transactional services (such as military command and control) as well as to cloud computing. Techniques that are only useful for protecting the storage and dissemination of quasi‐static data are insufficient.

A clear need therefore exists for fundamentally new DDoS defenses that afford far greater resilience to these attacks, across a broader range of contexts, than existing approaches or evolutionary extensions thereto.

B. Program Description

The XD3 program considers three broad areas of opportunity to improve resilience against DDoS attacks, as summarized in Table 1. Each of these opportunities addresses a common aspect of current cyber infrastructure that inherently limits our ability to defend against DDoS attacks. In general, the program aims to thwart DDoS attacks by dispersing cyber assets (physically and/or logically), disguising the characteristics and behaviors of those assets, and mitigating the attacks (especially low‐volume attacks) that still penetrate the targeted environment. Each opportunity also constitutes a distinct XD3 program technical area. Section I.C provides additional information on program structure, including a full listing of all XD3 technical areas as well as constraints on BAA responses to each area.

DARPA-BAA-15-56 XD3 6

Table 1. XD3 focuses on three broad concepts for improving DDoS defenses.

These XD3 concepts have broad applicability to a variety of scenarios of interest to the US military and to the broader community, including commercial network service providers, cloud computing and storage service providers, and enterprises of all sizes. Accordingly, responses to this BAA may consider a wide range of possible network and service contexts, to include enterprise networks, wide‐area networks, wireless networks, cloud computing, and software‐ defined networks, among others. However, proposers must be clear about the specific context(s) in which their solutions are applicable, why these contexts are relevant, the critical assumptions underlying the chosen context and technical approach, the types of attacks that their solutions address, and the potential limitations of their approaches.

Solutions that have relatively broad applicability to a variety of network architectures and usage scenarios will be viewed favorably. For technical approaches that assume specific types of architectures or scenarios, proposals should specify the extent to which solution components are extensible to other cases (for example, virtualized versus physical networks and hosts;

wireless versus wired networks; or software‐defined networks versus those with conventional control and data planes).

Performers in Technical Areas 1‐3 will be responsible for devising and implementing their own project‐specific experimentation and demonstration capabilities. Proposers for these technical areas must include the following information in their submissions:

A description of the planned testing environment and how it will illuminate advances in DDoS defense capabilities relevant to their chosen TA and context during the course of the program.

A plan for conducting periodic demonstrations consistent with the notional program schedule shown in Section I.E.

Weakness of Current Art XD3 Concept Rationale and Impact

Concentrated locus of information and computing makes it easy to locate targets (data centers, servers)

Manageable Dispersion of Cyber Resources (Technical Area 1)

Spreads physical or logical locations of cyber resources to mitigate centralized points of vulnerability

Static, predictable behavior of targets facilitates attack planning and execution

Networked Maneuver (Technical Area 2)

Greatly increases attacker work factor in planning and executing focused DDoS;

can deflect DDoS in ways that minimize damage

Low-volume DDoS can hide in “noise” of ambient traffic, defeating in-line intrusion detection systems

Adaptive Endpoint Sensing and Response

(Technical Area 3)

Enables reliable detection, and point-of-attack mitigation, for low-volume DDoS attacks that find their targets

DARPA-BAA-15-56 XD3 7

A description of metrics to be used to assess the performance of their systems. Note that the development of these metrics itself may pose a significant technical challenge.

The scope of XD3 does not include the detection and mitigation of DDoS‐related malware (e.g., bot malware) on hosts or other networked devices. Proposals should assume that hosts and network elements within XD3 systems are trusted, and that other means are available for protecting these nodes from intrusion and compromise.

XD3 seeks truly innovative, revolutionary approaches to DDoS defense, as opposed to incremental or evolutionary advances to current art. Proposals must clearly articulate why their solutions represent a major advance over existing techniques.

C. Program Structure and Technical Areas

The XD3 program comprises the five technical areas (TAs) described below. Each proposal submitted in response to this BAA shall address only one TA, with the exception of TA4, which proposers must include as an optional effort in their proposals for TA1, TA2 or TA3. For example, a proposal may include TA1 and TA4, but not TA1 and TA2. Organizations may submit multiple proposals to any one technical area, or they may propose to multiple technical areas.

However, organizations performing in TA1, TA2, TA3 or TA4 cannot also be performers in TA5.

In addition, proposals for TA4 alone will not be accepted.

The overriding objective of the XD3 program is to produce the best possible technologies for enabling resilience against DDoS attacks. To this end, the Government intends XD3 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 (see Section VIII.C). This clause is intended to ensure appropriate coordination and potential integration of work done by the XD3 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 TAs, to ensure a full understanding of the program context, structure, and anticipated relationships among performers.

XD3 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 April 1, 2016. Proposals for TA1, TA2 and TA3 should provide plans for iteratively developing, testing, and refining their solutions throughout the entire three‐year program. Proposers may assume that TA4 activities will be limited to Phase 2 only.

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 XD3 program objectives.

DARPA-BAA-15-56 XD3 8

Strong proposals for TAs 1‐3 will include in their technical plans a high‐level concept of operation for the envisioned system. Points of interest include how users or administrators would interact with the system during operation, and a basic operational description explaining how developed components would interact with each other, both before attacks and in response to attacks.

Topics that are explicitly out of scope for the XD3 program include the following:

Techniques to detect malware in hosts or networks, or to defeat malware propagation

DDoS traceback mechanisms, or techniques for detection of DDoS‐related traffic within the network, unless proposals present such techniques as part of a broader, cohesive plan that directly addresses XD3 objectives in TA1, TA2 or TA3

Technical Area 1: Manageable Dispersion of Cyber Resources

In the current art, critical functions such as cloud computing, C2, situational awareness, and multimedia session control rely heavily on highly shared, centralized servers and data centers.

Existing protocols and architectures to support these functions include (among others) Internet Relay Chat (IRC), File Transfer Protocol (FTP), the military’s Global Command and Control System (GCCS), the Session Initiation Protocol (SIP), and implementations of MapReduce or related programming models within data centers. The concentrated loci of information and cyber capabilities within these architectures can greatly facilitate DDoS target development and attack execution. The goal of XD3 TA1 is to devise and demonstrate new architectures that physically and logically disperse these capabilities while retaining (or even exceeding) the performance of traditional centralized approaches.

Prior art has considered more‐distributed forms of some of the aforementioned functionality, such as peer‐to‐peer versions of session control1 and MapReduce computation2, as well as control of dispersed micro‐clusters.3 These concepts have not previously been considered as possible defenses against DDoS. Moreover, a major unaddressed challenge in such approaches is the full incorporation of network awareness into the formation and control of the distributed architecture. Highly variable bandwidths, congestion conditions, and the possibility of network attacks will substantially impact the connectivity and throughputs available between machines within these distributed architectures. These conditions stand in stark contrast to conventional treatments of cloud computing and peer‐to‐peer designs, which have generally taken reliable, high‐capacity connectivity for granted. For example, the selection of locations to perform tasks should incorporate knowledge of the task’s likely network requirements (e.g., does a computation require high‐capacity data transfer from specific locations, or between machines that will perform the computation?), as well as the mission’s tolerance to task completion delay

1 K. Singh and H. Schulzrinne, “Peer‐to‐peer Internet telephony using SIP,” Proc. NOSSDAV’05, June 13‐14, pp. 63‐ 2 F. Marozzo, D. Talia and P. Trunfio, “P2P‐MapReduce: Parallel data processing in dynamic Cloud environments,” J.

Computer and System Sciences, Vol. 78, no. 5, 9/2012, pp. 1382‐1402.

3 S. Wagner et al., “Autonomous collaborative control for resilient cyber defense,” Proc. 2012 SASO, Lyon, Sept. 10‐ 14, pp. 39‐46.

DARPA-BAA-15-56 XD3 9

or failure due to, e.g., adverse network conditions. In addition, the ability to replicate critical information (if required) among locations in the distributed architecture will also depend critically on network conditions; hence, the architecture must be robust to variable connectivity.

Solutions for TA1 that strongly support a broad range of capabilities and scenarios, including the ability to support interactive transactional services such as C2, will be viewed favorably.

Techniques that only support access to static content are discouraged.

TA1 proposals should describe the expected scalability of their technical approaches in terms of the number of hosts, the communications or computing capacities, or similar measures that are relevant to the contexts addressed. Proposals should also include metrics for assessing the effectiveness of the approach. Metrics of particular interest would include:

Measures of performance (e.g., utility, resilience) with respect to conventional baseline architectures, as a function of network conditions, both in the presence and absence of attacks

Measures of overhead associated with formation and control of the architecture

Technical Area 2: Networked Maneuver

The concepts of cyber agility and defensive maneuver (CAADM) have been well studied as means of complicating adversaries’ target development and attack execution. Many CAADM‐ related techniques have considered obfuscation within individual hosts, such as address space layout randomization (ASLR). Such host‐centric CAADM approaches are out of scope for XD3.

Network‐oriented approaches have largely been limited to techniques such as address and port hopping. In general, this prior art has suffered from four significant limitations:

Hopping approaches tend to create closed user groups (i.e., users and hosts that are privy to the hopping strategy), limiting their applicability and potentially interfering with access by legitimate users who are outside the group. More generally, any CAADM approach should have means of assessing its impact on user communication or computation, and offering assurance that such impacts can be minimized.

Maneuver plans are typically pre‐conceived, with no means for adapting it to the onset of attack or to major changes in mission activity. In the presence of these unforeseen conditions, static pre‐planned maneuvers may become counter‐productive, or even irrelevant, to mission needs.

Prior CAADM emphasis has predominantly focused on confusion and obfuscation of the environment to be protected. The potential for deception, in which CAADM establishes a false reality for the adversary, has been far less explored. In contrast to simple obfuscation, deception has the potential to divert attacks in ways that minimize damage to mission activities, while giving the adversary the illusion of success.

No means have been established for measuring CAADM effectiveness either before or during active maneuver. If the objective of the obfuscation is to reduce the amount of

DARPA-BAA-15-56 XD3 10

information that the adversary could obtain from observation of the target environment (or, in the case of deception, to provide the adversary with as much false information as possible about the environment), how can we quantify effectiveness and success, preferably both before and during on‐line operation?

The goal of XD3 is to develop new CAADM techniques that greatly improve resilience against DDoS attacks by overcoming the above limitations. Solutions to these problems may be closely related, and when viewed synergistically, could offer new flexibility in addressing DDoS threats.

For example, the ability to quantify CAADM effectiveness, together with measurements of the maneuver’s impact on legitimate user activities, would provide commanders or other network operators with the ability to trade one against the other, and to adapt this tradeoff to changing circumstances.

Applications and usage scenarios relevant to TA2 are similar to those listed for TA1, but are not limited to those examples. Proposals should explicitly state the types of applications and scenarios that their technical approaches can accommodate, and should identify suitable metrics for assessing progress during the course of the program. TA2 proposals should describe the expected scalability of their technical approaches in terms of the number of hosts, the communications or computing capacities, or similar measures that are relevant to the contexts addressed.

Topics that are out of scope for TA2 include wireless anti‐jamming approaches and other technologies that specifically focus on agility and maneuver within the physical, link, or network layers of wireless networks.

Technical Area 3: Adaptive Endpoint Sensing and Response

Low‐volume DDoS attacks can be highly effective in disrupting specific protocols and applications. Examples include shrew attacks4 against the retransmission mechanisms within the Transmission Control Protocol (TCP), and slowloris attacks against Web servers.

Conventional protocol operation typically assumes that all communicating participants adhere to a commonly accepted, mutually constructive set of behaviors (this assumption is, after all, inherent in the definition of “protocol”). Underlying protocol logic and state machines are typically not designed to deal with a wide range of potentially malicious actions, thus providing the opportunities that low‐volume DDoS attacks exploit.

The difficulty in detecting and mitigating such attacks with traditional in‐line intrusion detection mechanisms arises not only from the sparseness of the malicious traffic, but also from the fact that the traffic’s impacts may be readily observable only within the contexts of the hosts that they target (e.g., seemingly benign and protocol‐compliant messages that lead to exhaustion of CPU or memory).

4 A. Kuzmanovic and E. Knightly, “Low‐rate TCP‐targeted denial of service attacks: the shrew vs. the mice and elephants,” Proc. 2003 SIGCOMM, pp. 75‐86.

DARPA-BAA-15-56 XD3 11

XD3 TA3 aims to infuse potential DDoS targets, such as servers, with the ability to sense that they are under attack, and to adapt their operation in real time to mitigate the attack.

Potential approaches of interest within TA3 include, but are not limited to, the following:

Instrumentation of host kernel and application programs

Correlation of state (CPU, memory, queues) with input/output activity

Adaptation of host operation (e.g., state machines, protocol logic) on the fly to mitigate perceived attacks

Sharing of information among hosts to decide collectively whether attacks have occurred, and/or to determine what mitigations might be most effective

The XD3 TA3 vision poses at least two significant challenges. The first challenge is to ensure that any instrumentation placed on hosts for purposes of identifying DDoS attacks, as well as any subsequent adaptation of host behavior, does not significantly interfere with the operation of applications and protocols under normal (non‐attacked) operating conditions. The TA3 goal is to limit such interference to no more than 1% degradation in relevant performance measures, such as throughput or latency. At the same time, DARPA recognizes that tradeoffs may exist between the effectiveness of DDoS defense and potential performance penalties that might result from the presence of such defensive measures during non‐attacked conditions.

Technical plans that illuminate and quantify such tradeoffs are encouraged.

The second challenge is to enable rapid convergence to an effective mitigation following the onset of attack. TA3 end‐of‐program goals include a response time of 10 seconds or less, and at least a 90% recovery in application performance compared with hosts that do not have XD3 capabilities. DARPA recognizes that both the response time and percent recovery will depend on the nature and severity of attacks; hence, proposers should regard these goals as high‐level objectives that may be revisited during the course of the program.

Strong TA3 proposals will include examples and substantiated estimates of the levels of degradation and response times that could be achieved for specific DDoS attacks. TA3 proposers are encouraged to identify additional metrics that would illuminate the effectiveness of mitigation strategies. XD3 will not require support for any specific server operating system, but proposals should specify what operating systems will be included in their experimental plans.

In addition, strong TA3 proposals will offer solutions with relatively broad applicability across multiple protocols, applications, and the low‐volume DDoS attacks that could target them.

Proposals should state and justify the expected range of applicability.

Technical Area 4: Technology Integration

During XD3 Phase 1, the Government will identify potentially synergistic technologies from TA1, TA2 and TA3 for possible integration activities during Phase 2. The program will refer to these Phase 2 activities as TA4. Prior art has rarely considered useful combinations of the concepts

DARPA-BAA-15-56 XD3 12

from TAs 1‐3 as a means of mitigating DDoS attacks (for example, the combination of networked maneuver with adaptive endpoint sensing to provide coordinated response to DDoS events); hence, TA4 provides a further opportunity for XD3 to achieve a considerable advance over previous defensive approaches.

Proposers to TA1, TA2 or TA3 must include a TA4 Integration Concept description in their proposals (see Section IV.B). This description should provide a vision for how the technology being proposed for TA1, TA2 or TA3 might synergistically work with technologies and concepts from the other two TAs. The Government recognizes that this initial vision will be hypothetical due to the inability to predict the specific technologies that other XD3 performers will produce.

Proposers to TA1, TA2 or TA3 must also include an optional effort for TA4 in their statements of work and cost proposals for Phase 2 of the program, consistent with their TA4 Integration Concept descriptions. If necessary, the Government will execute change orders during the program to cover more‐specific work statements associated with TA4, for those performers who are selected to participate in these activities.

Technical Area 5: Voice of the Offense

XD3 TA5 performer(s) will be responsible for periodically reviewing system designs and testing plans for performers in TA1, TA2 and TA3. The objective of design reviews is the proactive identification of weaknesses and vulnerabilities that would reduce the effectiveness of DDoS attack detection or mitigation. The objective of test plan reviews is to identify shortcomings in test scenario design, metrics, assumptions, and scope, as well as to apprise performers of potential DDoS attack methods or features that they might not have considered.

Given that XD3 seeks truly revolutionary technologies for DDoS defense, TA5 performer(s) generally cannot expect to obtain detailed software documentation or algorithmic descriptions from other TAs early in the program. Similarly, the timelines for availability of detailed data will vary among performers in other TAs depending on the progress and maturity of their technical approaches. TA5 performers must therefore be prepared to rely on relatively informal means of analysis adapted to the technical plans and progress of other program participants, especially in early stages of the program.

TA5 performer(s) will furnish the Government with a report on their reviews for each performer within TA1, TA2 and TA3 at least every six months throughout the program’s three‐year duration. For costing purposes, proposals for TA5 can assume three performers for each of these three TAs.

In addition, TA5 performer(s) should perform similar review functions for combinations of technologies to be integrated within TA4 during Phase 2. For costing purposes, TA5 proposals can assume two distinct, parallel integration efforts within TA4.

Proposals for TA5 should illustrate detailed knowledge of DDoS attack methodologies, including both volumetric and low‐volume DDoS, as well as a clear understanding of existing DDoS defenses and their limitations. In light of TA3’s emphasis on host‐based mitigation, TA5

DARPA-BAA-15-56 XD3 13

proposals should also reflect knowledge of how low‐volume attacks affect operation of common protocol stacks, state machines, and associated applications that would use such mechanisms.

D. Optional Program Field Exercises

The XD3 program schedule (see Section I.E below) includes field exercises near the end of Phase 1 and Phase 2. The purpose of these exercises is to showcase promising XD3 technologies to potential transition partners, and to elicit feedback from these partners concerning features and capabilities that are under development. During both XD3 phases, the Government will identify candidate performers to participate in these exercises based on the technical progress of their respective projects and the degree of interest from transition partners.

Proposals for TA1, TA2, TA3 and TA5 should include two separate, optional efforts (one for the end of each phase) associated with possible participation in XD3 field exercises. The exact nature, dates and locations of these exercises will not be determined until after XD3 program commencement. Given this uncertainty, proposals should reflect a nominal two‐week effort by two personnel, along with associated travel, to San Diego, CA.

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 April 1, 2016. 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.

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

Program Phase

Fiscal Year

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

Proposed Test Plans

TA Component Expts

System Expts

Integration Plan

Voice of Offense Evals

Field Exercises

Phase 2Phase 1

16 17 18 19

DARPA-BAA-15-56 XD3 14

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.

DARPA-BAA-15-56 XD3 15

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 and/or 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 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-56 XD3 16 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 may be met by proposers intending to perform fundamental research. The Government does not anticipate applying publication restrictions of any kind to individual awards for fundamental research that may result from this BAA. Notwithstanding this statement of expectation, the Government is not prohibited from considering and selecting research proposals that, while perhaps not qualifying as fundamental research under the foregoing definition, still meet the BAA criteria for submissions. If proposals are selected for award that offer other than a fundamental research solution, the Government will either work with the proposer to modify the proposed statement of work to bring the research back into line with fundamental research or else the proposer will agree to restrictions in order to receive an award.

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

DARPA-BAA-15-56 XD3 17

Information: type (e.g., conference, principal investigator meeting, article or paper), date, 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/work-with-us/contract-management/public-release for further information about DARPA’s public release process.

DARPA-BAA-15-56 XD3 18

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 U.S.C. § 3710a to be sufficient legal authority to show eligibility. For some entities, 10 U.S.C. § 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 U.S.C. §§ 203, 205, and 208). Prior to the start of proposal evaluation, the Government will assess potential OCIs and will promptly notify the proposer if any appear to exist. The Government assessment does not

DARPA-BAA-15-56 XD3 19

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). All facts relevant to the existence or potential existence of OCIs must be disclosed. The disclosure shall include a description of the action the proposer has taken or proposes to take to avoid, neutralize, or mitigate such conflict. If, in the sole opinion of the Government after full consideration of the circumstances, a proposal fails to fully disclose potential conflicts of interest and/or any identified conflict situation cannot be effectively mitigated, the proposal will be rejected without technical evaluation and withdrawn from further consideration for award.

If a prospective proposer believes a conflict of interest exists or may exist (whether organizational or otherwise) or has a question as to what constitutes a conflict, a summary of the potential conflict should be sent to XD3@darpa.mil before preparing a proposal and mitigation plan.

C. Cost Sharing/Matching

Cost sharing is not required; however, it will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument (e.g., OTs under the authority of 10 U.S.C. § 2371).

D. Other Eligibility Requirements

1. Ability to Receive Awards in Multiple Technical Areas ‐ Conflicts of Interest

While proposers may submit proposals for all XD3 Technical Areas, performers in TA5 cannot also be performers for any portion of other TAs, whether as a prime, subcontractor, or in any other capacity from an organizational to individual level. This is to avoid OCI situations between the TAs and to ensure objective test and evaluation results. The decision as to which proposal to consider for award is at the discretion of the Government.

2. Ability to Support Classified Activities

At the time of proposal submission, all proposers wishing to submit proposals under TA5 must have personnel with a TOP SECRET clearance. TA5 proposers must provide their CAGE code and security point(s) of contact in their proposals.

Proposers to other XD3 technical areas are not required to hold or obtain security clearances;

however, these performers may require personnel with a SECRET clearance to participate in field exercises. Proposers to these other technical areas who wish to have access to

DARPA-BAA-15-56 XD3 20

classified data in support of field exercises (should they be selected to participate in such exercises) must have personnel and access to facilities with a minimum classification level of SECRET at the time of award, and must provide their CAGE code and security point(s) of contact in their proposals.

DARPA-BAA-15-56 XD3 21

IV. APPLICATION AND SUBMISSION INFORMATION

A. Address to Request Application Package

This document contains all information required to submit a response to this solicitation. No additional forms, kits, or other materials are needed except as referenced herein. No request for proposal (RFP) or additional solicitation regarding this opportunity will be issued, nor is additional information available except as provided at the Federal Business Opportunities website (https://www.fbo.gov), the Grants.gov website (http://www.grants.gov/), or referenced herein.

B. Content and Form of Application Submission

1. Proposals

Proposals consist of Volume 1: Technical and Management Proposal (including mandatory Appendix A and optional Appendix B) and Volume 2: Cost Proposal.

All pages shall be formatted for printing on 8‐1/2 by 11‐inch paper with 1‐inch margins, single‐line spacing, and a font size not smaller than 12 point. Font sizes of 8 or 10 point may be used for figures, tables, and charts. Document files must be in .pdf, .odx, .doc, .docx, .xls, or .xlsx formats. Submissions must be written in English.

Proposals not meeting the format prescribed herein may not be reviewed.

a. Volume 1: Technical and Management Proposal

The maximum page count for Volume 1 is 32 pages, including all figures, tables and charts but not including the cover sheet, table of contents or Appendices A and B. A submission letter is optional and is not included in the page count. Appendix A does not count against the page limit and is mandatory. Appendix B does not count against the page limit and is optional. Additional information not explicitly called for here must not be submitted with the proposal, but may be included as links in the bibliography in Appendix B. Such materials will be considered for the reviewers’ convenience only and not evaluated as part of the proposal. Proposals should be self‐contained and not rely on the referencing of other materials to explain or justify their technical approaches. Volume 1 submissions should strive for brevity and clarity.

Volume 1 must include the following components:

i. Cover Sheet: Include the following information.

Label: “Proposal: Volume 1”

BAA number (DARPA‐BAA‐15‐56)

Technical Area(s) Proposal title Lead organization (prime contractor) name

Type of organization, selected from the following categories: Large Business, DARPA-BAA-15-56 XD3 22

Small Disadvantaged Business, Other Small Business, HBCU, MI, Other Educational, or Other Nonprofit

Technical point of contact (POC) including name, mailing address, telephone, and email

Administrative POC including name, mailing address, telephone number, and email address

Award instrument requested: procurement contract (specify type), cooperative agreement or OT.5

Place(s) and period(s) of performance

Other team member (subcontractors and consultants) information (for each, include Technical POC name, organization, type of organization, mailing address, telephone number, and email address)

Proposal validity period (minimum 120 days)

Data Universal Numbering System (DUNS) number6

Taxpayer identification number7

Commercial and Government Entity (CAGE) code8

Security POC including name, mailing address, telephone number, and email address (TA5 proposers or as applicable)

Proposer’s reference number (if any)

ii. Table of Contents

iii. Executive Summary: Provide a synopsis of the proposed project, including answers to the following questions:

What is the proposed work attempting to accomplish or do?

How is it done today, and what are the limitations?

What is innovative about the proposed work?

What will be the impact if the work is successful?

How much will it cost, and how long will it take?

The executive summary should include a description of the key technical challenges, a concise review of the technologies proposed to overcome these challenges and achieve the project’s goal, and a clear statement of the novelty and uniqueness of the proposed work.

5 Information on award instruments can be found at http://www.darpa.mil/work‐with‐us/contract‐management.

6 The DUNS number is used as the Government's contractor identification code for all procurement‐related activities. Go to http://fedgov.dnb.com/webform/index.jsp to request a DUNS number (may take at least one business day). See Section VI.B.8 for further information.

7 See http://www.irs.gov/businesses/small/international/article/0,,id=96696,00.html for information on requesting a TIN. Note, requests may take from 1 business day to 1 month depending on the method (online, fax, mail).

8 A CAGE Code identifies companies doing or wishing to do business with the Federal Government. See Section VI.B.8 for further information.

DARPA-BAA-15-56 XD3 23

iv. Goals and Impact: Describe what the proposed team is trying to achieve and the difference it will make (qualitatively and quantitatively) if successful. Describe the innovative aspects of the project in the context of existing capabilities and approaches, clearly delineating the uniqueness and benefits of this project in the context of the state of the art, alternative approaches, and…