Protocol Break
Protocol break is the foundational security mechanism in a cross-domain solution. If you understand one thing about how CDS works, it should be this.
What Protocol Break Is
A protocol break is the deliberate termination of one network connection, extraction of the data payload, and initiation of a completely new connection on the other side of the security boundary.
The NCSC defines it plainly: a protocol break "will terminate one transmission path, extract the relevant information, and use this to initiate a new transmission path."
More specifically: "A protocol break will terminate the network connection, and the application protocol. The payload will then be passed via a simplified protocol."
The source and destination systems never have a direct network connection. The CDS sits between them, receiving data on one side, tearing apart the protocol, inspecting the content, and rebuilding everything from scratch on the other side.
If your CDS doesn't do protocol break, it's not a CDS
Protocol break is not optional. It is not an advanced feature. It is the architectural characteristic that distinguishes a genuine cross-domain solution from a proxy, a filter, or a firewall with deep packet inspection.
If a product passes network packets through -- even with inspection -- it is not performing protocol break. The original protocol headers, session state, and network-layer information must be completely discarded and rebuilt. This is the litmus test.
Why It Matters
Protocol break prevents an entire class of attacks: those that exploit vulnerabilities in network protocol implementations.
Malformed protocol messages cannot propagate
The protocol break receiver must be "robustly designed" with the critical goal that "malformed messages in the original protocol cannot exploit vulnerabilities." Because the original protocol is terminated at the CDS boundary, any exploit crafted into the protocol headers, handshake, or session negotiation is discarded. Only the extracted data payload crosses.
Attack surface is minimised
The simplified transport protocol used across the boundary has far fewer features -- and therefore far fewer potential vulnerabilities -- than a full application protocol like HTTP or SMTP. The Isode M-Guard, for example, uses GCXP (Guard Content eXchange Protocol) internally, which transmits XML messages via CBOR framing over TLS. That is dramatically simpler than full XMPP or SMTP.
Command and control channels are severed
Even if malware reaches the destination network through the content payload, a unidirectional protocol break prevents it from communicating back to the attacker. The NCSC notes that "flow control does not stop a vulnerability being exploited within the destination system but it can make it difficult for an attacker to perform command and control."
Defence in depth across the stack
Protocol break operates at the network and transport layers. Content treatments (CDR, format verification, dirty word search) operate at the application layer. Together they provide protection across the full protocol stack -- failure of one layer does not compromise the other.
How It Works: Step by Step
The architecture follows the NCSC's import pipeline pattern, placing complex processing on the untrusted side and simple verification on the trusted side:
1. Terminate the inbound connection
The CDS accepts the connection from the source domain, acting as a full protocol endpoint. The original network session ends here. No packets pass through.
2. Extract the data payload
The CDS strips the protocol headers, session information, and transport metadata. Only the content payload is retained.
3. Transform (untrusted side)
Complex data formats are converted into simpler, verifiable formats. The NCSC places the transformation engine deliberately on the untrusted side because "we assume that the transformation engine could be compromised." This is intentional: the complex, potentially vulnerable processing happens where a compromise is least damaging.
4. Pass via simplified protocol
The extracted and transformed payload crosses the boundary via a minimal internal transport. This is often hardware-enforced -- the NCSC specifies "hardware enforced one way flow" for both import and export paths. The simplified protocol provides "a simple transport mechanism" with minimal features and minimal attack surface.
5. Verify (trusted side)
On the trusted side, a verification engine performs syntactic checks ("the structure and syntax of the object are correct") and semantic checks ("the meaning is valid in the context of the operation or business process"). Because the data has been simplified by the transformation step, verification is tractable.
6. Reconstruct and deliver
Approved data is wrapped "in known good protocol headers" and delivered to the destination via a new, independent protocol session. The destination system receives clean data via a clean connection that has no relationship to the original inbound session.
The key insight
The architecture is deliberately asymmetric. Complex, dangerous processing (parsing untrusted formats, handling full application protocols) happens on the untrusted side. Simple, verifiable processing (checking structure and semantics of already-simplified data) happens on the trusted side. The hardware-enforced break between them means that even if the transformation engine is compromised, it cannot contaminate the trusted side.
Protocol-Specific Examples
HTTP
The CDS terminates the HTTP connection on the untrusted side, extracts the request or response body, and reconstructs a new HTTP transaction on the trusted side. Because HTTP is inherently bidirectional, the CDS must "correlate requests and responses" to ensure "a response cannot pass without a corresponding request of the correct type."
SMTP (Email)
The CDS terminates the SMTP session, extracts the message envelope (sender, recipients) and body (MIME content), processes each component through the treatment pipeline, and reconstructs a new SMTP delivery on the other side. Email is the most common bidirectional CDS use case and the original guard application going back to the ACCAT Guard in the 1980s.
XMPP (Chat and Messaging)
The Isode M-Guard operates as "an application level data diode, with traffic flowing in one direction only" for XMPP traffic. It uses GCXP -- which "transfers a stream of XML Messages" via CBOR framing over TLS -- as the simplified boundary protocol. Guards are commonly deployed in pairs for bidirectional chat.
Database
Database protocol break terminates the database wire protocol (ODBC, JDBC, or proprietary), extracts query results or update operations, validates them against schema and policy, and reconstructs new database operations on the trusted side. The NCSC highlights SQL queries as a case requiring request/response correlation to prevent unauthorised data export.
File Transfer (FTP)
FTP protocol break terminates both the FTP control and data channels, extracts the file content, processes it through CDR and verification, and delivers the file via a new connection. Data diode products typically support this as a standard use case.
Protocol Break and CDR: Defence in Depth
Protocol break handles the transport layer. Content Disarm and Reconstruct (CDR) handles the content layer. Together they provide layered protection across the full data transfer:
| Layer | Threat | Control |
|---|---|---|
| Network / transport | Protocol exploits, malformed packets | Protocol break + hardware-enforced flow |
| Session | Session hijacking, C&C channels | Session isolation, unidirectional flow |
| Application format | Malformed files, polyglot attacks | Format verification, schema validation |
| Application content | Embedded malware, active content | CDR, active content removal |
| Semantic | Covert channels, data exfiltration | Semantic verification, label checks |
The NCSC captures this principle: "assurance is not gained at a single point, but through the pipeline."
Each control addresses a different attack vector. The failure of any single control does not compromise the entire boundary -- the remaining controls continue to provide protection. This is why a real CDS is fundamentally more secure than a device that only operates at one layer.
Flow Separation
The NCSC requires that import and export flows are handled separately, with specific hardware enforcement:
- Export flows require "hardware enforced one way flow"
- Import flows need "hardware enforced one way flow inbound, and a protocol break"
There must also be "a clear separation between these externally exposed components, and internal components which have connectivity to more protected core network systems and services."
This separation ensures that a compromise of the external-facing protocol handling cannot provide a route into the protected core network.
For more on how data moves through these flows, see Data Flow Models. For the content-level treatments applied after protocol break, see Treatments and Transforms. For the policy that governs what gets through, see Security Enforcement.