HR001120S0026.pdf

Broad Agency Announcement Open Programmable Secure 5G (OPS-5G)

HR001120S0026

January 30, 2020

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

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 2

Table of Contents Part I: Overview Information……………………………………………………………………...………3

Part II: Full Text of Announcement………………………………………………………………………..5

I. Funding Opportunity Description

II. Award Information

A. Awards

B. Fundamental Research

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

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

D. Associate Contractor Agreement (ACA)

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 3

PART I: OVERVIEW INFORMATION

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

Funding Opportunity Title: Open Programmable Secure 5G (OPS-5G)

Announcement Type: Initial Announcement

Funding Opportunity Number: HR001120S0026

Catalog of Federal Domestic Assistance Numbers (CFDA):

12.910 Research and Technology Development

Dates o Posting Date: January 30, 2020 o Proposal Due Date: March 17, 2020, 12:00 noon (ET) o Proposal Closing Date: March 17, 2020, 12:00 noon (ET) o Proposers Day: January 7, 2020

Types of Instruments that May be Awarded: Procurement contracts, cooperative agreements or Other Transactions

Agency Contacts o Technical POC: Jonathan M. Smith, Program Manager, DARPA/I2O o BAA Email: Ops-5G@darpa.mil o BAA Mailing Address:

DARPA/I2O

ATTN: HR001120S0026

675 North Randolph Street Arlington, VA 22203-2114 o I2O Solicitation Website: http://www.darpa.mil/work-with-us/opportunities mailto:Ops-5G@darpa.mil http://www.darpa.mil/work-with-us/opportunities

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 4

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

DARPA is soliciting innovative research proposals in the area of open source software and systems enabling secure 5G and follow-on mobile 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 Broad Agency Announcement (BAA) is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016.

