A Collaborative Framework for Cyberspace Governance: the Internet of Governance

Introduction With the development of the Internet, Cyberspace governance has extended from key resource allocation to various aspects. Cyberspace governance today faces two new problems: the lack of collaboration and the difficulty of implementation. Cyberspace needs a new technology supporting platform to resolve these problems. This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. IoG is an open and interconnected platform that facilitates inter-domain and international collaboration to resolve cyberspace governance issues. As infrastructure, IoG achieves facility and data sharing. As community, IoG achieves interpersonal coordination and rule consensus. This document provides IoG architectural design and provides practical use cases.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Terminology Internet of Governance (IoG): Refers to a supporting platform that connects entities involved in cyberspace governance, such as ISPs, ICPs and IT companies. Governance Domain: Refers to entities that join the Internet of Governance. Governance Data: Refers to data collected by governance domains. The sources of the governance data can be traditional network information such as routing information, DNS information and IP information. The sources of the governance data can also be structured information such as IP credit information and AS rankings, and non-structured information such as model parameters of learning-based active measurement. Governance Service: Refers to services provided by governance domains, such as looking glasses, virtual machines or containers. Governance Metadata: Refers to the metadata that describes governance data or governance service, such as network address, index and access level. It can be used to address and route governance data and governance service. Governance Center: Refers to a facility that holds management functionalities of IoG, such as routing, authentication, identity management, etc. Governance Gateway: Refers to software systems that execute IoG-related functionalities. Governance gateways are deployed in governance domains. Governance gateways should be able to access local devices and resources. Governance gateways connect to each other and to the governance center.

The Internet of Governance (IoG)

Definition IoG is an open and interconnected platform that facilitates inter-domain and international collaboration to resolve cyberspace governance issues. IoG contains multiple cyberspace governance entities, such as Internet organizations, ISPs and ICPs.

Concept of IoG ______________________________________________________ / ______________ ______________ / / / Governance / / Governance / / / / Gateway 1 / / Gateway 2 / / / /_____________/ ,--,--. /_____________/ / / \ ,-' `-. / / / ( IoG ) / / `-. ,-' / / ______________ / `--'--' \_____________ / / / Governance / / Governance / / / / Gateway 3 / / Gateway 4 / / / /_____________/ /_____________/ / /_____________________________________________________/ | | | | | | | | | _______|_________________________|_______|___________ |/ _____|________ | ____|_________ / | / Governance / | / Governance // /| / Domain 1 / | / Domain 2 // / |/_____________/ ,--,--. |/_____________// / | \ ,-' `-. / | / / | ( Internet ) | / / | `-. ,-' | / /_____|________ / `--'--' \____|_________ / // Governance / / Governance / / // Domain 3 / / Domain 4 / / //_____________/ /_____________/ / /____________________________________________________/

Two Roles IoG serves as both infrastructure and community. As infrastructure, it provides automated collaboration procedures, so that participants can share data and access services in an efficient and automated manner. As a community, it provides an organizational structure and agenda, so that participants can communicate and share information efficiently and conveniently.

Layered Representation of IoG +--------------------------------------------------------------+ | IoG | +--------------------------------------------------------------+ | | +---------------------------+ +---------------------------+ | Community | | Infrastructure | | +-----------------------+ | | +-----------------------+ | | | Organization Model | | | | Functional Model | | | +-----------------------+ | | +-----------------------+ | | +-----------------------+ | | +-----------------------+ | | | Credit Model | | | | Information Model | | | +-----------------------+ | | +-----------------------+ | | +-----------------------+ | | +-----------------------+ | | | Incentive Model | | | | Communication Model | | | +-----------------------+ | | +-----------------------+ | +---------------------------+ +---------------------------+

