DARPA-SN-27-13.pdf

Special Notice Request for Information Verification and Compliance Checking for Natural-Language Network Requirements (FastVacc)

DARPA-SN-27-13

October 29, 2026

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

DARPA-SN-27-13

REQUEST FOR INFORMATION (RFI) DESCRIPTION

Modern networks need to be reconfigured quickly in response to mission changes or emerging threats, but checking compliance with security requirements can take months. This creates a window in which adversaries may exploit vulnerabilities introduced by those changes. The Defense Advanced Research Projects Agency (DARPA) Information Processing Techniques Office (IPTO) seeks information on approaches, tools and practices for closing that window by reducing, by 2-3 orders of magnitude, the time and cost of verifiable compliance checking.

DARPA envisions a capability that would take as input two items: (a) a requirements document written in natural language and (b) the configurations in a concrete network. In an offline phase, it would reason about the requirements for inconsistency, redundancy and incompleteness, and output consistent, non-redundant and completed requirements. Then, it would check, in near real-time, whether the concrete configurations satisfy all of the requirements. In all cases, its output would be understandable by a human.

RFI BACKGROUND

Today, requirement documents such as commercial solutions for classified (CSfC) capability packages1, zero trust architecture (ZTA)2, and systems and communications protection3 are written in natural language. These consist of a description of the intended purpose, the design principles for accomplishing that purpose and a checklist of requirements and procedures to evaluate them against configurations. Analysts read the document, interpret what the requirements mean for a given network, identify the abstract structures in diagrams and raw configurations, and then execute the evaluation procedures against the network’s configuration. The limitations of this process arise from the inherent hardness of three challenges: natural language understanding, reasoning and evaluation.

Challenge 1: Natural Language Understanding

• Requirements documents can run into hundreds of pages producing hundreds of requirements. Often, they recursively reference other documents.

• Requirements cannot be understood in isolation. Often, they are defined in terms of document-specific, mission-specific abstractions that can only be understood in the context of the full document. Examples of these are the inner and outer encryption gateways, and red, gray and black networks in CSfC, policy-enforcement points in ZTA and boundary-protection points in Systems and Communications Protection. Often, these abstractions may not even be a single network element but instead a collection of these e.g., an inner encryption gateway may be a high availability cluster of physical gateways.

• Document-specific abstractions need to be identified in configurations. Network configurations are not labeled with these abstractions. These have to be inferred/learned from the concrete configurations before requirements can be evaluated against those configurations.

• The instantiated requirements need to be further translated into scripts for running network tests and the query language of network verification tools.

1 https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/capability-packages/ 2 https://doi.org/10.6028/NIST.SP.800-207 3 https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=SC.

https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/capability-packages/ https://doi.org/10.6028/NIST.SP.800-207 https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=SC

Challenge 2: Reasoning

• Reasoning requirements mean evaluating e.g., if requirements are contradictory, redundant or incomplete. Such reasoning is inherently hard due to the scale and complexity of the requirements. The number of consequences of these can be enormous as can be the number of possible ways in which security violations can occur.

• The hardness is compounded by the fact that reasoning has to be carried out in the abstract without reference to a concrete structure or configuration. Indeed, the reasoning implicit in the requirement document is itself of this form: if any network satisfies all of the stated requirements, then that network will possess the desired security properties.

• The hardness is further compounded when requirements are under-specified. Typically, documents supply requirements for a reference architecture but, they leave undefined how those requirements should extend to features beyond the reference architecture, such as high availability, redundancy, failover, or performance, needed for real-world deployment.

When such features are added, analysts must infer the original security intent and formulate additional requirements needed to preserve it in the modified architecture.

• Network verification tools require, as input, configurations from a concrete network. These tools, while powerful and scalable, cannot solve the above reasoning problems. They are designed for analysis of a specific, fully-specified network configuration, not for reasoning about the requirements themselves.

Challenge 3: Evaluation

• Often, requirements are tested, not formally verified. A single requirement can range

(quantify) over sets of multiple entities such as firewalls, packet flows, gateways, or paths.

In a real network, such a requirement can induce a very large number of concrete instances.

Manually checking all such instances against configuration is slow, labor-intensive and error prone. Thus, in practice, only a finite number of instances are evaluated, leaving undetected a potentially large number of violating instances. Existing network verification tools can overcome this limitation by symbolically evaluating all requirement instances. In practice, they are rarely deployed, perhaps because of the hardness of translating the natural language requirements into precise requirements, translating concrete configurations into the abstractions in these requirements, and then further translating these into the precise language of network verification tools.

REQUESTED INFORMATION

1. A baseline solution is to upload a requirement document and a concrete configuration into a large language model and ask it to perform the above tasks. Is this baseline adequate, and if not, why not? If the baseline is not adequate, what is required to move beyond it? In particular, do we need an intermediate formal system to bridge the gap between natural-language requirement documents and low-level network configurations and if so, what are the design principles of such a system? Should such a system take the form of a domain-specific language (DSL) along with a semantics, axioms, lemmas and a deductive system in which strategies for reasoning at scale can be programmed? To what extent should the DSL’s abstractions, semantics, and the reasoning strategies mirror those already present, explicitly or implicitly, in requirement documents themselves? How can these abstractions be sufficiently minimal yet intuitive, while permitting formalization of all network requirements of interest?