Any negotiations and/or awards will use procedures under FAR 15.4 (or 32 CFR § 200.203 for grants and 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 posts BAAs on the System for Award Management, Contract Opportunities (Beta.Sam.Gov) website (https://beta.sam.gov/) and, when applicable, the Grants.gov website (https://www.grants.gov/).

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

Introduction/Background Ubiquitous mobile networking has been transformative, with impacts that pervade our daily lives. Captured data is aggregated, analyzed, and shared, typically via Internet applications using cloud computing and storage resources. Virtualization has made this approach very cost-effective.

Step 1989 2019 Contact friends Multiple phone calls Social network messaging Choose restaurant Yellow pages, local newspaper, travel guide Consult reviews on restaurant rating web sites

Estimate travel time Map, time of day, history Consult online map service Travel to restaurant Arrange rides, etc. Ride-sharing Application Delayed? Annoyance, late seating Share with instant messaging Seating Stand in line Alert with text message Payment Cash, check, credit card Payment Application Rate restaurant Letter to manager Post review to rating site

Table 1: Mobile Networking Transforms Lifestyles

Today, user equipment (UE) on mobile networks is dominated by smartphones, tablets, and laptops. These “edge devices” access network services such as localization on an as-needed basis. UE access to web services is via one or both of 802.11x-based WiFi and cellular.

Limitations on radiated energy, shadowing and absorption by building materials, irregular deployment, and varying enterprise-specific policies limit WiFi’s use as a public network.

https://beta.sam.gov/

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 5

5Gi is the latest in a series of evolutions in public mobile networking, with widespread coverage and access on a subscription basis. 5G networks are characterized by improved capabilities across a variety of measures, including throughputs, latencies, numbers of devices, and battery life. 5G is used to attach small special purpose devices comprising the Internet of Things (IoT) to the Internet, and the important and growing number of services provided by the World Wide Web. IoT devices are often sensors, and 5G access to their data is envisioned to play important roles in medicine, manufacturing, and smart cities.

Core network features to support new applications are also present, ranging from network slicing to support for programmable networks. Support for programmability may include software-defined network (SDN)ii switches, network function virtualization (NFV) nodes, and many-core data plane processing devicesiii. The combination of customized virtual infrastructures and programmability permits customization at a wide variety of network locations.

The 5G networking agenda demands massive investment, not least in infrastructure such as switches, radio equipment, real estate, swathes of provisioned radio spectrum, as well as a prodigious amount of software. Equipment vendors, mobile network operators, Internet companies, entrepreneurs, device retailers, and national governments thus have a keen focus on the evolution of the 5G network ecosystem.

Standards processes are used to maintain interoperability required for a public network, and while many of the components and component behaviors of 5G have changed little from predecessors such as 4G and LTE, the standards for the most futuristic 5G features are those most in fluxiv. These futuristic features also present the greatest risk to US national securityv, as networks are simultaneously critical infrastructure and the means used for cyberespionagevi and cyberwarfare.

DARPA’s Open, Programmable, Secure 5G (OPS-5G) will address this risk by pursuing research leading to development of a portable standards-compliant network stack for 5G mobile that is open source and secure by design.

Program Description/Scope OPS-5G will create open source software and systems enabling secure 5G and subsequent mobile networks such as 6G. The signature security advantage of open source software is increased code visibilityviiviii, meaning that code can be examined, analyzed and audited, either manually or with automated tools. In addition, the portabilityix of open source serves, as a desired side-effect, to decouple the hardware and software ecosystems. This significantly raises the difficulty of a supply-chain attack and eases the introduction of innovative hardware into the market.

Programmability must be implemented and managed carefullyx to achieve its potential benefits.

Such benefits include bespoke networks that are tuned to application needs, as well as increased network adaptation capabilities. Programmability must also be developed in ways that avoid rampant opportunities for misuse. Ideally, the introduction of programmability for 5G will incorporate lessons learned from the well-intentioned introduction of programmability into web browsers, a capability that quickly became weaponized by malicious actors.

OPS-5G aims to improve overall 5G security. OPS-5G changes are focused on increasing trust at a set of soft points that include unmanaged, unattended, long-lived, and possibly long-forgotten

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 6

IoT devices. Additionally, OPS-5G addresses unintended and unwanted interactions between network slices and threats from the vast increases in network scale.

OPS-5G’s strategic vision of mobile networking’s future is shown in Figure 1.

Figure 1: OPS-5G augments Open Source Software to obtain a secure 5G system (red: non- US; blue: US; green: OPS-5G)

Technical Areas and Program Structure Challenges addressed by OPS-5G’s Technical Areas (TA) are:

(1) Decreasing the time required for updates to OPS-5G open source software in response to new versions of the 5G standards;

(2) Achieving a usable scalable “zero-trust”xi security architecture for devices ranging from IoT sensors to servers. The architecture should have a minimal impact on size, weight and power (SWaP), and price;

(3) Mitigating new attack surfaces (such as side-channels) introduced by virtualization and slicing; and

(4) Changing programmability from a threat vector to an enabler of security at scale.

Proposers are encouraged to survey the research literature for approaches that provide differentiating value for the OPS-5G network. An example of this might use cryptographic markers or other techniques found in the network security literature to provide cryptographic proof that a path through the network was takenxii. Exploitation of such techniques should be explicitly identified and referenced in the proposal. Advantages of the proposed work over prior approaches as well as possible risks must be discussed.

Proposers must indicate any assumptions that may limit the applicability of their solutions.

Proposers should concisely (1/2 page limit) state a “Plan B” to overcome project risks when unmet assumptions emerge.

In cases where a proposed approach requires programmability features such as network function virtualization (NFV) or software-defined networking (SDN) offered or under development by open source consortia, proposers must justify the feasibility of the deployment timeline.

As the ultimate objective for each of the technical areas (see Figure 2) is to create open-source software to be incorporated into an open source code base, any tools, methods, processes, and prototypes must be accepted by and work seamlessly in the open source 5G environment. OPS- 5G performers are encouraged to view technology transition as a continuous process underway at all times during their period of performance.

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 7

Figure 2: OPS-5G Research Results Transition to Deployable 5G Software

Proposers should detail how their research results will be inserted into typical software development processes used by an open source consortium contributing to the open source network stack. Proposers are expected to produce working prototypes that will operate within an open source consortium’s ongoing 5G network development efforts.

Proposers should include time and costs for interacting with an open source consortium in their cost proposals, as the deployment of OPS-5G results via an open source consortium’s networking stack is an essential element of the OPS-5G program.

Program Structure

OPS-5G is a 4-year program organized into three phases – two 18-month phases followed by a 12-month phase.

Proposals should encompass all three phases under a single, four-year effort and a nominal start date of October 1, 2020. Proposals should provide plans for iteratively developing, testing, and refining their TA1, TA2, TA3, and TA4 technologies throughout the entire four-year program.

Proposals must address only one TA, but there are no restrictions on the number of proposal submissions. Any combination of TAs (e.g., TA1 and TA4, or TA2, TA3, and TA4) may be awarded to the same proposer. If a proposer submits to multiple TAs, a discussion of the potential synergies between the proposal and the other submissions from the proposer should be included in the cost volume.

To support collaboration and the development of technology and systems in the OPS-5G program, performers will have an Associate Contractor Agreement (ACA) clause or similar language included in their award (see Section VIII.D). The ACAs are intended to ensure appropriate coordination and potential integration of work done by program performers.

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 8

Technical Area 1: Standards Meet Software

Open-source software development typically lags commercial software development because of the portable nature of open-source software, which requires the definition and software implementation of a hardware abstraction layer (HAL). This open-source versus commercial software disparity in “feature velocity” inhibits open-source software deployment in fast-paced markets (Figure 3). OPS-5G TA1 will focus on accelerating open source software development with machine translation of 5G standards documents. 5G standards are maintained online as a set of electronic documents and updated as needed. As operational 5G software must be standards compliant, updates in standards spur new software development.

Figure 3: Today, hardware-independent open source code development often takes longer

The high degree of structurexiii xivxv present in these standards documents enables machine extraction of information relevant to software implementations including software structure, service interfaces, timing parameters, flow diagrams, and protocol graphs. This extracted information provides a foundation for automated compliance testing, partial proofs of correctness, protocol execution integrity checks, and other critical aspects of software development.

Accurate translation to a domain-specific intermediate form (such as frames) or a domain-specific language can feed a series of refinement steps that can accelerate production of correct software as well as improve responsiveness to standards updates. In addition to code generation, such representations are useful for tools such as theorem provers, control flow enforcement tools, compilers, etc.

The Independent Test and Evaluation (ITE) and TA1 teams will collaborate to define a sufficiently powerful and flexible formal representation for 5G standards. The ITE team will provide a ground-truth translation of these natural language documents into the representation, and TA1 performers will be evaluated on their ability to accurately translate from natural language (NL) standards documents.

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 9

Accuracy will be assessed via precision and recall as follows:

Precision = Recall =

|{𝐺𝑇} ⋂ {𝑇𝐴1.𝑇𝑒𝑎𝑚𝑋}|

|{𝑇𝐴1.𝑇𝑒𝑎𝑚𝑋}|

|{𝐺𝑇} ⋂ {𝑇𝐴1.𝑇𝑒𝑎𝑚𝑋}|

|{𝐺𝑇}|

where and|{𝑇𝐴1.𝑇𝑒𝑎𝑚𝑋}| = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑐𝑙𝑎𝑢𝑠𝑒𝑠 𝑡𝑟𝑎𝑛𝑠𝑙𝑎𝑡𝑒𝑑 𝑏𝑦 𝑡ℎ𝑒 𝑇𝐴1 𝑡𝑒𝑎𝑚, |{𝐺𝑇}| = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑐𝑙𝑎𝑢𝑠𝑒𝑠 𝑡𝑟𝑎𝑛𝑠𝑙𝑎𝑡𝑒𝑑 𝑏𝑦 𝑡ℎ𝑒 𝐼𝑇𝐸, 𝑎𝑛𝑑

|{𝐺𝑇} ⋂ {𝑇𝐴1.𝑇𝑒𝑎𝑚𝑋}| =

𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑚𝑎𝑡𝑐ℎ𝑖𝑛𝑔 𝑔𝑟𝑜𝑢𝑛𝑑 𝑡𝑟𝑢𝑡ℎ 𝑎𝑛𝑑 𝑇𝐴1 𝑡𝑒𝑎𝑚 𝑐𝑙𝑎𝑢𝑠𝑒𝑠.

Proposers should make clear how their process of translating or extracting information from a standards document will accelerate production of correct source code or systems elements that will contribute to a faster, more robust software infrastructure for 5G.

Capabilities of interest in TA1 include:

(1) Extracting interface descriptions used in interactions between modules and services;

(2) Extracting descriptions of interactions that describe protocols in whole or in part;

(3) Extracting parameters, such as throughputs, object sizes and delay bounds; and

(4) Extracting other features from 5G standards, such as options and error handling, when they are specified; these can be used to provide additional validationxvi of interactions between network elements and services that form the basis of the 5G software components in the core and mobile edge architecture.

Proposers may propose solutions that:

(1) Exploit in-network data plane processing;

(2) Result in fragments of code written in either a detailed domain specific language intended to be translated into an executable form; or

(3) Include translation directly to fragments of a target source language such as C, C++ or

Java.

Other useful results related to code fragment inference are the generation of self-documenting code: generating in-line comments attached to the code fragments, along with the standards text from which the comments and code were derived. Such research may identify promising directions for further automation, such as building associations amongst code and related natural language to aid the generation of new or revised standards documents that are tightly bound to working software.

Technical Area 2: Cross-scale 5G node and network security

5G will drive substantial growth in networked devices. The size, weight, and power (SWaP) characteristics of such devices will vary tremendously, ranging from tiny battery-powered Internet of Things (IoT) sensors to substantial computing systems. The goal of TA2 is to develop techniques and security architectures enabling security at scale across devices with widely disparate SWaP.

A security architecture provides methods to preserve desired levels of confidentiality, integrity, and availability across the set of systems spanned by the architecture. On larger platforms, such

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 10

as those in the 5G core, services, protocols, hardware support, and administrative resources are available to detect and remediate problems. IoT devices, on the other hand, may be severely resource-constrained (e.g., battery-operated), cost-limited, and unattended, while meeting mission requirements for multi-year operational lifetimes. Improvements in processing time and battery life from low-cost hardware supportxvii for security primitives such as in-silico entropy sources and encryption, as well as those required for roots of trust such as Trusted Platform Modules (TPMs)xviii, Titanxix, Subscriber Identity Modules (SIMs)xx and e-SIMsxxi, have resulted in their presence in many microcontroller and microprocessor systems. Given needs such as trusted initialization of a nodexxii, TA2 submissions must identify hardware support presumed by their proposed solutions. If your proposal requires embedded hardware to meet OPS-5G TA2 objectives for performance and energy efficiency, it must provide comparisons of the performance versus a pure software solution, as well as estimated impacts on hardware production costs.

Adding a new, networked devicexxiii to a household with many existing devices, such as security cameras, shows the need for cross-scale security approaches. Starting from a basis of zero trustxxiv (“the network cannot be trusted”), a zero trust architecture is based upon the principle of least privilegexxvxxvi. Roots of trust, as described above, may be used; proposers are encouraged to avoid overdependence on their presence. As trust is established amongst nodes, the network security architecture can then bind devices together using delegated authoritiesxxvii to control their roles (e.g., by not sharing security camera outputs with unauthorized users). IoT devices may be bought, sold, loaned, and relocated; thus solutions must remain secure in both long-term emplacements and in situations where trust relationships are dynamic and short-lived.

To be successful, proposers to TA2 must describe and justify security architectures that operate across all scales of nodes and networks, minimizing use of 5G core network services, and maximizing use of mobile edge computing (MEC) to avoid performance bottlenecks from shared central services. Architectures should support low-cost, unattended, long-lived, battery-powered sensors, which will be the smallest, cheapest, and most numerous devices in the 5G ecosystem.

Of particular relevance are cryptographic operations, which typically demand high levels of power. The TA2 metric is cost-effective security; costs are measured using battery life relative to a baseline as a metric for SWaP. The Government will use penetration test scores devised by the Government Independent Test and Evaluation (ITE) team to gauge network and device security.

Technical Area 3: Secure slices

The performance requirements of mobile networks vary by customer and use. For example, video streaming demands completely different latency, bandwidth, and delay variability (jitter) than tele-operation. Playback of stored video can overcome the majority of timing challenges using an elastic buffer at the user device, while interactive tele-operation cannot tolerate the delays inherent in playback from a large buffer. Thus, a 5G network slice intended for content distribution must be provisioned differently than a slice used for tele-robotic surgery.

Network slicing overlays virtual networks across multiple enterprises, and thus may use infrastructure that is untrustworthy, under-provisioned or even adversarial (Figure 4). Slice virtualization security risksxxviii thus include timing side-channelsxxix used to extract information from activities occurring in co-resident slices.

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 11

Figure 4: Network Infrastructure; Trusted (Blue), Untrusted (Red)

OPS-5G TA3 approaches can base slice-provisioning decisions on priority, soft or hard real-time capabilities at nodes, allocation of resources such as pinned memory pages, etc. System-levelxxx and network-level slice isolation approaches include routing to minimize use of shared or untrusted resources (e.g., by purposeful route separation) as the slice is provisioned. Once policies are able to shape selection of physical components for the slice, more aggressive “moving target”-inspired periodic re-routing using programmable networks is also possible.

Assessments of integrity using remote attestation can be used in route setup or when re-routing to detect and avoid use of suspect devices. Techniques such as the ICINGxxxi approach used in the NEBULA Future Internet Architecturexxxii can be used to prove an intended path was taken.

The TA3 metric is capacity. Side-channels, like covert channels, are impossible to eliminate completely. Reducing the side channel capacity is a measure of the effectiveness of performer solutions in isolating a “secure slice” from co-located slices that might be used by adversaries to extract information leaked, for example by accidental cache pollution. The capacity measure is solution-agnostic, and proposers may suggest additional metrics or milestones.

Obtaining information from a side-channel requires knowledge of its presence and a means of extracting information from it. The OPS-5G ITE team will specify the means for determining the capacity metric in bits per second (see Table 2). As an imaginative adversary might use novel or unknown methods for extracting information, ITE’s assessment of the capacity metric will be limited to the benchmarks and techniques developed or adopted for use in the OPS-5G program.

TA3 proposers should provide a clear and explicit threat model. The proposed solution and plan should be tied to the threat model.

TA3 proposers should make clear any assumptions about technologies provided by the other technical areas that they may have in their proposed research. For example, if particular cryptographic signature primitives are necessary for hashing or supporting challenge-response remote attestation protocols must be present in all nodes comprising a secure slice, this is a strong presumption; thus, it should be clearly and explicitly stated. Similar assumptions would

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 12

include those regarding availability and performance of cryptographic security primitives from TA2 at a selected number of nodes (e.g., the elements of a mobile edge cloud). Additional examples of such assumptions include:

(1) That awareness of node hardware provenance is available;

(2) That awareness of code bases running in the network elements may be available; or

(3) That this information is itself trustworthy (e.g., that no spoofing has occurred).

If the performance of a proposed TA3 solution depends on the availability of specific fractions of nodes with hardware roots of trust, encryption support or other technologies, this must be clearly and explicitly stated for evaluating the proposal.

TA3 approaches may also include so-called “moving target” defenses, where the network infrastructure is periodically altered as a method of blunting attacks and information extraction.

If such an approach is used, proposers must clearly and explicitly state the expected effects on analysis of the capacity metric used by the ITE to evaluate TA3. For example, if a degree of redundancy in network paths is necessary for slice provisioning or re-provisioning in a TA3 solution, that expectation must be clearly stated. Measures of redundancy, such as average or minimum in-degree or out-degree for graph nodes, should be clearly and explicitly stated by proposers. Additionally, the risk if the assumption is not met must also be discussed.

TA3 proposers may build combinations of techniques; such combinations may derive their primitives from either programmability or cryptographic capabilities but should be focused on breakthrough approaches leading to secure slices.

Technical Area 4: Principled programmable defenses

Technologies such as Network Function Virtualization (NFV), Software Defined Networking (SDN), etc., allow customization of networks by injecting code on-demand to meet evolving sets of requirements. Accelerating network evolution is a central goal of OPS-5G as well. OPS-5G’s ability to evolve is achieved via use and management of SDNs, NFVs, and emerging data plane capabilities.

The consequences of introducing programmability with insufficient attention to malicious actors and their capabilities is illustrated by the addition of scripting languages to web browsers.

Initially intended to customize local behavior of downloaded Web content for presentation by a web browser, the execution of programs of unknown provenance has opened hosts to a multiplicity of security threats. OPS-5G’s TA4, Principled programmable defenses, seeks to develop techniques that use programmability, and the resulting network adaptability, as a means to increase security. In particular, TA4 focuses on (1) innovative approaches leveraging programmability to ensure that in-network code is trustworthy; and (2) concrete demonstrations of programmable networking’s advantages for network defense.

Proposers should propose novel solutions to address the challenges of:

(1) Generating and signing trustworthy code for programmability for in-line network devices;

(2) Generating and signing trustworthy code for SDN switches;

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 13

(3) Full or partial verification of code for virtual network functions (VNFs) in NFV; and

(4) Preserving integrity of the code between verification and execution.

Approaches of particular interest include:

(1) Use of programming languages and programming language techniques including strong typing, proof carrying codexxxiii and theorem provers;

(2) Use of system-level integrity protectionsxxxiv achieved, for example, through cryptographic operations and cryptographic protocols; and

(3) Processes for deploying new functionality in defensive nodes; these might entail use of a special purpose programming languagexxxv and creation of tools to verify software written in a conventional programming language that can then be cryptographically signed and hashed in order to provide integrity protections.

Ultimately, the goal of TA4 is to maintain availability of the 5G infrastructure and its services in spite of active threats to its availability by malicious actors, and to use the programmable elements of the OPS-5G infrastructure to defend against compromised elements outside the control of the OPS-5G software. TA2 will provide a network security architecture that makes injection and propagation of malware within the IoT very difficult. However, devices that are not compliant with TA2’s models may in fact be compromised and turned to malice, e.g., the aggregation of a titanic “botnet of things”. It is such threats that TA4 solutions must defend against.

TA4 proposers should plan to design and prototype a scalable Distributed Denial of Service (DDoS) defense for 5G networks (see Table 2). Approaches to defending against DDoS attacks can include packet dropping, queuing and other techniques for policing the behavior of the network with programmable defenses. TA4 submissions may propose additional defensive applications to demonstrate the generality of a proposed approach; each additional application must be proposed as a separate extra-cost option.

Examples of additions include auxiliary protocol graphs extracted from systems that can test interactions within the distributed systems being defended. These graphs could be used to place various fault-testing code at observation points that would be embedded in the network infrastructure. For example, programmable defenses might identify themselves with cryptographic tokens and may also be used to provide an index of behavioral properties that could be used to check the application behavior as evidenced by packet flows in the network.

This class of approach has the virtue that it can be used for self-checking and in addition, detection of malicious behavior.

TA4 proposals must include a specific demonstration of the efficacy of the proposed general approach to exploiting programmability as a defensive capability. TA4 proposals must include plans to evaluate proposed solutions on a challenge problem, namely countering large botnets via elision of their connectivity.

A botnet comprises a set of compromised machines (“bots”) under the control of a “botmaster”.

The Mirai botnet is distinguished by its exploitation and use of IoT devices as bots. At its peak size of an estimated 600K nodes, Mirai delivered crippling DDoS attacks, with 623 Gbps of packet traffic directed against a target server.

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 14

In light of this, the vast increase in IoT devices connected via 5G represents a significant threat.

While the technologies developed under TA2 will inhibit bot recruitment, IoT devices independent of OPS-5G will remain subject to compromise at scale. TA4 technologies will enable scalable resilience by detecting the onset of DDoS attacks with in-network sensors and deploying active in-network defensesxxxvi in response. Proposers should plan to prototype capabilities sufficient to meet program metrics for the scale of DDoS attacks generated by large pools of IoT nodes as exemplified by the Mirai botnetxxxvii.

The TA4 metric is latency at scale, to measure the ability to rapidly detect threats, determine appropriate defenses, and deploy and actuate these defenses against an adaptive adversary operating at scale. Latency measures the ability of the defender to adapt and dominate an adaptive adversary using the principles of John Boyd’s “Observe Orient Decide Act” (OODA) Loop. OPS-5G scalability milestones are designed so that botnet reaction velocity goals remain extremely aggressive as the number of 5G devices expands throughout the course of the program.

TA4 proposers should describe their approach for achieving TA4 metrics for Phases 1, 2, and 3.

This must include description of a simulator or emulator (e.g., Mininetxxxviii ) that permits architectural features such as programmability in the edge or caching in the edge to be modeled.

TA4 performers will be able to evolve their evaluation environments over the course of the program in response to guidance provided by the OPS-5G ITE team. The ITE team will validate TA4 performer’s evaluations at TA4 performer sites, using TA4 performer facilities.

TA4 proposers should indicate any cryptographic requirements presumed available in the proposed approach (e.g., cryptographic hashes needed for secure bootstrap) and if needed, where these capabilities reside, e.g., in OPS-5G TA2 IoT devices or elsewhere in the environment where code is executing. Any assumptions about availability and timing of results from the other OPS-5G technical areas must be explicitly stated in TA4 submissions. TA4 proposers must explicitly state any and all assumptions made about the availability of programmable infrastructures needed for their solutions such as where 5G mobile edge computing (MEC) or other edge clouds are in the architecture. Any requirements that must be known to the ITE to evaluate proposed systems must be specified clearly and explicitly in TA4 proposals. Research prototypes must operate in the network programmability frameworks provided by an open source consortium. This is necessary to validate real-world deployment of OPS-5G.

Experimental validation of moderate-scale realizations of TA4 solutions at the end of Phase 2 requires software deliverables (e.g., for Virtual Network Functions) that operate in an OPS-5G evaluation environment to be defined by the ITE team. The ITE team will evaluate TA4 realizations on US Government facilities. Therefore, TA4 proposals must not replicate independent testbeds at program scale (10,000 nodes).

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 15

Schedule/Milestones OPS-5G is a 4-year program organized into three phases:

Phase 1 (18 months): During this phase, OPS-5G will develop the initial capabilities at performance levels (see Table 2) required for the four OPS-5G technical areas described in this document. DARPA management is initiating a relationship with an open source consortium to enable transition efforts. During this phase, performers will continue to develop this relationship, which includes adoption of an appropriate integrated code and documentation delivery process, and support of other developers as needed. The end of phase milestone for the program will be a functioning demonstration of voice telephony between the DARPA Conference Center (DCC) in Arlington, Virginia and the USD(R&E) 5G test site at NIWC Pacific.

Phase 2 (18 months): This phase will focus on maturing the capabilities demonstrated in Phase 1 to meet performance levels (see Table 2) for the four OPS-5G technical areas.

The end of phase milestone will be a demonstration of data collected from 1,000 or more devices delivered over an OPS-5G slice operating over untrusted hardware. The demonstration will transfer data from the devices to infrastructure at the DARPA Conference Center for real-time analysis and display.

Phase 3 (12 months): This phase finalizes the maturation of the capabilities developed in Phase 2, and achieves the end of program performance levels (see Table 2) for the four OPS-5G technical areas. The end of program milestone is commercial availability of the OPS-5G stack in at least one mobile network operator and in user equipment as appropriate.

Phase 1 (18 months) Phase 2 (18 months) Phase 3 (12 months)

TA1

Accuracy as precision and recall

60% precision and recall, ITE-chosen document

80% precision and recall, ITE-chosen document

95% precision and recall ITE-chosen document

TA2

Security and SWaP

256-bit “encrypt & sign” in < 10 sec using < 70% battery

Resist ITE penetration test of many-to-many IoT for 4 hours using < 50% battery

Resist ITE penetration test on 10K IoT + UE for 2 days using < 25% battery

TA3

Secure slice timing channel capacity

3x reduction in timing channel capacity

10x reduction in timing channel capacity

50x reduction in timing channel capacity

TA4

Mirai botnet DDoS mitigation time

60 seconds 1G emulated nodes

1 second 10K distributed IoT nodes

60 seconds 1T emulated nodes

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 16

Phase 1 (18 months) Phase 2 (18 months) Phase 3 (12 months)

Milestone Demonstrations

Secure voice call between DARPA Conference Center (DCC) and USD(R&E) 5G test site at NIWC Pacific.

Data from 1K devices to DCC over untrusted hardware from USD(R&E) 5G test site at NIWC Pacific and other sites.

Commercial availability in User Equipment (UE) and at least 1 US mobile network operator.

Table 2: Program Metrics by Phase and Technical Area (TA)

Program Meetings DARPA will conduct frequent meetings, workshops, and demonstration events throughout the OPS-5G program. For cost estimation purposes, assume that the locations for all meetings will alternate between San Diego, CA, and Washington, DC unless specified otherwise below.

Biannual Principal Investigator (PI) meetings and biannual development workshops will be held throughout the OPS-5G program. The Program Manager will assess progress at PI meetings via performer briefings and technical exchanges along with input from the USG ITE. Performers will be expected to demonstrate their individual projects at every PI meeting. The development workshops will be held to facilitate integration efforts across the program. Anticipate the duration of PI meetings to be 2 days and development workshops to be 1 day.

One-day program summits will be held at the same location immediately following the PI meetings. The OPS-5G program uses these invitation-only summits to drive interaction amongst OPS-5G performers, mobile network operators, infrastructure and device vendors, DoD and other government components such as the Department of State, the Intelligence Community, the Department of Homeland Security, and the Federal Communications Commission.

Demonstrations will be held at summits.

Formal program evaluations, including integrated system demonstrations, will be conducted by the Government team at the conclusion of each phase at DARPA and are expected to last one day each.

The program schedule and milestones are shown in Table 3.

Table 3: OPS-5G Schedule and Milestones

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 17

Deliverables All performers will be required to provide the following deliverables:

All technical documents and products derived from work funded by this program;

Annotated slide presentations must be delivered within one month after each PI meeting, development workshop or other program event;

Quarterly technical status reports detailing progress made, tasks accomplished, major risks, planned activities, trip summaries, changes to key personnel any potential issues of problem areas that require the attention of the government team these must be part provided within 15 days of the end of each quarter;

Monthly financial status reports must be provided within 15 days of the end of each calendar month;

A final phase report for each program phase that concisely summarizes the effort conducted, technical achievements, and remaining technical challenges will be due 30 days after the end of each phase; and

A final report at the end of the overall period of performance that summarizes the project.

The Government desires the following deliverables:

Commented source code, delivered in a form and with licensing acceptable to an open source consortium;

All other necessary data, build scripts, and documentation including at a minimum user manuals and a detailed software design document for all software developed under this program.

Government-furnished Property/Equipment/Information None.

Intellectual Property The OPS-5G program will emphasize creating and leveraging open source technology and architectures. Clarity is of the utmost importance regarding these rights assertions, as a key goal of the OPS-5G program is establishing an open standards-based, multisource plug-and-play mobile networking architecture that allows for an unprecedented degree of 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 to use OPS-5G program technologies and deliverables in their products and networks.

The Government desires for all work products and deliverables produced by OPS-5G program efforts, such as software, documentation and generated technical data be provided with a license and rights acceptable to an open source consortium. Any lesser rights may adversely impact the intended goals of the program and thus will be carefully examined as part of the review process.

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 18

II. Award Information

A. Awards

DARPA anticipates multiple awards for each of TA1, TA2, TA3, and TA4.

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.

The Government will select for award proposals which are determined to be the most advantageous 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. Grants will NOT be awarded under this program.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In accordance with 10 U.S.C. § 2371b(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this BAA if: (1) that participant in the OT, or a recognized successor in interest to the OT, successfully completed the entire prototype project provided for in the OT, as modified; and (2) the OT provides for the award of a follow-on production contract or OT to the participant, or a recognized successor in interest to the OT.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms http://www.darpa.mil/work-with-us/contract-management#OtherTransactions http://www.darpa.mil/work-with-us/contract-management#OtherTransactions

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 19

and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it 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 the section below on Fundamental Research.

B. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (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 proposed efforts for fundamental research and non-fundamental research. Some proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the anticipated type of proposer (e.g., university or industry) and the nature of the solicited work, the Government expects that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to determine whether the proposed research shall be considered fundamental and to select the award instrument type. Appropriate language will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This language can be found at http://www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research to be performed by a potential awardee is non-fundamental research, its proposed subawardee’s effort may be fundamental research. It is also possible that the research performed by a potential awardee is fundamental research while its proposed subawardee’s effort may be non-fundamental research.

In all cases, it is the potential awardee’s responsibility to explain in its proposal which proposed efforts are fundamental research and why the proposed efforts should be considered fundamental research.

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

The following provisions and clause apply to all solicitations and contracts; however, the definition of “controlled technical information” clearly exempts work considered fundamental http://www.darpa.mil/work-with-us/additional-baa

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 20

research and therefore, even though included in the contract, will not apply if the work is fundamental research.

DFARS 252.204-7000, “Disclosure of Information” DFARS 252.204-7008, “Compliance with Safeguarding Covered Defense Information Controls” DFARS 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting”

The full text of the above solicitation provision and contract clauses can be found at http://www.darpa.mil/work-with-us/additional-baa#NPRPAC.

Compliance with the above requirements includes the mandate for proposers to implement the security requirements specified by National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations” (see https://doi.org/10.6028/NIST.SP.800-171r1) that are in effect at the time the BAA is issued.

For awards where the work is considered fundamental research, the contractor will not have to implement the aforementioned requirements and safeguards. However, should the nature of the work change during performance of the award, work not considered fundamental research will be subject to these requirements.

http://www.darpa.mil/work-with-us/additional-baa#NPRPAC https://doi.org/10.6028/NIST.SP.800-171r1

HR001120S0026 OPEN PROGRAMMABLE SECURE 5G 21

III. Eligibility Information

A. Eligible Applicants

DARPA welcomes engagement from all responsible sources capable of satisfying the Government's needs, including academia (colleges and universities); businesses (large, small, small disadvantaged, etc.); other organizations (including non-profit); other entities (foreign, domestic, and government); FFRDCs; minority institutions; and others.

DARPA welcomes engagement from non-traditional sources in addition to current DARPA performers.

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

a. FFRDCs FFRDCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions. (1) FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs must provide a letter, on official letterhead from their sponsoring organization, that (a) cites the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and (b) certifies the FFRDC’s compliance with the associated FFRDC sponsor agreement’s terms and conditions. These conditions are a requirement for FFRDCs proposing to be awardees or subawardees.

b. Government Entities Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government Entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations and compete with industry.