Certificates Exchange Profile

The Certificates Exchange Profile specifies the use of public standards for exchange of digital certificates.

Digital Certificate Services

Mandatory

The PEM format with base64-encoded data shall be used to exchange Certificates, Certificate Revocation Lists (CRLs), and Certification Requests.

• IETF RFC 7468 - Textual Encodings of PKIX, PKCS, and CMS Structures

Cryptographic Algorithms Profile

The Cryptographic Algorithms Profile specifies the use of public standards for cryptographic algorithm interoperability to protect IT systems.

Digital Certificate Services

Mandatory

• NIST FIPS PUB 186-4 - Digital Signature Standard (DSS)
• NIST FIPS PUB 197 - Advanced Encryption Standard (AES)
• NIST FIPS PUB 180-4 - Secure Hash Standard (SHS)
• NIST SP 800-56A Rev 2 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
• IETF RFC 3526 - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• NIST SP 800-56B Rev2 - Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography

The following algorithms and parameters are to be used to support specific functions

• Root CA Certificates
  • Digest Algorithm SHA-256 or SHA-384 (Root CA certificates, which were signed using SHA-1 before 1 January 2016, may be used until 1 January 2025)
  • RSA modulus size (bits) 3072 or 4096
  • ECC Curve NIST P-256 or P-384
• Subordinate CA Certificates
  • Digest Algorithm SHA-256 or SHA-384
  • RSA modulus size (bits) 2048, 3072 or 4096
  • ECC Curve NIST P-256 or P-384
• Subscriber Certificates
  • Digest Algorithm SHA-256 or SHA-384
  • RSA modulus size (bits) 2048, 3072 or 4096
  • ECC Curve NIST P-256 or P-384

• A digital certificate service provider shall choose which combination of algorithm and keylength chain to build. The service portfolio may contain several parallel solutions.
• You shall not mix key-algorithms in one CA/sub-CA chain.
• A digital certificate service consumer shall support the full spectrum of possible combinations in algorithm and keylength.
• During a mission instantiation, the service designer shall verify service consumer capabilities with regard to supported algorithms.

Digital Certificate Profile

The Digital Certificate Profile provides standards and guidance in support of a Public Key Infrastructure (PKI) on federated mission networks.

Digital Certificate Services

Mandatory

• ITU-T X.509 - Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks

Mandatory

The Online Certificate Status Protocol (OCSP) capability is mandatory for PKI Service providers. The addresses of OCSP endpoints shall be provided in digital certificates through X.509 certificate extensions such as Authority Information Access (AIA). Clients might support this protocol.

• IETF RFC 6960 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

Mandatory

CRLs may be provided at multiple endpoints. The addresses of these endpoints shall be provided in digital certificates through X.509 certificate extensions such as Authority Information Access (AIA) and CRL distribution point (CDP). Each CA shall provide CRLs over HTTP. Clients must support this protocol.

• IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

The version of the encoded public key certificate shall be version 3. The version of the encoded certificate revocation list (CRL) shall be version 2.For further guidance on the implementation the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2 shall also be considered.

Virtual Appliance Interchange Profile

The Virtual Appliance Interchange Profile provides standards and guidance to support the Virtualized Processing Services to exchange virtual appliances between different host platforms.

Virtualized Processing Services

Conditional

If automated importing of virtual appliances is supported by the service provider, OVF format shall be used as exchange format.

• DMTF OVF 2.0.1 (DSP0243) - Open Virtualization Format (OVF) Specification Ver 2.0.1

Mandatory

File format for virtual hard disk drives, which the service consumer has to be able to provide.

• VMware VDDK 5.0 - Virtual Disk Format 5.0
• Microsoft Virtual Hard Disk Image Format Specification - Virtual Hard Disk (VHD) Image Format Specification

To ensure optimization of the exchange of virtual appliances, the following guidelines should be observed.The environment should be prepared for optimal implementation of a virtual machine (VM).

• Strip down the hardware as much as possible, by removing sound cards, USB controllers, CD-ROM and floppy drives, and para-virtualized devices;
• Minimize the VMs’ HDD footprint to a minimum and use thin provisioning;
• Unmount any removable devices before exporting to Open Virtualization Format (OVF);
• Delete all snapshots;
• Shutdown machine; and
• Include a CRC Integrity Check.

• vCPU support minimal two vCPUs supported per VM
• SCSI disk controller minimal two
• Virtual SCSI harddisks and optical disk minimal eight
• IDE nodes
• Virtual IDE disks
• Virtual IDE CD-ROMs
  • E1000 (Network Interface)
• SVGA displays minimal one
• Serial ports minimal one

Time Synchronization Profile

The Time Synchronization Profile provides standards and guidance to support the synchronization of clients and servers across a network or a federation of networks and the safeguard of the accurate use of timestamps.

Distributed Time Services

Mandatory

• IETF RFC 5905 - Network Time Protocol (NTP) Version 4: Protocol and Algorithms Specification
• ITU-R TF.460-6 - Standard-frequency and time-signal emissions. Annex 1: Coordinated universal time (UTC)

Stratum 1 devices must implement IPv4 so that they can be used as time servers for IPv4-based mission networks.

Secure Domain Naming Profile

The Secure Domain Naming Profile provides standards and guidance to support the hierarchical distributed name system with a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality. These extensions are combined in the Domain Name System Security Extensions (DNSSEC), a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks.

Domain Name Services

Mandatory

• IETF RFC 4033 - DNS Security (DNSSEC) Introduction
• IETF RFC 4034 - Resource Records for the DNS Security Extensions
• IETF RFC 4035 - Protocol Modifications for the DNS Security Extensions
• IETF RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
• IETF RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• IETF RFC 5702 - Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

Only the following security algorithms shall be used

• RSASHA256,
• RSASHA512,
• ECDSAP256SHA256,
• ECDSAP384SHA384.

Domain Naming Profile

The Domain Naming Profile provides standards and guidance to support the hierarchical distributed name system for computers, services, or any resource connected to a federated mission network.

Domain Name Services

Mandatory

• IETF RFC 1034 - Domain names - concepts and facilities
• IETF RFC 1035 - Domain names - implementation and specification
• IETF RFC 2181 - Clarifications to the DNS Specification
• IETF RFC 2782 - A DNS RR for specifying the location of services (DNS SRV)
• IETF RFC 3258 - Distributing Authoritative Name Servers via Shared Unicast Addresses
• IETF RFC 4786 - Operation of Anycast Services
• IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR)
• IETF RFC 5966 - DNS Transport over TCP - Implementation Requirements
• IETF RFC 6382 - Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
• IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
• IETF RFC 7094 - Architectural Considerations of IP Anycast

ISR Library Interface Profile

The ISR Library Interface is the standard interface for querying and accessing heterogeneous product libraries maintained by various nations.

Intelligence and ISR Functional Services

Mandatory

The Basic Image Interchange Format (BIIF) is mandated for interoperability of ISR libraries.

• ISO/IEC 12087-5 - Image Processing and Interchange (IPI) - Functional Specification - Part 5: Basic Image Interchange Format (BIIF)
• ISO/IEC 12087-5 Cor 1 - Technical Corrigendum 1 to International Standard ISO/IEC 12087-5:1998
• ISO/IEC 12087-5 Cor 2 - Technical Corrigendum 2 to International Standard ISO/IEC 12087-5:1998

Mandatory

The following NATO standards provide the specification as well as business rules for interoperability of ISR libraries.

• NATO AEDP-17 Ed A Ver 1 - NATO Standard ISR Library Interface

Mandatory

Implementation of STANAG 5525 in the context of the ISR Library Interface Profile is limited to the definition of unique keys that could be used to unambiguously refer to an external information object that is modelled in accordance with STANAG 5525. Note that AEDP-17 refers to the metadata attribute “JC3IEDMIdentifier” on page G-15, but to “identifierJC3IEDM” on page G-79. The correct attribute to use is “identifierJC3IEDM”.

• NATO JC3IEDM Baseline 3.1.4 - Joint C3 Information Exchange Data Model Baseline 3.1.4

Mandatory

The following NATO standards are mandated for interoperability of ISR library products.

• NATO MISP-2015.1 - US Motion Imagery Standards Board (MISB) - Motion Imagimary Standards Profile-2015.1
• NATO AEDP-04 Ed 2 Ver 1 - NATO Secondary Imagery Format (NSIF) STANAG 4545 Implementation Guide
• NATO AEDP-07 Ed 2 Ver 1 - NATO Ground Moving Target Indicator (GMTI) Format STANAG 4607 Implementation Guide

Mandatory

