Internet-Draft IOG April 2024
Wang & Qiao Expires 23 October 2024 [Page]
Intended Status:
WJL. Wang, Ed.
Tsinghua University
QY. Qiao, Ed.
Tsinghua University

A Collaborative Framework for Cyberspace Governance: the Internet of Governance


This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. This document illustrates IoG definition, two roles and four functionalities, and develops architectural models to carry out these functionalities. This document provides the design of IoG framework and the collaboration life-cycle and uses some practical applications as examples.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 October 2024.

Table of Contents

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

1.1. 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 [RFC2119].

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

3. The Internet of Governance (IoG)

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

            /  ______________                   ______________    /
           /  /  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  / /
  //_____________/                     /_____________/ /
Figure 1: Concept of IoG

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

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

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

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

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

      |                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    )
`-.                  ,-'               `-.                  ,-'
   `--'--',--,,--,--'                     `--'--',--,,--,--'
Figure 3: IoG Architecture Model and Components

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

4.2. Collaboration Life-Cycle

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

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.
Suppose another domain (caller) generates demand for the services from the provider in step 1.
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.
The caller calls these APIs by providing proper parameters and authentication information.
The provider receives the API calls and runs local implementation.
The result is returned to the caller.
       |                Governance Center                |
Step 3:         |                               |       Step 1:
Search Metadata |                               |       Publish
                |                               |       Metadata
                |          Step 4:              |
          +-----+-----+    Remote Call    +-----+-----+
          |  Gateway1 |<----------------->|  Gateway2 |
          +-----^-----+    Step 6:        +-----^-----+
Step 2:         |          Return               |       Step 5:
Collab Request  |                               |       Local
                |                               |       Execution
            ,--,--,--.                      ,--,--,--.
         ,-'          `-.                ,-'          `-.
        (    Domain1     )              (     Domain2    )
         `-.          ,-'                `-.          ,-'
            `--'--'--'                      `--'--'--'
Figure 4: IoG Collaboration Life-cycle

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

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

An IoG domain(A) decides to expose the IP traceback service. It announces service metadata in the API catalog in the governance center.
Another IoG domain(B) decides to trace a certain IP.
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.
B initiates API calls according to the service metadata from A, providing proper parameters and authentication token.
A accesses local IP traceback databases if A receives API calls from B and B is certified.
A returns the IP traceback information to B.

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

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.
A intiates multiple API calls to measure the delay between AO, BO, CO, AB, AC, BC.
A calculates the size of triangle ABC, AOC, BOC and AOB.
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.
After all iterations, A calculates the ratio of correct results to decide whether O is the correct geolocation.

6. Security Considerations

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

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

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

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

8. IANA Considerations

This memo includes no request to IANA.

9. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, , <>.
Bellovin, S., "Security Mechanisms for the Internet", RFC 3631, , <>.

Authors' Addresses

Jilong Wang (editor)
Tsinghua University
Yi Qiao (editor)
Tsinghua University