idnits 2.17.1 draft-choi-anima-trust-networking-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 391 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1055 has weird spacing: '... Trust netwo...' -- The document date (October 14, 2018) is 2022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-anima-autonomic-control-plane' is defined on line 1239, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 1244, but no explicit reference was found in the text == Unused Reference: 'ITU-T Y.3052' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'ITU-T Y.3053' is defined on line 1253, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T Y.3052' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T Y.3053' == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-08 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA T.S.Choi 3 Internet Draft T.S.Jeong 4 Intended status: Standards Track ETRI 5 Expires: January 13, 2019 J.K.Choi 6 J.S.Han 7 KAIST 8 October 14, 2018 10 Trust networking and procedures for Autonomic Networking 12 draft-choi-anima-trust-networking-01 14 Abstract 16 This document describes trust networking as an application of 17 autonomic networking. The objective of trustworthy autonomic 18 networking is providing trust networking environment where all 19 autonomic nodes can communicate without any security concern. It 20 defines a trust networking domain and describes how to configure and 21 maintain the trust networking domain. While communication within the 22 trust networking domain is done with trust, the communication with 23 external nodes should be done via a specific autonomic service agent 24 (ASA) called "trust gateway". The trust gateway ASA performs trust 25 evaluation of the external nodes and enforces domain specific 26 policies to keep the domain trustworthy. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 13, 2019 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................ 4 60 2. Background .................................................. 4 61 2.1. Security Model and its Limitations ...................... 5 62 2.2. Trust Model and Trust Relations ......................... 6 63 2.3. Comparisons of Security and Trust Model ................. 7 64 3. Trust Networking Framework 65 ................................... 8 66 3.1. Defining Trust Networking Domain ........................ 9 67 3.2. Protecting Trust Networking Domain ...................... 9 68 3.3. Expanding Trust Networking Domain ...................... 10 69 3.4. Communicating with External Entities ................... 11 70 4. Differences between trust networking and ANIMA security framework 72 .............................................................. 12 73 4.1. Domain as a Whole 74 ...................................... 12 75 4.2. Individual Nodes (Domain members) ...................... 13 76 4.3. Domain Boundary........................................ 13 77 4.4. Topology .............................................. 14 78 4.5. Technology ............................................ 15 79 4.6. Connection to the Internet 80 ............................. 15 81 4.7. Security, Trust and Privacy Model ...................... 16 82 4.8. Operations ............................................ 16 83 5. Trust networking domain as an application of autonomic networking 85 .............................................................. 17 86 5.1. Definition of a Trust networking domain ................ 18 87 5.2. Configuration of Trust networking domain ............... 19 88 5.3. Communication between Trusted Autonomic Nodes within a trust 89 networking domain .......................................... 20 90 5.4. Communication between trusted autonomic nodes and external 91 nodes ...................................................... 20 92 6. Trust Networking in the Autonomic Networking Infrastructure 93 .. 21 94 6.1. Identification of Trust networking domain and Trusted 95 Autonomic Node ............................................. 22 96 6.2. Discovery of Trust networking domain ................... 23 97 6.3. Signaling Between Trusted Autonomic Nodes .............. 23 98 6.4. Trust Evaluation 99 ....................................... 24 100 7. Procedures for trust networking 101 ............................. 25 102 7.1. Building a trust networking domain ..................... 25 103 7.1.1. Domain initialization 104 ............................. 25 105 7.1.2. Node registration 106 ................................. 26 107 7.2. Evicting existing node from trust networking domain 108 7.3. Terminating trust networking domain .................... 28 109 7.4. Communication among trust networking domains ........... 28 110 7.4.1. Trustworthy networking within a single trust networking 111 domain .................................................. 28 112 7.4.2. Trustworthy networking between trust networking domains 114 ........................................................ 28 115 8. Security Considerations 116 ..................................... 30 117 9. IANA Considerations ........................................ 31 118 10. Acknowledgements .......................................... 31 119 11. Contributors .............................................. 31 120 12. References ................................................ 31 121 12.1. Normative References 122 .................................. 31 123 12.2. Informative References 124 ................................ 31 126 1. Introduction 128 The document describes the concept of trust networking as an 129 application of Autonomic Networking Architecture. It defines a trust 130 networking domain in compliance with reference model of autonomic 131 networking. By definition of autonomic domain [rfc7575 Autonomic 132 Networking Definitions and Design Goals] the trust networking domain 133 is defined as a collection of autonomic nodes which trust other 134 nodes in the same trust networking domain. That means, 135 communications within the trust networking domain with sufficient 136 trust level can be done without any further security concerns. For 137 example, assume that a subnet properly protected from external 138 threats and all nodes in the subnet are verified through trust 139 evaluation procedures, then the communications within the subnet can 140 be done with confidence that nodes do no harm to each other. 142 This document first defines a trust networking domain and then 143 describes how to configure the trust networking domain and keep the 144 domain trustworthy. This document also describes a trust networking 145 framework that consists of interconnected trust networking domains. 146 The framework guides how to define the trust networking domain, how 147 to manage members of the domain, how to protect the domain from 148 hostile external world, how to expand the domain, and how to handle 149 communications with external entities. Finally this documents shows 150 how to apply the trust networking framework to the existing IP based 151 network with minor modifications 153 2. Background 155 One of the biggest problems in the current Internet is protecting 156 information assets against divergent attacks. In the beginning of 157 the Internet, security was not considered to be an essential 158 component of the network architecture but optional solutions such as 159 IPSec were used instead. This section compares the security model of 160 the traditional Internet and our proposed trust model. 162 2.1. Security Model and its Limitations 164 The security model of the current Internet is based on the 165 assumption that all traffic coming from the Internet is suspicious. 166 The lack of inherent security in IP protocol has led various attacks, 167 such as attack on confidentiality by intercepting packets, integrity 168 attack by modifying of the contents of packets, authentication 169 attack by identity fabrication, and availability attack by 170 interfering normal communications. In the context of untrusty 171 Internet, each host should protect itself from potential risks of 172 the hostile Internet. This protection usually take place at the 173 final destination as seen in Figure 1. This model operates basically 174 in reactive manner. That means, after receiving all arriving packets, 175 threatening packets can be detected and removed. Detection of 176 threatening packets are based on pre-defined rules extracted from 177 previous attacks. 179 +-------------------------------------------+ 180 | +------------+ +------------+ | 181 | :Interception: :Modification: | 182 | +------------+ +------------+ | 183 | : : | 184 | : +------------+ : +-----------+ | 185 | : :Interruption: : :Fabrication: | 186 | : +------------+ : +-----------+ | 187 | : : : : | 188 | : : : : | 189 +------+ | <*| <*| <*| +------+ | 190 | +-----------------------------------+ | | 191 | +- X | | 192 | : +-----------------------------------+ | | 193 +---:--+ | +------+ | 194 : | | 195 : +-------------------------------------------+ 196 : 197 +----------+ 198 :Protection: 199 +----------+ 200 Figure 1. Security Model 202 The reactive operations of security model result in endless 203 malicious cycle of attacks and defenses. Rules has to be upgraded 204 for every newly discovered attacks and more complicate rules are 205 required as more sophisticate attacks emerge. This model is fatal in 206 the case of devices with limited or no processing power. Also 207 stronger security makes the system weaker in defending DoS (Denial 208 of Service) attacks. 210 2.2. Trust Model and Trust Relations 212 In contrast to the security model based on doubt, the trust model 213 is based on the confidence that any entity in the domain is not 214 harmful to other entities and the communication environment within 215 the domain is safe enough. Instead of unlimited connectivity, the 216 trust model restrict connectivity to the limited group of trusted 217 entities. Of course, the limited connectivity can be extended by the 218 domain expansion principle described in Section 3.3. Figure 2 219 illustrates the trust model, which needs 3 requirements: 220 Identification, Trust Relation, and Safe Environment. 221 For identification purpose, the trust model uses self-certifying ID 222 (SCID), which provides secure binding between ID and key of an 223 entity. Many future Internet researches already use SCID for 224 accountability or trusted path selection. The trust model assume 225 that every entity has a public key and hash of the public key is 226 defined as the ID of the entity. This ID can be used in validity 227 check of claimed key against actual public key of the entity. The 228 valid public key is basis of further identity verification. After 229 identification the entity check trust relation with the peer entity 230 so that only trusted entity is allowed to communicate. 232 +----------------------------------------------------+ 233 | | 234 | | 235 | +----------------+ +----------------+ | 236 | : Identification : : Identification : | 237 | +----------------+ +----------------+ | 238 | : : | 239 | : : | 240 | +------+ |*> |*> <*| +------+ | 241 | | +--------------------------+ | | 242 | | | | 243 | | Node +--------------------------+ Node | | 244 | | | | | | 245 | | <--------------------------> | | 246 | +------+ Trust Relation +------+ | 247 | | 248 | | 249 | | 250 +----------------------------------------------------+ 252 Figure 2. Trust Model 254 The trust relation used in the trust model is assumed to be 255 reflexive, symmetric, and transitive. Reflexive means that entity A 256 trust itself, denoting as AA. Symmetric relation assumes that two 257 entities A and B satisfy AB and BA at the same time, denoting as 258 AB. Transitive means that for three entities A, B, and C, if AB 259 and BC then A C. If all entities in a given group satisfy all 260 three characteristics, the group is declared as a trust equivalent 261 class. We can easily guess the role of the trust model as formation 262 of a trust equivalent class for the set of entities trusting each 263 other. 264 The trust model should provide safe and reliable communication 265 environment to entities without requiring additional security 266 features on the entities. Thanks to the transitive trust relation, 267 if an external entity is trusted by one member of the domain as a 268 trust equivalence class, other members in that domain also can trust 269 the external entity. By restricting the domain to trusted entities, 270 the environment can be kept safe and reliable. 272 2.3. Comparisons of Security and Trust Model 274 The trust model is opposite in almost every aspect as shown in 275 Table 1. First of all, the trust model is based on confidence that 276 entities in a trust networking domain never do harm, while the 277 security model is based on suspicion that adversaries attacks 278 anytime. The relationship in trust model is binary in the sense that 279 an entity trust another specific entity, but relationship in the 280 security model is unary because the entity itself must protect 281 regardless of other entities. With respect of rules, trust model 282 keeps trusted IDs as a white list but security model keeps 283 threatening entities as a black list. Thus, behavior of entities in 284 the trust model is proactive while the security model acts in 285 reactive manner. That leads the policy of the trust model is to 286 prevent risk by communicating only with trusted entities, but policy 287 of the security model monitors all communications to detect and 288 remove threatening actions. The trust model provides mechanisms for 289 accepting entities or domains after verifying their trust, while the 290 security model provides mechanisms for watching the traffic and 291 blocking the threatening traffics. As the result, the network space 292 of the trust model starts with a restricted space and incrementally 293 glows as new entities or domains are accepted, while the network 294 space of security model starts as an unrestricted and open space, 295 but the space may be diminished by excluding misbehaving entities. 297 Table 1 Comparison of Trust and Security Model 299 +--------------+---------------+ 300 | Trust Model | Security Model| 301 +-------------------------------------------+ 302 | based on | confidence | suspicion | 303 +-------------------------------------------+ 304 |relationship| binary | unary | 305 +-------------------------------------------+ 306 | rules | white list | black list | 307 +-------------------------------------------+ 308 | behavior | proactive | reactive | 309 +-------------------------------------------+ 310 | policy | prevention | detect and | 311 | | | remove | 312 +-------------------------------------------+ 313 | mechanism | verify and | watch and | 314 | | accept | block | 315 +-------------------------------------------+ 316 | network | unrestricted | rectricted | 317 | space | and | and | 318 | | diminishing | expanding | 319 +------------+--------------+---------------+ 321 3. Trust Networking Framework 323 The purpose of the trustworthy communication framework is to provide 324 safe and reliable environment to entities without requiring 325 additional security features. For keeping the environment 326 trustworthy, the domain accepts only eligible entities. However, 327 this restriction seems contradict to global scalability that 328 requires the domain being open to everyone. Our solution is the 329 incremental strategy, where a domain starts from a small and 330 restricted network space and gradually expands to a global scale 331 network space by accepting external entities or collaborating with 332 other domains. This section discusses technical issues on the 333 trustworthy communication framework. 335 3.1. Defining Trust Networking Domain 337 A primitive domain can be defined as the network space that is 338 autonomous, isolated, and well protected from external attacks. For 339 example, isolated home or enterprise network can be defined as a 340 domain. If all hosts in the domain are disinfected and communication 341 links are not exposed, the domain can be declared as a trust 342 networking domain. The trust networking domain is not always a 343 physical network space but sometime it can be formed by a logical 344 group of users with mutual trust. In any case, the entities in the 345 domain forms a trust equivalence class and communication with other 346 entities in the domain is allowed without any protection. 347 To keep to domain trustworthy only qualified entities can be 348 accepted as a member of the domain, and misbehaving entities have to 349 be removed from the domain. For maintenance of a domain, the 350 behavior of entities in the domain may be monitored, and if 351 suspicious activities are discovered, the corresponding entity must 352 be removed. 354 3.2. Protecting Trust Networking Domain 356 The domain representing an autonomous network space can take role 357 of security unit as well as packet processing unit. The isolated 358 domain from external world does not allow communication with 359 external entities. For opening the domain to untrusty external world, 360 well-defined interfaces are required to protect the domain. Let's 361 call this protected domain an "insulated trust networking domain". 362 As an example of insulated trust networking domain, we can imagine 363 the local area network with firewalls on all links to the external 364 Internet. The local area network is not isolated but is insulated 365 from attacks injected through the external links. 366 The proposed framework assumes that each domain has at least one 367 gateway that performs security functions for the domain. The gateway 368 identifies external entities, evaluate trust level, accepts or 369 rejects the packets according to the trust levels of external 370 entities. And also the gateway will forward only authorized and 371 sterilized packets to peer domain for keeping its reputation or 372 trust level. In the sense that gateways performs security functions 373 on the behalf of the entities inside of the domain, the security of 374 entities is said to be delegated to gateways. This delegated 375 security has great benefit in applying complex security functions to 376 devices with a limited or no processing power. 378 3.3. Expanding Trust Networking Domain 380 If all communications are limited within a trust networking domain, 381 the serious scalability arises with respect to global communication. 382 Now, we have to consider expansion of trust networking domain, 383 starting from a small trust networking domain to a global scale 384 network. First, consider the situation that an entity outside of 385 domain tries to communicate with an entity inside of the domain. For 386 trustworthy communication across border of domain, the entity must 387 be a member of the domain. The domain gateway performs well-defined 388 procedure for checking identity and evaluating the trust level of 389 the external entity, and then only qualified entities are allowed to 390 communicate with entities in the domain. Also the link connecting 391 the domain with external entities should be secure enough for the 392 trust level. This is one way to expand a domain. 394 +-----------------------+ +-------------------------+ 395 | +------+ +------+ | | +------+ +------+ | 396 | | | | | | | | | | | | 397 | | Node <-----> Node | <-------> | Node <----->| Node | | 398 | | | | | | | | | | | | 399 | +------+ +------+ | | +------+ +------+ | 400 | +-------+ | 401 | | 402 | +--+ +--+ | 403 | | | | | | 404 | Trust Domain | | | | Trust Domain | 405 | A | | | | B | 406 | | | | | | 407 +----------+------------+ | | +-------------------------+ 408 ^ | | +------+ 409 | | | | | 410 +-------+--------+ | +-------+ Node | 411 | | +---------+ | 412 +--+---+ +--+---+ +------+ 413 | | | | 414 | Node | | Node | <------+ : Trust Verification 415 | | | | 416 +------+ +------+ <------> : Trust relation 418 +------+ : Reliable 419 +------+ channel 421 Figure 3. Expansion of Trust Model 423 Expanding a domain by accepting new entities has limitation when 424 reaching the maximum number of entities being managed by a single 425 domain. The other solution is collaboration of domains. Suppose two 426 domains trust each other and those are connected by reliable links, 427 then entities within one domain can trust entities within another 428 domain. 429 Figure 3 shows a trust networking domain with trusted entities and 430 3 ways how to expand the domain. First, new entities can join to the 431 domain after passing trust verification. Second, a remote entity can 432 join to the domain via reliable channel. And third, when two domains 433 may have trust agreement and connected by reliable channel, all 434 entities in one domain can exchange packets in the pre-agreed trust 435 level. 437 3.4. Communicating with External Entities 439 As already seen, the communication inside of a domain requires no 440 further security. However, communication with entities outside of 441 the domain needs special care. Assume that all communication with 442 external entities must take place at the special entity called a 443 gateway, which enforce well-defined procedure communication for 444 external entities. As explained in Section 3.3.2, an insulated trust 445 networking domain has one or more gateways to perform trust 446 verification for every packet injected to the domain. 447 When a packet arrives at the gateway of a domain, the gateway first 448 check whether the source ID of the packet is in the trusted ID list. 449 If exists, the packet is accepted. Otherwise, the gateway lookups 450 the trusted domain list to find sending domain of the packet. If the 451 sending domain is in the list, the packet can also be accepted and 452 ID of the packet is saved in the trust ID list. This mean that the 453 gateway believes the trusted sending domain not to send harmful 454 packets. If ID of the packet is not in the trusted ID list nor the 455 sending domain is in the trust networking domain list, then 456 verification procedure for individual ID has to be performed. The 457 procedure is somewhat similar to accepting new entities in the 458 domain. The overall procedure of a gateway is shown in Figure 4. 460 4. Differences between trust networking and ANIMA security framework 462 This section describes major differences between the proposed trust 463 autonomic domain (TAD) and ANIMA security framework. The 464 differences are explained based on a following set of criteria 465 defined in the draft-carpenter-limited-domains-03: domain as a whole, 466 domain members, domain boundary, topology, technology, connection to 467 the Internet, security/trust/privacy model, and operation since our 468 proposed domain and that of ANIMA are kinds of limited domains. 470 4.1. Domain as a Whole 472 Networking is a very complex task and traditional way of handling 473 the complexity is layering, where each layer takes a specific role 474 and provides its services to the next higher later. This layering 475 architecture decomposes the whole networking task functions 476 vertically. However, the network in general spans physical or 477 logical regions. Each region may have distinct features, such as 478 different physical media, separate administration, and diverse 479 networking requirement. The concept of domain in this document is 480 defined as the networking region that shares common characteristics 481 and also is distinguished from the rest of the network. Traditional 482 layers cover its own regions implicitly; the physical layer spans 483 the range covering electric signals. The data link covers the range 484 connected by layer 2 bridges, and the network layer covers the whole 485 devices connected by routers, and so on. Instead of implicit regions 486 of the layers, a domain can be defined as any region of the network 487 which is distinguishable from the rest of the network. It can be 488 defined as a region covered by electric signal, a home network owned 489 by a single user, a virtual private network overlaid on the Internet, 490 a social network composed of members. Thus, it can be defined by any 491 layer. 493 In the context of TAD, the domain can be defined by trust. That 494 means all members within a TAD trust each other so that the members 495 can communicate with others without any concern of security. For 496 this, TAD needs to add an additional ASA which performs a role of 497 domain administrator. Its main functionality is to manage trust 498 policies including allocating trust level to domains and their 499 members. Domain administrator can extend the functionality of ANIMA 500 MASA or define a new ASA for the purpose of the domain 501 administration. The details of domain administrator is specified in 502 Section 5 below. 504 4.2. Individual Nodes (Domain members) 506 As defined in the previous section, the domain covers a specific 507 region of the network, to where a set of nodes belongs. Since a 508 domain shares common characteristics, any node within the domain 509 must be able to communicate with other nodes in the domain. The node 510 as a member of a domain can be host, networking devices, 511 applications depending on the characteristics of the domain. For 512 keeping the same characteristics, a node trying to be a new member 513 of the domain must prove its functionalities to all or a designated 514 member of the domain. Joining to a domain may be accomplished by 515 simply plugging interfaces to the networking device or well-defined 516 interactions enforced by domain administrator. The joining procedure 517 may be implicit when a domain has fixed and permanent members, or 518 explicit in case that a node can join or leave the domain. 520 In the sense of TAD, a node is assumed as a host that has 521 communication functions required by the domain. Since a TAD is 522 defined under the intent of trust, a node should have identifiable 523 and authenticatable ID. TAD utilizes a concept of self-certifying ID. 524 The self-certifying ID can be newly defined. However, in the 525 context of TDA as an application use case of ANIMA, we can utilize 526 IdevID as a self-certifiable ID and preferably extend IdevID with 527 public key information as an option to ensure the global uniqueness. 529 4.3. Domain Boundary 531 Since a domain is a set of nodes that shares common characteristics, 532 only nodes within a domain can communicate. In other words, a node 533 within a domain cannot communicate with nodes outside of the domain. 534 However, we can assume special nodes that belongs multiple domains 535 simultaneously. Let's call a node joining more than two domains a 536 "gateway". A gateway node must be equipped with multiple 537 functionalities, each for the joined domain. The role of gateway is 538 conveying interactions of one domain to other domains. Of course, 539 conveying interaction may include necessary functions such as 540 interpretation, filtering, transformation etc. From outside of a 541 domain, the internals of the domain is hidden and the boundary of 542 the domain composed of gateways are only exposed. All interactions 543 passing the boundary of a domain must performed by at least one of 544 the gateways whose role is to enforce necessary gatewaying 545 procedures. 547 In the context of TAD, all members of a TAD trust each other, but 548 cannot trust nodes outside of the domain. The only way for an 549 internal node to communicate with external nodes is passing through 550 a gateway of the domain. Once the gateway receives communication 551 request from a node outside of the domain, it authenticates the node 552 and evaluates the trustworthiness of the node. If the external node 553 is trustworthy and communication channel between gateway and the 554 node is safe and reliable enough for the domain trust level, the 555 gateway accepts communication and injects the communication possibly 556 with transformation. Unlike ANIMA which assumes IP based 557 communications by every domains, TAD may allow any networking 558 technology besides IP. Therefore, a gateway is a mandatory 559 component where the need for it is implicit in ANIMA due to the 560 homogenous nature networking technology used in a domain. The 561 details of domain gateway functionality is specified in Section 5 562 below. 564 4.4. Topology 566 As defined in Section 4.1, a domain is a range of network where all 567 members can communicate. The communication can be done in either 568 specific layer protocols or any common functionalities. For example, 569 if domain is defined by local area network, the domain may use local 570 IP addresses, link-local or site-local. For domains defined by 571 virtual network overlaid on global Internet may use global IP 572 addresses with filtering functions. 574 As already explained in section 4.3, some special nodes may belong 575 to multiple domains. In this case the range of the domains that 576 involve the same nodes can be viewed as overlapped domains. The node 577 belonging multiple domains should have multiple functionalities, one 578 of each domain. Those functionalities should be separated. We can 579 find similar situation in multi-homed IP host in the Internet, where 580 the host has separate IP addresses, one for each IP address domain. 582 In the context of TAD, domains also have self-certifying ID as an 583 ordinary node to become a member of another domain. The domain 584 administrator must take a role of the required procedures of the 585 parent domain such as trust evaluation, join and leave. Also the 586 gateways must take necessary translation of the interactions when 587 passing the domain boundary. 589 4.5. Technology 591 In the context of TAD, any technology is allowed for the domain 592 since a domain has its own mechanisms hidden from outside. Apart 593 from the existing Internet using global IP addresses, each domain 594 may use its own routing or forwarding mechanisms, such as Ethernet, 595 MPLS, or Upper-Layer IDs. Only requirement for inter-domain 596 communication is that the gateway must aware of mechanisms for both 597 domain and takes a role of translation. Note that each domain has a 598 domain specific addressing scheme and identification of 599 nodes/domains must be done by globally unique identifier. With 600 global ID a node can join a domain or move from one domain to 601 another. In this case a node acquires a domain specific address when 602 joining the domain. 604 4.6. Connection to the Internet 606 In the context of TAD, the existing Internet can be viewed as a huge 607 domain with global coverage. Nodes or domains with IP capability can 608 join the global Internet domain as members. Since the existing 609 Internet has no notion of ID, let us assume the global Internet 610 domain top-level domain where every domain can join. Each domain 611 with its specific mechanism can join the global Internet domain 612 permanently or intermittently. The communication from one domain to 613 another domain through the global Internet domain is done by the 614 normal IP communication. However, the gateway of each domain must 615 translate its internal communication mechanism to that of the 616 corresponding IP address communications. More specifically, Inter- 617 domain communication is done by global ID and the ID is translated 618 into domain-specific address when passing the domain boundary. This 619 ID based communication may be encapsulated in IP packet when 620 traversing the global Internet domain. To allow this translation, 621 the ID to IP address mapping system must be provided, where IP 622 address is the gateway address of the domain that involves the node 623 with the ID. 625 4.7. Security, Trust and Privacy Model 627 One of implication of a domain is secure protection of the domain 628 internals from the rest of the network. That is members of a domain 629 should be identified, authenticated, and authorized. According to 630 domain's policies, well-defined procedures must be enforced to a 631 node to become a member of the domain. 633 In TAD all members of the domain must have the same or higher trust 634 level than the domain requires. That means, whenever a new node 635 tries to be a member of the domain or an external node tries to 636 communicate with an internal node, the domain administrator must 637 authenticate and evaluate the node. Only the node passing the 638 evaluation procedure is allowed to communicate. In this case 639 communication must be done via channels safe and reliable enough for 640 the trust level. In some cases where the channel is not safe nor 641 reliable, the communicating nodes must authenticate or encrypt the 642 traffic. Note that whether the traffic is protected or not depends 643 on the risk level of the channel and trust level of the domain. 644 Unlike the VPN that protects all channels in the same security 645 protocols, channels for a domain are additionally protected only 646 when the risk level of a specific channel is higher than required. 648 4.8. Operations 650 In addition to trust relation between nodes within a domain, the 651 environment of the domain must be considered. Environment of a 652 domain includes factors affecting domain operation such as 653 communication channels among nodes, operation skills of domain 654 administrator, reliability of devices, etc. To be protected from the 655 rest of networks, a domain should be securely protected from 656 external attacks. 658 Since communications within a TAD are carried out on the mutual- 659 trust basis, the domain administrator should keep the domain 660 trustworthy by accepting only trusted members, monitoring traffic to 661 detect suspicious behavior, and periodic auditing the logs of domain 662 members, and so on. 664 5. Trust networking domain as an application of autonomic networking 666 This section defines what a trust networking domain is and describes 667 how to configure the trust networking domain as an application of 668 autonomic networking solutions. The autonomic nodes with trust 669 networking domain will run with autonomic functions at Reference 670 Model for Autonomic Networking. Autonomic networking infrastructure 671 with trust management functions is capable to configure the trust 672 networking domain. A set of autonomic nodes consists of a trust 673 networking domain, which is configured, and managed by management 674 plane. Within a trust networking domain, the full connectivity among 675 autonomic nodes is securely and stably guaranteed. An autonomic node 676 can easily communicate with other nodes at same trust networking 677 domain. The trust level of autonomic nodes is calculated or assigned 678 by trust evaluation function of management plane. 679 On the other hand, it is possible for autonomic nodes to communicate 680 with different trust networking domains or non-autonomic networks 681 via the trust gateway system, in which the traditional security or 682 certificate mechanisms can be running. 684 +----------------+ 685 | Incoming | 686 | Packets (ID) | 687 | | 688 +----------+-----+ 689 | 690 | 691 +----------------------------|---------------------+ 692 | +---------+ +----v--------+ | 693 | | Trusted +-----+ Check ID | Hit | 694 | +-+--> ID +-----+ +------+ | 695 | : : +---------+ +----+--------+ | | 696 | : : | | | 697 | : : | | | 698 | : : | | | 699 | : : +---------+ +-----v--------+ Hit | | 700 | : : | Trusted +----+ Check +------+ | 701 | : : | Domains +----+ Domain | | | 702 | : : +---------+ +-+---+--------+ | | 703 | : : | | | | 704 | : +-------------------+ | | | 705 | : | | | 706 | : +-----v--------+ | | 707 | : | Trust | Pass | | 708 | +-------------------+ Verification +------+ | 709 | +--+-----------+ | | 710 | Fail | | | 711 | X <---------+ | | 712 +--------------------------------------------|-----+ 713 | 714 +------v--------+ 715 | Accepted | 716 | Packets (ID) | 717 | | 718 +---------------+ 720 Figure 4. Packet Processing at the Gateway 721 5.1. Definition of a Trust networking domain 723 A trust networking domain is defined as a collection of autonomic 724 nodes trusting each other. Since all nodes within a trust networking 725 domain maintains certain trust level set by the domain, 726 communications within the domain can be done without any further 727 security concern. However, communications with external node require 728 additional verification phase before the communications actually 729 begin. The verification is performed at the border of the domain, 730 where external nodes are checked if their trust level are 731 sufficiently high for the domain. In the sense that the domain as a 732 collection of node are protected from external world, it seems "zone 733 defense" rather than "individual defense" of the traditional 734 security scheme. 736 Figure 5 shows the high-level architectural view of trust networking 737 domain. Autonomic nodes has the interface with management function. 738 Trust management functions define the trusted autonomic nodes 739 according to their trust level. They also define the trust 740 networking domain by grouping or classifying autonomic nodes. At the 741 same trust networking domain, an autonomic node directly 742 communicates with each other. The control and management functions 743 at the trust networking domain are defined at the interfaces between 744 autonomic nodes and management plane. 745 There are trust gateway for an autonomic node to communicate with 746 different trust networking domains or non-autonomic nodes since 747 there is no direct communication path. Trust gateway is used to 748 communicate autonomic nodes with different trust networking domains 749 or the non-autonomic nodes. An autonomic node can communicate remote 750 autonomic nodes or non-autonomic nodes through trust gateway. In 751 these cases, the traditional trust evaluation and/or certificate 752 procedures can be applied at trust gateway. Trust evaluation 753 procedure is running by management plane of autonomic networking. 755 +-----------------------------------------------+ 756 : : 757 : Trust networking domain : 758 : : +------------ 759 : : : 760 : : : 761 : +---------------------------+ +-------------+: : 762 : : Autonomic Function : :Trust Gateway:: : 763 : : : : : Function :: : 764 : : ASA 1 : ASA 1 : : ASA 2 :: : 765 : : : : : :: : 766 : +---------------------------+ +--------------: : 767 : : : : : :: : 768 : +--------------------------------------------+: : 769 : : :: : 770 : : Autonomic Networking Infrastructure :: : 771 : +--------------------------------------------+: : 772 : : : : : :: : 773 : : +---------+ : +---------+: : +---------+ :: : +---------+ 774 : : : Trusted : : : Trusted :: : : Trusted : :: : : External: 775 : : :Autonomic:---:Autonomic:-...-:Autonomic:---------: Node : 776 : : : Node 1 : : : Node 2 :: : : Node N : :: : : : 777 : : +---------+ : +---------+: : +---------+ :: : +---------+ 778 : : : : : :: : 779 +-----------------------------------------------+ +------------ 781 Figure 5. Trust networking domain at the Autonomic Networking 783 5.2. Configuration of Trust networking domain 785 A trust networking domain is consisted of a group of autonomic nodes. 786 The network management plane communicates with a list of autonomic 787 nodes to build the trust networking domain. The trust management 788 information database which contains a list of autonomic nodes 789 according to the trust level of each domain is built at the 790 bootstrapping time or at the instance of request. 792 At the bootstrapping time, the management plane securely distributes 793 the trust information of each domain to the corresponding autonomic 794 nodes. The membership management is done by management plane when 795 the autonomic nodes can be joined to or leaved from each trust 796 networking domain. 797 At the instance that an autonomic node request to build a trust 798 networking domain to the management plane, trust management function 799 confirm to build a trust networking domain after completing the 800 proper trust evaluation procedures. 801 If an autonomic node could not continue to be a member of the 802 certain trust networking domain, it notify to management plane for 803 leave. Similarly, if the trust management functions decide that an 804 autonomic node is not relevant to stay in a certain trust networking 805 domain, they notify the corresponding autonomic node for leave and 806 update the trust management information database. 808 Within a trust networking domain, an autonomic node can communicate 809 each other without any additional security and certificate procedure. 810 In a case, an autonomic node may register multiple trust networking 811 domains simultaneously. 813 5.3. Communication between Trusted Autonomic Nodes within a trust 814 networking domain 816 At the same trust networking domain, autonomic nodes directly 817 communicate with each other. Autonomic nodes can discover other 818 nodes at the same trust networking domain. It requires control or 819 management information between autonomic nodes and 820 control/management plane. It can be pre-configured during 821 bootstrapping. The control information between autonomic nodes can 822 be used to identify the trust networking domain. The autonomic nodes 823 can easily communicate with each other at the same trust networking 824 domain by enabling self-managing capability of autonomic networking. 825 The autonomic service agents can be implemented for trusted 826 communication. 828 5.4. Communication between trusted autonomic nodes and external nodes 829 Autonomic nodes must communicate with autonomic nodes of the 830 different trust networking domain. They also communicate with the 831 non-autonomic nodes. 832 Trust gateway can help that an autonomic node communicate with the 833 autonomic nodes with different trust networking domain or the non- 834 autonomic nodes. Some autonomic service agents (ASA) may include the 835 trust gateway functions for communicating autonomic nodes with 836 different trust networking domain, which is in the reference model 837 for Autonomic Networking [I-D.ietf-anima-reference-model]. 839 6. Trust Networking in the Autonomic Networking Infrastructure 841 This section describes trust networking of autonomic network. Within 842 a trust networking domain, an autonomic node is credited by their 843 trust level from management plane. 844 The trust management plane maintains the trust information tables up 845 to date. The trust management plane is tracking of trust status of 846 each autonomic node as an application of autonomic networking. The 847 trust information table contains the trust information of autonomic 848 nodes based on the trust networking domain. All the interactions 849 between autonomic nodes should be verified according to trust 850 evaluation procedures of management plane. 852 The autonomic nodes within the same trust networking domain create 853 and maintain network connectivity without additional complexity. 854 Trust provisioning among autonomic nodes is to exempt any additional 855 processing (like identification, addressing, routing, forwarding, 856 and security, etc.) to maintain autonomic networking within the same 857 trust networking domain. 859 The interactions between autonomic nodes are based on the trust 860 evaluation of the trust networking domain. The trust information is 861 used to leverage the direct interactions between autonomic nodes. 862 Trust gateway can help to the interaction of autonomic nodes with 863 different trust networking domains or with non-autonomic nodes. 865 The trust management plane is used to handle the trust level of each 866 autonomic node with proper trust evaluation procedure. 868 +---------------------------+ 869 | Trust management plane | 870 | | 871 | - Provisioning of the | 872 | identities of nodes | 873 | | 874 | - Trust evaluation | 875 | | 876 +------+------+------+------+ +--------------------------+ 877 | : : : | | | 878 | : : : | | | 879 | +----+---+ : +----+---+ | | +--------+ | 880 | | | : | | | | | | | 881 | | Node 1 | : | Node 2 | | | | Node 3 | | 882 | | +----+ | | | | | | 883 | | | : | | | | | | | 884 | +--------+ : +----+---+ | | +---+----+ | 885 | : | | | | | 886 | : | | | | | 887 | +-----+------+---+ | | +-----+------------+ | 888 | | Trust Gateway | | | | Trust Gateway | | 889 | | of domain A <---------------> of domain B | | 890 | +----------------+ | | +------------------+ | 891 +---------------------------+ +--------------------------+ 892 Figure 6. Trust provisioning at the Autonomic Networking 894 6.1. Identification of Trust networking domain and Trusted Autonomic 895 Node 897 This section describes trust level. An autonomic node can initiate 898 to create their own trust networking domain. The management plane 899 provides that an autonomic node can build the relevant trust 900 networking domain by identifying the corresponding autonomic nodes. 901 Specific policies can be applied to build trust networking domain. 903 In a trust networking domain, each autonomic node should be 904 identified by the relevant naming and addressing schemes, which are 905 also compliant with the Reference Model for Autonomic Networking [I- 906 D.ietf-anima-reference-model]. Before data exchange, the autonomic 907 nodes obtains the identities (e.g., IP address and port number, 908 etc.) of destination nodes and the corresponding trust networking 909 domain. In a case, the MAC address can be also used for 910 identification. 911 The trust management information database is used for the discovery 912 of autonomic nodes at the same trust networking domain. The 913 autonomic nodes with the same trust networking domain may use the 914 relevant identification schemes. In the trust management information 915 database, a list of autonomic nodes are classified into the relevant 916 identification code which indicates the same trust networking domain. 917 The identification code for a trust networking domain may contain 918 name/nickname and number as well as IP address and port number, etc. 920 6.2. Discovery of Trust networking domain 922 The trust management information database is used for the discovery 923 of autonomic nodes at the same trust networking domain. Before data 924 exchange, an autonomic node looks up the trust management 925 information database to find the destination autonomic nodes. If the 926 destination node belongs to the same trust networking domain with 927 original autonomic node, it is possible to initiate data exchange. 929 6.3. Signaling Between Trusted Autonomic Nodes 931 At the same trust networking domain, an autonomic nodes communicate 932 with each other. For data exchange, the autonomic node should 933 discover each other by accessing the trust management information 934 database of management plane. 935 After discovery of destination autonomic node, the signaling 936 protocol like "A Generic Autonomic Signaling Protocol (GRASP)" [I- 937 D.ietf-anima-grasp] are needed to initiate data exchange. Within the 938 same trust networking domain, an autonomic node directly 939 communicates with each other after completing signaling procedure, 940 in which the connectivity among autonomic nodes are securely and 941 automatically maintained. The pre-configuration between autonomic 942 nodes can be done during bootstrapping. The autonomic control plane 943 at the Reference Model for Autonomic Networking [I-D.ietf-anima- 944 reference-model] can be either implemented to carry signaling 945 protocol. 946 For data exchange with different trust networking domains or non- 947 autonomic nodes, the trust gateway provides proper interworking 948 functions for data exchange and signaling since there is no direct 949 communication paths between them. The trust gateway provides the 950 relevant control and management information to extend data exchange 951 with different trust networking domains or non-autonomic nodes. The 952 authentication and certificate procedures equivalent with the trust 953 networking domain can be applicable to provide external connectivity. 955 6.4. Trust Evaluation 957 Trust evaluation of network is the way of calculating trust for 958 networking services. It requires data collection from various 959 sources. Physical data sources are collected from the capability of 960 data processing, storage, and communication through network. In 961 cyber world, logical data sources are software that work on 962 computing algorithm, storage, and networking. In the social world, 963 human produces various data through user interfaces. 965 In the physical network, trust can be measured by counting on their 966 trustworthiness of network elements. In the cyber world, software 967 can be accidentally or maliciously altered or destroyed during 968 control, computing, and communicating instances. The unexpected 969 behaviors of software is detected or monitored to evaluate and 970 update their trust level. In the social world, human behaviors can 971 be measured by considering its trustworthiness in terms of ability, 972 honesty and benevolence. Social trust reflects individual human 973 activity. Human interacts with others honestly and kindly so that 974 their trust level is affected by some risks. 975 For trust evaluation, the collected data are categorized into two 976 types of attributes and indicators namely, qualitative and 977 quantitative. Trust index is used to calculate the certain trust 978 level of each network entity. As the results of trust evaluation, 979 trustor finally make a decision. The network management plane 980 provides to calculate the trust level of the network elements from 981 various data sources and store their values to trust management 982 information database. 984 The trust management information contains the trust level of 985 autonomic nodes. The interactions inside a trust networking domain 986 are analyzed and accumulated to evaluate the trust level of each 987 node. The trust level of autonomic node is contained at the trust 988 management information database. All the interactions between 989 autonomic nodes in a same trust networking domain is validated by 990 the trust evaluation procedure. 992 The trust evaluation procedure is fed by the following inputs. 994 o Pre-provisioned or manually configured by policy or management 995 information 997 o Analysis from interactions between autonomic nodes 999 o The accumulated history information of trust verifications such 1000 as authentication of non-autonomic nodes and validity of application 1001 specific transactions. 1002 o other unaccepted or unexpected behaviors 1004 While autonomic nodes communicate with each other, they choose the 1005 relevant trust management protocol whether they meet trust 1006 requirements in the same trust networking domain or not. Trust 1007 management protocol between autonomic nodes and trust management 1008 database is needed to check trust evaluation. Trust evaluation 1009 procedure between autonomic nodes at same trust networking domain 1010 are taken for trust identification. 1011 If the prerequisite and pre-configuration procedures are already 1012 taken for trust management, simple and light-weight solution can be 1013 applicable for communication between autonomic nodes. 1015 7. Procedures for trust networking 1017 7.1. Building a trust networking domain 1019 7.1.1. Domain initialization 1021 To build a new trust networking domain, the domain administrator 1022 needs to initiate the functionalities of trust networking domain as 1023 follows: 1025 - Domain administration 1026 To initialize a domain with respect to the trust, the domain 1027 administrator needs to configure policies of trust and membership. 1028 To manage the trust level, the domain administrator sets the 1029 required trust level of membership with domain policy management 1030 (DPM) ASA. The domain administrator can explicitly dedicate a node 1031 for trust management functions and trust provisioning. 1033 - Access & delivery control 1034 The nodes that connected outside of the domain should equip trust 1035 gateway functions. For IP network case, every node of the domain 1036 should assign their gateway to the nodes with trust gateway ASA. 1038 +---------------------------------+ 1039 | | +--------------+ 1040 | +-------------+ Private IP +----+----+ | | 1041 | | Domain | Networking | Domain | | | 1042 | |Administrator+------------+ Gateway +------------+ The Internet | 1043 | +-------------+ +----+----+ Public IP | | 1044 | | Networking | | 1045 | Trust networking domain | +--------------+ 1046 +---------------------------------+ 1047 Figure 7. Initialization of a new trust networking domain 1049 7.1.2. Node registration 1051 After the trust networking domain has been initialized, domain can 1052 adopt network nodes. 1053 +-----------------------------------------+ 1054 | | 1055 | Trust networking Domain | 1056 | | 1057 +----------+ +-----+--------+ +-----------------+ | 1058 | | | | | | | 1059 | Node A +--+----> Domain +------> Domain | | 1060 | | | | Gateway | | Administrator | | 1061 +----------+ | | | | | | 1062 | +-----+--------+ +-----------------+ | 1063 Registration | | 1064 Message | | 1065 +-----------------------------------------+ 1067 Figure 8. Registration of a new node 1069 The procedures of node registration are as follows: 1071 +-----------+ +-------------+ +----------------+ 1072 | | (1) | | | | 1073 | +----------> Domain | | | 1074 | | (2) | Gateway | | Trust Info. <---+ 1075 | <----------+ | | Management | | 1076 | | (3) +-------------+ | ASA | | 1077 | <-----------------------------+ | | 1078 | | +----------------+(5)| 1079 | | +----------------+ | 1080 | | (4) | | | 1081 | Node A +-----------------------------+ Domain Member <---+ 1082 | | | Management <---+ 1083 | | | ASA | | 1084 | | +----------------+ | 1085 | | +----------------+(7)| 1086 | | | | | 1087 | | (6) | ID-Location | | 1088 | <-----------------------------+ Management <---+ 1089 | | | ASA | 1090 +-----------+ +----------------+ 1091 Figure 9. Procedures of node registration 1093 (1) Node A connects to the network of trust networking domain; 1094 (2) The domain assigns a private IP address to Node A. The domain 1095 gateway is assigned as the default gateway for IP network; 1096 (3) Trust information management ASA analyses the trust information 1097 of node A; 1098 (4) Node A request to join the domain; 1099 (5) Domain membership management ASA of the domain administrator 1100 receives the requests and decides to approve Node A, based on 1101 the domain policy and trust level of Node A; 1102 (6) ID-Location management ASA of the domain administrator issues a 1103 new identifier of Node A; 1104 (7) ID-Location management ASA archives Node A's identifier and 1105 private IP address. 1107 7.2. Evicting existing node from trust networking domain 1109 (Editors' note) This section describes how to evict existing node in 1110 trust networking domain including trust management procedures. 1111 Further details are for further study. 1113 7.3. Terminating trust networking domain 1115 (Editors' note) This section describes how to terminate trust 1116 networking domain including signalling procedures with child nodes 1117 (or domains) and parent domains. Further details are for further 1118 study. 1120 7.4. Communication among trust networking domains 1122 This section describes trustworthy communication between nodes 1123 within a single trust networking domain and between nodes separated 1124 into multiple trust networking domains. 1126 7.4.1. Trustworthy networking within a single trust networking domain 1128 In order for the two hosts to send and receive messages to each 1129 other, a networking path must first be established. If two hosts are 1130 located in the same domain, they already have trust relationship 1131 with each other which means no additional security procedures are 1132 needed. 1134 7.4.2. Trustworthy networking between trust networking domains 1136 Two hosts are in different domains. It means that they do not know 1137 each other's IP address directly. The domain administrator provides 1138 IP address of each hosts for trustworthy networking between two 1139 hosts in different domains. If a Host 2 wants to perform trustworthy 1140 networking with a Host 1 in other domain, it is possible to 1141 establish a networking path between two nodes through interactions 1142 between domain administration functions and access and delivery 1143 control functions. Figure 10 shows an overview of trustworthy 1144 networking between trust networking domains. 1146 +------------------------+ +-------------------------+ 1147 | Trust networking | | Trust networking | 1148 | domain 1 | | domain 2 | 1149 | | | | 1150 | +--------+ +-------+ Communication +-------+ +--------+ | 1151 | | | | Domain| Path | Domain| | | | 1152 | | Host 1 +-----+ Gate- <---------------> Gate- +------+ Host 2 | | 1153 | | | | way 1 | | way 2 | | | | 1154 | +--------+ +---+---+ +---+---+ +--------+ | 1155 | | | | | | 1156 | +-------+ | | +--------+ | 1157 | | | | | | 1158 | +------+------+ | | +-----+-------+ | 1159 | | Domain | | ID/IP exchange| | Domain | | 1160 | |Administrator<--------------------------->Administrator| | 1161 | | 1 | | | | 2 | | 1162 | +-------------+ | | +-------------+ | 1163 +------------------------+ +-------------------------+ 1165 Figure 10. Trustworthy networking between trust networking domains 1167 Figure 11 shows detailed procedures for trustworthy networking 1168 between trust networking domains are follows: 1169 +------+ (1) +--------+ +--------+ +------+ 1170 | +------> Domain | (2) | Domain | | | 1171 | | (3) | Admin. +--------+ Admin. | | | 1172 | <------+ ASA 2 | | ASA 1 | | | 1173 | | +--------+ +--------+ | | 1174 | | (4) +--------+ (5) +--------+ | | 1175 | +------+ Trust +--------> Trust | | | 1176 | | (6) | Info. | | Info. | | | 1177 | Host <------+ ASA 2 +--------+ ASA 1 | | Host | 1178 | 2 | +--------+ +--------+ | 1 | 1179 | | | | 1180 | | +--------+ +--------+ | | 1181 | | | | (7) | | | | 1182 | | (9) | Domain <--------> Domain | (9) | | 1183 | +------> gate- | (8) | gate- +------> | 1184 | | | way 2 <--------> way 1 | | | 1185 | | | +--------> | | | 1186 +------+ +--------+ (9) +--------+ +------+ 1187 Figure 11. Procedures of trustworthy networking between trust 1188 networking domains 1190 (1) Host 2 requests IP address of Host 1 to the domain administration 1191 ASA 2 through the ID of the host 1; 1192 (2) The domain administration ASA 2 requests IP address of the Host 1 1193 to the domain administration ASA 1; 1194 (3) The domain administration ASA 1 obtains IP address of the Host 1 1195 and reply ID and IP address of the Host 1 to domain administration 1196 ASA 2, and it replies to Host 2; 1197 (4) Host 2 requests a trust level of Host 1 through the domain 1198 administration ASA 2; 1199 (5) The domain administration ASA 2 checks a trust level of Host 2 1200 through the trust information management ASA and requests a trust 1201 level of Host 1 to domain administration ASA 1; 1202 (6) The domain administration function 1 obtains the trust level of 1203 Host 1 through the trust information management ASA and replies it to 1204 the domain administration ASA 2, and the result replies to Host 2; 1205 (7) The access and delivery control ASA 2 forms a routing path with 1206 the access and delivery control function 1 through the ID-based 1207 routing ASA; 1208 (8) The Host 2 and the Host 1 establish a reliable link through the 1209 domain gateway ASA of each trust networking domain; 1210 (9) Networking path established between Host 1 and Host 2. 1212 8. Security Considerations 1214 Data exchange between autonomic nodes at the trust networking domain 1215 must be secured. The signaling or management protocols for trust 1216 identification and discovery of trust networking domain are secure. 1217 The control/management plane for trust management is self-protecting. 1218 The autonomic node in a trust networking domain should be certified by 1219 its identity. The pre-configuration information of autonomic nodes 1220 from trust management information database should be certified during 1221 bootstrapping time. 1222 For data exchange with different trust networking domain or non- 1223 autonomic network, the trust gateway should be securely implemented. 1224 Trust gateway maintains the same trust level for cross-domain 1225 applications or interaction with non-autonomic network. 1227 9. IANA Considerations 1229 This document requests no action by IANA. 1231 10. Acknowledgements 1233 11. Contributors 1235 12. References 1237 12.1. Normative References 1239 [I-D.ietf-anima-autonomic-control-plane] 1241 Eckert,T., Behringer, M., and S. Bjarnason, "An Autonomic 1242 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1243 plane-13 (work in prgress), December 2017. 1244 [I-D.ietf-anima-grasp] 1246 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1247 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1248 grasp-15 (work in progress), April 2018. 1249 [ITU-T Y.3052] Overview of trust provisioning in information and 1250 communication technology infrastructures and service, 1251 March 2017 1253 [ITU-T Y.3053] Framework of trustworthy networking with trust- 1254 centric network domains, January 2018 1256 12.2. Informative References 1258 [I-D.ietf-anima-reference-model] 1259 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 1260 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 1261 Reference Model for Autonomic Networking", draft-ietf- 1262 anima-reference-model-08 (work in progress), February 1263 2018. 1265 Authors' Addresses 1267 Tae Sang Choi 1268 Electronics and Telecommunication Research Institute (ETRI) 1269 218 Gajeong-ro, Gajeong-dong, Yuseong-gu, Daejeon 1270 Korea 1272 Email: choits@etri.re.kr 1274 Jun Kyun Choi (editor) 1275 Korea Advanced Institute of Science and Technology (KAIST) 1276 193 Munji Ro, Yuseong-gu, Daejeon 1277 Korea 1279 Email: jkchoi59@kaist.ac.kr 1281 Tae Su Jeong 1282 Electronics and Telecommunication Research Institute (ETRI) 1283 218 Gajeong-ro, Gajeong-dong, Yuseong-gu, Daejeon 1284 Korea 1286 Email: tsjeong@etri.re.kr 1288 Nam Seok Ko 1289 Electronics and Telecommunication Research Institute (ETRI) 1290 218 Gajeong-ro, Gajeong-dong, Yuseong-gu, Daejeon 1291 Korea 1293 Email: nsko@etri.re.kr 1295 Jae Seob Han 1296 Korea Advanced Institute of Science and Technology (KAIST) 1297 193 Munji Ro, Yuseong-gu, Daejeon 1298 Korea 1300 Email: j89449@kaist.ac.kr