The following international standards are mandated for interoperability of ISR libraries.

• ISO 639-2 - Representation of Names of Languages Part 2: Alpha-3
• ISO/IEC 11179-3 - Information technology -- Metadata registries (MDR) -- Part 3: Registry metamodel and basic attributes
• ISO/IEC 14750 - Information technology -- Open Distributed Processing -- Interface Definition Language

To ensure optimization of network resources the ISR Library Interface services work best with a unicast address space.AEDP-17 defines four interfaces

• STANAG 4559 CORBA’s interface
• Provider-consumer interface (see ISR Library Access Pattern) based on HTTP/HTTPS
• CSD-Publish services interface
• CSD-Query services interface

ISR Streaming Profile

The ISR streaming services architecture defined by AEDP-18 covers the ISR enterprise wide sharing and management of streaming data, i.e. data generated by sensors and which is periodically updated. The ISR Streaming Services Standard mandates support for streams of one or more of the data types: Ground Moving Target Indicator (GMTI).Motion imagery.Link 16. The supported datatype(s) of the ISR Streaming Services are required information in the Joining instructions.

Intelligence and ISR Functional Services

Mandatory

Implementation mandates that one or more of the following standards be implemented:

• NATO MISP-2015.1 - US Motion Imagery Standards Board (MISB) - Motion Imagimary Standards Profile-2015.1
• NATO AEDP-07 Ed 2 Ver 1 - NATO Ground Moving Target Indicator (GMTI) Format STANAG 4607 Implementation Guide
• NATO ATDLP-5.18 Ed B Ver 2 - Interoperability Standard for Joint Range Extension Application Protocol (JREAP)

Mandatory

• NATO AEDP-18 Ed A Ver 1 - NATO Standard ISR Streaming Services

The operational processes facilitated by the ISR Streaming architecture are described in detail in the Procedural Instructions for Intelligence and JISR.

Maritime C2 Processes Profile

Maritime Operations includes a set of military activities conducted by maritime air, surface, sub-surface and amphibious forces to attain and maintain a desired degree of control of the surface, sub-surface, and air above the sea, influence events ashore, and, as required, support land, air/space, and cyber operations

Business Processes

Mandatory

• NATO AJP-3.1 Ed A Ver 1 - Allied Joint Doctrine for Maritime Operations

The maritime conflict and operation themes are likely to cover the following types of operations in the maritime environment (AJP-3.1)

• Major combat operations,
• Peace support,
• Peacetime military engagement.

• Warfare and combat,
• Maritime security,
• Security cooperation.

Land C2 Information Exchange Profile

The Land C2 Information Exchange Profile provides standards and guidance to support the exchange of Command and Control information within a coalition network or a federation of networks.

Situational Awareness Services,

Battlespace Object Services

Mandatory

• NATO ADatP-5644 (FD) Ed A Ver 1 - Web Service Messaging Profile (WSMP)
• MIP MIP IES 4.3.1 - MIP4 Information Exchange Specification 4.3.1

The MIP4 profile should be used primarily for the exchange of Battlespace Objects (BSOs); this profile is not intended to support high volume, high frequency updates such as Friendly Force Tracking (FFT). Nor is it intended to support the exchange of data over tactical bearers (with limited capacity and intermittent availability).The MIP interoperability specification comprises both a mandatory technical interface specification as well as implementation guidance documents, and is available on the MIP website (https //www.mip-interop.org). The minimum iteration for MIP4 implementation is MIP4.3 (and MIP4.3 is the basis for the capabilities covered by the Spiral 4 Specification). However, as the MIP4 specification supports inter-version compatibility, later iterations of MIP4 (i.e. MIP4.4+) are expected to remain interoperable with MIP4.3.The suite of guidance documents includes the MIP Operating Procedures (MOP), which provides technical procedures for configuration/operation of MIP 4.3 interfaces in a coalition environment.

Maritime C2 Information Exchange Profile

The Maritime C2 Information Exchange Profile provides standards and guidance to support the exchange of the Recognized Maritime Picture (RMP) information within a coalition network or a federation of networks.

Recognized Maritime Picture Services

Conditional

For conditional use, coupled with the AIS line from OTH-T GOLD Baseline 2007.

• US DoN OTH-T Gold Baseline 2000 - Operational Specification for Over-The-Horizon Targeting Gold Revision D, OS-OTG (Rev. D)

Mandatory

• US DoN OTH-T Gold Baseline 2007 - Operational Specification for Over-The-Horizon Targeting Gold (OS-OTG), Baseline 2007

The implementation of the following message types is mandatory

• Enhanced Contact Report (XCTC);
• Overlay Message (OVLY2, OVLY3);

• Area of Interest Filter (AOI);
• FOTC Situation Report;
• Group Track Message (GROUP);
• Operator Note (OPNOTE);
• PIM Track (PIMTRACK);

• TCP (connect, send, disconnect) - default port 2020

Land Tactical C2 Information Exchange Profile

The Land Tactical C2 Information Exchange Profile provides standards and guidance with regard to a core set of Command and Control information and also on how to exchange XML messages within a coalition tactical environment with mobile units.

Track Distribution Services,

Situational Awareness Services,

Battlespace Object Services,

Direct Messaging Services

Mandatory

AEP-76 is to be used for direct C2 Data Exchange between coalition units at the Mobile Tactical Edge, where a shared interoperability network is in place built upon the loaned radio concept. The data model of AEP-76 is based on variant of MIP 3.1 XML messages. The following 8 messages of the messages defined in Volume II are mandatory for federating JDSS in coalition operations: Presence MessageIdentification MessageContact /Sighting MessageSketch MessageGenInfo MessageReceipt MessageOverlay MessageCasualty Evacuation Request Message (Request Message Body only)

• NATO AEP-76 Vol II Ed A Ver 2 - Specifications Defining the Joint Dismounted Soldier System Interoperability Network (JDSSIN) - Data Model

Mandatory

• NATO AEP-76 Vol III Ed A Ver 2 - Specifications Defining the Joint Dismounted Soldier System Interoperability Network (JDSSIN) - LOANED RADIO

Mandatory

• NATO AEP-76 Vol III Ed A Ver 2 - Specifications Defining the Joint Dismounted Soldier System Interoperability Network (JDSSIN) - LOANED RADIO

Mandatory

• NATO AEP-76 Vol V Ed A Ver 2 - Specifications Defining the Joint Dismounted Soldier System Interoperability Network (JDSSIN) - Network Access
• NATO AEP-76 Vol I Ed A Ver 2 - Specifications Defining The Joint Dismounted Soldier System Interoperability Network (JDSSIN) - Security
• NATO AEP-76 Vol IV Ed A Ver 2 - Specifications Defining the Joint Dismounted Soldier System Interoperability Network (JDSSIN) - Information Exchange Mechanism

Developers may useAEP-76 Ed A V2 XML Schema Definitionsfor implementing JDSS.See SIP for Loaned Radio Connector for an interim replacement of the cancelled standard AEP-86 (STANAG 4619).AEP-76 is to be used for direct C2 Data Exchange between coalition units at the Mobile Tactical Edge, where a shared interoperability network is in place built upon the loaned radio concept. The information exchange mechanism of AEP-76 supports the efficient information exchange of XML messages over a coalition mobile tactical edge network.The following two JDSS messages are out-scoped for FMN Spiral 4

• Coordination message. STANAG 4677 provides the Overlay message that is a superset of functionality that is provided by the coordination message and can be used instead..
• NBC message. STANAG 4677 provides the Overlay message that is a superset of functionality that is provided by the coordination message and can be used instead.

Battlespace Event Federation Profile

The Battlespace Event Federation Profile provides standards and guidance to support the exchange of information on significant incidents, important events, trends and activities within a coalition network or a federation of networks.

Battlespace Event Services

Mandatory

To support exploitation the following APP-11 message formats MUST be supported (MTF Identifier, MTF Index Ref Number): Incident Report (INCREP, A078)Incident Spot Report (INCSPOTREP, J006)Troops in Contact SALTA format (SALTATIC, A073)Events Report (EVENTREP, J092)Improvised Explosive Device Report (IEDREP, A075) The INCREP is used to report any significant incident caused by terrorism, civil unrest, natural disaster, or media activity. The INCSPOTREP is used to provide time critical information on important events that have an immediate impact on operations. The SALTATIC is used to report troops in contact, the report should be made as soon as possible by the unit that has come under some form of attack. It uses the following basic format: Size of enemy, Action of enemy, Location, Time and Action taken The EVENTREP is used to provide the chain of command information about important Events, trends and activities that do not have an element of extreme urgency, but do influence on-going operations The IEDREP is sent when an IED has been encountered. It identifies the hazard area, tactical situation, operational priorities and the unit affected. This initial report should be followed by normal EOD/Engineer reporting requirements.

• NATO APP-11 Ed D Ver 1 - NATO Message Catalogue

Friendly Force Tracking Profile

The Friendly Force Tracking Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks.

Text-based Communication Services,

Track Distribution Services,

Track Management Services

Mandatory

• NATO APP-11 Ed D Ver 1 - NATO Message Catalogue
• NATO ADatP-36 Ed A Ver 2 - Friendly Force Tracking Systems (FFTS) Interoperability

Messages exchanged according to the exchange mechanisms described in ADatP-36(A)(2) shall comply with the Message Text Format (FFI MTF) schema incorporated in APP-11.IP1 is the preferred protocol for FMN Spiral 4. Where needed, the other ADatP-36(A)(2) protocols (IP2 or WSMP 1.3.2) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 4 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(A)(2) does not unambiguously state a version of WSMP to be used.

Tactical Message Distribution Profile

The Tactical Message Distribution Profile provides standards and guidance to support the exchange of selected messages between Tactical Data Link networks and IP based federation of networks.

Track Management Services,

Recognized Air Picture Services,

Recognized Ground Picture Services,

Recognized Maritime Picture Services,

Situational Awareness Services

Mandatory

The "Minimum Link-16 Message Profile", as described in the FMN Spiral 3 Service Interface Profile for RAP Data, defines the minimum set of data elements that are required to be available for operational or technical reasons so that correctly formatted technical message can be generated to establish the RAP in a federated environment. The implementation of the following message types of ATDLP-5.16 is MANDATORY and refers to Appendix A of the standard for the detailed requirement of receive or transmit support, also based on the role of the MNP: Precise Participant Location and Identification (PPLI) MessagesJ2.0 Indirect Interface Unit PPLIJ2.2 Air PPLIJ2.3 Surface (Maritime) PPLIJ2.4 Subsurface (Maritime) PPLIJ2.5 Land (Ground) Point PPLIJ2.6 Land (Ground) Track PPLISurveillance MessagesJ3.0 Reference PointJ3.1 Emergency PointJ3.2 Air Track messageJ3.3 Surface (Maritime) TrackJ3.4 Subsurface (Maritime) TrackJ3.5 Land (Ground) Point/TrackJ3.7 Electronic Warfare Product Information For MNPs that are contributing to Shared Situational Awareness production, the following messages should be supported to maximize the ability to share tactical data: J7 Information ManagementJ9 Weapons Coordination and ManagementJ10 Weapons Coordination and ManagementJ12 ControlJ13 Platform and System StatusJ15 Threat WarningJ17 Miscellaneous More recent editions of this standard may be implemented for operational use but ATDLP-5.16 is the minimum to guarantee Link 16 tactical message distribution.

• NATO ATDLP-5.16 Ed B Ver 1 - Tactical Data Exchange - Link 16

Mandatory

The JREAP Standard enables TDL data to be transmitted over digital media and networks not originally designed for tactical data exchange. JREAP consists of three different protocols: A, B and C. For implementation in FMN only JREAP-C 'Encapsulation over Internet Protocol (IP)' which enables TDL data to be transmitted over an IP network must be used. Refer to Appendix E of the standard for an overview of which messages are MANDATORY for implementation. Within JREAP-C, UTC must be supported as the common time reference. If no common time reference is available, round-trip shall be used.

• NATO ATDLP-5.18 Ed B Ver 2 - Interoperability Standard for Joint Range Extension Application Protocol (JREAP)

JREAP is designed to support operations using Link 16 over most communication media (JRE media) including forwarding TDL data over satellite communication links (JREAP-A), serial links (JREAP-B), and over IP networks (JREAP-C). Each JRE medium has unique characteristics. For implementation in FMN only JREAP-C Encapsulation over IP is to be used. It supports UDP Unicast, UDP multicast, and TCP.

Ground-to-Air Situational Awareness Profile

The Ground-to-Air (G2A) Situational Awareness Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16.

Track Distribution Services,

Track Management Services

Mandatory

• NATO ADatP-36 Ed A Ver 2 - Friendly Force Tracking Systems (FFTS) Interoperability
• NATO ADatP-37 Ed A Ver 1 - Services to forward Friendly Force Information to Weapon Delivery Assets

Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP).

