Internet DRAFT - draft-jilongwang-opsawg-iog
draft-jilongwang-opsawg-iog
opsawg WJL. Wang, Ed.
Internet-Draft QY. Qiao, Ed.
Intended status: Informational Tsinghua University
Expires: 24 April 2024 22 October 2023
A Collaborative Framework for Cyberspace Governance: the Internet of
Governance
draft-jilongwang-opsawg-iog-02
Abstract
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 https://datatracker.ietf.org/drafts/current/.
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 24 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang & Qiao Expires 24 April 2024 [Page 1]
Internet-Draft IOG October 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Internet of Governance (IoG) . . . . . . . . . . . . . . 3
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Two Roles . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Four Functionalities . . . . . . . . . . . . . . . . . . 5
3.4. Architectural Model . . . . . . . . . . . . . . . . . . . 6
4. Components and Collaboration Life-cycle . . . . . . . . . . . 7
4.1. Components . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Collaboration Life-Cycle . . . . . . . . . . . . . . . . 9
5. Supporting Cyberspace Governance Applications . . . . . . . . 10
5.1. DDoS Tracing and Defense . . . . . . . . . . . . . . . . 10
5.2. IP Geolocation and Verification . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 11
6.2. Secured Transport . . . . . . . . . . . . . . . . . . . . 11
6.3. Privacy Protection . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
Wang & Qiao Expires 24 April 2024 [Page 2]
Internet-Draft IOG October 2023
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)
Wang & Qiao Expires 24 April 2024 [Page 3]
Internet-Draft IOG October 2023
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.
Wang & Qiao Expires 24 April 2024 [Page 4]
Internet-Draft IOG October 2023
+--------------------------------------------------------------+
| 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.
Wang & Qiao Expires 24 April 2024 [Page 5]
Internet-Draft IOG October 2023
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.
Wang & Qiao Expires 24 April 2024 [Page 6]
Internet-Draft IOG October 2023
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.
Wang & Qiao Expires 24 April 2024 [Page 7]
Internet-Draft IOG October 2023
+------------------------+-------------------------+
| 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.
Wang & Qiao Expires 24 April 2024 [Page 8]
Internet-Draft IOG October 2023
4.2. 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.
+------------------------+------------------------+
| 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
Wang & Qiao Expires 24 April 2024 [Page 9]
Internet-Draft IOG October 2023
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.
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.
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.
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.
Wang & Qiao Expires 24 April 2024 [Page 10]
Internet-Draft IOG October 2023
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.
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.
Wang & Qiao Expires 24 April 2024 [Page 11]
Internet-Draft IOG October 2023
8. IANA Considerations
This memo includes no request to IANA.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3631] Bellovin, S., "Security Mechanisms for the Internet",
RFC 3631, December 2003,
<https://www.rfc-editor.org/rfc/rfc3631>.
Authors' Addresses
Jilong Wang (editor)
Tsinghua University
Beijing
100084
China
Email: wjl@tsinghua.edu.cn
Yi Qiao (editor)
Tsinghua University
Beijing
100084
China
Email: qiaoy21@mails.tsinghua.edu.cn
Wang & Qiao Expires 24 April 2024 [Page 12]