Network Infrastructure and Gateways

Network infrastructure

The BoB infrastructure and all endpoint interfaces are designed to be exposed in an open environment between the participating entities. The communication protocols used (HTTP over TLS with JWT assertions) results – if correctly implemented – in integrity protection, confidentiality and federated authentication (with local authorisation).

The basis for all communication between BoB components is correctly implemented TLS certificate validation and key management for JWT assertions. The metadata published by the Coordination Function may contain information on expected public key material (through the use of TLSA). This information can also be published using the domain name system (DNS) if the zone used is secured using DNSSEC. Both mechanisms are required to be checked when validating the identity of an endpoint. It is not recommended to rely on a list of public certificate authorities, such as those distributed by operating system and web browser vendors.

The endpoints of the BoB servers can be protected using a number of different means. It is not uncommon to use a load-balancer for terminating incoming traffic. In this, basic content and flow control can be implemented and managed, as well as logging of all requests. Additional filtering, for example based on clients IP addresses, are technically possible, but could add a significant administrative burden and be error-prone, as it may be hard to determine exactly from what IP addresses communication will originate. Adding of additional transport protection and encapsulation of communication, e.g., through the use of VPN-technology, could of course be used as well if required, but will naturally also add substantial administrative and technical complexity. Before such mechanisms are implemented, it is highly recommended that the purpose, benefits and draw-backs of them are carefully weighted, and that the alternative of providing the services as intended on open networks are considered.

Gateways

There are no general requirements in the architecture for defining gateways or proxies. A participant who desires to introduce such elements into its own infrastructure would direct incoming traffic to this function directly using the metadata, instead of the actual endpoint. If the TLS session is terminated in the intermediate, the necessary access control will have to be implemented transparent to the requestor. Introducing these extra elements may bring some draw-backs, as they can affect the performance, scalability and robustness of the infrastructure, as there is a critical dependency introduced to a function through which all traffic have to be funneled. It will also be harder to instantiate functions at new locations, et cetera.