Ground-to-Air Information Exchange Profile

The Ground-to-Air Information Exchange Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16.

Track Distribution Services,

Track Management Services

Mandatory

• NATO ADatP-37 Ed A Ver 1 - Services to forward Friendly Force Information to Weapon Delivery Assets

Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP).

Overlay Distribution Profile

The Overlay Distribution Profile covers the standards for overlays and (military) symbology that identify locations on the surface of the planet. These overlays are employed when disseminating recognized domain or functional pictures and related picture elements between different communities of interest in a federated mission network environment, as well as sharing with partners operating outside of the Operational Network.

Symbology Services

Mandatory

Applies to NVG only. Implementation Guidance is provided inNVG 2.0 APP-6D Bindings

• NATO APP-06 Ed D Ver 1 - NATO Joint Military Symbology

Conditional

Conditional for three use cases that typically involve cross-domain information exchange: sharing overlays outside of the Mission Network or,sharing overlays to exchange information in the form of Cross-security domain exchange. If an Affiliate has the requirement to share (export/import) with external (non-MN) organisations, then it is to support exchange via KMLexchanging of targeting and JISR products that are prepared on national networks. This particular COI have articulated a requirement to use KML for “Named Area of Interest”. In terms of conditionality, this use is to be defined by that COI. When exporting KML files that reference external resources, KML Zipped (KMZ) must be used and all relevant referenced external resources must be included in the KMZ structure as relative references. The references to these files can be found in the href attribute (or sometimes, the '"`UNIQ--nowiki-00008B5E-QINU`"' element) of several KML elements. To enable cross domain exchange and long-term preservation relative references must be used for those resources that are included in the KMZ structure. As many Earth Viewers only work with legacy PKZIP 2.x format for KMZ, .zip folders shall be created in accordance withhttps://www.pkware.com/documents/APPNOTE/APPNOTE-2.0.txt.

• OGC 07-147r2 - OGC KML 2.2.0

Mandatory

The minimum conformance level for Spiral 4 is defined as conformant with type B3R - as per the NVG 2.0.2 Specification summarized as: File-based and NVG Request/Response Protocol, all symbolized content, with timing information and operationally relevant extended data.

• NATO NVG 2.0.2 - NATO Vector Graphics (NVG) 2.0.2

All presentation services shall render tracks, tactical graphics, and battlespace objects using the defined symbology standards except in the case where the object being rendered is not covered in the standard. In these exceptional cases, additional symbols shall be defined as extensions of existing symbol standards and must be backwards compatible. These extensions shall be submitted as a request for change within the configuration management process to be considered for inclusion in the next version of the specification.

Routing Encapsulation Profile

The Routing Encapsulation Profile provides standards and guidance for generic routing encapsulation functions between network interconnection points (NIPs).

Packet-based Transport Services

Mandatory

• IETF RFC 2784 - Generic Routing Encapsulation (GRE)
• IETF RFC 4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
• IETF RFC 4303 - IP Encapsulating Security Payload (ESP)
• IETF RFC 4754 - IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)
• IETF RFC 4868 - Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
• IETF RFC 5903 - Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2
• IETF RFC 6379 - Suite B Cryptographic Suites for IPsec
• IETF RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2)
• IETF RFC 7427 - Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
• IETF RFC 7670 - Generic Raw Public-Key Support for IKEv2
• IETF RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)

Protected Core Networking does not support the use of pre-shared keys as an authentication method. While classified information domains in Coloured Clouds may use pre-shared keys in their NIP-G interfaces, IKEv2 is used for authentication both using digital certificates and pre-shared keys.

Inter-Autonomous Systems Routing Profile

The Inter-Autonomous Systems Routing Profile provides standards and guidance for routing between inter-autonomous systems. The best current practice for the Border Gateway Protocol (BGP) based network routing operations and security is described in RFC 7454 - "BGP Operations and Security". Deployment guidance with regards to the application of BGP in the Internet is described in IETF RFC 1772:1995.

IPv4 Routed Access Services,

Packet Routing Services

Mandatory

The following standards are added to improve BGP resilience through faster detection of network failures

• IETF RFC 5880 - Bidirectional Forwarding Detection (BFD)
• IETF RFC 5881 - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
• IETF RFC 5883 - Bidirectional Forwarding Detection (BFD) for Multihop Paths