Four Functionalities As infrastructure, IoG carries out two functionalities, facility sharing and data sharing. As a community, IoG carries out another two functionalities, interpersonal coordination and rule consensus. Facility sharing means that after authentication, a governance domain can access or operate monitoring or control facilities owned by another domain. IoG provides a higher level of facility sharing than Looking Glasses (LG). LG sites execute simple commands (ping, trace, bgp, etc.), while IoG domains can execute more complicated operations on other participants, such as obtaining network probers, executing scrutinized programs, or applying for a virtual machine. These operations are exposed and accessed as services. Data sharing means that governance domains share governance data while ensuring privacy and security. Data sharing can benefit many cyberspace governance problems, such as IP traceback, network attack tracing and defense. To address privacy and security concerns of data sharing, IoG follows the rules that data are usable yet invisible. Governance data are stored locally by its owner, and other governance domains launch remote operations on these data and obtain the results without accessing raw data. Interpersonal coordination means to construct an official platform for collaboration negotiation and information sharing. Participants negotiate practical details of facility sharing and data sharing, such as methods of calling, service exposure, authentication, etc. Participants share cyberspace governance information, such as 0-day network attacks or sudden network failures, taking measures to mitigate losses. Rule consensus means to consolidate consensus reached during the collaboration process of facility sharing, data sharing and interpersonal coordination. In IoG, new governance methods can emerge to complement current rule-based cyberspace governance.

Architectural Model This document proposes architectural models to achieve IoG's two roles described in 3.1. Functional model, communication model and information model are required to achieve IoG's role as infrastructure. Organization model, credit model and incentive model are required to achieve IoG's role as community. Functional model defines mandatory functionalities that IoG participants need to implement to achieve streamlined and automated collaboration. IoG collaboration, such as data sharing and facility sharing are implemented with API (Application Programming Interface) calls. An IOG domain (provider) can expose or publish services as APIs in an API catalog managed by IoG governance center. Another domain (caller) can search and call these APIs, providing API parameters and authentication information. The provider executes these APIs by manipulating its facilities or operating on local databases, and only returns the result of the API. No extra data movement is involved, so that privacy is protected. Communication model defines how IoG domains communicate each other and how to publish and access service metadata. IOG domains form an overlay network with VPN (Virtual Private Network) to meet the security requirement. A centralized API catalog is managed by IoG governance center to store published service metadata. Information model defines homogeneous information structure of governance data so that IoG domains deployed with different underlying local management systems can understand each other. IoG collaborations are all performed by API calls, and the participants do not exchange data but service results. IOG domains are obliged to translate raw data into understandable, formatted parameters and results of API calls, so that mutual-understanding can be achieved even with heterogeneous local management systems. Organization model defines the organization structure and agenda of IoG. IoG consists of participants, an advisory group and a secretariat. Participants are entities that collaborates via IoG. An advisory group are selected representatives of IoG responsible for making decisions. The secretariat performs administrative and management tasks. Incentive model defines how to encourage IoG collaboration and how to increase collaboration efficiency and effects. IoG community is designed to be relatively loose, so that incentive mechanisms are needed to balance cooperativeness and selfishness of the participants. Credit model defines how to translate participant behaviors and attributes to credits. Credits can be used to assess participant performance and cooperativeness.

Components and Collaboration Life-cycle This section provides an IoG framework consisting of three major components. The interaction of these components are illustrated through the collaboration life-cycle figure.

IoG Architecture Model and Components +------------------------+-------------------------+ | Governance Center | | +-------------------------+ | | | Organization Model | | | +-------------------------+ | | +-------------------------+ | | | Credit Model | | | +-------------------------+ | | +-------------------------+ | | | Incentive Model | | | +-------------------------+ | +--------------------------------------------------+ / \ / \ +-------------------------+ +-------------------------+ | Governance Gateway | | Governance Gateway | | +---------------------+ | | +---------------------+ | | | Functional Model | | | | Functional Model | | | +---------------------+ | | +---------------------+ | | +---------------------+ |<--------->| +---------------------+ | | | Communication Model | | | | Communication Model | | | +---------------------+ | | +---------------------+ | | +---------------------+ | | +---------------------+ | | | Information Model | | | | Information Model | | | +---------------------+ | | +---------------------+ | +-------------------- ----+ +-------------------------+ | | ,--,--,,--,,--,--. ,--,--,,--,,--,--. ,-' `-. ,-' `-. ( Governace Domain ) ( Governace Domain ) `-. ,-' `-. ,-' `--'--',--,,--,--' `--'--',--,,--,--'