2. How would this intermediate formal system simplify the above natural language analysis, reasoning and evaluation problems? Are richer forms of reasoning, such as induction, needed in order to extend or complete requirements when new architectural features are introduced? How can we leverage the special nature of networks to design efficient reasoning strategies such as decompose-merge?

3. Could this formal system be a “Netlib” for networking, analogous to Lean’s Mathlib for math, a growing library in which informal math proofs are formalized? If so, what are the networking analogs of informal proofs? Are these informal proofs of properties of architecture patterns or reference network architectures found in networking textbooks, network administrator certification study guides, request for comments (RFCs), vendor design guides, standards documents, or security requirement documents?

4. What are the metrics for assessing progress on translation fidelity, reasoning quality and compliance evaluation accuracy? Could there be a Turing test to assess the fidelity of the natural language understanding, in collaboration with a human? What are the risks in attempting to solve these problems and what early indicators would show that an approach is on a credible path?

5. What are real-world examples of the adverse consequences of the high time and monetary cost of current network compliance practice, and the benefits of reducing this cost by 2-3 orders of magnitude?

6. What current technologies exist to solve parts of the above problems and what are their shortcomings?

7. What datasets exist and what additional datasets would need to be created?

Responses are invited to the above questions (not necessarily all) with a one-page narrative and up to two slides with visual depictions of key concepts. At least one slide should include a filled out version of Table 1 (below).

Problem How is it done today?

What are limitations of current practice?

What is new in your approach?

How will it overcome the limitations?

What is the strategic surprise?

Natural Language understanding

Reasoning

Evaluation

Table 1: Response Slide

ELIGIBLE RESPONDENTS

Responses are welcome from all capable sources including, but not limited to, private or public companies, individuals, universities, university-affiliated research centers, not-for-profit research institutions, and U.S. Government-sponsored labs. Note that DARPA assumes that feedback through standard scientific discourse, including direct communication with the corresponding authors or through additional manuscripts, will proceed as usual and views this RFI as in addition to that discourse.

SUBMISSION INSTRUCTIONS

• Response Due Date: November 13, 2026, by 5:00 PM Eastern Time (ET)

• All responses must be submitted to FastVacc@darpa.mil

• All responses must be at the UNCLASSIFIED level. No classified responses will be accepted against this RFI.

To the maximum extent possible, respondents should submit non-proprietary information. If proprietary information is submitted, it is the respondent’s responsibility to clearly mark what is considered proprietary data. All proprietary information should be clearly labeled “Proprietary.”

NOTE: “Confidential” is not a classification marking used to control the dissemination of U.S.

Government National Security Information as dictated in Executive Order 13526 and should not be used to identify proprietary business information. DARPA will disclose submission contents only for the purpose of review by DARPA staff, other Government agencies, or DARPA Support Contractors.

NOTE: DARPA may reach out to respondents to clarify and/or discuss technical information received against this RFI.

FORMAT AND CONTENT INSTRUCTIONS

• All responses are required to include the submitting organization’s name, the name of a Technical Point of Contact (POC), and the Technical POC’s email address and phone number. Respondents may also include the name and contact information for an Administrative POC.

• DARPA encourages all respondents to submit a one (1)-page narrative and two (2) slides with visual depictions of key concepts. One (1) slide should include a filled-out copy of Table 1 (shown above).

• All submissions must be submitted as an unprotected Microsoft Word and Microsoft Power Point file or as an unprotected PDF file. Submissions not meeting this requirement may be discarded.

• All submissions must be written in English, and all pages shall be formatted for printing on 8-1/2 by 11-inch paper with 1-inch margins and font size no smaller than 12-point font.

Font sizes of 8 or 10-point may be used for figures, tables, and charts.

DARPACONNECT

Entities who have not worked with DARPA before are encouraged to learn more about DARPAConnect, an initiative established to facilitate collaboration between DARPA and potential performers. DARPAConnect offers customized support, resources, and guidance on how to prepare your ideas for high-impact conversations with DARPA program managers. Please visit DARPAConnect.us to access a digital hub of online resources, including a curriculum for self-paced learning, personalized support, and in-person and virtual events. In addition to the self-paced online materials, DARPAConnect is able to schedule one-on-one conversations to discuss your specific ideas, questions, and paths to DARPA. You can use the contact form at DARPAConnect.us or email DARPAConnect directly at darpaconnect@darpa.mil to request assistance.

ADMINISTRATIVE

This RFI contains all information required to submit a response. No additional forms, kits, or other materials are needed. All administrative and technical questions should be directed to FastVacc@darpa.mil. Please refer to the Special Notice number (DARPA-SN-27-1313) in all correspondence.

This RFI does not constitute a formal solicitation for abstracts or proposals; any abstract or proposal received against this RFI will be disregarded. In accordance with FAR 15.201(e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. DARPA will not provide reimbursement for costs incurred in responding to this RFI.

Respondents are advised that DARPA is under no obligation to acknowledge receipt of the submission received, invite respondents to events, include tools identified in responses, or provide feedback to respondents with respect to any information submitted under this RFI.

https://www.darpaconnect.us/ mailto:darpaconnect@darpa.mil