Mandatory

The following standard applies for unicast routing.

• IETF RFC 4632 - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

Mandatory

The following standards apply for all IP interconnections.

• IETF RFC 1997 - Border Gateway Protocol (BGP) Communities Attribute
• IETF RFC 4271 - A Border Gateway Protocol 4 (BGP-4)
• IETF RFC 4360 - BGP Extended Communities Attribute
• IETF RFC 4760 - Multiprotocol Extensions for BGP-4
• IETF RFC 5492 - Capabilities Advertisement with BGP-4
• IETF RFC 6286 - Autonomous-System-Wide Unique BGP Identifier for BGP-4
• IETF RFC 6793 - BGP Support for Four-Octet Autonomous System (AS) Number Space
• IETF RFC 7153 - IANA Registries for BGP Extended Communities
• IETF RFC 7606 - Revised Error Handling for BGP UPDATE Messages

Conditional

Additionally, the following standard applies for 32-bit extended communities used for traffic engineering purposes. The confidition to use 32-bit extended communities is that MNSMA defines community values to be used for the traffic engineering as well as traffic engineering policies to be applied.

• IETF RFC 5668 - 4-Octet AS Specific BGP Extended Community

Mandatory

The following standard is added to improve security of BGP peering

• IETF RFC 5082 - The Generalized TTL Security Mechanism (GTSM)

BGP sessions must be authenticated, through a TCP message authentication code (MAC) using a one-way hash function (MD5), as described in IETF RFC 4271.

Inter-Autonomous Systems Multicast Routing Profile

The Inter-Autonomous Systems Multicast Routing Profile provides standards and guidance for multicast routing between inter-autonomous systems. Interconnections are based on bilateral agreements.

IPv4 Routed Access Services,

Packet Routing Services

Mandatory

Service providers with their own multicast capability shall provide a Rendezvous Point (RP) supporting the following IP multicast protocol standards.

• IETF RFC 4760 - Multiprotocol Extensions for BGP-4
• IETF RFC 3618 - Multicast Source Discovery Protocol (MSDP)

Mandatory

The following standards shall apply to multicast routing.

• IETF RFC 5771 - IANA Guidelines for IPv4 Multicast Address Assignments
• IETF RFC 2365 - Administratively Scoped IP Multicast
• IETF RFC 6308 - Overview of the Internet Multicast Addressing Architecture

Mandatory

These standards shall apply for all IP interconnections.

• IETF RFC 1112 - Host Extensions for IP Multicasting
• IETF RFC 3376 - Internet Group Management Protocol, Version 3
• IETF RFC 7761 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)

Web Feeds Profile

The Web Feeds Profile provides standards and guidance for the delivery of content to feed aggregators (web sites as well as directly to user agents).

Web Hosting Services

Mandatory

Web content providers must support at least one of the two standards (RSS and/or Atom).

• RSS RSS 2.0 Specification - RSS 2.0 Specification
• IETF RFC 4287 - Atom Syndication Format, v1.0
• IETF RFC 5023 - Atom Publishing Protocol

Mandatory

Receivers of web content such as news aggregators or user agents must support both the RSS and the ATOM standard.

• RSS RSS 2.0 Specification - RSS 2.0 Specification
• IETF RFC 4287 - Atom Syndication Format, v1.0
• IETF RFC 5023 - Atom Publishing Protocol

RSS and Atom documents should reference related OpenSearch description documents via the Atom 1.0 link element, as specified in Section 4.2.7 of RFC 4287.The rel attribute of the link element should contain the value search when referring to OpenSearch description documents. This relationship value is pending IANA registration. The reuse of the Atom link element is recommended in the context of other syndication formats that do natively support comparable functionality.The following restrictions apply

• The type attribute must contain the value application/opensearchdescription+xml.
• The rel attribute must contain the value search.
• The href attribute must contain a URI that resolves to an OpenSearch description document.
• The title attribute may contain a human-readable plain text string describing the search engine.

Web Hosting Services Metadata Labelling Profile

The Web Hosting Services Metadata Labelling Profile describes how to apply standard confidentiality metadata to web hosting services.

Web Hosting Services

Mandatory

The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata.

• NATO ADatP-4774 Ed A Ver 1 - Confidentiality Metadata Label Syntax
• NATO ADatP-4778 Ed A Ver 1 - Metadata Binding Mechanism
• FMN SIP for Binding Metadata to HTTP Messages - SIP for Binding Metadata to HTTP Messages
• FMN SIP for Binding Metadata to SOAP Messages - SIP for Binding Metadata to SOAP Messages

The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission.

Web Content Profile

The Web Content Profile provides standards and guidance for the processing, sharing and presentation of web content on federated mission networks. Web presentation services must be based on a fundamental set of basic and widely understood protocols, such as those listed below. Recommendations in the Service Interface Profile (SIP) for Web Applications are intended to improve the experience of Web applications and to make information and services available to users irrespective of their device and Web browser. However, it does not mean that exactly the same information is available in an identical representation across all devices: the context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Some services and information are more suitable for and targeted at particular user contexts. While services may be most appropriately experienced in one context or another, it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations.

Web Hosting Services

Mandatory

Providing a common style sheet language for describing presentation semantics (that is, the look and formatting) of documents written in markup languages like HTML.

• W3C CSS Color Module Level 3 - CSS Color Module Level 3
• W3C CSS Namespaces Module Level 3 - CSS Namespaces Module Level 3
• W3C CSS Style Attributes - CSS Style Attributes
• W3C REC-CSS2 - Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification

Mandatory

Publishing information including text, multi-media, hyperlink features, scripting languages and style sheets on the network.

• IETF RFC 2854 - The 'text/html' Media Type
• IETF RFC 4329 - Scripting Media Types
• W3C CSS Media Queries - CSS Media Queries
• W3C CSS Selectors Level 3 - CSS Selectors Level 4
• W3C APIs for HTML5 and XHTML - HTML5 - A vocabulary and associated APIs for HTML and XHTML (2014)

To enable the use of web applications by the widest possible audience, web applications shall be device independent and shall be based on HTML5 standards and criteria for the development, delivery and consumption of web applications and dynamic websites. HTML5 contains new features for attributes and behaviors, plus a large set of associated technologies such as CSS 3 and JavaScript that allows more diverse and powerful Web sites and applications.Web applications will not require any browser plug-ins on the client side as some organizations or end user devices do not allow the use of Java Applets or proprietary extensions such as Silverlight (Microsoft), Flash (Adobe) or Quick Time (Apple). Implementers shall use open standard based solutions (HTML5 / CSS3) instead.The requirements defined in the SIP for Web Applications are mandatory for all web content consumers (browsers) and are optional for web content providers. It is expected that in the future FMN Spiral Specifications they will also become mandatory for the web content providers.

Common File Format Metadata Labelling Profile

The Common File Format Metadata Labelling Profile describes how to apply standard confidentiality metadata to common file formats.

Information Products

Mandatory

The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata.

• NATO ADatP-4774 Ed A Ver 1 - Confidentiality Metadata Label Syntax
• NATO ADatP-4778 Ed A Ver 1 - Metadata Binding Mechanism
• FMN SIP for Binding Metadata to Common File Formats - SIP for Binding Metadata to Common File Formats

The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission.

Web Service Messaging Profile

The Web Service Messaging Profile (WSMP) defines a set of service profiles to exchange a wide range of XML-based messages. WSMP is extensible and may be used by any Community of Interest (COI). It is based on publicly available standards and defines a generic message exchange profile based on the Request/Response (RR) and the Publish/Subscribe (PubSub) Message Exchange Pattern (MEP). WSMP is platform independent and can be profiled for different wire protocols such as SOAP. Other protocols like REST, JMS, AMQP, and WEBSocket will be profiled later. This profile is intended for software developers to implement interoperable "WSMP services" and "WSMP clients".

Message-Oriented Middleware Services

Mandatory

• NATO ADatP-5644 (FD) Ed A Ver 1 - Web Service Messaging Profile (WSMP)

To enable plug-and-play interoperability a pre-defined minimum set of topics referenced and shared by multiple communities of interest is recommended. This TopicNamespace is included in Annex A Information Products - Detailed Definitions to the FMN Spiral 4 Procedural Instructions for Situational Awareness.The version of the WSMP Standard used with MIP4-IES (Version 4.3) is WSMP 1.3.2.

Web Platform Profile

The Web Platform Profile provides standards and guidance to enable web technology on federated mission networks.

Web Hosting Services

Mandatory

