AComP-5640 protected core networking deployable specifications

What it is

AComP-5640 is the NATO Allied Communications Publication that defines the interoperability specifications for Protected Core Networking (PCN) in deployable mission environments. It exists so that separately-owned national network segments, called Protected Core Segments (PCSs), can plug into each other and into a shared federated core without every nation building or trusting a single network. The document says its own objective is "to define the Interoperability Specifications (ISpecS) of the PCN interfaces and PCS characteristics applicable to deployable mission environments." It covers deployable connections specifically, distinguishing its own scope from the "Deployable and Static environments" the wider PCN concept spans.

The document binds through STANAG 5640: "The agreement of nations to use this publication is recorded in STANAG 5640." AComP-5640 itself creates no direct obligation on a company. It reaches an implementer when a national or NATO programme decides a network segment has to interconnect over PCN-1 or PCN-2, whether that comes from a mission requirement, a Federated Mission Networking commitment, or a contract that names the document. A nation can also ratify with reservations rather than adopt the whole document: this edition's Record of Specific Reservations shows Denmark excepting two Traffic Flow Confidentiality types for satellite links "as current national systems don't have the necessary bandwidth yet."

Two interfaces: PCN-1 between segments, PCN-2 to consumers

PCN-1 connects two Protected Core Segments to each other. PCN-2 connects a Protected Core Service Consumer (a national or mission network, via its "P-functionality") into a Protected Core Segment. Both interfaces follow the same basic pattern when the connecting entities are not physically co-located: mutual authentication using IKEv2 with X.509 certificates, a GRE tunnel protected by IPsec ESP in transport mode, and AES-256-GCM encryption over a 384-bit elliptic-curve key exchange. Where entities are co-located at a single point of interconnection, a simpler native IP link with implicit, procedural authentication is permitted instead, and is treated as meeting the full range of Traffic Flow Confidentiality by virtue of the physical controls around it.

One difference between the two interfaces is easy to miss: PCN-1 runs BGP-4 as its mandatory routing protocol, but "the PCN-2 interface does not support dynamic routing protocols. Routing over the PCN-2 is based on static routing" - a default route from the consumer side and specific advertised subnets from the core side.

Traffic Flow Confidentiality: five types defined, two required now

The document defines five types of Traffic Flow Confidentiality (TFC): Per-Packet Authentication, Source/Destination Hiding, Precedence Hiding, TFC Padding and Traffic Volume Hiding. Only two are mandated in this edition: "Supported TFC types for this STANAG version are: Packet Authentication and Source/Destination Hiding." PCS owners declare which TFC types their own infrastructure supports to their peers "via NMCD information exchange" rather than through any external assessment. Traffic Volume Hiding is explicitly not yet supported: the document notes that mechanism is left for a future version.

Trust authorities, certificates and SLAs

Every PCN entity (E-nodes, P-functionalities, NMCDs) authenticates using X.509v3 certificates issued by an Infrastructure of Trust Authorities, with a signature algorithm of RSA 4096 with SHA-384, or EC P384 (EC P521 optional), and certificate revocation supported via CRL, with OCSP as an option. Because PCN is federated, there is deliberately no single trust authority: multiple trust authorities issue certificates to different segments, and a trust relationship (at minimum, trust lists) has to be established between them before entities on different sides can connect.

Every connection needs a Service Level Agreement covering, at minimum, traffic markings, minimum and maximum bandwidth, maximum transfer delay and maximum delay variation, built on the traffic classes and QoS model in STANAG 4711. Where a connection has to go live before its SLA is fully negotiated, all traffic is marked Low-Priority Data by default rather than left unclassified.

What the deployable environment does not cover

The document is explicit about scope it deliberately leaves out. Information confidentiality of the actual payload is not PCN's job: the Protected Core is "a non-classified network" that "will not provide information confidentiality and integrity of the consumer data/payload," which stays the responsibility of the consumer's own cryptographic units. Likewise for security architecture in general: "offering a holistic cyber security architecture is out of the scope of PCN. PCS operators are responsible for developing and implementing a robust cyber security design in their PCS." PCN requires a border protection function that whitelists a specific, narrow protocol set (BGP, BFD, ICMP, and RIPng where autoconfiguration is used) at each interface, not a general security programme. Network Address Translation is forbidden inside the shared core but allowed at the consumer-facing edge, and every PCN entity has to stay synchronised to UTC within 1200 milliseconds, both concrete, checkable numbers rather than general guidance.

How you are evaluated

There is no accreditation, certification or notified-body scheme for AComP-5640. Conformance is expressed as being "PCN-compliant," and the document defines that operationally, not institutionally: an entity "shall implement PCN-1 interface, PCN-2 interface, or both" depending on its role, and whether it actually interoperates is what proves it, not an audit. The one place the document uses the word "certify" is the TFC capability declaration PCS owners exchange with their peers through the NMCD, which is a technical self-declaration, not a compliance certificate issued by any authority.

Standards it references

AComP-5640 leans on a small set of other NATO publications and a long list of IETF protocol standards. STANAG 5637 and its Allied Publication, AComP-5637 - the PCN "Head STANAG" - carry the overarching PCN architecture this document only summarises for completeness. STANAG 4711 / AComP-4711 supplies the traffic classes and QoS model this document's SLA requirements are built on. STANAG 4290 / AComP-4290 supplies the tactical connector standard named for field Ethernet deployments. Outside our catalogue, the document repeatedly points at STANAG 5655 / AComP-5655, the Network Management and Cyber Defence Specification, which is still "under development" and is where the NMCD interface this document only sketches is meant to be fully defined, and at a Standards Related Document for STANAG 5637's PCN address schema, also under development. The protocol mechanics themselves come from IETF RFCs: IKEv2 (RFC 7296, with its algorithm profile in RFC 8247), GRE (RFC 2784, extended by RFC 2890), ESP (RFC 4303), X.509 certificates and CRLs (RFC 5280), OCSP (RFC 6960), BGP-4 and its extensions (RFCs 4271, 4760, 2545, 6793, 1772), Bidirectional Forwarding Detection (RFC 5880, RFC 7419), the Generalized TTL Security Mechanism (RFC 5082), and private addressing (RFC 1918, RFC 4193).

AComP-5640 is published by the NATO Standardization Office and listed in the NATO Standardization Document Database, free of charge. NATO's documents are not sold by ComplyTrain and we host no copies.

Standards it references

• STANAG 4711Binds
• STANAG 5637Background
• AComP-5637Background
• AComP-4711Background
• STANAG 4290Background
• AComP-4290Background