SWIM Technical Infrastructure Foundation Material

SWIM TI Introduction

The SWIM technical infrastructure (TI) enables the implementation of interfaces between systems, providing technical capabilities for the secure, high-performing and reliable exchange of information.

The SWIM TI is a collection of software ^[1] used to enable the provision of information services. Applications consume information services via a SWIM TI that enables the exchange of information over an IP network. Both the service provider (responsible for the information service), and the service consumer (responsible for the consuming application) are responsible for the implementation of their own infrastructure ^[2] .

The SWIM TI enables technical interoperability based on interfaces that use industry standards, the SWIM TI interface bindings, which specify the protocols used for the exchange of information between systems. The SWIM TI provides technical capabilities that are adapted to support various information exchange needs, including different communication needs (Ground/Ground or Air/Ground), different types of Message Exchange Patterns (Publish/Subscribe or Request/Reply cf. [2] and different service levels with different availability requirements.

Definitions

Term	Definition	Source
Capability	The ability of a system to provide a service or perform a function that, either on its own or with other services or functions, can deliver a definable level of performance.	SWIM Glossary
COTS	A software and/or hardware product that is commercially ready-made and available for sale, lease, or license to the general public.	NIST glossary
Information Service	A type of service that provides an ATM information sharing capability.	SWIM Glossary
PKI	A Public Key Infrastructure (PKI) is a combination of policies, procedures and technology needed to manage digital certificates in a public key cryptography scheme. A digital certificate is an electronic data structure that binds an entity, being an institution, a person, a computer program, a web address etc., to its public key. Digital certificates are used for secure communication, using public key cryptography, and digital signatures. The purpose of a PKI is to make sure that the certificate can be trusted.	ENISA (European Union Agency for CyberSecurity) glossary
Service	A mechanism to enable access to one or more capabilities using a prescribed interface. Note: In the context of system wide information management, the notion of service addresses machine-to-machine interaction based on service oriented architecture principles, and is not to be confused with the notion of service as used in ICAO provisions referring to business services such as AIS, ATS, etc.	SWIM Glossary
Technical Infrastructure	The assembly of software and hardware used to enable the provision of information services.	SWIM Glossary
Technical Infrastructure Capability	A characteristic of the SWIM TI.	SWIM Glossary

SWIM TI Context

From a conformance point of view, a SWIM TI is a technical infrastructure that satisfies the requirements of a standardised SWIM TI Specification and supports at least some of the functional and non-functional capabilities described here. At the time of this writing:

• The EUROCONTROL SWIM TI YP Specification is the only available SWIM standard for TI in Europe.
• Additional TI specification for PKI activities as required by CP1 regulation (EU IR 2021/116 - Family 5.1.1 and Family 5.2.1).

EUROCONTROL SWIM TI Yellow Profile Specification

The EUROCONTROL SWIM TI Yellow Profile Specification (YP Spec) is a standard that provides requirements for general purpose SWIM TI capabilities based on mainstream technologies. It addresses a wide spectrum of information exchange needs in all the various ATM information domains (i.e. Aeronautical, Meteorological, Flight and Flow)

SWIM Common Infrastructure Components

SWIM Common Infrastructure Components provide specialised TI capabilities that require a common or coordinated deployment by all stakeholders. These include:

• Public Key Infrastructure. It enables the secure exchange of information by enabling the implementation of public-key encryption and digital signature.
• SWIM Service Registry. It contains information services that are implemented based on SWIM standards. It stores structured descriptions that facilitate the discovery and comparability of services.

Additional TI Profiles

The YP Spec a general-purpose exchange specification and it is acknowledged ^[3] that more specialised use cases will need to be addressed by dedicated specification and standardization activities which will be documented in, for example:

• Blue TI profile, specifies all TI requirements that are specific to the exchange of flight information between ATCs.

SWIM TI Principles

The SWIM TI contributes to achieving the benefits of SWIM as described in ICAO Doc 10039 Vol I. To do so, the SWIM TI respects certain principles:

• Managed technical diversity. Technological diversity is managed to minimize significant costs related to the maintenance, expertise and integration between several different processing environments, while allowing flexibility to accommodate new technologies and to select the technologies that best meet the needs of the intended ATM businesses. This is the primary focus of the SWIM TI Bindings.
• Standards Based Technical Interoperability. The SWIM TI is based on open standards that promote technical interoperability.
• Established technology standards. The SWIM TI is based on widely deployed and widely supported technology standards that enable economical and efficient implementation and operation of information services.
• Modularity. The SWIM TI is modular, enabling the progressive deployment of different SWIM TI functional capabilities and bindings, which will allow a fit for purpose, flexible and agile implementation and evolution.
• Platform Independent interfaces. Interfaces between systems do not create dependencies imposed by implementation platforms, such as operating system or programming language.
• SWIM TI Functional Capabilities supported by COTS. The SWIM TI functional capabilities are common features of established COTS.

SWIM TI Decomposition

The SWIM TI is characterized by a set of technical capabilities and interface bindings that together enable the actual exchange of information between systems.

• SWIM TI capabilities. These are divided in functional and non-functional capabilities.
  • SWIM TI functional capabilities are infrastructure functions (e.g. protocol transformation, encryption), not specific to a particular business area or information domain, that enable information to be exchanged between systems.
  • SWIM TI non-functional capabilities are characteristics of the SWIM TI that contribute to the quality of services. (E.g. the availability of the SWIM TI has direct impact on the availability of the service it supports). While the TI functional capabilities are executable (e.g. encryption), the non-functional capabilities are a consequence of functional capabilities (e.g. confidentiality) or other contributing elements such as the deployment architecture (e.g. a redundant deployment contributes to availability).
• SWIM TI interface bindings. An interface binding is a set of protocols and their configuration that defines how to interoperate technically with a system. In relation with the SWIM TI functional capabilities, an interface binding is a type of connectivity used by the messaging capabilities of the TI to interoperate with another system. Interface bindings play a critical role in enabling technical interoperability in SWIM, and as such, are highlighted as specific components of the TI.

SWIM TI Functional Capabilities

The functional capabilities of the SWIM TI can be grouped in three categories:

• Messaging Capabilities: Enable the actual exchange of information using various access methods (e.g., publish/subscribe, request/reply).
• Security Capabilities: Enable the secured exchange of information, including, but not limited to identity access management, digital certificates, encryption, etc.
• TI Management Capabilities: Enable monitoring of the technical infrastructure for fault and performance, ensuring reliable and high-performing execution of the information exchanges.

The functional capabilities (i.e. functions) described in this section are common features widely supported by mainstream commercial of the shelf (COTS) systems and services.

Messaging Functionality

A ‘message’ ^[4] is the unit of exchange between providers and consumers. Messaging is therefore the most important capability of the SWIM TI, as it enables the actual exchange of information between systems. It includes:

• Connectivity: Enabling the exchange of messages over the network according to well-defined protocols. This function instantiates interface binding specifications (set of protocols) into what is commonly known as adaptors or connectors, in order to exchange information with other systems. Connectivity to a system is performed via a system endpoint that is an addressable system resource.
• Message Distribution: Enabling the processing and distribution of messages. This function uses information exchange resources (i.e. queues, topics) to decouple the various TI functions involved in the processing of messages (connectivity, validation...) based on configurable distribution rules (e.g. content/context based routing). The components that provide this kind of functionality are commonly referred to as message brokers.
  • Context-Based Routing: In this case, messages are routed based on contextual information associated with the message. This context can include attributes such as message source, user identity, location, or any other relevant metadata.
  • Subject-Based Routing: In this case, message routing relies on message subjects or topics to determine the routing path. Each message is tagged with a specific subject, and routers use these subjects to direct messages to the appropriate subscribers.
  • Content-Based Routing: In this case, messages are routed based on the actual content within the message payload. The router examines specific data fields or patterns to make routing decisions.
  These mechanisms are usually configurable per each message exchange. Moreover, the infrastructure may need to have the capability to prioritise between different types of traffic according to predefined prioritisation rules and/or perform a configurable number of automatic retries (at application layer) on failed message delivery.
• Validation: Enabling the validation of messages to ensure they are syntactically well formed, and according to predefined schemas.
• Policy Enforcement: Enforcing the application of messaging policies (e.g. routing and filtering policies, reliability policy)
• Data Transformation: Enabling the transformation from one data format to another.
• Orchestration : Enabling the coordination or integration of several services, and exposing them as a single service.

Security Functionality

As supporting functions to messaging, the security capabilities of the SWIM TI are of high importance as they enable a trusted exchange of information. These capabilities are:

• Identity Management: Enabling the management of identities (e.g. identity creation, identity validation, federated identity retrieval). It can rely on SWIM Common Infrastructure Components to perform its functionality.
• Authentication: Enabling the verification of the validity of credentials and their correspondence with an identity.
• Authorization: Enabling the management of permissions associated to identities and based on these the enforcement of access control to the TI services and resources.
• Cryptography: Providing secure functions for encryption, decryption and hashing.
• Key Management: Enabling the secure management of cryptographic keys.
• Audit: Recording contextual information related to security events.
• Security Monitoring : Enabling monitoring, event handling and reporting of security related events.
• Policy Enforcement: Enforcing the application of security policies.
• Boundary Protection: Providing capabilities to ensure the protection of the infrastructure against external threats (e.g. firewall, rate limit management).

TI Management Functionality

As supporting functions to messaging, the TI management capabilities ensure the reliable and performant exchange of information. These capabilities are:

• Resource Monitoring: Enabling the monitoring of the TI resources (e.g. processors, memory).
• Service Monitoring: Enabling the monitoring of the TI services provided (e.g. status, uptime, and response times).
• Alerting: Enabling management alerts related to the monitoring of infrastructure related events (e.g. threshold management).
• Logging: Enabling the recording of system events with the relevant contextual information.
• Replication: Enabling the management of system and data replication, enabling different degrees of fault tolerance and failover (e.g. by providing failure and replication transparency, thus ensuring that broker and/or service endpoint failure is invisible to the consumers).
• Persistence: Enabling the management of data persistence in the TI (e.g. by providing Subscription and/or message persistency when a Publish/Subscribe MEP is used).
• Load Balancing: Enabling the management of load distribution across the TI resources, enabling horizontal scaling and high availability.

SWIM TI Non-Functional Capabilities

These are qualities of the SWIM TI that directly contribute to the quality of SWIM Services that use the SWIM TI. While the TI functional capabilities are executable (e.g. encryption), the SWIM TI non-functional capabilities addressed in this section are a consequence of using functional capabilities (e.g. confidentiality is the result of using encryption). The non-functional capabilities of the SWIM TI are based on ISO 25010 and include:

Performance efficiency Qualities

These are characteristics of the SWIM TI related to its performance. They include:

• Time behaviour, including response time and latency can be directly correlated to the execution time of any of the functional capabilities of the TI. The deployment architecture can also influence time behaviour as well as the SWIM TI replication and load balancing functionalities.
• Capacity (e.g. messages per second) is also directly correlated to the execution time of any of the functional capabilities of the TI. The deployment architecture can also influence capacity as well as the SWIM TI replication and load balancing functionalities.

Security Non-Functional Qualities

These are characteristics of the SWIM TI related to security. They include:

• Confidentiality ensures that data is accessible only to those authorized to have access, and it can be achieved as a combination of functional capabilities such as authentication, authorization, or cryptography.
• Integrity prevents unauthorized access to, or modification of data, and it can be achieved as a combination of functional capabilities such as authentication, authorization, or cryptography.
• Non-repudiation ensures actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later. It is supported by a combination of functional capabilities such as authentication and authorization, auditing, cryptographic digital signatures…
• Accountability ensures actions of an entity can be traced uniquely to the entity and it can be achieved as a combination of functional capabilities such as logging, authentication, and cryptography.
• Authenticity ensures the identity of a subject or resource can be proved to be the one claimed and it can be achieved as a combination of functional capabilities such as authentication, cryptography.

Reliability Qualities

These are characteristics of the SWIM TI related to reliability. They include:

• Availability enables the SWIM TI to remain operational and accessible when required for use. The deployment architecture is of high importance to ensure availability as well as the SWIM TI replication and load balancing functionalities.
• Recoverability enables the SWIM TI to recover the data directly affected by an interruption or a failure and re-establish the desired state of the system. The deployment architecture is of high importance to ensure availability as well as the SWIM TI persistence and replication functionalities.
• Fault tolerance enables the SWIM TI to operate as intended despite the presence of hardware or software faults. The deployment architecture is of high importance to ensure fault tolerance as well as the SWIM TI persistence, load balancing and replication functionalities.

SWIM TI Interface Bindings

Technical interoperability in SWIM is enabled by the TI and more specifically by the SWIM TI interface bindings. A binding is a consistent, self-contained grouping of interface requirements that specify the protocols and configuration options to be used for the exchange of information between systems.

Two types of interface bindings are distinguished based on the interface they specify with different systems:

• Service Bindings. Specifying the technical infrastructure protocols that are used by the application to interoperate with information services.
• Network Bindings. Specifying the protocols used to interoperate with the network infrastructure. SWIM relies on an IP network that is considered outside the scope of SWIM. However, there are multiple protocols that can be used to interface with an IP network, and those have a dependency with the service binding protocols.

The Service Bindings correspond to the Application Layer of the TCP/IP Stack while the Network Bindings correspond to the Transport and Internet Layers. Figure 3 relates the different Bindings with the TCP/IP stack, the OSI layer model and the protocol scope covered by ICAO Doc 9896 and Doc 9880 (P3-4).

The number of potential technologies used for interface bindings and the number of information flows to be realized create a risk of lacking uniformity which may negatively impact the cost of SWIM. Furthermore, consuming from SWIM based on interface bindings selected by service providers, may also trigger costs related to the implementation of consuming clients. For these reasons it is good practice to consolidate the interface bindings around mainstream standards. This will then enable cost benefits and other synergies among the SWIM stakeholders.

SWIM TI YP Spec Traceability to Functional Capabilities

Identifier	Title	Functional Capability	Function
SWIM-TIYP-0004	TCP	Messaging	Connectivity
SWIM-TIYP-0005	IPSec	Messaging	Connectivity
SWIM-TIYP-0006	IPv4	Messaging	Connectivity
SWIM-TIYP-0007	IPv6	Messaging	Connectivity
SWIM-TIYP-0008	TLS	Messaging	Connectivity
SWIM-TIYP-0009	HTTP	Messaging	Connectivity
SWIM-TIYP-0010	HTTP over TLS	Messaging	Connectivity
SWIM-TIYP-0011	SOAP 1.1	Messaging	Connectivity
SWIM-TIYP-0012	SOAP 1.2	Messaging	Connectivity
SWIM-TIYP-0013	MTOM	Messaging	Connectivity
SWIM-TIYP-0014	WSDL 1.1	Messaging	Validation
SWIM-TIYP-0015	WSDL 2.0	Messaging	Validation
SWIM-TIYP-0016	WS-I	Messaging	Validation
SWIM-TIYP-0017	WS-I Security	Messaging	Validation
SWIM-TIYP-0018	WS Notification (deprecated)	Messaging	Connectivity
SWIM-TIYP-0019	IPv6 Node Requirements	Messaging	Connectivity
SWIM-TIYP-0020	RFC 1122	Messaging	Connectivity
SWIM-TIYP-0022	RFC950	Messaging	Connectivity
SWIM-TIYP-0023	WS Policy	Messaging	Policy Enforcement
SWIM-TIYP-0024	WS Secure Conversation	Security	Authentication
SWIM-TIYP-0025	WS Trust	Security	Identity Management
SWIM-TIYP-0026	WS Addressing	Messaging	Routing
SWIM-TIYP-0027	SOAP Message Security	Security	Cryptography
SWIM-TIYP-0028	XML Message Encryption	Security	Cryptography
SWIM-TIYP-0029	XML	Messaging	Connectivity
SWIM-TIYP-0030	WS Security Username Token	Security	Identity Management
SWIM-TIYP-0031	WS Security X509	Security	Identity Management
SWIM-TIYP-0033	HTTP Content Type Header	Messaging	Connectivity
SWIM-TIYP-0034	WS Federation	Security	Identity Management
SWIM-TIYP-0035	WS Reliable Messaging	Messaging	Connectivity
SWIM-TIYP-0036	AMQP	Messaging	Connectivity
SWIM-TIYP-0038	HTTP Compression and Content Encoding Header	Messaging	Connectivity
SWIM-TIYP-0040	XML Digital Signature	Messaging	Cryptography
SWIM-TIYP-0042	TLS Authentication	Security	Authentication
SWIM-TIYP-0043	HTTP Status Code Header	Messaging	Connectivity
SWIM-TIYP-0044	HTTP Reason Phrase Header	Messaging	Connectivity
SWIM-TIYP-0045	HTTP POST	Messaging	Connectivity
SWIM-TIYP-0046	SOAP Message Encryption	Security	Cryptography
SWIM-TIYP-0047	WS Security Token Profiles	Security	Identity Management
SWIM-TIYP-0048	AMQP Content Type Header	Messaging	Connectivity
SWIM-TIYP-0049	AMQP Content Encoding Header	Messaging	Connectivity
SWIM-TIYP-0051	SASL	Security	Authentication
SWIM-TIYP-0052	AMQP over TLS	Messaging	Connectivity
SWIM-TIYP-0112	S/MIME 4.0	Security	Cryptography
SWIM-TIYP-0113	OpenAPI	Messaging	Validation
SWIM-TIYP-0053	Common Time Reference	Security	Authentication
SWIM-TIYP-0054	Overload Protection	Security	Boundary Protection
SWIM-TIYP-0057	Least Privileged Principle Access	Security	Authorization
SWIM-TIYP-0058	Automatic Sessions termination	Security	Boundary Protection
SWIM-TIYP-0060	Verification of Signed Messages Integrity	Security	Cryptography
SWIM-TIYP-0062	Message Payload Validation	Messaging	Validation
SWIM-TIYP-0064	Validation of X.509 Certificates	Security	Identity Management
SWIM-TIYP-0065	Cryptographic Algorithms	Security	Key Management
SWIM-TIYP-0066	Strong Passwords	Security	Key Management
SWIM-TIYP-0067	Mandatory Access Control	Security	Authorization
SWIM-TIYP-0068	Recording of Failed Authentication Requests	Security	Security Monitoring
SWIM-TIYP-0069	Restriction after Failed Authentication Requests	Security	Boundary Protection
SWIM-TIYP-0070	Satisfactory Authorization	Security	Authorization
SWIM-TIYP-0073	Secure Password Storage	Security	Key Management
SWIM-TIYP-0074	Security Patching	Operation Procedure
SWIM-TIYP-0075	Vulnerability Assessment	Operation Procedure
SWIM-TIYP-0077	Audit of identity validity events	Security	Security Monitoring
SWIM-TIYP-0114	Audit of Security Relevant Events	Security	Security Monitoring
SWIM-TIYP-0085	Safe Mode Operation	Security	Boundary Protection
SWIM-TIYP-0087	CAVP approved Cryptographic Modules	Security	Cryptography
SWIM-TIYP-0088	Audit of Cryptographic Events	Security	Audit
SWIM-TIYP-0089	Configurable Authentication	Security	Authentication
SWIM-TIYP-0090	Audit of federated identity events	Security	Audit
SWIM-TIYP-0092	Denial of Service Protection	Security	Boundary Protection
SWIM-TIYP-0093	Identity Validity Information Exchange	Security	Identity Management
SWIM-TIYP-0103	Hardware Monitoring	TI Management	Resource Monitoring
SWIM-TIYP-0104	Monitoring Alerts	TI Management	Alerting
SWIM-TIYP-0105	Service Monitoring	TI Management	Service Monitoring
SWIM-TIYP-0106	Persistent Storage Recording	TI Management	Persistence
SWIM-TIYP-0107	Log Retention	TI Management	Persistence

References

1. EUROCONTROL Specification for SWIM TI Yellow Profile , EUROCONTROL
2. SWIM TI Message Exchange Patterns Identification Guidelines, EUROCONTROL

Notes

1. Note that it might also encompass appliances running on dedicated hardware ↑

2. An information service enables provision of information to consumers (e.g. Weather Service) as well as access to a capability (e.g. Flight Plan Filing Service). ↑

3. As stated in the rolling development plan of the European ATM Standards Coordination Group, and the deployment program managed by the SESAR Deployment Manager. ↑

4. The term message is used in this document in relation to a unit of exchange between systems that communicate via information services. Although there are similarities, no direct comparison should be made with the term message used in other ICAO documents (e.g. CPDLC message, AMHS Message). ↑