ANIMA T.S.Choi
Internet Draft T.S.Jeong
Intended status: Standards Track ETRI
Expires: January 13, 2019 J.K.Choi
J.S.Han
KAIST
October 14, 2018
Trust networking and procedures for Autonomic Networking
draft-choi-anima-trust-networking-01
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."
Choi, et,al. Expires January 13, 2019 [Page 1]
Internet-Draft Trust Networking & Procedures for AN October 2018
This Internet-Draft will expire on January 13, 2019
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 October 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 ........................ 9
3.2. Protecting Trust Networking Domain ...................... 9
3.3. Expanding Trust Networking Domain ...................... 10
3.4. Communicating with External Entities ................... 11
4. Differences between trust networking and ANIMA security framework
.............................................................. 12
4.1. Domain as a Whole
...................................... 12
4.2. Individual Nodes (Domain members) ...................... 13
4.3. Domain Boundary........................................ 13
4.4. Topology .............................................. 14
4.5. Technology ............................................ 15
4.6. Connection to the Internet
............................. 15
4.7. Security, Trust and Privacy Model ...................... 16
4.8. Operations ............................................ 16
5. Trust networking domain as an application of autonomic networking
.............................................................. 17
5.1. Definition of a Trust networking domain ................ 18
5.2. Configuration of Trust networking domain ............... 19
5.3. Communication between Trusted Autonomic Nodes within a trust
networking domain .......................................... 20
5.4. Communication between trusted autonomic nodes and external
nodes ...................................................... 20
6. Trust Networking in the Autonomic Networking Infrastructure
.. 21
6.1. Identification of Trust networking domain and Trusted
Autonomic Node ............................................. 22
6.2. Discovery of Trust networking domain ................... 23
6.3. Signaling Between Trusted Autonomic Nodes .............. 23
6.4. Trust Evaluation
....................................... 24
7. Procedures for trust networking
............................. 25
7.1. Building a trust networking domain ..................... 25
7.1.1. Domain initialization
............................. 25
7.1.2. Node registration
................................. 26
7.2. Evicting existing node from trust networking domain
..... 28
Choi, et,al. Expires January 13, 2019 [Page 3]
Internet-Draft Trust Networking & Procedures for AN October 2018
7.3. Terminating trust networking domain .................... 28
7.4. Communication among trust networking domains ........... 28
7.4.1. Trustworthy networking within a single trust networking
domain .................................................. 28
7.4.2. Trustworthy networking between trust networking domains
........................................................ 28
8. Security Considerations
..................................... 30
9. IANA Considerations ........................................ 31
10. Acknowledgements .......................................... 31
11. Contributors .............................................. 31
12. References ................................................ 31
12.1. Normative References
.................................. 31
12.2. Informative References
................................ 31
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
Choi, et,al. Expires January 13, 2019 [Page 4]
Internet-Draft Trust Networking & Procedures for AN October 2018
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.
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
Choi, et,al. Expires January 13, 2019 [Page 5]
Internet-Draft Trust Networking & Procedures for AN October 2018
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
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.
+----------------------------------------------------+
| <Safe Environment> |
| |
| +----------------+ +----------------+ |
| : Identification : : Identification : |
| +----------------+ +----------------+ |
| : : |
| : : |
| +------+ |*> |*> <*| +------+ |
| | +--------------------------+ | |
| | | |
| | Node +--------------------------+ Node | |
| | | | | |
Choi, et,al. Expires January 13, 2019 [Page 6]
Internet-Draft Trust Networking & Procedures for AN October 2018
| | <--------------------------> | |
| +------+ Trust Relation +------+ |
| |
| |
| |
+----------------------------------------------------+
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
Choi, et,al. Expires January 13, 2019 [Page 7]
Internet-Draft Trust Networking & Procedures for AN October 2018
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
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 | rectricted |
| 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
Choi, et,al. Expires January 13, 2019 [Page 8]
Internet-Draft Trust Networking & Procedures for AN October 2018
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
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
Choi, et,al. Expires January 13, 2019 [Page 9]
Internet-Draft Trust Networking & Procedures for AN October 2018
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
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
Choi, et,al. Expires January 13, 2019 [Page 10]
Internet-Draft Trust Networking & Procedures for AN October 2018
+------+ 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
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.
Choi, et,al. Expires January 13, 2019 [Page 11]
Internet-Draft Trust Networking & Procedures for AN October 2018
4. Differences between trust networking and ANIMA security framework
This section describes major differences between the proposed trust
autonomic domain (TAD) and ANIMA security framework. The
differences are explained based on a following set of criteria
defined in the draft-carpenter-limited-domains-03: domain as a whole,
domain members, domain boundary, topology, technology, connection to
the Internet, security/trust/privacy model, and operation since our
proposed domain and that of ANIMA are kinds of limited domains.
4.1. Domain as a Whole
Networking is a very complex task and traditional way of handling
the complexity is layering, where each layer takes a specific role
and provides its services to the next higher later. This layering
architecture decomposes the whole networking task functions
vertically. However, the network in general spans physical or
logical regions. Each region may have distinct features, such as
different physical media, separate administration, and diverse
networking requirement. The concept of domain in this document is
defined as the networking region that shares common characteristics
and also is distinguished from the rest of the network. Traditional
layers cover its own regions implicitly; the physical layer spans
the range covering electric signals. The data link covers the range
connected by layer 2 bridges, and the network layer covers the whole
devices connected by routers, and so on. Instead of implicit regions
of the layers, a domain can be defined as any region of the network
which is distinguishable from the rest of the network. It can be
defined as a region covered by electric signal, a home network owned
by a single user, a virtual private network overlaid on the Internet,
a social network composed of members. Thus, it can be defined by any
layer.
In the context of TAD, the domain can be defined by trust. That
means all members within a TAD trust each other so that the members
can communicate with others without any concern of security. For
this, TAD needs to add an additional ASA which performs a role of
domain administrator. Its main functionality is to manage trust
policies including allocating trust level to domains and their
members. Domain administrator can extend the functionality of ANIMA
MASA or define a new ASA for the purpose of the domain
administration. The details of domain administrator is specified in
Section 5 below.
Choi, et,al. Expires January 13, 2019 [Page 12]
Internet-Draft Trust Networking & Procedures for AN October 2018
4.2. Individual Nodes (Domain members)
As defined in the previous section, the domain covers a specific
region of the network, to where a set of nodes belongs. Since a
domain shares common characteristics, any node within the domain
must be able to communicate with other nodes in the domain. The node
as a member of a domain can be host, networking devices,
applications depending on the characteristics of the domain. For
keeping the same characteristics, a node trying to be a new member
of the domain must prove its functionalities to all or a designated
member of the domain. Joining to a domain may be accomplished by
simply plugging interfaces to the networking device or well-defined
interactions enforced by domain administrator. The joining procedure
may be implicit when a domain has fixed and permanent members, or
explicit in case that a node can join or leave the domain.
In the sense of TAD, a node is assumed as a host that has
communication functions required by the domain. Since a TAD is
defined under the intent of trust, a node should have identifiable
and authenticatable ID. TAD utilizes a concept of self-certifying ID.
The self-certifying ID can be newly defined. However, in the
context of TDA as an application use case of ANIMA, we can utilize
IdevID as a self-certifiable ID and preferably extend IdevID with
public key information as an option to ensure the global uniqueness.
4.3. Domain Boundary
Since a domain is a set of nodes that shares common characteristics,
only nodes within a domain can communicate. In other words, a node
within a domain cannot communicate with nodes outside of the domain.
However, we can assume special nodes that belongs multiple domains
simultaneously. Let's call a node joining more than two domains a
"gateway". A gateway node must be equipped with multiple
functionalities, each for the joined domain. The role of gateway is
conveying interactions of one domain to other domains. Of course,
conveying interaction may include necessary functions such as
interpretation, filtering, transformation etc. From outside of a
domain, the internals of the domain is hidden and the boundary of
the domain composed of gateways are only exposed. All interactions
passing the boundary of a domain must performed by at least one of
the gateways whose role is to enforce necessary gatewaying
procedures.
Choi, et,al. Expires January 13, 2019 [Page 13]
Internet-Draft Trust Networking & Procedures for AN October 2018
In the context of TAD, all members of a TAD trust each other, but
cannot trust nodes outside of the domain. The only way for an
internal node to communicate with external nodes is passing through
a gateway of the domain. Once the gateway receives communication
request from a node outside of the domain, it authenticates the node
and evaluates the trustworthiness of the node. If the external node
is trustworthy and communication channel between gateway and the
node is safe and reliable enough for the domain trust level, the
gateway accepts communication and injects the communication possibly
with transformation. Unlike ANIMA which assumes IP based
communications by every domains, TAD may allow any networking
technology besides IP. Therefore, a gateway is a mandatory
component where the need for it is implicit in ANIMA due to the
homogenous nature networking technology used in a domain. The
details of domain gateway functionality is specified in Section 5
below.
4.4. Topology
As defined in Section 4.1, a domain is a range of network where all
members can communicate. The communication can be done in either
specific layer protocols or any common functionalities. For example,
if domain is defined by local area network, the domain may use local
IP addresses, link-local or site-local. For domains defined by
virtual network overlaid on global Internet may use global IP
addresses with filtering functions.
As already explained in section 4.3, some special nodes may belong
to multiple domains. In this case the range of the domains that
involve the same nodes can be viewed as overlapped domains. The node
belonging multiple domains should have multiple functionalities, one
of each domain. Those functionalities should be separated. We can
find similar situation in multi-homed IP host in the Internet, where
the host has separate IP addresses, one for each IP address domain.
In the context of TAD, domains also have self-certifying ID as an
ordinary node to become a member of another domain. The domain
administrator must take a role of the required procedures of the
parent domain such as trust evaluation, join and leave. Also the
Choi, et,al. Expires January 13, 2019 [Page 14]
Internet-Draft Trust Networking & Procedures for AN October 2018
gateways must take necessary translation of the interactions when
passing the domain boundary.
4.5. Technology
In the context of TAD, any technology is allowed for the domain
since a domain has its own mechanisms hidden from outside. Apart
from the existing Internet using global IP addresses, each domain
may use its own routing or forwarding mechanisms, such as Ethernet,
MPLS, or Upper-Layer IDs. Only requirement for inter-domain
communication is that the gateway must aware of mechanisms for both
domain and takes a role of translation. Note that each domain has a
domain specific addressing scheme and identification of
nodes/domains must be done by globally unique identifier. With
global ID a node can join a domain or move from one domain to
another. In this case a node acquires a domain specific address when
joining the domain.
4.6. Connection to the Internet
In the context of TAD, the existing Internet can be viewed as a huge
domain with global coverage. Nodes or domains with IP capability can
join the global Internet domain as members. Since the existing
Internet has no notion of ID, let us assume the global Internet
domain top-level domain where every domain can join. Each domain
with its specific mechanism can join the global Internet domain
permanently or intermittently. The communication from one domain to
another domain through the global Internet domain is done by the
normal IP communication. However, the gateway of each domain must
translate its internal communication mechanism to that of the
corresponding IP address communications. More specifically, Inter-
domain communication is done by global ID and the ID is translated
into domain-specific address when passing the domain boundary. This
ID based communication may be encapsulated in IP packet when
traversing the global Internet domain. To allow this translation,
the ID to IP address mapping system must be provided, where IP
address is the gateway address of the domain that involves the node
with the ID.
Choi, et,al. Expires January 13, 2019 [Page 15]
Internet-Draft Trust Networking & Procedures for AN October 2018
4.7. Security, Trust and Privacy Model
One of implication of a domain is secure protection of the domain
internals from the rest of the network. That is members of a domain
should be identified, authenticated, and authorized. According to
domain's policies, well-defined procedures must be enforced to a
node to become a member of the domain.
In TAD all members of the domain must have the same or higher trust
level than the domain requires. That means, whenever a new node
tries to be a member of the domain or an external node tries to
communicate with an internal node, the domain administrator must
authenticate and evaluate the node. Only the node passing the
evaluation procedure is allowed to communicate. In this case
communication must be done via channels safe and reliable enough for
the trust level. In some cases where the channel is not safe nor
reliable, the communicating nodes must authenticate or encrypt the
traffic. Note that whether the traffic is protected or not depends
on the risk level of the channel and trust level of the domain.
Unlike the VPN that protects all channels in the same security
protocols, channels for a domain are additionally protected only
when the risk level of a specific channel is higher than required.
4.8. Operations
In addition to trust relation between nodes within a domain, the
environment of the domain must be considered. Environment of a
domain includes factors affecting domain operation such as
communication channels among nodes, operation skills of domain
administrator, reliability of devices, etc. To be protected from the
rest of networks, a domain should be securely protected from
external attacks.
Since communications within a TAD are carried out on the mutual-
trust basis, the domain administrator should keep the domain
trustworthy by accepting only trusted members, monitoring traffic to
detect suspicious behavior, and periodic auditing the logs of domain
members, and so on.
Choi, et,al. Expires January 13, 2019 [Page 16]
Internet-Draft Trust Networking & Procedures for AN October 2018
5. 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.
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--------+ | |
Choi, et,al. Expires January 13, 2019 [Page 17]
Internet-Draft Trust Networking & Procedures for AN October 2018
| : | Trust | Pass | |
| +-------------------+ Verification +------+ |
| +--+-----------+ | |
| Fail | | |
| X <---------+ | |
+--------------------------------------------|-----+
|
+------v--------+
| Accepted |
| Packets (ID) |
| |
+---------------+
Figure 4. Packet Processing at the Gateway
5.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
Choi, et,al. Expires January 13, 2019 [Page 18]
Internet-Draft Trust Networking & Procedures for AN October 2018
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.
+-----------------------------------------------+
: :
: 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
5.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.
Choi, et,al. Expires January 13, 2019 [Page 19]
Internet-Draft Trust Networking & Procedures for AN October 2018
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.
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.
5.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.
5.4. Communication between trusted autonomic nodes and external nodes
Choi, et,al. Expires January 13, 2019 [Page 20]
Internet-Draft Trust Networking & Procedures for AN October 2018
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
trust gateway functions for communicating autonomic nodes with
different trust networking domain, which is in the reference model
for Autonomic Networking [I-D.ietf-anima-reference-model].
6. 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 21]
Internet-Draft Trust Networking & Procedures for AN October 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
6.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 [I-
D.ietf-anima-reference-model]. Before data exchange, the autonomic
nodes obtains the identities (e.g., IP address and port number,
Choi, et,al. Expires January 13, 2019 [Page 22]
Internet-Draft Trust Networking & Procedures for AN October 2018
etc.) of destination 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.
6.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.
6.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 [I-D.ietf-anima-
reference-model] 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
Choi, et,al. Expires January 13, 2019 [Page 23]
Internet-Draft Trust Networking & Procedures for AN October 2018
functions for data exchange and signaling since there is no direct
communication paths between them. The trust gateway provides the
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.
6.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
Choi, et,al. Expires January 13, 2019 [Page 24]
Internet-Draft Trust Networking & Procedures for AN October 2018
management information database. All the interactions between
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.
7. Procedures for trust networking
7.1. Building a trust networking domain
7.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
Choi, et,al. Expires January 13, 2019 [Page 25]
Internet-Draft Trust Networking & Procedures for AN October 2018
required trust level of membership with domain policy management
(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
7.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 26]
Internet-Draft Trust Networking & Procedures for AN October 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 27]
Internet-Draft Trust Networking & Procedures for AN October 2018
7.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.
7.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.
7.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.
7.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.
7.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 28]
Internet-Draft Trust Networking & Procedures for AN October 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 29]
Internet-Draft Trust Networking & Procedures for AN October 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.
8. 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 30]
Internet-Draft Trust Networking & Procedures for AN October 2018
9. IANA Considerations
This document requests no action by IANA.
10. Acknowledgements
11. Contributors
12. References
12.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
12.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-08 (work in progress), February
2018.
Choi, et,al. Expires January 13, 2019 [Page 31]
Internet-Draft Trust Networking & Procedures for AN October 2018
Authors' 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
Nam Seok Ko
Electronics and Telecommunication Research Institute (ETRI)
218 Gajeong-ro, Gajeong-dong, Yuseong-gu, Daejeon
Korea
Email: nsko@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
Choi, et,al. Expires January 13, 2019 [Page 32]