• IETF RFC 1738 - Uniform Resource Locators (URL)
• IETF RFC 2817 - Upgrading to TLS Within HTTP/1.1
• IETF RFC 3986 - Uniform Resource Identifiers (URI): Generic Syntax
• IETF RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• IETF RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• IETF RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
• IETF RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests
• IETF RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching
• IETF RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication

HTTP MAY (only) be used as the transport protocol for CRL and AIA exchange between all service providers and consumers (unsecured HTTP traffic). HTTP traffic shall use port 80 by default.HTTPS MUST be used as the transport protocol between all service providers and consumers to ensure confidentiality requirements (secured HTTP traffic). HTTPS traffic shall use port 443 by default.

Web Services Profile

The Web Services Profile provides standards and guidance for transport-neutral mechanisms to address structured exchange of information in a decentralized, distributed environment via web services.

Web Hosting Services

Mandatory

Provide the elements a web service needs to deliver a suitable UI service, such as remote portlet functionality.

• W3C Cross-Origin Resource Sharing - Cross-Origin Resource Sharing

Mandatory

• W3C SOAP 1.1 - Simple Object Access Protocol (SOAP) 1.1
• W3C WSDL 1.1 - Web Service Description Language (WSDL) 1.1
• W3C WS-Addressing 1.0 - Core - Web Services Addressing 1.0 - Core
• W3C WSDL 2.0 SOAP 1.1 binding - Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding

The preferred method for implementing web-services are SOAP, however, there are many use cases (mashups etc.) where a REST based interface is easier to implement and sufficient to meet the IERs.Restful services support HTTP caching, if the data the Web service returns is not altered frequently and not dynamic in nature. REST is particularly useful for restricted-profile devices such as mobile phones and tablets for which the overhead of additional parameters like headers and other SOAP elements are less. The foundational document of the REST architectural style may be found athttp //www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

Structured Data Profile

The Structured Data Profile provides standards and guidance for the structuring of web content on federated mission networks.

Web Hosting Services

Mandatory

General formatting of information for sharing or exchange.

• W3C XHTML 1.0 in XML Schema - XHTML™ 1.0 in XML Schema
• IETF RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON)
• W3C XML 1.0 (Fith Edition) - eXtensible Markup Language (XML) 1.0 (Fifth Edition)
• W3C XML Schema Part 1: Structures Ed 2 - XML Schema Part 1: Structures Second Edition
• W3C XML Schema Part 1: Datatypes Ed 2 - XML Schema Part 2: Datatypes Second Edition

XML shall be used for data exchange to satisfy those Information Exchange Requirements (IERs) within a FMN mission network instance that are not addressed by a specific information exchange standard. XML schemas and namespaces are required for all XML documents.

Web Authentication Profile

The Web Authentication Profile provides standards and guidance in support of principal authentication and exchange of authenticated principal's identity attributes between Mission Network Participants.

Authentication Services

Mandatory

• IETF RFC 3986 - Uniform Resource Identifiers (URI): Generic Syntax
• IETF RFC 5322 - Internet Message Format
• OASIS SAML V2.0 - OASIS SAML V2.0 Metadata Interoperability Profile
• IETF RFC 2256 - A summary of the X.500(96) User Schema for Use with LDAPv3
• IETF RFC 2798 - Definition of the inetOrgPerson LDAP Object Class
• IETF RFC 4519 - Lightweight Directory Access Protocol (LDAP) - Schema for User Applications

Identity providers must support the following components of the SAML 2.0 specification

• Profiles Web Browser SSO Profile and Single Logout Profile.
• Bindings HTTP Redirect Binding and HTTP POST Binding.

Directory Data Structure Profile

The Directory Data Structure Profile provides standards and guidance in support of the definition of the namespace of a federated mission network on the basis of the Lightweight Directory Access Protocol (LDAP).

Directory Services

Mandatory

• IETF RFC 2798 - Definition of the inetOrgPerson LDAP Object Class
• IETF RFC 4519 - Lightweight Directory Access Protocol (LDAP) - Schema for User Applications

The Federated Directory Services shall be able to exchange inetOrgPerson object class with mandatory Common Name (cn) and Surname (sn) attributes. Based on the specific mission network's requirements, the list of exchanged attributes for a particular mission network might be extended by Service Management Authority (SMA) during the planning process.

Directory Data Exchange Profile

The Directory Data Exchange Profile provides standards and guidance in support of a mechanism used to connect to, search, and modify Internet directories on the basis of the Lightweight Directory Access Protocol (LDAP).

Directory Services

Mandatory

• IETF RFC 4519 - Lightweight Directory Access Protocol (LDAP) - Schema for User Applications
• IETF RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification
• IETF RFC 4510 - Lightweight Directory Access Protocol (LDAP) - Technical Specification Road Map
• IETF RFC 4511 - Lightweight Directory Access Protocol (LDAP) - The Protocol
• IETF RFC 4512 - Lightweight Directory Access Protocol (LDAP) - Directory Information Models
• IETF RFC 4513 - Lightweight Directory Access Protocol (LDAP) - Authentication Methods and Security Mechanisms
• IETF RFC 4514 - Lightweight Directory Access Protocol (LDAP) - String Representation of Distinguished Names
• IETF RFC 4515 - Lightweight Directory Access Protocol (LDAP) - String Representation of Search Filters
• IETF RFC 4516 - Lightweight Directory Access Protocol (LDAP) - Uniform Resource Locator
• IETF RFC 4517 - Lightweight Directory Access Protocol (LDAP) - Syntaxes and Matching Rules
• IETF RFC 4518 - Lightweight Directory Access Protocol (LDAP) - Internationalized String Preparation

IP Quality of Service Profile

The IP Quality of Service Profile provides standards and guidance to establish and control an agreed level of performance for Internet Protocol (IP) services in federated networks.

Packet-based Transport Services,

IPv4 Routed Access Services

Mandatory

The following normative standards shall apply for IP Quality of Service (QoS).

• NATO AComP-4711 Ed A Ver 1 - Interoperability Point Quality of Service (IP QoS)

Mandatory

Utilize Quality of Service capabilities of the network (Diffserve, no military precedence on IP).

• IETF RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
• IETF RFC 4594 - Configuration Guidelines for DiffServ Service Classes
• ITU-T Y.1540 - Internet protocol data communication service - IP packet transfer and availability performance parameters
• ITU-T Y.1541 - Network performance objectives for IP-based services
• ITU-T Y.1542 - Framework for achieving end-to-end IP performance objectives
• ITU-T M.2301 - Performance objectives and procedures for provisioning and maintenance of IP-based networks
• ITU-T J.241 - Quality of service ranking and measurement methods for digital video services delivered over broadband IP networks

Inter-Autonomous Systems IP Communications Security Profile

The Inter-Autonomous Systems IP Communications Security Profile provides standards and guidance for communications security for transporting IP packets between federated mission network interconnections and in general over the whole Mission Network.

Transport CIS Security Services

Conditional

In missions where no NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected with technical structures by mutual agreement made during the mission planning phase.

• NSA CSfC MSC CP Ver 1.0 - CSfC Multi-Site Connectivity Capability Package Ver 1.1
• DPC AC/322-D(2015)0031 - CIS Security Technical and Implementation Directive on Cryptographic Security and Mechanisms for the Protection of NATO Information within NNN & IO CIS

Conditional

In missions where NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected at minimum with Type-B crypto devices.

• DPC AC/322-D(2015)0031 - CIS Security Technical and Implementation Directive on Cryptographic Security and Mechanisms for the Protection of NATO Information within NNN & IO CIS

In missions where the mission network classification is MISSION RESTRICTED (MR) or lower, communication infrastructure is protected at the minimum with technical structures that comply with the Security section in the Service Instructions for Communications, and in the Routing Encapsulation Profile.

Inter-Autonomous Systems IP Transport Profile

The Inter-Autonomous Systems IP Transport Profile provides standards and guidance for Edge Transport Services between autonomous systems, using the Internet Protocol (IP) over point-to-point ethernet links on optical fibre.

Packet-based Transport Services

Mandatory

For automatic detection of MTU between end-points.

• IETF RFC 1191 - Path MTU Discovery

Mandatory

The use of LC-connectors is required for network interconnections inside shelters (or inside other conditioned infrastructure).

• IEC 61754-20-100 - Interface standard for LC connectors with protective housings related to IEC 61076-3-106
• ITU-T G.652 - Characteristics of a single-mode optical fibre and cable

Mandatory

Standards for IP version 4 (IPv4) over Ethernet.