Components IoG consists of three components: governance center, governance gateway, and governance domain. The governance center stores service metadata and runs administrative and management tasks. The Governance gateway is usually deployed at the entrance the governance domain's network, performing IoG-related functionalities. The governance gateway can communicate with each other and the governance center. The Governance domain contains all governance-related entities inside the domain's network, including governance databases, monitoring and control facilities, and network management systems. The governance gateway is given permission to access the governance domain to implement service APIs.

Collaboration Life-Cycle The IoG component design leads to the collaboration life-cycle illustrated in Figure 2 and the following procedures.

1.: An IoG domain (provider) decides to expose one of its services by publishing service API metadata to the governance center. The service API metadata includes the API name, parameter format, parameter descriptions, the provide hostname/IP and calling methods (such as URL or REST). The provider should also implement the API with its facilities.
2.: Suppose another domain (caller) generates demand for the services from the provider in step 1.
3.: The caller searches API catalog in the governance center of the demanded service and obtain a list of APIs related to the service. The caller selects one or more APIs.
4.: The caller calls these APIs by providing proper parameters and authentication information.
5.: The provider receives the API calls and runs local implementation.
6.: The result is returned to the caller.

Supporting Cyberspace Governance Applications The following subsections provide examples of IoG supporting practical cyberspace governance applications based on the component design and collaboration life-cycle described in Section 4.

DDoS Tracing and Defense IoG can provide a reliable supporting platform for DDoS tracing and defense. Tracing an IP source requires coordination among multiple ASes (Autonomous Systems). IoG provides automated procedures to access IP traceback data maintained by ASes in their own infrastructures. The following steps are performed to enable IP traceback data sharing within the IoG architecture defined in section 4.

1.: An IoG domain(A) decides to expose the IP traceback service. It announces service metadata in the API catalog in the governance center.
2.: Another IoG domain(B) decides to trace a certain IP.
3.: B search the API catalog of the IP traceback services and obtain available services provided by other domains, including A. The identity of B is certified by the governance center and obtains authentication token.
4.: B initiates API calls according to the service metadata from A, providing proper parameters and authentication token.
5.: A accesses local IP traceback databases if A receives API calls from B and B is certified.
6.: A returns the IP traceback information to B.

IP Geolocation and Verification The following steps are performed to implement CPV [CPV] algorithm to verify IP geolocations within the IoG framework. CPV is an advanced IP geolocation verification method that requires more complex operations on probers to achieve better accuracy than simple commands like ping or traceroute. Suppose an IoG participant A decides to verify that the geolocation of a certain IP is O.

1.: A selects other participants B and C that provides CPV service APIs. According to CPV algorithm, B and C should be selected so that O is located inside the triangle formed by A,B and C.
2.: A intiates multiple API calls to measure the delay between AO, BO, CO, AB, AC, BC.
3.: A calculates the size of triangle ABC, AOC, BOC and AOB.
4.: A checks whether the summation of the size of triangle AOB, AOC, BOC equals to the size of triangle ABC. If so, then A decides the location of O is correct in this iteration and record the result. A then starts another iteration, performing step 1 again with new choices of B and C.
5.: After all iterations, A calculates the ratio of correct results to decide whether O is the correct geolocation.

Security Considerations

Authentication Authentication checks are carried out throughput the collaboration life-cycle of IoG to ensure security. The governance center maintains identity information of each governance domain. Each governance zone needs to be authenticated when they communicate with the governance center in step 1 and step 3 described in section 4.2. Besides, in step 3, the caller zone obtains a token from the governance center and uses this token when API calls are initiated in step 4. The provider checks the token before responding.

Secured Transport As discussed in [RFC7861], measures are taken satisfy RPC security. All communications involved in IoG collaboration life-cycle described in section 4.2 should use secured protocols such as HTTPS where TLS [RFC8446] is mandatory.

Privacy Protection In section 3.2, privacy protection has been discussed. The key issue of data sharing is to exchange information with minimal privacy risks. In IoG framework, all communications between governance domains are remote API operations, where only parameters and results are exchanged. The raw data can only be locally accessed.

Acknowledgements The authors would like to thank the support of Tsinghua University and Joint Research on IPv6 Network Governance: Research, Development and Demonstration under Grant 2020YFE0200500.

IANA Considerations This memo includes no request to IANA.