ANIMA T.S.Choi Internet Draft T.S.Jeong Intended status: Standards Track ETRI Expires: January 13, 2019 J.K.Choi J.S.Han W.J.Chun KAIST July 2, 2018 Trust networking and procedures for Autonomic Networking draft-choi-anima-trust-networking-00 Abstract This document describes trust networking as an application of autonomic networking. The objective of trustworthy autonomic networking is providing trust networking environment where all autonomic nodes can communicate without any security concern. It defines a trust networking domain and describes how to configure and maintain the trust networking domain. While communication within the trust networking domain is done with trust, the communication with external nodes should be done via a specific autonomic service agent (ASA) called "trust gateway". The trust gateway ASA performs trust evaluation of the external nodes and enforces domain specific policies to keep the domain trustworthy. 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 http://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 January 13, 2019 Choi, et,al. Expires January 13, 2019 [Page 1] Internet-Draft Trust Networking & Procedures for AN July 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Choi, et,al. Expires January 13, 2019 [Page 2] Internet-Draft Trust Networking & Procedures for AN July 2018 Table of Contents 1. Introduction ................................................. 4 2. Background ................................................... 4 2.1. Security Model and its Limitations ...................... 5 2.2. Trust Model and Trust Relations ......................... 6 2.3. Comparisons of Security and Trust Model ................. 7 3. Trust Networking Framework ................................... 8 3.1. Defining Trust Networking Domain ........................ 8 3.2. Protecting Trust Networking Domain ...................... 9 3.3. Expanding Trust Networking Domain ....................... 9 3.4. Communicating with External Entities ................... 11 4. Trust networking domain as an application of autonomic networking ............................................................... 11 4.1. Definition of a Trust networking domain ................ 13 4.2. Configuration of Trust networking domain ............... 14 4.3. Communication between Trusted Autonomic Nodes within a trust networking domain ........................................... 15 4.4. Communication between trusted autonomic nodes and external nodes ....................................................... 15 5. Trust Networking in the Autonomic Networking Infrastructure.. 16 5.1. Identification of Trust networking domain and Trusted Autonomic Node .............................................. 17 5.2. Discovery of Trust networking domain ................... 18 5.3. Signaling Between Trusted Autonomic Nodes .............. 18 5.4. Trust Evaluation ....................................... 19 6. Procedures for trust networking ............................. 20 6.1. Building a trust networking domain ..................... 20 6.1.1. Domain initialization ............................. 20 6.1.2. Node registration ................................. 21 6.2. Evicting existing node from trust networking domain..... 23 6.3. Terminating trust networking domain .................... 23 6.4. Communication among trust networking domains ........... 23 6.4.1. Trustworthy networking within a single trust networking domain ................................................... 23 6.4.2. Trustworthy networking between trust networking domains ......................................................... 23 7. Security Considerations ..................................... 25 8. IANA Considerations ......................................... 26 9. Acknowledgements ............................................ 26 10. Contributors ............................................... 26 Choi, et,al. Expires January 13, 2019 [Page 3] Internet-Draft Trust Networking & Procedures for AN July 2018 11. References ................................................. 26 11.1. Normative References................................... 26 11.2. Informative References ................................ 26 1. Introduction The document describes the concept of trust networking as an application of Autonomic Networking Architecture. It defines a trust networking domain in compliance with reference model of autonomic networking. By definition of autonomic domain [rfc7575 Autonomic Networking Definitions and Design Goals] the trust networking domain is defined as a collection of autonomic nodes which trust other nodes in the same trust networking domain. That means, communications within the trust networking domain with sufficient trust level can be done without any further security concerns. For example, assume that a subnet properly protected from external threats and all nodes in the subnet are verified through trust evaluation procedures, then the communications within the subnet can be done with confidence that nodes do no harm to each other. This document first defines a trust networking domain and then describes how to configure the trust networking domain and keep the domain trustworthy. This document also describes a trust networking framework that consists of interconnected trust networking domains. The framework guides how to define the trust networking domain, how to manage members of the domain, how to protect the domain from hostile external world, how to expand the domain, and how to handle communications with external entities. Finally this documents shows how to apply the trust networking framework to the existing IP based network with minor modifications 2. Background One of the biggest problems in the current Internet is protecting information assets against divergent attacks. In the beginning of the Internet, security was not considered to be an essential component of the network architecture but optional solutions such as IPSec were used instead. This section compares the security model of the traditional Internet and our proposed trust model. Choi, et,al. Expires January 13, 2019 [Page 4] Internet-Draft Trust Networking & Procedures for AN July 2018 2.1. Security Model and its Limitations The security model of the current Internet is based on the assumption that all traffic coming from the Internet is suspicious. The lack of inherent security in IP protocol has led various attacks, such as attack on confidentiality by intercepting packets, integrity attack by modifying of the contents of packets, authentication attack by identity fabrication, and availability attack by interfering normal communications. In the context of untrusty Internet, each host should protect itself from potential risks of the hostile Internet. This protection usually take place at the final destination as seen in Figure 1. This model operates basically in reactive manner. That means, after receiving all arriving packets, threatening packets can be detected and removed. Detection of threatening packets are based on pre-defined rules extracted from previous attacks. +-------------------------------------------+ | +------------+ +------------+ | | :Interception: :Modification: | | +------------+ +------------+ | | : : | | : +------------+ : +-----------+ | | : :Interruption: : :Fabrication: | | : +------------+ : +-----------+ | | : : : : | | : : : : | +------+ | <*| <*| <*| +------+ | | +-----------------------------------+ | | | +- X | | | : +-----------------------------------+ | | +---:--+ | +------+ | : | | : +-------------------------------------------+ : +----------+ :Protection: +----------+ Figure 1. Security Model The reactive operations of security model result in endless malicious cycle of attacks and defenses. Rules has to be upgraded for every newly discovered attacks and more complicate rules are required as more sophisticate attacks emerge. This model is fatal in the case of devices with limited or no processing power. Also Choi, et,al. Expires January 13, 2019 [Page 5] Internet-Draft Trust Networking & Procedures for AN July 2018 stronger security makes the system weaker in defending DoS (Denial of Service) attacks. 2.2. Trust Model and Trust Relations In contrast to the security model based on doubt, the trust model is based on the confidence that any entity in the domain is not harmful to other entities and the communication environment within the domain is safe enough. Instead of unlimited connectivity, the trust model restrict connectivity to the limited group of trusted entities. Of course, the limited connectivity can be extended by the domain expansion principle described in Section 3.3. Figure 2 illustrates the trust model, which needs 3 requirements: Identification, Trust Relation, and Safe Environment. For identification purpose, the trust model uses self-certifying ID (SCID), which provides secure binding between ID and key of an entity. Many future Internet researches already use SCID for accountability or trusted path selection. The trust model assume that every entity has a public key and hash of the public key is defined as the ID of the entity. This ID can be used in validity check of claimed key against actual public key of the entity. The valid public key is basis of further identity verification. After identification the entity check trust relation with the peer entity so that only trusted entity is allowed to communicate. +----------------------------------------------------+ | | | | | +----------------+ +----------------+ | | : Identification : : Identification : | | +----------------+ +----------------+ | | : : | | : : | | +------+ |*> |*> <*| +------+ | | | +--------------------------+ | | | | | | | | Node +--------------------------+ Node | | | | | | | | | | <--------------------------> | | | +------+ Trust Relation +------+ | | | | | | | +----------------------------------------------------+ Choi, et,al. Expires January 13, 2019 [Page 6] Internet-Draft Trust Networking & Procedures for AN July 2018 Figure 2. Trust Model The trust relation used in the trust model is assumed to be reflexive, symmetric, and transitive. Reflexive means that entity A trust itself, denoting as AA. Symmetric relation assumes that two entities A and B satisfy AB and BA at the same time, denoting as AB. Transitive means that for three entities A, B, and C, if AB and BC then A C. If all entities in a given group satisfy all three characteristics, the group is declared as a trust equivalent class. We can easily guess the role of the trust model as formation of a trust equivalent class for the set of entities trusting each other. The trust model should provide safe and reliable communication environment to entities without requiring additional security features on the entities. Thanks to the transitive trust relation, if an external entity is trusted by one member of the domain as a trust equivalence class, other members in that domain also can trust the external entity. By restricting the domain to trusted entities, the environment can be kept safe and reliable. 2.3. Comparisons of Security and Trust Model The trust model is opposite in almost every aspect as shown in Table 1. First of all, the trust model is based on confidence that entities in a trust networking domain never do harm, while the security model is based on suspicion that adversaries attacks anytime. The relationship in trust model is binary in the sense that an entity trust another specific entity, but relationship in the security model is unary because the entity itself must protect regardless of other entities. With respect of rules, trust model keeps trusted IDs as a white list but security model keeps threatening entities as a black list. Thus, behavior of entities in the trust model is proactive while the security model acts in reactive manner. That leads the policy of the trust model is to prevent risk by communicating only with trusted entities, but policy of the security model monitors all communications to detect and remove threatening actions. The trust model provides mechanisms for accepting entities or domains after verifying their trust, while the security model provides mechanisms for watching the traffic and blocking the threatening traffics. As the result, the network space of the trust model starts with a restricted space and incrementally glows as new entities or domains are accepted, while the network Choi, et,al. Expires January 13, 2019 [Page 7] Internet-Draft Trust Networking & Procedures for AN July 2018 space of security model starts as an unrestricted and open space, but the space may be diminished by excluding misbehaving entities. Table 1 Comparison of Trust and Security Model Trust Model Security Model based on confidence suspicion relationship binary unary rules white list black list behavior proactive reactive policy prevention detect and remove mechanism verify and watch and accept block network unrestricted restricted space and and diminishing expanding 3. Trust Networking Framework The purpose of the trustworthy communication framework is to provide safe and reliable environment to entities without requiring additional security features. For keeping the environment trustworthy, the domain accepts only eligible entities. However, this restriction seems contradict to global scalability that requires the domain being open to everyone. Our solution is the incremental strategy, where a domain starts from a small and restricted network space and gradually expands to a global scale network space by accepting external entities or collaborating with other domains. This section discusses technical issues on the trustworthy communication framework. 3.1. Defining Trust Networking Domain A primitive domain can be defined as the network space that is autonomous, isolated, and well protected from external attacks. For example, isolated home or enterprise network can be defined as a domain. If all hosts in the domain are disinfected and communication links are not exposed, the domain can be declared as a trust networking domain. The trust networking domain is not always a physical network space but sometime it can be formed by a logical Choi, et,al. Expires January 13, 2019 [Page 8] Internet-Draft Trust Networking & Procedures for AN July 2018 group of users with mutual trust. In any case, the entities in the domain forms a trust equivalence class and communication with other entities in the domain is allowed without any protection. To keep to domain trustworthy only qualified entities can be accepted as a member of the domain, and misbehaving entities have to be removed from the domain. For maintenance of a domain, the behavior of entities in the domain may be monitored, and if suspicious activities are discovered, the corresponding entity must be removed. 3.2. Protecting Trust Networking Domain The domain representing an autonomous network space can take role of security unit as well as packet processing unit. The isolated domain from external world does not allow communication with external entities. For opening the domain to untrusty external world, well-defined interfaces are required to protect the domain. Let's call this protected domain an "insulated trust networking domain". As an example of insulated trust networking domain, we can imagine the local area network with firewalls on all links to the external Internet. The local area network is not isolated but is insulated from attacks injected through the external links. The proposed framework assumes that each domain has at least one gateway that performs security functions for the domain. The gateway identifies external entities, evaluate trust level, accepts or rejects the packets according to the trust levels of external entities. And also the gateway will forward only authorized and sterilized packets to peer domain for keeping its reputation or trust level. In the sense that gateways performs security functions on the behalf of the entities inside of the domain, the security of entities is said to be delegated to gateways. This delegated security has great benefit in applying complex security functions to devices with a limited or no processing power. 3.3. Expanding Trust Networking Domain If all communications are limited within a trust networking domain, the serious scalability arises with respect to global communication. Now, we have to consider expansion of trust networking domain, starting from a small trust networking domain to a global scale network. First, consider the situation that an entity outside of domain tries to communicate with an entity inside of the domain. For trustworthy communication across border of domain, the entity must be a member of the domain. The domain gateway performs well-defined Choi, et,al. Expires January 13, 2019 [Page 9] Internet-Draft Trust Networking & Procedures for AN July 2018 procedure for checking identity and evaluating the trust level of the external entity, and then only qualified entities are allowed to communicate with entities in the domain. Also the link connecting the domain with external entities should be secure enough for the trust level. This is one way to expand a domain. +-----------------------+ +-------------------------+ | +------+ +------+ | | +------+ +------+ | | | | | | | | | | | | | | | Node <-----> Node | <-------> | Node <----->| Node | | | | | | | | | | | | | | | +------+ +------+ | | +------+ +------+ | | +-------+ | | | | +--+ +--+ | | | | | | | | Trust Domain | | | | Trust Domain | | A | | | | B | | | | | | | +----------+------------+ | | +-------------------------+ ^ | | +------+ | | | | | +-------+--------+ | +-------+ Node | | | +---------+ | +--+---+ +--+---+ +------+ | | | | | Node | | Node | <------+ : Trust Verification | | | | +------+ +------+ <------> : Trust relation +------+ : Reliable +------+ channel Figure 3. Expansion of Trust Model Expanding a domain by accepting new entities has limitation when reaching the maximum number of entities being managed by a single domain. The other solution is collaboration of domains. Suppose two domains trust each other and those are connected by reliable links, then entities within one domain can trust entities within another domain. Figure 3 shows a trust networking domain with trusted entities and 3 ways how to expand the domain. First, new entities can join to the domain after passing trust verification. Second, a remote entity can Choi, et,al. Expires January 13, 2019 [Page 10] Internet-Draft Trust Networking & Procedures for AN July 2018 join to the domain via reliable channel. And third, when two domains may have trust agreement and connected by reliable channel, all entities in one domain can exchange packets in the pre-agreed trust level. 3.4. Communicating with External Entities As already seen, the communication inside of a domain requires no further security. However, communication with entities outside of the domain needs special care. Assume that all communication with external entities must take place at the special entity called a gateway, which enforce well-defined procedure communication for external entities. As explained in Section 3.3.2, an insulated trust networking domain has one or more gateways to perform trust verification for every packet injected to the domain. When a packet arrives at the gateway of a domain, the gateway first check whether the source ID of the packet is in the trusted ID list. If exists, the packet is accepted. Otherwise, the gateway lookups the trusted domain list to find sending domain of the packet. If the sending domain is in the list, the packet can also be accepted and ID of the packet is saved in the trust ID list. This mean that the gateway believes the trusted sending domain not to send harmful packets. If ID of the packet is not in the trusted ID list nor the sending domain is in the trust networking domain list, then verification procedure for individual ID has to be performed. The procedure is somewhat similar to accepting new entities in the domain. The overall procedure of a gateway is shown in Figure 4. 4. Trust networking domain as an application of autonomic networking This section defines what a trust networking domain is and describes how to configure the trust networking domain as an application of autonomic networking solutions. The autonomic nodes with trust networking domain will run with autonomic functions at Reference Model for Autonomic Networking. Autonomic networking infrastructure with trust management functions is capable to configure the trust networking domain. A set of autonomic nodes consists of a trust networking domain, which is configured, and managed by management plane. Within a trust networking domain, the full connectivity among autonomic nodes is securely and stably guaranteed. An autonomic node can easily communicate with other nodes at same trust networking domain. The trust level of autonomic nodes is calculated or assigned by trust evaluation function of management plane. Choi, et,al. Expires January 13, 2019 [Page 11] Internet-Draft Trust Networking & Procedures for AN July 2018 On the other hand, it is possible for autonomic nodes to communicate with different trust networking domains or non-autonomic networks via the trust gateway system, in which the traditional security or certificate mechanisms can be running. +----------------+ | Incoming | | Packets (ID) | | | +----------+-----+ | | +----------------------------|---------------------+ | +---------+ +----v--------+ | | | Trusted +-----+ Check ID | Hit | | +-+--> ID +-----+ +------+ | | : : +---------+ +----+--------+ | | | : : | | | | : : | | | | : : | | | | : : +---------+ +-----v--------+ Hit | | | : : | Trusted +----+ Check +------+ | | : : | Domains +----+ Domain | | | | : : +---------+ +-+---+--------+ | | | : : | | | | | : +-------------------+ | | | | : | | | | : +-----v--------+ | | | : | Trust | Pass | | | +-------------------+ Verification +------+ | | +--+-----------+ | | | Fail | | | | X <---------+ | | +--------------------------------------------|-----+ | +------v--------+ | Accepted | | Packets (ID) | | | +---------------+ Figure 4. Packet Processing at the Gateway Choi, et,al. Expires January 13, 2019 [Page 12] Internet-Draft Trust Networking & Procedures for AN July 2018 4.1. Definition of a Trust networking domain A trust networking domain is defined as a collection of autonomic nodes trusting each other. Since all nodes within a trust networking domain maintains certain trust level set by the domain, communications within the domain can be done without any further security concern. However, communications with external node require additional verification phase before the communications actually begin. The verification is performed at the border of the domain, where external nodes are checked if their trust level are sufficiently high for the domain. In the sense that the domain as a collection of node are protected from external world, it seems "zone defense" rather than "individual defense" of the traditional security scheme. Figure 5 shows the high-level architectural view of trust networking domain. Autonomic nodes has the interface with management function. Trust management functions define the trusted autonomic nodes according to their trust level. They also define the trust networking domain by grouping or classifying autonomic nodes. At the same trust networking domain, an autonomic node directly communicates with each other. The control and management functions at the trust networking domain are defined at the interfaces between autonomic nodes and management plane. There are trust gateway for an autonomic node to communicate with different trust networking domains or non-autonomic nodes since there is no direct communication path. Trust gateway is used to communicate autonomic nodes with different trust networking domains or the non-autonomic nodes. An autonomic node can communicate remote autonomic nodes or non-autonomic nodes through trust gateway. In these cases, the traditional trust evaluation and/or certificate procedures can be applied at trust gateway. Trust evaluation procedure is running by management plane of autonomic networking. Choi, et,al. Expires January 13, 2019 [Page 13] Internet-Draft Trust Networking & Procedures for AN July 2018 +-----------------------------------------------+ : : : Trust networking domain : : : +------------ : : : : : : : +---------------------------+ +-------------+: : : : Autonomic Function : :Trust Gateway:: : : : : : : Function :: : : : ASA 1 : ASA 1 : : ASA 2 :: : : : : : : :: : : +---------------------------+ +--------------: : : : : : : :: : : +--------------------------------------------+: : : : :: : : : Autonomic Networking Infrastructure :: : : +--------------------------------------------+: : : : : : : :: : : : +---------+ : +---------+: : +---------+ :: : +---------+ : : : Trusted : : : Trusted :: : : Trusted : :: : : External: : : :Autonomic:---:Autonomic:-...-:Autonomic:---------: Node : : : : Node 1 : : : Node 2 :: : : Node N : :: : : : : : +---------+ : +---------+: : +---------+ :: : +---------+ : : : : : :: : +-----------------------------------------------+ +------------ Figure 5. Trust networking domain at the Autonomic Networking 4.2. Configuration of Trust networking domain A trust networking domain is consisted of a group of autonomic nodes. The network management plane communicates with a list of autonomic nodes to build the trust networking domain. The trust management information database which contains a list of autonomic nodes according to the trust level of each domain is built at the bootstrapping time or at the instance of request. At the bootstrapping time, the management plane securely distributes the trust information of each domain to the corresponding autonomic nodes. The membership management is done by management plane when the autonomic nodes can be joined to or leaved from each trust networking domain. Choi, et,al. Expires January 13, 2019 [Page 14] Internet-Draft Trust Networking & Procedures for AN July 2018 At the instance that an autonomic node request to build a trust networking domain to the management plane, trust management function confirm to build a trust networking domain after completing the proper trust evaluation procedures. If an autonomic node could not continue to be a member of the certain trust networking domain, it notify to management plane for leave. Similarly, if the trust management functions decide that an autonomic node is not relevant to stay in a certain trust networking domain, they notify the corresponding autonomic node for leave and update the trust management information database. Within a trust networking domain, an autonomic node can communicate each other without any additional security and certificate procedure. In a case, an autonomic node may register multiple trust networking domains simultaneously. 4.3. Communication between Trusted Autonomic Nodes within a trust networking domain At the same trust networking domain, autonomic nodes directly communicate with each other. Autonomic nodes can discover other nodes at the same trust networking domain. It requires control or management information between autonomic nodes and control/management plane. It can be pre-configured during bootstrapping. The control information between autonomic nodes can be used to identify the trust networking domain. The autonomic nodes can easily communicate with each other at the same trust networking domain by enabling self-managing capability of autonomic networking. The autonomic service agents can be implemented for trusted communication. 4.4. Communication between trusted autonomic nodes and external nodes Autonomic nodes must communicate with autonomic nodes of the different trust networking domain. They also communicate with the non-autonomic nodes. Trust gateway can help that an autonomic node communicate with the autonomic nodes with different trust networking domain or the non- autonomic nodes. Some autonomic service agents (ASA) may include the Choi, et,al. Expires January 13, 2019 [Page 15] Internet-Draft Trust Networking & Procedures for AN July 2018 trust gateway functions for communicating autonomic nodes with different trust networking domain, which is in the reference model for Autonomic Networking [xxx]. 5. Trust Networking in the Autonomic Networking Infrastructure This section describes trust networking of autonomic network. Within a trust networking domain, an autonomic node is credited by their trust level from management plane. The trust management plane maintains the trust information tables up to date. The trust management plane is tracking of trust status of each autonomic node as an application of autonomic networking. The trust information table contains the trust information of autonomic nodes based on the trust networking domain. All the interactions between autonomic nodes should be verified according to trust evaluation procedures of management plane. The autonomic nodes within the same trust networking domain create and maintain network connectivity without additional complexity. Trust provisioning among autonomic nodes is to exempt any additional processing (like identification, addressing, routing, forwarding, and security, etc.) to maintain autonomic networking within the same trust networking domain. The interactions between autonomic nodes are based on the trust evaluation of the trust networking domain. The trust information is used to leverage the direct interactions between autonomic nodes. Trust gateway can help to the interaction of autonomic nodes with different trust networking domains or with non-autonomic nodes. The trust management plane is used to handle the trust level of each autonomic node with proper trust evaluation procedure. Choi, et,al. Expires January 13, 2019 [Page 16] Internet-Draft Trust Networking & Procedures for AN July 2018 +---------------------------+ | Trust management plane | | | | - Provisioning of the | | identities of nodes | | | | - Trust evaluation | | | +------+------+------+------+ +--------------------------+ | : : : | | | | : : : | | | | +----+---+ : +----+---+ | | +--------+ | | | | : | | | | | | | | | Node 1 | : | Node 2 | | | | Node 3 | | | | +----+ | | | | | | | | | : | | | | | | | | +--------+ : +----+---+ | | +---+----+ | | : | | | | | | : | | | | | | +-----+------+---+ | | +-----+------------+ | | | Trust Gateway | | | | Trust Gateway | | | | of domain A <---------------> of domain B | | | +----------------+ | | +------------------+ | +---------------------------+ +--------------------------+ Figure 6. Trust provisioning at the Autonomic Networking 5.1. Identification of Trust networking domain and Trusted Autonomic Node This section describes trust level. An autonomic node can initiate to create their own trust networking domain. The management plane provides that an autonomic node can build the relevant trust networking domain by identifying the corresponding autonomic nodes. Specific policies can be applied to build trust networking domain. In a trust networking domain, each autonomic node should be identified by the relevant naming and addressing schemes, which are also compliant with the Reference Model for Autonomic Networking [xxx]. Before data exchange, the autonomic nodes obtains the identities (e.g., IP address and port number, etc.) of destination Choi, et,al. Expires January 13, 2019 [Page 17] Internet-Draft Trust Networking & Procedures for AN July 2018 nodes and the corresponding trust networking domain. In a case, the MAC address can be also used for identification. The trust management information database is used for the discovery of autonomic nodes at the same trust networking domain. The autonomic nodes with the same trust networking domain may use the relevant identification schemes. In the trust management information database, a list of autonomic nodes are classified into the relevant identification code which indicates the same trust networking domain. The identification code for a trust networking domain may contain name/nickname and number as well as IP address and port number, etc. 5.2. Discovery of Trust networking domain The trust management information database is used for the discovery of autonomic nodes at the same trust networking domain. Before data exchange, an autonomic node looks up the trust management information database to find the destination autonomic nodes. If the destination node belongs to the same trust networking domain with original autonomic node, it is possible to initiate data exchange. 5.3. Signaling Between Trusted Autonomic Nodes At the same trust networking domain, an autonomic nodes communicate with each other. For data exchange, the autonomic node should discover each other by accessing the trust management information database of management plane. After discovery of destination autonomic node, the signaling protocol like "A Generic Autonomic Signaling Protocol (GRASP)" [I- D.ietf-anima-grasp] are needed to initiate data exchange. Within the same trust networking domain, an autonomic node directly communicates with each other after completing signaling procedure, in which the connectivity among autonomic nodes are securely and automatically maintained. The pre-configuration between autonomic nodes can be done during bootstrapping. The autonomic control plane at the Reference Model for Autonomic Networking [xxx] can be either implemented to carry signaling protocol. For data exchange with different trust networking domains or non- autonomic nodes, the trust gateway provides proper interworking functions for data exchange and signaling since there is no direct communication paths between them. The trust gateway provides the Choi, et,al. Expires January 13, 2019 [Page 18] Internet-Draft Trust Networking & Procedures for AN July 2018 relevant control and management information to extend data exchange with different trust networking domains or non-autonomic nodes. The authentication and certificate procedures equivalent with the trust networking domain can be applicable to provide external connectivity. 5.4. Trust Evaluation Trust evaluation of network is the way of calculating trust for networking services. It requires data collection from various sources. Physical data sources are collected from the capability of data processing, storage, and communication through network. In cyber world, logical data sources are software that work on computing algorithm, storage, and networking. In the social world, human produces various data through user interfaces. In the physical network, trust can be measured by counting on their trustworthiness of network elements. In the cyber world, software can be accidentally or maliciously altered or destroyed during control, computing, and communicating instances. The unexpected behaviors of software is detected or monitored to evaluate and update their trust level. In the social world, human behaviors can be measured by considering its trustworthiness in terms of ability, honesty and benevolence. Social trust reflects individual human activity. Human interacts with others honestly and kindly so that their trust level is affected by some risks. For trust evaluation, the collected data are categorized into two types of attributes and indicators namely, qualitative and quantitative. Trust index is used to calculate the certain trust level of each network entity. As the results of trust evaluation, trustor finally make a decision. The network management plane provides to calculate the trust level of the network elements from various data sources and store their values to trust management information database. The trust management information contains the trust level of autonomic nodes. The interactions inside a trust networking domain are analyzed and accumulated to evaluate the trust level of each node. The trust level of autonomic node is contained at the trust management information database. All the interactions between Choi, et,al. Expires January 13, 2019 [Page 19] Internet-Draft Trust Networking & Procedures for AN July 2018 autonomic nodes in a same trust networking domain is validated by the trust evaluation procedure. The trust evaluation procedure is fed by the following inputs. o Pre-provisioned or manually configured by policy or management information o Analysis from interactions between autonomic nodes o The accumulated history information of trust verifications such as authentication of non-autonomic nodes and validity of application specific transactions. o other unaccepted or unexpected behaviors While autonomic nodes communicate with each other, they choose the relevant trust management protocol whether they meet trust requirements in the same trust networking domain or not. Trust management protocol between autonomic nodes and trust management database is needed to check trust evaluation. Trust evaluation procedure between autonomic nodes at same trust networking domain are taken for trust identification. If the prerequisite and pre-configuration procedures are already taken for trust management, simple and light-weight solution can be applicable for communication between autonomic nodes. 6. Procedures for trust networking 6.1. Building a trust networking domain 6.1.1. Domain initialization To build a new trust networking domain, the domain administrator needs to initiate the functionalities of trust networking domain as follows: - Domain administration To initialize a domain with respect to the trust, the domain administrator needs to configure policies of trust and membership. To manage the trust level, the domain administrator sets the required trust level of membership with domain policy management Choi, et,al. Expires January 13, 2019 [Page 20] Internet-Draft Trust Networking & Procedures for AN July 2018 (DPM) ASA. The domain administrator can explicitly dedicate a node for trust management functions and trust provisioning. - Access & delivery control The nodes that connected outside of the domain should equip trust gateway functions. For IP network case, every node of the domain should assign their gateway to the nodes with trust gateway ASA. +---------------------------------+ | | +--------------+ | +-------------+ Private IP +----+----+ | | | | Domain | Networking | Domain | | | | |Administrator+------------+ Gateway +------------+ The Internet | | +-------------+ +----+----+ Public IP | | | | Networking | | | Trust networking domain | +--------------+ +---------------------------------+ Figure 7. Initialization of a new trust networking domain 6.1.2. Node registration After the trust networking domain has been initialized, domain can adopt network nodes. +-----------------------------------------+ | | | Trust networking Domain | | | +----------+ +-----+--------+ +-----------------+ | | | | | | | | | Node A +--+----> Domain +------> Domain | | | | | | Gateway | | Administrator | | +----------+ | | | | | | | +-----+--------+ +-----------------+ | Registration | | Message | | +-----------------------------------------+ Figure 8. Registration of a new node Choi, et,al. Expires January 13, 2019 [Page 21] Internet-Draft Trust Networking & Procedures for AN July 2018 The procedures of node registration are as follows: +-----------+ +-------------+ +----------------+ | | (1) | | | | | +----------> Domain | | | | | (2) | Gateway | | Trust Info. <---+ | <----------+ | | Management | | | | (3) +-------------+ | ASA | | | <-----------------------------+ | | | | +----------------+(5)| | | +----------------+ | | | (4) | | | | Node A +-----------------------------+ Domain Member <---+ | | | Management <---+ | | | ASA | | | | +----------------+ | | | +----------------+(7)| | | | | | | | (6) | ID-Location | | | <-----------------------------+ Management <---+ | | | ASA | +-----------+ +----------------+ Figure 9. Procedures of node registration (1) Node A connects to the network of trust networking domain; (2) The domain assigns a private IP address to Node A. The domain gateway is assigned as the default gateway for IP network; (3) Trust information management ASA analyses the trust information of node A; (4) Node A request to join the domain; (5) Domain membership management ASA of the domain administrator receives the requests and decides to approve Node A, based on the domain policy and trust level of Node A; (6) ID-Location management ASA of the domain administrator issues a new identifier of Node A; (7) ID-Location management ASA archives Node A's identifier and private IP address. Choi, et,al. Expires January 13, 2019 [Page 22] Internet-Draft Trust Networking & Procedures for AN July 2018 6.2. Evicting existing node from trust networking domain (Editors' note) This section describes how to evict existing node in trust networking domain including trust management procedures. Further details are for further study. 6.3. Terminating trust networking domain (Editors' note) This section describes how to terminate trust networking domain including signalling procedures with child nodes (or domains) and parent domains. Further details are for further study. 6.4. Communication among trust networking domains This section describes trustworthy communication between nodes within a single trust networking domain and between nodes separated into multiple trust networking domains. 6.4.1. Trustworthy networking within a single trust networking domain In order for the two hosts to send and receive messages to each other, a networking path must first be established. If two hosts are located in the same domain, they already have trust relationship with each other which means no additional security procedures are needed. 6.4.2. Trustworthy networking between trust networking domains Two hosts are in different domains. It means that they do not know each other's IP address directly. The domain administrator provides IP address of each hosts for trustworthy networking between two hosts in different domains. If a Host 2 wants to perform trustworthy networking with a Host 1 in other domain, it is possible to establish a networking path between two nodes through interactions between domain administration functions and access and delivery control functions. Figure 10 shows an overview of trustworthy networking between trust networking domains. Choi, et,al. Expires January 13, 2019 [Page 23] Internet-Draft Trust Networking & Procedures for AN July 2018 +------------------------+ +-------------------------+ | Trust networking | | Trust networking | | domain 1 | | domain 2 | | | | | | +--------+ +-------+ Communication +-------+ +--------+ | | | | | Domain| Path | Domain| | | | | | Host 1 +-----+ Gate- <---------------> Gate- +------+ Host 2 | | | | | | way 1 | | way 2 | | | | | +--------+ +---+---+ +---+---+ +--------+ | | | | | | | | +-------+ | | +--------+ | | | | | | | | +------+------+ | | +-----+-------+ | | | Domain | | ID/IP exchange| | Domain | | | |Administrator<--------------------------->Administrator| | | | 1 | | | | 2 | | | +-------------+ | | +-------------+ | +------------------------+ +-------------------------+ Figure 10. Trustworthy networking between trust networking domains Figure 11 shows detailed procedures for trustworthy networking between trust networking domains are follows: +------+ (1) +--------+ +--------+ +------+ | +------> Domain | (2) | Domain | | | | | (3) | Admin. +--------+ Admin. | | | | <------+ ASA 2 | | ASA 1 | | | | | +--------+ +--------+ | | | | (4) +--------+ (5) +--------+ | | | +------+ Trust +--------> Trust | | | | | (6) | Info. | | Info. | | | | Host <------+ ASA 2 +--------+ ASA 1 | | Host | | 2 | +--------+ +--------+ | 1 | | | | | | | +--------+ +--------+ | | | | | | (7) | | | | | | (9) | Domain <--------> Domain | (9) | | | +------> gate- | (8) | gate- +------> | | | | way 2 <--------> way 1 | | | | | | +--------> | | | +------+ +--------+ (9) +--------+ +------+ Choi, et,al. Expires January 13, 2019 [Page 24] Internet-Draft Trust Networking & Procedures for AN July 2018 Figure 11. Procedures of trustworthy networking between trust networking domains (1) Host 2 requests IP address of Host 1 to the domain administration ASA 2 through the ID of the host 1; (2) The domain administration ASA 2 requests IP address of the Host 1 to the domain administration ASA 1; (3) The domain administration ASA 1 obtains IP address of the Host 1 and reply ID and IP address of the Host 1 to domain administration ASA 2, and it replies to Host 2; (4) Host 2 requests a trust level of Host 1 through the domain administration ASA 2; (5) The domain administration ASA 2 checks a trust level of Host 2 through the trust information management ASA and requests a trust level of Host 1 to domain administration ASA 1; (6) The domain administration function 1 obtains the trust level of Host 1 through the trust information management ASA and replies it to the domain administration ASA 2, and the result replies to Host 2; (7) The access and delivery control ASA 2 forms a routing path with the access and delivery control function 1 through the ID-based routing ASA; (8) The Host 2 and the Host 1 establish a reliable link through the domain gateway ASA of each trust networking domain; (9) Networking path established between Host 1 and Host 2. 7. Security Considerations Data exchange between autonomic nodes at the trust networking domain must be secured. The signaling or management protocols for trust identification and discovery of trust networking domain are secure. The control/management plane for trust management is self-protecting. The autonomic node in a trust networking domain should be certified by its identity. The pre-configuration information of autonomic nodes from trust management information database should be certified during bootstrapping time. For data exchange with different trust networking domain or non- autonomic network, the trust gateway should be securely implemented. Trust gateway maintains the same trust level for cross-domain applications or interaction with non-autonomic network. Choi, et,al. Expires January 13, 2019 [Page 25] Internet-Draft Trust Networking & Procedures for AN July 2018 8. IANA Considerations This document requests no action by IANA. 9. Acknowledgements 10. Contributors 11. References 11.1. Normative References [I-D.ietf-anima-autonomic-control-plane] Eckert,T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control- plane-13 (work in prgress), December 2017. [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), April 2018. [ITU-T Y.3052] Overview of trust provisioning in information and communication technology infrastructures and service, March 2017 [ITU-T Y.3053] Framework of trustworthy networking with trust- centric network domains, January 2018 11.2. Informative References [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Reference Model for Autonomic Networking", draft-ietf- anima-reference-model-06 (work in progress), February Choi, et,al. Expires January 13, 2019 [Page 26] Internet-Draft Trust Networking & Procedures for AN July 2018 2018. Choi, et,al. Expires January 13, 2019 [Page 27] Internet-Draft Trust Networking & Procedures for AN July 2018 Authors's Addresses Tae Sang Choi Electronics and Telecommunication Research Institute (ETRI) 218 Gajeong-ro, Gajeong-dong, Yuseong-gu, Daejeon Korea Email: choits@etri.re.kr Jun Kyun Choi (editor) Korea Advanced Institute of Science and Technology (KAIST) 193 Munji Ro, Yuseong-gu, Daejeon Korea Email: jkchoi59@kaist.ac.kr Tae Su Jeong Electronics and Telecommunication Research Institute (ETRI) 218 Gajeong-ro, Gajeong-dong, Yuseong-gu, Daejeon Korea Email: tsjeong@etri.re.kr Jae Seob Han Korea Advanced Institute of Science and Technology (KAIST) 193 Munji Ro, Yuseong-gu, Daejeon Korea Email: j89449@kaist.ac.kr Woo Jik Chun Korea Advanced Institute of Science and Technology (KAIST) 193 Munji Ro, Yuseong-gu, Daejeon Korea Email: woodbine@kaist.ac.kr Choi, et,al. Expires January 13, 2019 [Page 28]