• IETF RFC 826 - Ethernet Address Resolution Protocol
• IETF RFC 894 - A Standard for the Transmission of IP Datagrams over Ethernet Networks

Mandatory

Section 3 - Clause 38 - 1000BASE-LX, nominal transmit wavelength 1310nm.

• IEEE 803.3 - IEEE Standard for Ethernet

Mandatory

• ISO/IEC 11801-1 - Information technology -- Generic cabling for customer premises -- Part 1: General requirements

Conditional

If the interconnection point is outside a shelter in a harsh environment, the interconnection shall follow AComP-4290 or MIL-DTL-83526 connector specifications.

• US DoD MIL-DTL-83526C - Connector, Fibre Optic, Circular Hermaphroditic, Bulkhead, Low Profile Without Strain Relief, Jam-Nut Mount, 2 and 4 Positions, Expanded Beam
• NATO AComP-4290 Ed A Ver 2 - Standard for optical connector medium-rate and high-rate military tactical link

Use 1 Gb/s ethernet over single-mode optical fibre (SMF).

Tactical Interoperability Network Interconnection Profile

The Tactical Interoperability Network Interconnection Profile provides standards and guidance for a shared interoperability network at the mobile tactical edge: when no common waveform for land tactical radios can be used to interconnect networks, a standard "bridging" solution with loaned radios can be used to mitigate the interoperability problem. In that situation, interoperability will be achieved with the exchange of assets. Information exchange for mobile users at the tactical edge is based on STANAG 4677. The information exchange over the loaned radio interface shall be protected with similar mechanisms that are required to protect NATO RESTRICTED information or an equivalent mission classification level. The protection of information at the lower tactical level has a number of distinctive characteristics: The information is often transient and perishable – it is only relevant for a short period of time.The transmission of information is confined to a small geographic area.The information is held on portable devices which are often close to physical threats.The networks at the lower tactical level are often isolated from the wider network.

Packet-based Transport Services,

IPv4 Routed Access Services

Mandatory

Implement the following standard in addition to RFC 1112.

• IETF RFC 2236 - Internet Group Management Protocol, Version 2

Mandatory

• IETF RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
• IETF RFC 1191 - Path MTU Discovery
• IETF RFC 894 - A Standard for the Transmission of IP Datagrams over Ethernet Networks
• IETF RFC 950 - Internet Standard Subnetting Procedure
• IETF RFC 1112 - Host Extensions for IP Multicasting
• IETF RFC 1918 - Address Allocation for Private Internets
• IETF RFC 4632 - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
• IETF RFC 5771 - IANA Guidelines for IPv4 Multicast Address Assignments
• NATO AEP-76 Vol V Ed A Ver 2 - Specifications Defining the Joint Dismounted Soldier System Interoperability Network (JDSSIN) - Network Access

This profile is to be used exclusively for operations at the tactical edge (TACCIS [MC0640]) and not in combination with any of the other profiles defined in the SP4 SI for Communications, which are targeted at OPCIS [MC0640].

Interface Auto-Configuration Profile

The Interface Auto-Configuration Profile provides standards and guidance for support of the Routing Information Protocol (RIPv2 and RIPng) to expand the amount of useful information carried in RIP messages for the exploitation of auto-configurations over NIP-G and PCN-compliant interfaces, and for the inclusion of a measure of control.

Packet-based Transport Services

Mandatory

• IETF RFC 2080 - Routing Information Protocol next generation for IPv6 (RIPng)
• IETF RFC 2453 - Routing Information Protocol (RIP) Version 2

The auto-configuration is a highly recommended feature for the desired flexibility, maintainability and survivability in communications systems configuration. Nevertheless, there is always an option to follow a manual configuration process. This implies that auto-configuration in itself is not mandatory; when applied, the listed standards are mandatory.

Formatted Messages for MedEvac Profile

The Formatted Messages Profile for Medical Evacuation (MedEvac) provides standard for formatted messages that are typically used for C2 of Medical Evacuation missions. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), text collaboration (chat) or in standardized voice procedures.

Text-based Communication Services,

Informal Messaging Services,

Audio-based Communication Services

Mandatory

C2 of MedEvac Missions requires the following messages: Situational Awareness:Incident Report (INCREP – A078)Incident Spot Report (INCSPOTREP – J006)Troops in Contact SALTA Format (SALTATIC A073)Requests:Medical Evacuation Request (MEDEVAC – A012)Mechanism Injury Symptoms Treatment (MIST‐AT, supplement to A012)Diving Accident (DIVEACC – N019)Evacuation Request (EVACREQ – N096)

• NATO APP-11 Ed D Ver 1 - NATO Message Catalogue
• NATO AJMedP-2 Ed A Ver 1 - Allied Joint Medical Doctrine For Medical Evacuation
• NATO ATP-97 Ed A Ver 1 - NATO Land Urgent Voice Messages (LUVM) Pocket Book

Web Feature Service Profile

The Web Feature Service Profile provides standards and guidance for in support of Geospatial Services to provide a standardized interface for geodata provision in a defined format over a network connection.

Geospatial Web Feature Services

Mandatory

• OGC 09-025r2 - OGC Web Feature Service (WFS) 2.0 Interface Standard With Corrigendum

Implementation guidance can be found in DGIWG 122, Defence Profile of OGC’s Web Feature Service 2.0 v.2.0.1, 28 November 2017.

Geospatial Web Feeds Profile

The Geospatial Web Feeds Profile provides standards and guidance for in support of Geospatial Services to deliver geospatial content to web sites and to user agents, including the encoding of location as part of web feeds.

Web Hosting Services

Mandatory

GML subset for point "gml:Point", line "gml:LineString", polygon "gml:Polygon", and box "gml:Envelope". In Atom feeds, location shall be specified using Atom 1.0's official extension mechanism in combination with the GeoRSS GML Profile 1.0 whereby a "georss:where" element is added as a child of the <entry> element.

• OGC 03-105r1 - OpenGIS Geography Markup Language (GML) Implementation Specification version 3.1.1.

Mandatory

GeoRSS Simple encoding for "georss:point", "georss:line", "georss:polygon", "georss:box".

• OGC GeoRSS Schema 1.1 - GML application schema for the Simple and GML serializations of GeoRSS

Geography Markup Language (GML) allows to specify a coordinate reference system (CRS) other than WGS84 decimal degrees (lat/long). If there is a need to express geography in a CRS other than WGS84, it is recommended to specify the geographic object multiple times, one in WGS84 and the others in your other desired CRSs.

Geospatial Data Exchange Profile

The Geospatial Data Exchange Profile provides standards and guidance in support of Geospatial Services to produce and exchange geospatial data between different participants using standardized exchange formats. These datasets will be loaded into specialized geospatial information systems (GIS) and published via standardized web services.

Geospatial Services

Mandatory

This ESRI Technical Paper describes XML schemas for the Geodatabase in order to enable exchange of digital geospatial data. In contrary to the ESRI Arc Geodatabase (File-based), this document is freely available to the public and does not require vendor-specific licenses.

• ESRI XML Schema of the Geodatabase - XML Schema of the Geodatabase

Mandatory

Exchange of Digital Vector Data

• US DoD MIL-PRF-89039 - Vector Smart Map (VMAP) Level 0
• US DoD MIL-PRF-89033 - Vector Smart Map (VMAP) Level 1
• NATO AGeoP-11 Ed B Ver 1 - NATO Geospatial Information Framework
• NATO AGeoP-19 Ed A Ver 1 - Additional Military Layers (AML) - Digital Geospatial Data Products
• ESRI shapefile - ESRI Shapefile Technical Description

Mandatory

Exchange of Digital Raster Data

• NATO AGeoP-11 Ed B Ver 1 - NATO Geospatial Information Framework
• NATO AGeoP-19 Ed A Ver 1 - Additional Military Layers (AML) - Digital Geospatial Data Products
• US DoD MIL-PRF-89038 - Compressed ARC Digitized Raster Graphics (ADRG)
• NGA MIL-STD-2411 - Raster Product Format
• OGC 05-047r3 - GML in JPEG 2000 for Geographic Imagery (GMLJP2)
• US DoD PRF-89020B - Performance Specification - Digital Terrain Elevation Data
• ISO/IEC 15444-1 - JPEG 2000 image coding system — Part 1: Core coding system

Implementation guidance for GeoTIFF Format Specification is defined in STANAG 2592 - AGeoP 11.3 GeoTIFF Raster Format Specification – Edition A – Version 1 – December 2018.

Web Map Tile Service Profile

The Web Map Tile Service Profile provides standards and guidance in support of Geospatial Services to provide a standardized protocol for serving pre-rendered georeferenced map tiles over the Internet.

