Title
FMN Spiral 5 Standards Profile

Reference document

Org
FMN
Pubnum
Date
2021-10-20
Version
Title
Proposed FMN Spiral 5 Specification

Subprofiles

Status

URI

History

Flag Date RFC Version
added 2022-05-06 14-032 15.0
UUID
c7b21062-3aea-492a-8cfe-062bdb9b9551

FMN Spiral 5 Standards Profile

Infrastructure Standards Profiles

Infrastructure Security Standards Profiles

Service Standard Implementation Guidance

Certificates Exchange Profile

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

Digital Certificate Services,

Technical Services

Candidate

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

Candidate

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

Digital Certificate Validation (CRL) Profile

The Digital Certificate Validation (CRL) Profile provides standards and guidance in support of a digital certificate validation based on CRL.

Digital Certificate Services

Candidate

Standard group not available.

    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.The version of the encoded certificate revocation list (CRL) shall be version 2.

    Digital Certificate Validation (OCSP) Profile

    The Digital Certificate Validation (OCSP) Profile provides standards and guidance in support of a digital certificate validation based on OCSP.

    Digital Certificate Services

    Candidate

    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.

    Candidate

    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.

    Transport Layer Security Profile

    This profile provides detailed information, guidance, and standards to be used for the usage of Transport Layer Security version 1.3 (TLS 1.3) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers.

    Directory Services,

    Informal Messaging Services,

    Technical Services,

    Text-based Communication Services,

    Web Hosting Services

    Candidate

    Base standard

    Candidate

    Base standard

    Implementations shall be configured to only use the following cipher suites

    • TLS_AES_128_GCM_SHA256 (mandatory)
    • TLS_AES_256_GCM_SHA384 (recommended)
    • TLS_CHACHA20_POLY1305_SHA256 (recommended)

    Transport Layer Security Fallback Profile

    This profile provides detailed information, guidance, and standardsto be used for the usage of Transport Layer Security version 1.2 (TLS 1.2) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers.

    Directory Services,

    Informal Messaging Services,

    Technical Services,

    Text-based Communication Services,

    Web Hosting Services

    Candidate

    TLS 1.2 base standards. Mandatory extensions: Section 7.4.1.4.1 - Signature Algorithms

    Candidate

    TLS extensions Mandatory extensions: Section 3 - Server Name Indication Extension Disallowed extensions: Section 7 - Truncated HMAC

    Candidate

    Transport Layer Security (TLS) Renegotiation Indication Extension Renegotiation shall only be initiated by the server.Implementation shall be compliant with RFC 7525, section 3.5

    Candidate

    Negotiated Finite Field Diffie-Hellman Ephemeral Parameters Required curves: secp256p1secp384p1

    Candidate

    Supported Elliptic Curves extension. Required extensions: Section 5.1/5.2 - Supported Point Formats Required curves: secp256r1secp384r1

    Candidate

    Session Hash and Extended Master Secret Extension

    Candidate

    TLS 1.2 compression SHALL be disable with the use of the "null" compression method.

    Candidate

    TLS 1.2 base standards. Mandatory extensions: Section 7.4.1.4.1 - Signature Algorithms

    Candidate

    TLS extensions Mandatory extensions: Section 3 - Server Name Indication Extension Disallowed extensions: Section 7 - Truncated HMAC

    Candidate

    Transport Layer Security (TLS) Renegotiation Indication Extension Renegotiation shall only be initiated by the server.Implementation shall be compliant with RFC 7525, section 3.5

    Candidate

    Negotiated Finite Field Diffie-Hellman Ephemeral Parameters Required curves: secp256p1secp384p1

    Candidate

    Supported Elliptic Curves extension. Required extensions: Section 5.1/5.2 - Supported Point Formats Required curves: secp256r1secp384r1

    Candidate

    Session Hash and Extended Master Secret Extension

    Candidate

    TLS 1.2 compression SHALL be disable with the use of the "null" compression method.

    Implementations shall be configured to only use the following cipher suites

    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Mandatory for RSA certificates)
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Optional)
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Mandatory for ECC certificates)
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Optional)

    Cryptographic Algorithms Profile

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

    Digital Certificate Services,

    Technical Services

    Candidate

    Candidate

    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
    For further guidance on the implementation the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2 shall also be considered.Even more guidance
    • 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,

    Technical Services

    Candidate

    Candidate

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

    Infrastructure Processing Standards Profiles

    Service Standard Implementation Guidance

    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.

    Technical Services,

    Virtualized Processing Services

    Candidate

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

    Candidate

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

    Candidate

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

    Candidate

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

    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.
    The platform should be able to support the following minimalistic set of hardware features
    • 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
    Note although OVF defines standard for virtual machine images, there still might be a slight differences how various vendors use it, thus some manual modifications of the OVF files might be necessary before their import.

    Infrastructure Networking Standards Profiles

    Time Synchronization Profile

    Service Standard Implementation Guidance

    Peer Time Synchronization Profile

    The Symmetric Peer Profile provides standards and guidance to support the symmetric synchronization of time servers on the same NTP stratum level across a network or a federation of networks.

    Distributed Time Services

    Candidate

    Protocol modes 1 and 2

    Candidate

    Protocol modes 1 and 2

    Federation Time Synchronization Profile

    The Client/Server 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

    Candidate

    Protocol modes 3 and 4

    Candidate

    Protocol modes 3 and 4

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

    Domain Naming Profile

    Service Standard Implementation Guidance

    IPv6 Domain Naming Profile

    The IPv6 Domain Naming Profile contains additions to the base Domain Name System standards, which enable the usage of the Domain Name System in the context of the Internet Protocol, version6.

    C3 Taxonomy

    Candidate

    DNS Extensions for IP version 6

    Candidate

    Address Selection

    Candidate

    DNS Extensions for IP version 6

    Candidate

    Address Selection

    Zone Transfer Profile

    The Zone Transfer Profile provides standards and guidance to support zone synchronization in the hierarchical distributed name system for authoritative name servers of federated mission network ing.

    C3 Taxonomy

    Candidate

    Candidate

    Mandatory message digest algorithm is hmac-sha384.

    Candidate

    Candidate

    Mandatory message digest algorithm is hmac-sha384.

    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.

    C3 Taxonomy

    Candidate

    Candidate

    Only the following security algorithms shall be used

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

    Generic Domain Naming Profile

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

    C3 Taxonomy

    Candidate

    Additional types and bigger payloads

    Candidate

    Base standards

    Candidate

    Additional types and bigger payloads

    Candidate

    Base standards

    Anycast DNS Profile

    The Anycast DNS Profile provides standards and guidance for operating an Authoritative Domain Name Service on an anycast address.

    Packet-based Access Services

    Candidate

    Operation of anycast services

    Candidate

    DNS operation on shared unicast address

    Candidate

    Operation of anycast services

    Candidate

    DNS operation on shared unicast address

    COI-Specific Standards Profiles

    Command and Control Standards Profiles

    Land Tactical C2 Information Exchange Profile

    Service Standard Implementation Guidance

    XMPP/JDSSDM Mediation Profile.

    The XMPP/JDSSDM Mediation Profile provides standards and guidance on text based information exchange between TACCIS and OPCIS.

    Mediation Services,

    Situational Awareness Services,

    Text-based Communication Services

    Candidate

    Standard group not available.

      ADatP-36/JDSSDM Mediation Profile.

      The ADatP-36/JDSSDM Mediation Profile provides standards and guidance on self reporting FFT exchange between TACCIS and OPCIS.

      Mediation Services,

      Situational Awareness Services

      Candidate

      Standard group not available.

        NVG/JDSSDM Mediation Profile.

        The NVG/JDSSDM Mediation Profile provides standards and guidance on overlays exchange between TACCIS and OPCIS.

        Mediation Services,

        Situational Awareness Services

        Candidate

        Standard group not available.

          MIP 4/JDSSDM Mediation Profile.

          The MIP 4/JDSSDM Mediation Profile provides standards and guidance on non-friendly observed reported Battlespace Objects information exchange between TACCIS and OPCIS.

          Mediation Services,

          Situational Awareness Services

          Candidate

          Standard group not available.

            CIS Support Standards Profiles

            SMC Orchestration Profile

            Service Standard Implementation Guidance

            SMC Process Implementation Profile

            SMC Process Implementation Profile for Enabling Processes

            Service Standard Implementation Guidance

            SMC Process Implementation Profile for Activity Management

            Description The Activity Management, leveraging the TM Forum Process Flow Management API, enables the exchange of federated Service Tasks between Mission Network Participants.

            Business Support SMC Services

            Candidate

            Candidate

            SMC Process Implementation Profile for Party Management

            The Party Management, leveraging the TM Forum Party Management API, enables the exchange of federated Parties between Mission Network Participants.

            C3 Taxonomy

            Candidate

            Candidate

            SMC Process Implementation Profile for Geographic Location Management

            The Geographic Location Management, leveraging the - TM Forum Geographic Address Management API, - Tm Forum Geographic Site Management API, - Tm Forum Location Management enables the exchange of federated Locations between Mission Network Participants.

            C3 Taxonomy

            Candidate

            Candidate

            COI-Enabling Standards Profiles

            Operations Information Standards Profiles

            Service Standard Implementation Guidance

            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.

            Web Hosting Services

            Candidate

            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.

            Candidate

            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.

            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.

            Mediation Services,

            Situational Awareness Services,

            Track Distribution Services,

            Track Management Services

            Candidate

            Candidate

            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.

            Tactical Messaging Access Services

            Candidate

            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 COP 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.

            Candidate

            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.

            Candidate

            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 COP 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.

            Candidate

            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.

            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.

            Situational Awareness Standards Profiles

            Service Standard Implementation Guidance

            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.

            Mediation Services,

            Track Management Services,

            Wired Transmission Services,

            Wireless LOS Mobile Transmission Services

            Candidate

            Candidate

            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.

            Mediation Services,

            Track Management Services,

            Wired Transmission Services,

            Wireless LOS Mobile Transmission Services

            Candidate

            Candidate

            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.

            Communication and Collaboration Applications,

            Overlay Services,

            Recognized Picture Services,

            Situational Awareness Services,

            Text-based Communication Services

            Candidate

            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-00000016-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.

            Candidate

            Applies to NVG only. Implementation Guidance is provided inNVG 2.0.2 APP-6(D)(1) Bindings

            Candidate

            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.

            Candidate

            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-00000016-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.

            Candidate

            Applies to NVG only. Implementation Guidance is provided inNVG 2.0.2 APP-6(D)(1) Bindings

            Candidate

            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.

            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.

            Communications Access Standards Profiles

            Service Standard Implementation Guidance

            Traffic Flow Confidentiality Protection Profile

            The Traffic Flow Confidentiality Protection Profile provides standards and guidance for implementing IPSEC based protection for data traffic.

            Authentication Services,

            Communications Security Services,

            Transport Cryptography Services

            Candidate

            These are standards to implement protection profiles needed for IPSec.

            Candidate

            These are standards to implement protection profiles needed for IPSec.

            Generic Routing Encapsulation profile

            The Routing Encapsulation Profile provides standards and guidance for generic routing encapsulation functions over network interfaces both in PCN and in Information Domain network interconnection points (NIPs).

            Packet-based Broadcast Services,

            Packet-based Transport Services

            Candidate

            Key and sequence number extension for GRE

            Candidate

            Standards for GRE tunneling in IPv6

            Candidate

            Standards for GRE tunneling in IPv4

            Candidate

            Key and sequence number extension for GRE

            Candidate

            Standards for GRE tunneling in IPv6

            Candidate

            Standards for GRE tunneling in IPv4

            Inter-Autonomous Systems Multicast Source Discovery Profile

            The Inter-Autonomous Systems Multicast Source Discovery Profile provides standards and guidance for multicast group source active signaling between inter-autonomous systems.

            C3 Taxonomy

            Candidate

            Service providers with their own multicast capability shall provide signaling between their Rendezvous Point (RP) supporting the following IP multicast source discovery standards.

            Candidate

            Service providers with their own multicast capability shall provide signaling between their Rendezvous Point (RP) supporting the following IP multicast source discovery standards.

            Inter-Domain Multicast Planning Profile

            Multicast management within inter-domain context requires careful planning and orchestration.

            C3 Taxonomy

            Candidate

            The following standards shall apply to multicast routing.

            Candidate

            The following standards shall apply to multicast routing.

            NMCD Information Exchange Service Profile

            The NMCD Information Exchange uses RESTCONF-like exchange semantics to distribute Protected Core Community PCSOP information throughout the community.

            Web Hosting Services,

            Web Platform Services

            Candidate

            Confidentiality Information Labels used by the NMCD IES are bound to data objects using the ADatP-4778 Metadata Binding Mechanism.

            Candidate

            NMCD IES uses a subset of the RESTCONF protocol to exchange information between peering NMCD IESes.

            Candidate

            NMCD IES client discovers the resource root endpoint of the RESTCONF protocol using the Web Host Metadata standard.

            Candidate

            Information published by the NMCD IES is labelled according to ADatP-4774 confidentiality information label schema.

            Candidate

            Confidentiality Information Labels used by the NMCD IES are bound to data objects using the ADatP-4778 Metadata Binding Mechanism.

            Candidate

            NMCD IES uses a subset of the RESTCONF protocol to exchange information between peering NMCD IESes.

            Candidate

            NMCD IES client discovers the resource root endpoint of the RESTCONF protocol using the Web Host Metadata standard.

            Candidate

            Information published by the NMCD IES is labelled according to ADatP-4774 confidentiality information label schema.

            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.

            Audio-based Communication Services,

            Packet Routing Services,

            Video-based Communication Services

            Candidate

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

            Candidate

            Additionally, the following standards apply for use of communities, extended communities and 32-bit extended communities for traffic engineering purposes.

            Candidate

            The following standard is added to improve security of BGP peering

            Candidate

            The following standards apply for all IP interconnections.

            Candidate

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

            Candidate

            Additionally, the following standards apply for use of communities, extended communities and 32-bit extended communities for traffic engineering purposes.

            Candidate

            The following standard is added to improve security of BGP peering

            Candidate

            The following standards apply for all IP interconnections.

            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 Signaling Profile

            The Inter-Autonomous Systems Multicast Signaling Profile provides standards and guidance for multicast group signaling between inter-autonomous systems.

            C3 Taxonomy

            Candidate

            Service providers with their own multicast capability shall implement Rendezvous Point (RP) and provide signaling between their network segments supporting the following IP multicast signaling standards.

            Candidate

            Service providers with their own multicast capability shall implement Rendezvous Point (RP) and provide signaling between their network segments supporting the following IP multicast signaling standards.

            Communications Transmission Standards Profiles

            Wireless NB BLOS Standards Profiles

            Service Standard Implementation Guidance

            Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF) Phase 1 edition 1

            This profile specifies the interoperability and performance characteristics of terminal equipment that will operate over NATO or national UHF satellite systems.

            Wireless BLOS Mobile Narrowband Transmission Services

            Candidate

            Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF).

            Candidate

            Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF).

            Wireless NB LOS Standards Profiles

            Service Standard Implementation Guidance

            SATURN Waveform edition 4

            A narrow-band waveform with Fast Frequency Hopping EPM Mode for UHF Radio. A/G/A use, typically used voice-only.

            Wireless LOS Mobile Narrowband Transmission Services

            Candidate

            SATURN - a fast frequency hopping EPM mode for UHF radio. AComP-4372 EDITION A

            Candidate

            SATURN - a fast frequency hopping EPM mode for UHF radio. AComP-4372 EDITION A

            A/G/A use, typically used voice-only.

            NATO Narrowband waveform for VHF/UHF Radios edition 1

            The Narrowband Waveform (NBWF) provides ground–ground interoperability over air between troops/platforms of different nations at the tactical battlefield using the military VHF and UHF band (30 - 500 MHz).

            Wireless LOS Mobile Narrowband Transmission Services

            Candidate

            NBWF - Link Layer

            Candidate

            NBWF - HEAD STANAG

            Candidate

            NBWF - Physical Layer

            Candidate

            NBWF - Network Layer

            Candidate

            NBWF - Link Layer

            Candidate

            NBWF - HEAD STANAG

            Candidate

            NBWF - Physical Layer

            Candidate

            NBWF - Network Layer

            For FMN Spiral 5, NATO Narrowband Waveform Profile A shall be implemented according to Annex G of AComP 5630, i.e. one-hop voice and data wireless communication using PHY mode N1. Other PHY modes and profiles are optional.

            Wireless WB LOS Standards Profiles

            Service Standard Implementation Guidance

            NATO High Capacity Data Rate Waveform (NHCDRWF) edition 1

            Wideband UHF waveform

            Wireless LOS Mobile Wideband Transmission Services

            Candidate

            NHCDRWF - Modem Specification

            Candidate

            NHCDRWF - Head Specification

            Candidate

            NHCDRWF - Link/Network Layer Specification

            Candidate

            NHCDRWF - Modem Specification

            Candidate

            NHCDRWF - Head Specification

            Candidate

            NHCDRWF - Link/Network Layer Specification

            NATO HDRWF (ESSOR) Standards Profile edition 1

            NATO HDRWF (ESSOR) is a wideband waveform standard originated from the EU ESSOR program and community.

            Wireless LOS Mobile Wideband Transmission Services

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards LLC Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards NET Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards.

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards Physical Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards System Description

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards MGT Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards System Design

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards MAC Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards LLC Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards NET Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards.

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards Physical Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards System Description

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards MGT Layer Specifications

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards System Design

            Candidate

            These standards define NATO HDRWF based on ESSOR Standards MAC Layer Specifications

            Platform Standards Profiles

            Web Platform Standards Profiles

            Service Standard Implementation Guidance

            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

            Candidate

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

            Candidate

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

            Candidate

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

            Candidate

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

            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.

            C3 Taxonomy

            Candidate

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

            Candidate

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

            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

            Candidate

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

            Candidate

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

            Candidate

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

            Candidate

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

            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.

            C3 Taxonomy

            Candidate

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

            Candidate

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

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

            Brokered Notification Publish Subscribe Profile

            The Brokered Notification Publish Subscribe Profile provides standards and guidance based on WS-BrokeredNotification.

            Direct Messaging Services,

            Message Brokering Services,

            Technical Services,

            User Applications

            Candidate

            Candidate

            Candidate

            Candidate

            In a brokered environment it is possible to generate a situation, where notifications may circulate in a set of brokers. This behaviour has to be solved with organisational methods if no additional features are added to a brokered environment.

            SOAP Web Services Metadata Labelling Profile

            The SOAP Web Services Metadata Labelling Profile describes how to apply standard confidentiality metadata to SOAP-based web services.

            C3 Taxonomy

            Candidate

            Candidate

            The structure of the binding is defined in ADatP-4778.The Simple Object Access Protocol Binding Profile is defined in ADatP-4778.2 Edition A Version 1.0.The labelling values shall be based on the security policy defined for the mission.

            REST Web Services Metadata Labelling Profile

            The REST Web Services Metadata Labelling Profile describes how to apply standard confidentiality metadata to REST-based web services.

            C3 Taxonomy

            Candidate

            Candidate

            The structure of the binding is defined in ADatP-4778.The Representational State Transfer Binding Profile is defined in ADatP-4778.2 Edition A Version 1.0.The labelling values shall be based on the security policy defined for the mission.

            OAuth 2.0 Proof of Possession Profile

            DPoP, an abbreviation for Demonstrating Proof-of-Possession at the Application Layer, is an application-level mechanism for sender-constraining OAuth access and refresh tokens. It enables a client to demonstrate proof-of-possession of a public/private key pair by including a "DPoP" header in an HTTP request. The OAuth 2.0 Proof of Possession Profile is based on the internet draft ID OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer1.

            C3 Taxonomy

            Candidate

            Standard group not available.

              Proof-of-Possession may be supported between the Client and the Authorization Server and/or Client and Resource Server.

              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".

              C3 Taxonomy

              Candidate

              Candidate

              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

              Candidate

              Candidate

              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.

              C3 Taxonomy

              Candidate

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

              Candidate

              Candidate

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

              Candidate

              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.

              Secure REST-based Request Response Profile

              The Secure REST-based Request Response profile supports consistent and compliant use of the uniform interface offered by HTTP for accessing a federated protected resource (REST-based Web Service). The Client makes a protected access request to the Resource Server (authority part referred to within the request URI) presenting the Access Token in the Header of the HTTP request. The Access Token is self-contained which allows the Resource Server to validate the Access Token without reference to another service (or previous state). If the Access Token is successfully validated the Resource Server processes the authorised request and the result is returned to the Client.

              Direct Messaging Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              The Access Token is encoded in the HTTP Authorization entity-header by the Client.The auth-scheme parameter for the HTTP Authorization entity-header is specified to indicate the type of Access TokenAs a minimum for complying with this profile, the auth-scheme parameter value for the HTTP Authorization Header is Bearer. (If supporting the OAuth 2.0 Proof of Possession Profile the parameter value is DPoP).The Access Token shall be conformant with PRF-142 OAuth 2.0 Access Token Profile.In the cases where a Client receives a 401 status error code, that Client SHALL request an Access Token from the Authorization Server as specified in PRF-139 OAuth 2.0 Assertion Grant Profile.

              Secure SOAP-based Request Response Profile

              The Request-Response Message Exchange Pattern (MEP) involves a consumer sending a request message to a provider, which receives and processes the request, ultimately returning a message in response. The Secure SOAP-based Request Response profile provides the key elements of security infrastructure required to implement uniform, consistent, interoperable and effective protection of the resources exposed by partners in a federated environment.

              Direct Messaging Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              The recommendations provided in the Service Interface Profile (SIP) Securing SOAP-based Request-Response Web Services are intended to give directives, along with clarifications and amendments on the use of securing SOAP-based Request-Response web services.

              OAuth 2.0 Access Token Profile

              The OAuth 2.0 Access Token Profile facilitates interoperability for distributing Claims, structured as a JWT bearer Access Token, between federated entities.

              Direct Messaging Services,

              Security Token Services

              Candidate

              Candidate

              The list of Claims to be provided in the JWT assertion has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for JSON Web Token Format are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support OAuth 2.0 Access Tokens in JSON Web Token format.

              REST-Based Request Response Profile

              The REST-Based Request Response Profile provides the implementation details for REST-based Request-Response Message Exchange Pattern (MEP). The profile covers only the call from a Consumer to the Provider using HTTP, and the response from the Provider.

              Direct Messaging Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              Candidate

              When a Consumer asks a Provider for a resource, the Provider is expected to respond with the best possible representation for that resource, given the Consumer's preferences.This profile places no constraints on the type of data that can be exchanged between Consumers and Providers in the body of an HTTP Message request or response. However, it is recommended that XML or JSON be used as the MIME media type exchanged between Consumers and Providers in the body of an HTTP Message request or response.HTTP requests from the Consumers using the HTTP verbs GET, HEAD, PUT and DELETE are honoured as idempotent requests by the Provider.Create, Read, Update and Delete (CRUD) are the main operations used when dealing with information in persistent storage.While REST/HTTP has similar operations, the correspondence with CRUD is not a direct one-to-one match, specifically for the Create and Update methods, but also due to the granularity of HTTP resources.REST offers generic uniform HTTP interface methods (HTTP verbs RFC 7231 (IETF)]) that apply to the request URI entity which is the URI specified on the HTTP request.It is RECOMMENDED that RESTful web services use the prescribed HTTP verbs for Create, Read, Update and Delete (CRUD) operations as specified in below

              • Get Retrieves an information object identified by the request URI.
              • Put Creates a new information object identified by the request URI. (Updates an information object identified by the request URI. It is recommended that the update operation is a complete update of the information object identified by the request URI.)
              • Post Updates an information object identified by the request URI. (The request URI may create new additional information objects; update additional information objects; or perform a variety of create or updates of information objects.)
              • Patch Creates a partial update of an information object identified by the request URI. (Updates an information object identified by the request URI. It is recommended that the update operation includes a set of instructions or description of changes describing what needs to be modified in the information object identified by the request URI. The entire set of instructions are required to be applied atomically.)
              • Delete Deletes an information object identified by the request URI.
              • Head Retrieves the same HTTP header fields and HTTP status code as the GET HTTP verb without the representation of the information object identified by the request URI.
              • Options RESTful web services can use this HTTP verb to determine the list of HTTP verbs supported by the information object identified by the request URI.
              A fundamental axiom of the architecture of the World Wide Web is that URIs should be opaque to Consumers i.e. a Consumer should not need to pick apart a URI to determine what it means or what to do with it.Consumers must not be capable of gathering sensitive information about the information object or the Communications and Information System (CIS) containing the information object through aggregation techniques carried out on the URI.Where metadata about the resource needs to be conveyed, it must be done using the standard HTTP headers and the rest of the information a resource conveys is carried in the representation of the resource itself.In environments that typically have high latency and bandwidth constraints Consumers and Providers may support HTTP caching for the HTTP verbs GET, PUT and HEAD.Cached contents must be protected.Caching of sensitive information is prohibited. A Consumer shall indicate to all entities in the HTTP request/response chain that information shall not be cached by inserting the HTTP header cache-control with the additional directive of no-store. or no-cache. As such, information must not be cached when a HTTP request contains a HTTP Cache-Control Header field with the values no-store and no-cache.

              Structured Data Profile

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

              Direct Messaging Services,

              Technical Services,

              User Applications,

              Web Hosting Services

              Candidate

              General formatting of information for sharing or exchange.

              Candidate

              General formatting of information for sharing or exchange.

              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.

              Direct Notification Publish Subscribe Profile

              This profile provides provides standards and guidance for Publish-Subscribe components (Producer, Subscription Manager and Consumer) based on WS-BaseNotification.

              Direct Messaging Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              Candidate

              Candidate

              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.

              Security Token Services,

              Web Hosting Services

              Candidate

              Candidate

              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.
              When making authentication requests<code><samlp AuthnRequest> </code>to Identity Providers, the requesting SP/RP must fulfill the following requirements
              • All Authentication Requests shall be signed.
              • HTTP-Redirectbinding shall be used for the transmission of Authentication Request messages.
              Authentication responses from an identity provider must fulfill the following requirements
              • HTTP-POSTbinding shall be used for the receipt of<code><samlp Response> </code>messages.
              • SAML Assertions shall contain a<code> <saml NameID> </code>element with the following format to enable Single Logout <code>urn oasis names tc SAML 2.0 nameid-format transient.</code>
              • All<code><saml Attribute></code>elements shall contain a NameFormat of<code>urn oasis names tc SAML 2.0 attrname-format uri </code>. Required attribute names are listed in the Context section.
              • <code> <ds KeyName> </code>element, specified in the XML Digital Signature Core specification [1], inside the<code> <ds KeyInfo> </code>element shall be left empty.
              • If encryption is used for SAML Response messages, the assertion element shall be encrypted as a whole. Encryption of only Attributes and/or NameID is not allowed for SAML Response messages. Thus, SAML Response messages shall contain a<code> <saml EncryptedAssertion> </code>element in case encryption is used.
              • For Single Logout request messages<code> <saml EncryptedID> </code>element shall not be used. Instead transient NameIDs shall be used to hide the user identity.
              In order to make web authentication more robust, implementations should allow five (5) minutes of clock skew in both directions when interpreting timestamps in SAML assertions.[1] XML Signature Syntax and Processing Version 2.0, W3C Working Group Note 23 July 2015,https //www.w3.org/TR/xmldsig-core2/#sec-KeyInfo

              OAuth 2.0 Authorization Server Bootstrap Profile

              OAuth 2.0 Authorization Server Bootstrap Profile provides standards and guidance on how OAuth 2.0 Clients can obtain the necessary information required to interact with an OAuth 2.0 Authorization Server.

              Direct Messaging Services,

              Security Token Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              The OAuth 2.0 Authorization Server Metadata is retrieved from a well-known location.Alternatively, OAuth 2.0 Clients can configure some or all of this information in an out-of-band manner.As a minimum the OAuth 2.0 Authorization Server Metadata is recommended to contain the issuer, token_endpoint, jwks_uri and grant_types_supported fields.

              SAML 2.0 Bootstrap Profile

              The SAML 2.0 Bootstrap profile is based on the SAML2.0 standard.

              Direct Messaging Services,

              Security Token Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              Security Token Services Profile

              The Security Token Services Profile supports the exchange of SAML 2.0 assertions to support federated Identity and Access Management.

              Direct Messaging Services,

              Security Token Services

              Candidate

              Candidate

              Candidate

              Candidate

              How the SAML 2.0 Token has been retrieved from the local STS to be used at the federated STS is not a federation issue.The operations that are specified here are the minimal operations that SHALL be implemented by the STS in order to support the exchange of SAML Security Tokens between federation partners. Other operations that are defined by the relevant specification MAY be implemented by the STS in accordance with those specifications.

              • Issue
              Based on the credential provided/proven in the request, a new token is issued, possibly with new proof information.Providers and Consumers SHALL use the following WS-Addressing actions to enable specific processing context to be conveyed to the recipient -http //docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Issue-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinalProviders and Consumers SHALL use the following URI as a wst RequestType element -http //docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
              • Renew
              A previously issued token with expiration is presented (and possibly proven) and the same token is returned with new expiration semantics.Providers and Consumers SHALL use the following WS-Addressing actions to enable specific processing context to be conveyed to the recipient -http //docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Renew-http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/RenewFinalProviders and Consumers SHALL use the following URI as a wst RequestType element -http //docs.oasis-open.org/ws-sx/ws-trust/200512/Renew

              OAuth 2.0 Assertion Grant Profile

              The OAuth 2.0 Assertion Grant Profile supports the exchange of SAML 2.0 or JWT assertions for Access Tokens to be used to access federated protected resources (i.e. REST-based web services)

              Direct Messaging Services,

              Security Token Services

              Candidate

              Candidate

              Candidate

              Candidate

              A federated Authorization Server supports this profile by providing a Security Token Service Endpoint (HTTP collection resource identified by the request URI) for a Client to make a request to exchange a Security Token (SAML or JWT assertion) from its own domain for a new Security Token (Access Token) that can be used to support chaining web services and access to federated protected resources.How the Client receives a SAML or JWT assertion is out of scope for this profile.When complying with this profile the Client must set the fields of its assertion grant token requests as follows

              • If the Client is exchanging a SAML assertion for an Access Token the grant_type parameter value is urn ietf params oauth grant-type saml2-bearer and the assertion parameter value is the SAML assertion.
              • If the Client is exchanging a JWT assertion for an Access Token the grant_type parameter value is urn ietf params oauth grant-type JWT-bearer and the assertion parameter value is the JWT assertion.
              • The resource parameter must be used to indicate the federated service or protected resource where the resultant Access Token is intended to be used.
              The Authorization Server ensures that the assertion provided by the Client is valid and not expired.When complying with this profile the Authorization Server must set the fields of the assertion grant token response as follows
              • The access_token parameter value is the Access Token issued as part of the request.
              • The token_type parameter value is Bearer. (If supporting the OAuth 2.0 Proof of Possession Profile the parameter value is DPoP).

              JSON Web Token Assertion Profile

              The JSON Web Token Assertion Profile facilitates interoperability for distributing Claims, structured as a JWT assertion, between federated entities.

              Direct Messaging Services,

              Security Token Services

              Candidate

              Candidate

              The list of Claims to be provided in the JWT assertion has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for JSON Web Token Format are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that JSON Web Tokens.

              SAML Security Token Profile

              The SAML Security Token Profile facilitates interoperability for distributing Claims, structured in SAML 2.0, between federated entities.

              C3 Taxonomy

              Candidate

              Candidate

              The list of Claims to be provided in the SAML Security Token has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for SAML Security Token Format are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support SAML Security Tokens.

              SOAP-Based Request Response Profile

              The SOAP-Based Request Response Profile defines the standard interface for sending a SOAP Message from a Consumer to a Provider and returning the results. The profile covers only the call from a Consumer to the Provider using SOAP, and the response from the Provider. This details the structuring of the Message.

              Direct Messaging Services,

              Technical Services,

              User Applications

              Candidate

              Candidate

              Providers must reject unsupported versions of SOAP.Upon request, Providers are to make available to authorized Consumers a Web Service Description Language (WSDL) describing the service interface.

              Database Platform Standards Profiles

              Service Standard Implementation Guidance

              Global Address List Schema Mapping Profile

              Participants within a federation may use different directory representations (Active Directory and IETF schemas) for GAL information, therefore, information within the different directories needs to be mapped to the correct representation for each participant.

              C3 Taxonomy

              Candidate

              Candidate

              The ‘Contact’ Object Class, defined in Microsoft Active Directory schema, is not a standard LDAP class.In the case a mapping is required to be performed between the standardised IETF 'inetOrgPerson' Object Class and the 'Contact' Object Class then the following rules must be applied

              • All mandatory attributes in the Consumer object class must be created; and,
              • the cardinality of attributes values in the Consumer object class must be maintained (e.g. an attribute may only be allowed a single value in the Consumer’s object class, but the Provider’s object class may allow multiple values).
              A potential list of suitable attributes for replication is displayed in the Table. The table provides
              • Mappings between the Active Directory and IETF schemas (for those suitable attributes);
              Object class the attribute is derived from; and,
              • Obligations and cardinality.
              The following guide will assist in understanding the table
              • “ADUC” - the Active Directory field that is shown in “Active Directory User and Computers” for the attribute (where it exists);
              • “Attribute” - the attribute name (which may be different from the LDAP NAME);
              • “M” – is the attribute mandatory within the Object Class;
              • “OC” – the Object Class with which the attribute is associated; and,
              • “Single-Value” – is the attribute single or multi valued.
              [CREATE TABLE FROM TABLE 2 IN SIP FOR IDENTITY INFORMATION]

              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). The Directory Data Structure Profile facilitate the need to share contact information across all participants of a federation, in order to support improved collaboration and communication, for example through the sharing of a Global Address List (GAL) for email addresses.

              Directory Services

              Candidate

              Candidate

              The central DIT, for sharing GAL information, is based on the IETF standards for 'inetOrgPerson' LDAP Object Class.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. The table provides mandatory, recommended and optional specific guidance of such attributes within a federation context. The attributes refer back to those attributes as defined in ACP 133 Supp-1(C).[CREATE TABLE FROM TABLE 3 IN SIP FOR IDENTITY INFORMATION]

              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

              Candidate

              Candidate

              Communications Transport Standards Profiles

              Service Standard Implementation Guidance

              IPv6 Transport Services profile

              IPv6 transport services are generic packets transport services

              Packet-based Access Services,

              Packet-based Broadcast Services,

              Packet-based Transport Services,

              Transport Services

              Candidate

              Standards for IP version 6 (IPv6) neighbor discovery over link level network.

              Candidate

              For understanding different options to generate IPv6 addresses

              Candidate

              Standards for IPv6 address allocation scheme utilizing reserved address space for Unique Local IPv6 Unicast Addresses. It should be noted that actual allocation policy is not following the RFC, but co-ordinated policy. Also prefix that is used is from the non-defined area of ULA addresses.

              Candidate

              These standard are used for point-to-point interconnections between network devices.

              Candidate

              Standards for Internet Protocol version 6 (IPv6 and ICMPv6).

              Candidate

              For automatic detection of MTU between end-points. It is strongly recommended that IPv6 nodes implement Path MTU Discovery, in order to discover and take advantage of path MTUs greater than 1280 octets.

              Candidate

              Standards for IPv6 Anycast address assignment. These standards need to be taken account when assigning IPv6 addresses on systems.

              Candidate

              Standards for IP version 6 (IPv6) neighbor discovery over link level network.

              Candidate

              For understanding different options to generate IPv6 addresses

              Candidate

              Standards for IPv6 address allocation scheme utilizing reserved address space for Unique Local IPv6 Unicast Addresses. It should be noted that actual allocation policy is not following the RFC, but co-ordinated policy. Also prefix that is used is from the non-defined area of ULA addresses.

              Candidate

              These standard are used for point-to-point interconnections between network devices.

              Candidate

              Standards for Internet Protocol version 6 (IPv6 and ICMPv6).

              Candidate

              For automatic detection of MTU between end-points. It is strongly recommended that IPv6 nodes implement Path MTU Discovery, in order to discover and take advantage of path MTUs greater than 1280 octets.

              Candidate

              Standards for IPv6 Anycast address assignment. These standards need to be taken account when assigning IPv6 addresses on systems.

              NINE ISPEC

              NINE ISPEC - NETWORKING AND INFORMATION INFRASTRUCTURE (NII) INTERNET PROTOCOL (IP) NETWORK ENCRYPTOR – INTEROPERABILITY SPECIFICATION, will serve as a basis and allows manufacturers from different nations to develop and produce interoperable IPsec devices to be used in federated IP network environments such as the Federated Mission Networking (FMN).

              Communications Security Services

              Candidate

              Candidate

              AComP-4787 Ed1 contains several sections out of which following form basis for interoperability in the context of FMN SP5

              • Core Specification
                • Threshold requirements considered Minimum Interoperability Requirements.
              • Gateway Extension
                • Understand that NINE devices for FMN are gateway devices.
              • Generic Discovery Client Extension
                • The initiation of the discovery process is required when a packet transmitted to a SA endpoint is marked as unreachable; this is foreseen in NINE Core as part of the “Peer NINE Reachability Detection”. The support of this feature is essential for devices since it ensures the reachability of the NINE endpoints.
              • Reachability Extension
                • NINE “Reachability” Extension defines the required mechanism to discover, maintain and advertise subnets of networks which are available at the PlainText interface (including through SAs) using routing protocols (like RIPv2 and RIPng).
              • Traffic Protection - Suite B Cryptography Core

              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 Broadcast Services,

              Packet-based Transport Services

              Candidate

              Following standards give more information on implementation of QoS within IP networks.

              Candidate

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

              Candidate

              Following standards give more information on implementation of QoS within IP networks.

              Candidate

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

              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.

              Communications Security Services

              Candidate

              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.

              Candidate

              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.

              Candidate

              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.

              Candidate

              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.

              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.

              Frame-based Access Services,

              Packet-based Access Services,

              Transport Services

              Candidate

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

              Candidate

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

              Candidate

              Candidate

              Physical connectors for harsh environments

              Candidate

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

              Candidate

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

              Candidate

              Candidate

              Physical connectors for harsh environments

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

              IP Access to Tactical Radio

              This profile described the standards for IP access to a tactical radio. It contains the IP requirements of STANAG 5634 and STANAG 4677. This includes at least the following standards: UDP, IPv4 unicast and multicast, including IP addressing standards, IGMPv3, ICMP, DSCP.

              IPv4 Routed Access Services,

              Packet-based Broadcast Services,

              Packet-based Transport Services

              Candidate

              Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

              Candidate

              Path MTU discovery

              Candidate

              Host extensions for IP multicasting

              Candidate

              Address Allocation for Private Internets

              Candidate

              Internet Group Management Protocol, Version 3

              Candidate

              A Standard for the Transmission of IP Datagrams over Ethernet Networks (IPv4)

              Candidate

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

              Candidate

              IANA Guidelines for IPv4 Multicast Address Assignments

              Candidate

              Internet Standard Subnetting Procedure

              Candidate

              Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

              Candidate

              Path MTU discovery

              Candidate

              Host extensions for IP multicasting

              Candidate

              Address Allocation for Private Internets

              Candidate

              Internet Group Management Protocol, Version 3

              Candidate

              A Standard for the Transmission of IP Datagrams over Ethernet Networks (IPv4)

              Candidate

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

              Candidate

              IANA Guidelines for IPv4 Multicast Address Assignments

              Candidate

              Internet Standard Subnetting Procedure

              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 onSTANAG 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.

              C3 Taxonomy

              Candidate

              Implement the following standard in addition to RFC 1112.

              Candidate

              Candidate

              Implement the following standard in addition to RFC 1112.

              Candidate

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

              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.

              C3 Taxonomy

              Candidate

              Candidate

              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.

              IPv4 Transport Services profile

              These are standards associated to provide IPv4 based transport service.

              Edge Services,

              Packet-based Access Services,

              Packet-based Broadcast Services,

              Packet-based Transport Services,

              Transport Services

              Candidate

              For automatic detection of MTU between end-points.

              Candidate

              Standards for IP version 4 (IPv4)

              Candidate

              Standards for IP version 4 (IPv4) over Ethernet.

              Candidate

              For automatic detection of MTU between end-points.

              Candidate

              Standards for IP version 4 (IPv4)

              Candidate

              Standards for IP version 4 (IPv4) over Ethernet.

              Business Support Standards Profiles

              Information Management Standards Profiles

              Formal Messaging Standards Profiles

              Service Standard Implementation Guidance

              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.

              C3 Taxonomy

              Candidate

              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)

              Candidate

              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)

              Geospatial Standards Profiles

              Service Standard Implementation Guidance

              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

              Candidate

              Candidate

              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

              Candidate

              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.

              Candidate

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

              Candidate

              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.

              Candidate

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

              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.

              Communication and Collaboration Applications,

              File System Storage Services,

              Geospatial Services,

              Technical Services,

              Text-based Communication Services

              Candidate

              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.

              Candidate

              Exchange of Digital Vector Data

              Candidate

              Exchange of Digital Raster Data

              Candidate

              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.

              Candidate

              Exchange of Digital Vector Data

              Candidate

              Exchange of Digital Raster Data

              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

              Candidate

              Candidate

              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

              Candidate

              Candidate

              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 Coverage Service Profile

              The Web Coverage Service Profile provides standards and guidance in support of providing the geographical coverages across the web using platform-independent calls.

              C3 Taxonomy

              Candidate

              Candidate

              Implementation guidance can be found in DGIWG 119, Defence Profile of OGC Web Coverage Service 2.0 v.1.0.0, 28 November 2017.

              GeoPackage Profile

              A GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage standard describes a set of conventions for storing within a SQLite database vector features, tile matrix sets of imagery and raster maps at various scales and extensions. Please note that the spatial extent, vector and raster content, use of extensions, CRS, and metadata of a GeoPackage will generally be based on the intended use and the existing capabilities of system(s) that will use the GeoPackage.

              C3 Taxonomy

              Candidate

              Candidate

              All geopackages are based on version 3 of the SQLite file format, and will have a file name of “.gpkg”. The only tables that are mandated are the gpkg_spatial_ref_sys table and the gpkg_contents table. The gpkg_spatial_ref_sys table contains the spatial (coordinate) reference system (SRS) definitions needed by the gpk_contents and the gpkg_geometry_columns table to relate the vector and tile data in user tables to locations on the earth. The gpkg_contents table provides a list of all the geospatial contents in a GeoPackage and provides identifying and descriptive information that an application can display to a user as a menu of geospatial data that is available for access and/or update.Further implementation guidance can be found in DGIWG 126, the (DRAFT) DGIWG GeoPackage Profile, DRAFT Rev 2.1 (STD-DP-19-005), June 10, 2021, expected ratification April 2022. Providers should put emphasis on DGIWG Profile requirements and recommendations.The DGIWG Profile of Geopackage provides the following advantages to the users of GeoPackage data

              • common tile matrix set zoom levels and tile size;
              • common map projections for global data exchange and exploitation;
              • metadata populated for discovery, awareness and source of GeoPackage content;
              • agreement on extensions used;
              • compliance definition with abstract test suite.

              Communication and Collaboration Standards Profiles

              Audio-based Collaboration Standards Profiles

              Service Standard Implementation Guidance

              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.

              C3 Taxonomy

              Candidate

              The following standards are used for audio protocols.

              Candidate

              The following standards are used for audio protocols.

              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.

              IP voice to Half Duplex Radio

              The Tactical All-informed Voice Information Exchange profile, provides standards in order to establish all-informed voice communications between tactical units (TACCIS) that are interconnected via coalition waveforms.

              Audio-based Communication Services,

              Voice Access Services

              Candidate

              This profile covers the part of STANAG 5634 that describes the voice client interface (MELPe/RTP/UDP/IP) as well as the access to a radio device.

              Candidate

              This profile covers the part of STANAG 5634 that describes the voice client interface (MELPe/RTP/UDP/IP) as well as the access to a radio device.

              This profile MUST use the RTP-HE specification for voice interfacing with the radio and MUST NOT use the VARC approach that is also described in STANAG5634.

              Media-based Collaboration Standards Profiles

              Call Media Encoding Profile

              Service Standard Implementation Guidance

              Voice Services Media Encoding Profile

              Standards profile for encoding of voice services.

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

              Candidate

              VTC Services Audio and Video Encoding Profile

              Standards profile for encoding of video teleconferencing services.

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

              Candidate

              Unified Audio and Video Profile

              Service Standard Implementation Guidance

              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).

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

              Candidate

              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).

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

              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.

              Candidate

              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.

              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).

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

              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.

              Candidate

              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.

              Session Initiation and Control Profile

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

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

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

              Candidate

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

              Candidate

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

              Candidate

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

              Media Streaming Profile

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

              Audio-based Communication Services,

              Video-based Communication Services

              Candidate

              Candidate

              Secure Voice Profile

              Service Standard Implementation Guidance

              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.

              C3 Taxonomy

              Candidate

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

              Candidate

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

              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.

              C3 Taxonomy

              Candidate

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

              Candidate

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

              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,

              Video-based Communication Services

              Candidate

              SCIP Secure Applications.

              Candidate

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

              Candidate

              SCIP Signaling Plan and Negotiation.

              Candidate

              SCIP Network Standards for operation over other network types.

              Candidate

              SCIP Secure Applications.

              Candidate

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

              Candidate

              SCIP Signaling Plan and Negotiation.

              Candidate

              SCIP Network Standards for operation over other network types.

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

              Text-based Collaboration Standards Profiles

              Service Standard Implementation Guidance

              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.

              C3 Taxonomy

              Candidate

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

              Candidate

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

              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.

              Communication and Collaboration Applications,

              Metadata Repository Services,

              Text-based Communication Services

              Candidate

              Candidate

              Text-based Collaboration Chatroom Profile

              The Text-based Collaboration Managed Chatroom Profile provides standards and guidance to host moderated, password-protected and member-only chatrooms to support strongly controlled persistent near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations. In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc.

              Text-based Communication Services

              Candidate

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

              Candidate

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

              Text-based Collaboration Core Profile

              The Text-based Collaboration Core 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.

              Communication and Collaboration Applications,

              Metadata Repository Services,

              Technical Services,

              Text-based Communication Services

              Candidate

              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.

              Candidate

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

              Candidate

              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.

              Candidate

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

              Text-based Collaboration Information Discovery Profile

              The Text-based Collaboration Information Discovery Profile provides standards and guidance to support Information Discovery about XMPP entities.

              Text-based Communication Services

              Candidate

              Candidate

              Text-based Collaboration Tactical Profile

              The Text-based Collaboration Tactical Profile provides guidance and standards to support the exchange of chat messages between mission participants at the tactical level.

              Text-based Communication Services

              Candidate

                Candidate

                  The current proposal (Sep 21) is to up-issue STANAG 4677 to include a Chat Extension message to support the exchange of Chat messages at the tactical level.

                  Text-based Collaboration Publish-Subscribe Profile

                  The Text-based Collaboration Publish-Subscribe Profile provide standards and guidance in support of Text-based Collaboration Publish-Subscribe Services.

                  Text-based Communication Services

                  Candidate

                  Candidate

                  Video-based Collaboration Standards Profiles

                  Service Standard Implementation Guidance

                  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.

                  C3 Taxonomy

                  Candidate

                  The following standards are required for video coding in VTC.

                  Candidate

                  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.

                  Candidate

                  The following standards are required for audio coding in VTC.

                  Candidate

                  The following standards are required for video coding in VTC.

                  Candidate

                  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.

                  Candidate

                  The following standards are required for audio coding in VTC.

                  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.

                  Informal Messaging Standards Profiles

                  Service Standard Implementation Guidance

                  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,

                  Text-based Communication Services

                  Candidate

                  Media and content types.

                  Candidate

                  MIME encapsulation.

                  Candidate

                  Media and content types.

                  Candidate

                  MIME encapsulation.

                  Informal Messaging Profile

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

                  Informal Messaging Services

                  Candidate

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

                  Candidate

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

                  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.

                  C3 Taxonomy

                  Candidate

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

                  Candidate

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

                  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 and Scheduling Standards Profiles

                  Service Standard Implementation Guidance

                  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

                  Candidate

                  Candidate

                  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.