Geospatial Web Map Tile Services

Mandatory

• OGC 07-057r7 - OpenGIS Web Map Tile Service Implementation Standard
• NATO AGeoP-26 Ed A Ver 1 - Defence Geospatial Web Services

Implementation Guidance Service Providers can select which profile(s) to implement, and should put emphasis on DGIWG Profiles. Service Consumers that want to consume WMS/WMTS services provided by the NATO Command Structure must implement the NCIA SIP.

Web Map Service Profile

The Web Map Service Profile provides standards and guidance in support of Geospatial Services to provide a standardized interface for geodata provision in a defined format over a network connection.

Geospatial Web Map Services

Mandatory

• NATO AGeoP-26 Ed A Ver 1 - Defence Geospatial Web Services
• OGC 06-042 - OpenGIS Web Map Service (WMS) Implementation Specification

Service Providers can select which profile(s) to implement, and should put emphasis on DGIWG Profiles. Service Consumers that want to consume WMS/WMTS services provided by the NATO Command Structure must implement the NCIA SIP.

Audio-based Collaboration Profile

The Audio-based Collaboration Profile provides standards and guidance for the implementation of an interoperable voice system (telephony) on federated mission networks.

Audio-based Communication Services

Mandatory

The following standards are used for audio protocols.

• ITU-T G.711 - Pulse code modulation (PCM) of voice frequencies
• ITU-T G.722.1 - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss
• ITU-T G.722.1 (2005) Corrigendum 1 (06/08) - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss
• ITU-T G.729 - Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)

Voice over IP (VoIP) refers to unprotected voice communication services running on unclassified IP networks e.g. conventional IP telephony. Voice over Secure IP (VoSIP) refers to non-protected voice service running on a classified IP networks. Depending on the security classification of a FMN instance, VoIP or VoSIP is mandatory.If a member choses to use network agnostic Secure Voice services in addition to VoSIP, then SCIP specifications as defined for audio-based collaboration services (end-to-end protected voice) shall be used.The voice sampling interval is 40ms.

Voice Services Call Signaling Profile

Standards profile for signaling of voice services.

Audio-based Communication Services

Mandatory

• ITU-T G.711 - Pulse code modulation (PCM) of voice frequencies
• ITU-T G.722.1 - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss
• ITU-T G.722.1 (2005) Corrigendum 1 (06/08) - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss
• ITU-T G.729 - Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)

VTC Services Call Signaling Profile

Standards profile for signaling of video teleconferencing services.

Video-based Communication Services

Mandatory

• ITU-T H.264 - Advanced video coding for generic audiovisual services
• ITU-T G.711 - Pulse code modulation (PCM) of voice frequencies
• ITU-T G.722.1 - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss
• ITU-T G.722.1 (2005) Corrigendum 1 (06/08) - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss

Priority and Pre-emption Profile

The Priority and Pre-emption Profile provides standards are used to execute priority and pre-emption service with the Session Initiation protocol (SIP).

Video-based Communication Services,

Audio-based Communication Services

Mandatory

• IETF RFC 4411 - Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events
• IETF RFC 4412 - Communications Resource Priority for the Session Initiation Protocol (SIP)

SRTP-based Media Infrastructure Security Profile

The SRTP-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP).

Transport CIS Security Services

Conditional

Securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.

• IETF RFC 5246 - Transport Layer Security (TLS)The Transport Layer Security (TLS) Protocol Version 1.2
• IETF RFC 7919 - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
• IETF RFC 3711 - The Secure Real-time Transport Protocol (SRTP)
• IETF RFC 4568 - Session Description Protocol (SDP) Security Descriptions for Media Streams

Note that securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning.

IPSec-based Media Infrastructure Security Profile

The IPSec-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Internet Protocol Security (IPSec).

Infrastructure CIS Security Services,

Network Access Control Services

Conditional

Securing the media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.

• IETF RFC 4303 - IP Encapsulating Security Payload (ESP)
• IETF RFC 4754 - IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)
• IETF RFC 5903 - Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2
• IETF RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2)
• IETF RFC 7427 - Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
• IETF RFC 7670 - Generic Raw Public-Key Support for IKEv2

Session Initiation and Control Profile

The Session Initiation and Control Profile provides standards used for session initiation and control.

Video-based Communication Services

Mandatory

The following standards define the Session Initiation Protocol (SIP) and Real-time Transport Protocol (RTP) support for conferencing.

• IETF RFC 4353 - A Framework for Conferencing with the Session Initiation Protocol (SIP)
• IETF RFC 4579 - Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents
• IETF RFC 5366 - Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
• IETF RFC 7667 - RTP Topologies

Mandatory

The following standards are used for regular Session Initiation Protocol (SIP) support..

• IETF RFC 3261 - Session Initiation Protocol (SIP)
• IETF RFC 3262 - Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
• IETF RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP)
• IETF RFC 3311 - The Session Initiation Protocol (SIP) UPDATE Method
• IETF RFC 4028 - Session Timers in the Session Initiation Protocol (SIP)
• IETF RFC 4566 - SDP: Session Description Protocol
• IETF RFC 6665 - SIP-Specific Event Notification

Media Streaming Profile

The Media Streaming Profile provides standards used to stream media across the mission network.

Audio-based Communication Services

Mandatory

• IETF RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
• IETF RFC 4733 - RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals

SCIP PPK Profile

In the context of secure communications, PPK is the Pre-Placed Key, which is a symmetric encryption key, pre-positioned in a cryptographic unit. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network.

Communications Services

Conditional

When PPK is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.

• CIS3 C&IP SCIP-233.104 - NATO Pre Placed Key (PPK) Key Material Format and Fill Checks Specification Rev.1.0
• CIS3 C&IP SCIP-233.304 - NATO Point-to-Point and Multipoint PPK-Processing Specification Rev.1.0
• CIS3 C&IP SCIP-233.350 - Interoperable Terminal Priority (TP) Community of Interest (COI) Specification rev.1.0
• CIS3 C&IP SCIP-233.401 - Application State Vector Processing Specification rev.1.2
• CIS3 C&IP SCIP-233.422 - NATO Fixed Filler Generation Specification Rev. 1.0.
• CIS3 C&IP SCIP-233.441 - Point-to-Point Cryptographic Verification Specification Rev. 1.1.
• CIS3 C&IP SCIP-233.601 - AES-256 Encryption Algorithm Specification Rev. 1.0.

SCIP X.509 Profile

The X.509 standard is used in cryptography to define the format of public key certificates, which are used in many Internet protocols. One example is the use in Transport Layer Security (TLS) / Secure Sockets Layer (SSL), which is the basis for HTTPS, the secure protocol for browsing the web. Public key certificates are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. Besides the format for certificates themselves, X.509 specifies certificate revocation lists as a means to distribute information about certificates that are no longer valid, and a certification path validation algorithm, which allows for certificates to be signed by intermediate Certificate Authority (CA) certificates, which are in turn signed by other certificates, eventually reaching a trust anchor. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network.

Communications Services

Conditional

When X.509 is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.

• CIS3 C&IP SCIP-233.401 - Application State Vector Processing Specification rev.1.2
• CIS3 C&IP SCIP-233.601 - AES-256 Encryption Algorithm Specification Rev. 1.0.
• CIS3 C&IP SCIP-233.109 - X.509 Elliptic Curve (EC) Key Material Format Specification
• CIS3 C&IP SCIP-233.307 - ECDH Key Agreement and TEK Derivation rev.1.1
• CIS3 C&IP SCIP-233.423 - Universal Fixed Filler Generation Specification Rev. 1.0.
• CIS3 C&IP SCIP-233.444 - Point-to-Point Cryptographic Verification w/Signature rev.1.0

Secure Voice Profile

The Secure Voice Profile provides standards and guidance for the facilitation of secure telephony and other protected audio-based collaboration on federated mission networks.

Audio-based Communication Services

Mandatory

SCIP Secure Applications.

• CIS3 C&IP SCIP-233.501 - Secure MELP(e) Voice rev.1.1
• CIS3 C&IP SCIP-233.502 - Secure G.729D Voice Specification Rev. 1.1.

Mandatory

SCIP Network Standards for operation over VoIP Real-time Transport Protocol (RTP).

• CIS3 C&IP SCIP-214.2 - SCIP over RTP rev.1.0
• CIS3 C&IP SCIP-214.3 - Securing SIP Signaling - Use of TLS with SCIP

Mandatory

SCIP Signaling Plan and Negotiation.

• CIS3 C&IP SCIP-233.350 - Interoperable Terminal Priority (TP) Community of Interest (COI) Specification rev.1.0
• CIS3 C&IP SCIP-210 - SCIP Signalling Plan rev.3.3

Conditional

SCIP Network Standards for operation over other network types.

• CIS3 C&IP SCIP-214.1 - SCIP over the PSTN rev.1.0
• CIS3 C&IP SCIP-215 - U.S. SCIP/IP Implementation Standard and MER Publication rev.2.2
• CIS3 C&IP SCIP-216 - Minimum Essential Requirements (MER) for V.150.1 Gateways Publication rev.2.2

AComP-5068 Secure Communications Interoperability Protocol (SCIP) Edition A Version 1provides further guidance for the implementation of SCIP specifications.

Text-based Collaboration Services Metadata Labelling Profile

The Text-Based Collaboration Services Metadata Labelling Profile describes how to apply standard Confidentiality Metadata to Text-Based Collaboration Services.

Text-based Communication Services

Mandatory

The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata.

• NATO ADatP-4774 Ed A Ver 1 - Confidentiality Metadata Label Syntax
• NATO ADatP-4778 Ed A Ver 1 - Metadata Binding Mechanism
• FMN SIP for Binding Metadata to XMPP Stanzas - SIP for Binding Metadata to XMPP Stanzas

The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission.

Text-based Collaboration Data Forms Profile

The Text-based Collaboration Forms Profile provides standards and guidance to use (define, discover, fetch and submit) the data forms for use by XMPP entities.

Text-based Communication Services

Mandatory

• XSF XEP-0004 - XEP-0004: Data Forms (2020/05)
• XSF XEP-0068 - XEP-0068: Field Standardization for Data Forms
• XSF XEP-0346 - XEP-0346: Form Discovery and Publishing

Text-based Collaboration Chatroom Profile

The Text-based Collaboration Chatroom Profile provides standards and guidance to host chatrooms to support persistent near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations.

Text-based Communication Services,

Presence Services

Mandatory

XMPP Services hosting the shared chatrooms must comply with the following additional extensions.

• XSF XEP-0045 - XEP-0045: Multi-User Chat (2019/05)
• XSF XEP-0059 - XEP-0059: Result Set Management
• XSF XEP-0082 - XEP-0082: XMPP Date and Time Profiles
• XSF XEP-0313 - XEP-0313: Message Archive Management (2017/02)

Text-based Collaboration Profile

The Text-based Collaboration Profile provides standards and guidance to establish a basic near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations.

Text-based Communication Services,

Presence Services

Mandatory

The following standards are the base IETF protocols for interoperability of chat services.

• IETF RFC 6120 - Extensible Messaging and Presence Protocol (XMPP): Core
• IETF RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
• IETF RFC 6122 - Extensible Messaging and Presence Protocol (XMPP): Address Format

Mandatory

The following standards are required to achieve compliance for an XMPP Server and an XMPP Client dependent upon the categorisation of presenting a core or advanced instant messaging service interface.

• XSF XEP-0012 - XEP-0012: Last Activity
• XSF XEP-0030 - XEP-0030: Service Discovery (2017/10)
• XSF XEP-0047 - XEP-0047: In-Band Bytestreams
• XSF XEP-0054 - XEP-0054: vcard-temp
• XSF XEP-0055 - XEP-0055: Jabber Search
• XSF XEP-0060 - XEP-0060: Publish-Subscribe (2020/02)
• XSF XEP-0092 - XEP-0092: Software Version
• XSF XEP-0106 - XEP-0106: JID Escaping
• XSF XEP-0114 - XEP-0114: Jabber Component Protocol
• XSF XEP-0115 - XEP-0115: Entity Capabilities (2020/05)
• XSF XEP-0160 Ver 1.0 - XEP-0160: Best Practices for Handling Offline Messages (2016/01)
• XSF XEP-0199 - XEP-0199: XMPP Ping (2009/06)
• XSF XEP-0202 - XEP-0202: Entity Time
• XSF XEP-0203 - XEP-0203: Delayed Delivery
• XSF XEP-0220 - XEP-0220: Server Dialback (2015/03)

Video-based Collaboration Profile

The Video-based Collaboration Profile provides standards and guidance for the implementation and configuration of video teleconferencing (VTC) systems and services in a federated mission network.

Video-based Communication Services

Mandatory

The following standards are required for video coding in VTC.

• IETF RFC 6184 - RTP Payload Format for H.264 Video
• ITU-T H.264 - Advanced video coding for generic audiovisual services

Conditional

Use of the BFCP is conditional to that VTC conferencing services are used with the shared content like presentations and/or screen sharing, whose control needs to be shared among participants.

• IETF RFC 4582 - The Binary Floor Control Protocol (BFCP)

Mandatory

The following standards are required for audio coding in VTC.

• ITU-T G.711 - Pulse code modulation (PCM) of voice frequencies
• ITU-T G.722.1 - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss
• ITU-T G.722.1 (2005) Corrigendum 1 (06/08) - Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss

It Is recommended that dynamic port ranges are constrained to a limited and agreed number. This is an activity that needs to be performed at the mission planning stage. Different vendors have different limitations on fixed ports. However, common ground can always be found.As a minimum G.722.1 is to be used. Others are exceptions and need to be agreed by the mission network's administrative authority for video calls.

Content Encapsulation Profile

The Content Encapsulation Profile provides standards and guidance for content encapsulation within bodies of internet messages, following the Multipurpose Internet Mail Extensions (MIME) specification.

Informal Messaging Services

Mandatory

Media and content types.

• W3C APIs for HTML5 and XHTML - HTML5 - A vocabulary and associated APIs for HTML and XHTML (2014)
• IETF RFC 1896 - The text/enriched MIME Content-type
• IETF RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
• IETF RFC 3676 - The Text/Plain Format and DelSp Parameters
• IETF RFC 5147 - URI Fragment Identifiers for the text/plain Media Type
• W3C XHTML 1.0 in XML Schema - XHTML™ 1.0 in XML Schema

Mandatory

MIME encapsulation.

• IETF RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
• IETF RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
• IETF RFC 2047 - Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text
• IETF RFC 2049 - Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Example
• IETF RFC 6152 - SMTP Service Extension for 8-bit MIME Transport

Informal Messaging Profile

The Informal Messaging Profile provides standards and guidance for settings of Simple Mail Transfer Protocol (SMTP).

Informal Messaging Services

Mandatory

These standards are mandated for interoperability of e-mail services within the mission network.

• IETF RFC 1870 - SMTP Service Extension for Message Size Declaration
• IETF RFC 2034 - SMTP Service Extension for Returning Enhanced Error Codes
• IETF RFC 2920 - SMTP Service Extension for Command Pipelining
• IETF RFC 3207 - MTP Service Extension for Secure SMTP over Transport Layer Security (TLS)
• IETF RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
• IETF RFC 4954 - SMTP Service Extension for Authentication
• IETF RFC 5321 - Simple Mail Transfer Protocol
• IETF RFC 5322 - Internet Message Format

TLS with mutual authentication is mandatory for all SMTP communications. Detailed TLS protocol requirements are specified in the 'Service Interface Profile for Transport Layer Security'.

Informal Messaging Services Metadata Labelling Profile

The Informal Messaging Services Metadata Labelling Profile describes how to apply standard Confidentiality Metadata to Informal Messaging Services.

Informal Messaging Services

Mandatory

The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata.

• NATO ADatP-4774 Ed A Ver 1 - Confidentiality Metadata Label Syntax
• NATO ADatP-4778 Ed A Ver 1 - Metadata Binding Mechanism
• FMN SIP for Binding Metadata to Informal Messages - SIP for Binding Metadata to Informal Messages

The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission.

Calendaring Exchange Profile

The Calendaring Exchange Profile provides standards and guidance for the exchange meeting requests, free/busy information as well as calendar sharing implemented by common user access (CUA) software. The focus of this profile is on the exchange of the aforementioned information items and does not cover other typical features found in collaboration software.

Calendaring and Scheduling Services

Mandatory

• IETF RFC 5545 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)
• IETF RFC 5546 - iCalendar Transport-Independent Interoperability Protocol (iTIP)
• IETF RFC 6047 - iCalendar Message-Based Interoperability Protocol (iMIP)

RFC 5545 is required in order to allow a vendor independent representation and exchange of calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol.RFC 5546 defines the scheduling methods that permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling.RFC 6047 defines how calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped and transported over SMTP. Authentication, Authorization and Confidentiality with S/MIME (section 2.2 of RFC 6047) is not applicable for this profile.