idnits 2.17.1 draft-ietf-i2rs-security-environment-reqs-06.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SEC-ENV-REQ 4: The I2RS plane should be informed when a routing system resource is modified by a user outside the I2RS plane access. Notifications from the control plane SHOULD not be allowed to flood the I2RS plane, and rate limiting (or summarization) is expected to be applied. These routing system notifications MAY translated to the appropriate I2RS agent notifications, and passed to various I2RS clients via notification relays. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SEC-ENV-REQ 33: I2RS agent SHOULD not make a response redirection unless the redirection is previously validated and agreed by the destination. -- The document date (September 27, 2017) is 2393 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-netconf-rfc6536bis' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-revised-datastores' is defined on line 1221, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-netconf-rfc6536bis-05 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS WG D. Migault 3 Internet-Draft J. Halpern 4 Intended status: Informational Ericsson 5 Expires: March 31, 2018 S. Hares 6 Huawei 7 September 27, 2017 9 I2RS Environment Security Requirements 10 draft-ietf-i2rs-security-environment-reqs-06 12 Abstract 14 This document provides environment security requirements for the I2RS 15 architecture. Environment security requirements are independent of 16 the protocol used for I2RS. The security environment requirements 17 are the good security practices to be used during implementation and 18 deployment of the code related to the new interface to routing system 19 (I2RS) so that I2RS implementations can be securely deployed and 20 operated. 22 Environmental security requirements do not specify the I2RS protocol 23 seecurity requirements. This is done in another document (draft- 24 ietf-i2rs-protocol-security-requirements). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 31, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 62 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 63 3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 64 3.1. I2RS Plane and Management plane . . . . . . . . . . . . . 5 65 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 7 66 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 8 67 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 68 4. I2RS Access Control for Routing System Resources . . . . . . 11 69 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 11 70 4.1.1. Access control Enforcement Scope . . . . . . . . . . 14 71 4.1.2. Notification Requirements . . . . . . . . . . . . . . 14 72 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1.4. Sharing access control Information . . . . . . . . . 15 74 4.1.5. Sharing Access Control in Groups of I2RS Clients and 75 Agents . . . . . . . . . . . . . . . . . . . . . . . 17 76 4.1.6. Managing Access Control Policy . . . . . . . . . . . 19 77 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 20 78 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 20 79 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 21 80 4.2.3. Application and Access Control Policies . . . . . . . 22 81 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 23 82 5.1. Robustness Toward Programmability . . . . . . . . . . . . 23 83 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 24 84 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 5.2.2. Application Logic Control . . . . . . . . . . . . . . 26 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 91 9.2. Informative References . . . . . . . . . . . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 94 1. Introduction 96 This document provides environment security requirements for the I2RS 97 architecture. Environment security requirements are independent of 98 the protocol used for I2RS. The I2RS protocol security requirements 99 [RFC8241] define the security for the communication between I2RS 100 client and agent. The security environment requirements are good 101 security practices to be used during implementation and deployment of 102 the I2RS protocol so that I2RS protocol implementations can be 103 securely deployed and operated. These environment security 104 requirements address the security considerations described in the 105 I2RS Architecture [RFC7921] required to provide a stable and secure 106 environment in which the dynamic programmatic interface to the 107 routing system (I2RS) should operates. 109 Even though the I2RS protocol is mostly concerned with the interface 110 between the I2RS client and the I2RS agent, the environmental 111 security requirements must consider the entire I2RS architecture and 112 specify where security functions may be hosted and what criteria 113 should be met in order to address any new attack vectors exposed by 114 deploying this architecture. Environment security for I2RS has to be 115 considered for the complete I2RS architecture and not only on the 116 protocol interface. 118 This document is structured as follows: 120 o Section 2 describes the terminology used in this document, 122 o Section 3 describes how the I2RS plane can be securely isolated 123 from the management plane, control plane, and forwarding plane. 125 The subsequent sections of the document focus on the security within 126 the I2RS plane. 128 o Section 4 analyses how the I2RS access control policies can be 129 deployed throughout the I2RS plane in order to limit access to the 130 routing system resources to authorized components with the 131 authorized privileges. This analysis examines how providing a 132 robust communication system between the components aids the access 133 control. 135 o Section 5 details how I2RS keeps applications isolated from 136 another and without affecting the I2RS components. Applications 137 may be independent, with different scopes, owned by different 138 tenants. In addition, the applications may modify the routing 139 system in an automatic way. 141 Motivations are described before the requirements are given. 143 The reader is expected to be familiar with the I2RS problem statement 144 [RFC7920], I2RS architecture, [RFC7921], traceability requirements 145 [RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state 146 requirements [RFC8242], I2RS protocol security requirements 147 [RFC8241]. 149 2. Terminology and Acronyms 151 - Environment Security Requirements : Security requirements 152 specifying how the environment a protocol operates in needs to 153 be secured. These requirements do not specify the protocol 154 security requirements. 156 - I2RS plane: The environment the I2RS process is running on. It 157 includes the applications, the I2RS client, and the I2RS agent. 159 - I2RS user: The user of the I2RS client software or system. 161 - I2RS access control policies: The policies controlling access of 162 the routing resources by applications. These policies are 163 divided into policies applied by the I2RS client regarding 164 applications and policies applied by the I2RS agent regarding 165 I2RS clients. 167 - I2RS client access control policies: The access control policies 168 processed by the I2RS client. 170 - I2RS agent access control policies: The access control policies 171 processed by the I2RS agent. 173 2.1. Requirements notation 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 3. I2RS Plane Isolation 181 Isolating the I2RS plane from other network planes (the management, 182 forwarding, and control planes) is fundamental to the security of the 183 I2RS environment. Clearly differentiating the I2RS components from 184 the rest of the network device does the following: 186 1. protects the I2RS components from vulnerabilities in other parts 187 of the network, 189 2. protects other systems vital to the health of the network from 190 vulnerabilities in the I2RS plane. 192 Separating the I2RS plane from other network control and forwarding 193 planes is similar to the best common practice of placing software 194 into software containers within modules with clear interfaces to 195 exterior modules. In a similar way, although the I2RS plane cannot 196 be completely isolated from other planes, it can be carefully 197 designed so the interactions between the I2RS plane and other planes 198 can be identified and controlled. The following is a brief 199 description of how the I2RS plane positions itself in regard to the 200 other planes. 202 3.1. I2RS Plane and Management plane 204 The purpose of the I2RS plane is to provide a standard programmatic 205 interface to the routing system resources to network oriented 206 applications. Routing protocols often run in a control plane and 207 provide entries for the forwarding plane as shown in figure 1. The 208 I2RS plane contains the I2RS applications, the I2RS client, the north 209 bound interface between the I2RS client and I2RS applications, the 210 I2RS protocol, the I2RS agent, and the south bound API (SB API) to 211 the routing system. The communication interfaces in the I2RS plane 212 are shown on the the left hand side of figure 1. 214 The management plane contains the mangement application, the 215 management client, the north bound API between the management client 216 and management application, the mangement server, the management 217 protocol (E.g. RESTCONF) between mangement client and management 218 server, and the south bound API between the management server and the 219 control plane. The communication interfaces associated with the 220 management plane are shown on the right hand side of figure 2. 222 The I2RS plane and the management plane both interact with the 223 control plane on which the routing systems operate. [RFC7921] 224 describes several of these interaction points such as the local 225 configuration, the static system state, routing, and signaling. A 226 routing resource may be accessed by I2RS plane, the mangement plane, 227 or routing protocol(s) which creates the potential for overlapping 228 access. The southbound APIs can limit the scope of the management 229 plane's and the I2RS plane's interaction with the routing resources. 231 Security focus: 233 Data can be read by I2RS plane from configuration as copy of 234 configuration data, or by management plane as copies of the I2RS 235 plane. The problem is when the I2RS plane installs the routing plane 236 as its new configuration or the management plane installs the I2RS 237 plane information as management plane configuration. In this 238 circumstance, we define "infecting" as interfering with and leading 239 into a incoherent state. Planned interactions such as interactions 240 denoted in in two cooperating Yang data modules is not an incoherent 241 state. 243 The primary protection in this space is going to need to be 244 validation rules on: 246 o the data being sent/received by the I2RS agent (including 247 notification of changes that the I2RS agent sends the I2RS 248 client), 250 o any data transferred between management datastores (configuration 251 or operational state) and I2RS ephemeral control plane data 252 stores; 254 o data transferred between I2RS Agent and Routing system, 256 o data transferred between a management server and the I2RS routing 257 system, 259 o data transferred between I2RS agent and system (e.g. interfaces 260 ephemeral configuration), 262 o data transferred between management server and the system (e.g. 263 interface configuration). 265 APIs that interact with the 266 I2RS Plane and Management Plane 268 I2RS applications Mangement applications 269 || NB API NB API || 270 || || 271 I2RS plane management plane 272 || control plane configuration|| 273 || datastore datastore || 274 || || 275 ||SB API SB API || 276 --------------------------------------- 277 | Routing System with protocols | 278 | control plane | 279 | (applied datastore) | 280 +-------------------------------------+ 281 | forwarding plane | 282 +-------------------------------------+ 283 | system | 284 +-------------------------------------+ 286 Figure 1 - North Bound (NB) APIs and 287 South Bound (SB) APIs 289 3.2. I2RS Plane and Forwarding Plane 291 Applications hosted by the I2RS client belong to the I2RS plane. It 292 is difficult to constrain these applications to the I2RS plane, or 293 even to limit their scope within the I2RS plane. Applications using 294 I2RS may also interact with components outside the I2RS plane. For 295 example an application may use a management client to configure the 296 network and monitored events via an I2RS agent as figure 4 shows. 298 +--------------------------------------+ 299 | Application | 300 +--------------------------------------+ 301 || NB API NB API || 302 || I2RS client mgt client || 303 || || 304 I2RS protocol mgt protocol 305 (NETCONF/RESTCONF) 307 figure 2 309 Applications may also communicate with multiple I2RS clients in order 310 to have a broader view of the current and potential states of the 311 network and the I2RS plane itself. These varied remote communication 312 relationships between applications using the I2RS protocol to change 313 the forwarding plane make it possible for an individual application 314 to be an effective attack vector against the operation of the 315 network, a router's I2RS plane, the forwarding plane of the routing 316 system, and other planes (management and control planes). 318 Prevention measures: 320 Systems should consider the following prevention errors: 322 application validation - There is little the I2RS plane can do to 323 validate applications with which it interacts. The I2RS client 324 passes the I2RS agent an unique identifier for the application so 325 that an application's actions can be traced back to the 326 application. 328 Validation against common misconfigurations or errors - One way of 329 securing the interfaces between application, the I2RS plane, and 330 the forwarding plane is to limit the information accepted and to 331 limit the rate information is accepted between these three 332 software planes. Another method is to perform rudimentary checks 333 on the results of any updates to the forwarding plane. 335 3.3. I2RS Plane and Control Plane 337 The network control plane consists of the processes and protocols 338 that discover topology, advertise reachability, and determine the 339 shortest path between any location on the network and any 340 destination. I2RS client configures, monitors or receives events via 341 the I2RS agent's interaction with the routing system including the 342 process that handles the control plane signalling protocols (BGP, 343 ISIS, OSPF, etc.), route information databases (RIBs), and interface 344 databases. In some situations, to manage an network outage or to 345 control traffic, the I2RS protocol may modify information in the 346 route database or the configuration of routing process. While this 347 is not a part of normal processing, such action allows the network 348 operator to bypass temporary outages or DoS attacks. 350 This capability to modify the routing process information carries 351 with it the risk that the I2RS agent may alter the normal properties 352 of the routing protocols which provide normal loop free routing in 353 the control plane. For example, information configured by the I2RS 354 agent into routing process or RIBs could cause forwarding problems or 355 routing loops. As a second example, state which is inserted or 356 deleted from routing processes (control traffic, counters, etc.) 357 could cause the routing protocols to fail to converge or loop). 359 Prevention measures: 361 The I2RS implementation can provide internal checks after a routing 362 system protocol change that it is still operating correctly. These 363 checks would be specific to the routing protocol the I2RS Agent would 364 change. For example, if a BGP maximum prefix limit for a BGP peer is 365 lowered then the BGP peer should not allow the number prefixes 366 received from that peer to exceed this number. 368 3.4. Requirements 370 To isolate I2RS transactions from other planes, it is required that: 372 SEC-ENV-REQ 1: Application-to-routing system resources 373 communications should use an isolated communication 374 channel. Various levels of isolation can be 375 considered. The highest level of isolation may be 376 provided by using a physically isolated network. 377 Alternatives may also consider logical isolation 378 (e.g. using vLAN). In a virtual environment that 379 shares a common infrastructure, encryption may also 380 be used as a way to enforce isolation. Encryption 381 can be added by using a secure transport required by 382 the I2RS protocol security [RFC8241], and sending the 383 non-confidential I2RS data (designed for a non-secure 384 transport) over a secure transport. 386 SEC-ENV-REQ 2: The interface used by the routing element to receive 387 I2RS transactions via the I2RS protocol (e.g. the IP 388 address) SHOULD be a dedicated physical or logical 389 interface. As previously mentioned, a dedicated 390 physical interface may contribute to a higher 391 isolation. Isolation may also be achieved by using a 392 dedicated IP address or a dedicated port. 394 SEC-ENV-REQ 3: An I2RS agent SHOULD have specific permissions for 395 interaction with each routing element and access to 396 the routing element should governed by policy 397 specific to the I2RS agent's interfaces (network, 398 routing system, system, or cross-datastore). 400 Explanation: 402 When the I2RS agent performs an action on a routing element, the 403 action is performed in a process (or processes) associated with a 404 routing process. For example, in a typical UNIX system, the user is 405 designated with a user id (uid) and belongs to groups designated by 406 group ids (gid). If such a user id (uid) and group id (gid) is the 407 identifier for the routing processes peforming routing tasks in the 408 control plane, then the I2RS Agent process would communicate with 409 these routing processes. It is important that the I2RS agent has its 410 own unique identifier and the routing processes have their own 411 identifier so that access control can uniquely filter data between 412 I2RS Agent and routing processes. 414 The specific policy that the I2RS agent uses to filter data from the 415 network or from different processes on a system (routing, system or 416 cross-datastore) should be specific to the I2RS agent. For example, 417 the network access filter policy that the I2RS agent uses should be 418 uniquely identifiable from the configuration datastore updated by a 419 management protocol. 421 SEC-ENV-REQ 4: The I2RS plane should be informed when a routing 422 system resource is modified by a user outside the 423 I2RS plane access. Notifications from the control 424 plane SHOULD not be allowed to flood the I2RS plane, 425 and rate limiting (or summarization) is expected to 426 be applied. These routing system notifications MAY 427 translated to the appropriate I2RS agent 428 notifications, and passed to various I2RS clients via 429 notification relays. 431 Explanation: 433 This requirements is also described in section 7.6 of [RFC7921] for 434 the I2RS client, and this section extends it to the entire I2RS plane 435 (I2RS agent, client, and application). 437 A routing system resource may be accessed by management plane or 438 control plane protocols so a change to a routing system resource may 439 remain unnoticed unless and until the routing system resource 440 notifies the I2RS plane by notifying the I2RS agent. Such 441 notification is expected to trigger synchronization of the I2RS 442 resource state between the I2RS agent and I2RS client - signalled by 443 the I2RS agent sending a notification to an I2RS client. 445 The updated resource should be available in the operational state if 446 there is a yang module referencing that operational state, but this 447 is not always the case. In the cases where operational state is not 448 updated, the I2RS SB (southbound) API should include the ability to 449 send a notification. 451 SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite 452 policy". Such policy defines how an I2RS is able to 453 update and overwrite a resource set by a user outside 454 the I2RS plane. Such hierarchy has been described in 455 section 6.3 and 7.8 of [RFC7921] 457 Explanation: 459 A key part of the I2RS architecture is notification regarding routing 460 system changes across the I2RS plane (I2RS client to/from I2RS 461 agent). The security environment requirements above (SEC-ENV-REQ-03 462 to SEC-ENV-REQ-05) provide the assurance that the I2RS plane and the 463 routing systems the I2RS plane attaches to remains untouched by the 464 other planes or the I2RS plane is notificed of such changes. 465 Section 6.3 of [RFC7921] describes how the I2RS agent within the I2RS 466 plane interacts with forwarding plane's local configuration, and 467 provides the example of an overwrite policy between the I2RS plane 468 and local configuration (instantiated in 2 Policy Knobs) that 469 operators may wish to set. The prompt notification of any outside 470 overwrite is key to the architecture and proper interworking of the 471 I2RS Plane. 473 4. I2RS Access Control for Routing System Resources 475 This section provides recommendations on how the I2RS plane's access 476 control should be designed to protect the routing system resources. 477 These security policies for access control only apply within the I2RS 478 plane. More especially, the policies are associated to the 479 applications, I2RS clients and I2RS agents, with their associated 480 identity and roles. 482 The I2RS deployment of I2RS applications, I2RS clients, and I2RS 483 agents can be located locally in a closed environment or distributed 484 over open networks. The normal case for routing system management is 485 over an open environment. Even in a closed environment, access 486 control policies should be carefully defined to be able to, in the 487 future, carefully extend the I2RS plane to remote applications or 488 remote I2RS clients. 490 [RFC8241] defines the security requirements of the I2RS protocol 491 between the I2RS client and the I2RS agent over a secure transport. 492 This section focuses on I2RS access control architecture (section 493 4.1), access control policies of the I2RS agent (section 4.2), the 494 I2RS client (section 4.3), and the application (section 4.4). 496 4.1. I2RS Access Control Architecture 498 Overview: 500 Applications access the routing system resource via numerous 501 intermediate nodes. The application communicates with an I2RS 502 client. In some cases, the I2RS client is only associated with a 503 single application attached to one or more agents (case a and case b 504 in figure 4 below). In other cases, the I2RS client may be connected 505 to two applications (case c in figure 4 below), or the I2RS may act 506 as a broker (agent/client device shown in case d in figure 4 below). 507 The I2RS client broker approach provides scalability to the I2RS 508 architecture as it avoids each application being registered to the 509 I2RS agent. Similarly, the I2RS access control should be able to 510 scale to numerous applications. 512 The goal of the security environment requirements in this section are 513 to control the interactions between the applications and the I2RS 514 client, and the interactions between the I2RS client and the I2RS 515 agent. The key challenge is that the I2RS architecture puts the I2RS 516 Client in control of the stream of communication (application to I2RS 517 client and I2RS client to the I2RS agent). The I2RS agent must trust 518 the I2RS client's actions without having an ability to verify the 519 I2RS client's actions. 521 a) I2RS application-client pair talking 522 to one I2RS agent 524 +-----------+ +---------+ +-------+ 525 | I2RS |=====| I2RS |======| I2RS | 526 |application| | client 1| | agent | 527 +-----------+ +---------+ +-------+ 529 b) I2RS application client pair talking to 530 two i2RS agents 531 +--------+ 532 +-------------+ +---------+ | I2RS | 533 | I2RS |===| I2RS |=====| agent 1| 534 |application 1| | client 1| +--------+ 535 | | | | +--------+ 536 | | | |=====| I2RS | 537 +-------------+ +---------+ | agent 2| 538 +--------+ 540 c) two applications talk to 1 client 541 +--------+ 542 +-------------+ +--------+ | I2RS | 543 | I2RS |===|I2RS |=====| agent 1| 544 |application 1| |client 1| +--------+ 545 +-------------+ | | +--------+ 546 +-------------+ | |=====| I2RS | 547 | I2RS | | | | agent 2| 548 |application 2|===| | +--------+ 549 +-------------+ +--------+ 551 d) I2RS Broker (agent/client 552 +--------+ 553 +-------------+ +--------+ | I2RS | 554 | I2RS |==|I2RS |=====|agent 3/| 555 |application 1| |client 1| ==|client 3+----+ 556 +-------------+ +--------+ | +--+-----+ | 557 | | | 558 +-------------+ +--------+ | +-------+ +--|----+ 559 | I2RS | |I2RS |===| |I2RS | |I2RS | 560 |application 2|==|client 2| |agent 1| |agent 2| 561 +-------------+ +--------+ +-------+ +-------+ 563 figure 3 565 4.1.1. Access control Enforcement Scope 567 SEC-ENV-REQ 6: I2RS access control should be performed through the 568 whole I2RS plane. It should not be enforced by the 569 I2RS agent only within the routing element. Instead, 570 the I2RS client should enforce the I2RS client access 571 control against applications and the I2RS agent 572 should enforce the I2RS agent access control against 573 the I2RS clients. The mechanisms for the I2RS client 574 access control are not in scope of the I2RS 575 architecture [RFC7921], which exclusively focuses on 576 the I2RS agent access control provided by the I2RS 577 protocol. 579 Explanation: 581 This architecture results in a layered and hierarchical or multi- 582 party I2RS access control. An application will be able to access a 583 routing system resource only if both the I2RS client is granted 584 access by the I2RS agent and the application is granted access by the 585 I2RS client. 587 4.1.2. Notification Requirements 589 SEC-ENV-REQ 7: When an access request to a routing resource is 590 refused by one party (the I2RS client or the I2RS 591 agent), the requester (e.g the application) as well 592 as all intermediaries should indicate the reason the 593 access has not been granted, and which entity 594 rejected the request. 596 Explanation: 598 In case the I2RS client access control or the I2RS agent access 599 control does not grant access to a routing system resource, the 600 application should be able to determine whether its request has been 601 rejected by the I2RS client or the I2RS agent as well as the reason 602 that caused the reject. 604 SEC-REQ-07 indicates the I2RS agent may reject the request because 605 the I2RS client is not an authorized I2RS client or lacks the 606 privileges to perform the requested transaction (read, write, start 607 notifications or logging). The I2RS client should be notified of the 608 reason the I2RS agent rejected the transaction due to a lack of 609 authorization or privileges, and the I2RS client should return a 610 message to the application indicating the I2RS agent reject the 611 transaction with an indication of this reason. Similarly, if the 612 I2RS client does not grant the access to the application, the I2RS 613 client should also inform the application. An example of an error 614 message could be, "Read failure: you do not have read permission", 615 "Write failure: you do not have write permission", or "Write failure: 616 resource accessed by someone else". 618 This requirement has been written in a generic manner as it relates 619 to the following interactions: 621 o interactions between the application and the I2RS client, 623 o interactions between the I2RS client and the I2RS agent at a 624 content level (Protocol security requirements are described by 625 [RFC8241]), and 627 o interactions between the I2RS agent and the I2RS routing system 628 (forwarding plane, control plane, and routing plane). 630 4.1.3. Trust 632 SEC-ENV-REQ 8: In order to provide coherent access control policies 633 enforced by multiple parties (e.g. the I2RS client or 634 the I2RS agent), theses parties should trust each 635 other, and communication between them should also be 636 trusted (e.g. TLS) in order to reduce additional 637 vectors of attacks. 639 SEC-ENV-REQ 9: I2RS client or I2RS agent SHOULD also be able to 640 refuse a communication with an application or an I2RS 641 client when the communication channel does not 642 fulfill enough security requirements. 644 Explanation: 646 The participants in the I2RS Plane (I2RS client, I2RS agent, and I2RS 647 application) exchange critical information, and to be effective the 648 communication should be trusted and free from security attacks. 650 The I2RS client or the I2RS agent should be able to reject messages 651 over a communication channel that can be easily hijacked, like a 652 clear text UDP channel. 654 4.1.4. Sharing access control Information 656 For the I2RS client: 658 SEC-ENV-REQ 10: The I2RS client MAY request information on its I2RS 659 access control subset policies from the I2RS agent or 660 cache requests that have been rejected by the I2RS 661 agent to limit forwarding unnecessary queries to the 662 I2RS agent. 664 SEC-ENV-REQ 11: The I2RS client MAY support receiving notifications 665 when its I2RS access control subset policies have 666 been updated by the I2RS agent. 668 Similarly, for the applications: 670 SEC-ENV-REQ 12: The applications MAY request information on its I2RS 671 access control subset policies in order to limit 672 forwarding unnecessary queries to the I2RS client. 674 SEC-ENV-REQ 13: The applications MAY subscribe to a service that 675 provides notification when its I2RS access control 676 subset policies have been updated. 678 For both the application and the client: 680 SEC-ENV-REQ 14: The I2RS access control should explicitly specify 681 accesses that are granted. More specifically, 682 anything not explicitly granted should be denied 683 (default rule). 685 Explanation: 687 In order to limit the number of access requests that result in an 688 error, each application or I2RS client can retrieve the I2RS access 689 control policies that apply to it. This subset of rules is 690 designated as the "Individual I2RS access control policies". As 691 these policies are subject to changes, a dynamic synchronization 692 mechanism should be provided. However, such mechanisms may be 693 implemented with different levels of completeness and dynamicity of 694 the individual I2RS access control policies. One example may be 695 caching transaction requests that have been rejected. 697 I2RS access control should be appropriately balanced between the I2RS 698 client and the I2RS agent. It remains relatively easy to avoid the 699 complete disclosure of the access control policies of the I2RS agent. 700 Relative disclosure of access control policies may allow leaking 701 confidential information in case of misconfiguration. It is 702 important to balance the level of trust of the I2RS client and the 703 necessity of distributing the enforcement of the access control 704 policies. 706 I2RS access control should not solely rely only on the I2RS client or 707 the I2RS agent as illustrated below: 709 - 1) I2RS clients are dedicated to a single application: In this 710 case, it is likely that I2RS access control is enforced only by 711 the I2RS agent, as the I2RS client is likely to accept all 712 access requests of the application. It is recommended that 713 even in this case, I2RS client access control is not based on 714 an "Allow anything from application" policy, but instead the 715 I2RS client specifies accesses that are enabled. In addition, 716 the I2RS client may sync its associated I2RS access control 717 policies with the I2RS agent to limit the number of refused 718 access requests being sent to the I2RS agent. The I2RS client 719 is expected to balance benefits and problems with synchronizing 720 its access control policies with the I2RS agent to proxy 721 request validation versus simply passing the access request to 722 the I2RS agent. 724 - 2) A single I2RS client connects to multiple applications or 725 acts as a broker for many applications: 726 In this case the I2RS agent has a single I2RS client 727 attached, so the I2RS client could be configured to enforce 728 access control policies instead of the I2RS Agent. In this 729 circumstance, it is possible that the I2RS agent may grant 730 an I2RS client high priviledges and blindly trust the I2RS 731 client without enforcing access control policies on what the 732 I2RS client can do. Such a situation must be avoided as it 733 could be used by malicious applications for a privilege 734 escalation by compromising the I2RS client, causing the I2RS 735 client to perform some action on behalf of the application 736 that it normally does not have the privileges to perform. 737 In order to mitigate such attacks, the I2RS client that 738 connects to multiple applications or operates as a broker is 739 expected to host application with an equivalent level of 740 privileges. 742 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents 744 Overview: 746 To distribute the I2RS access control policies between I2RS clients 747 and I2RS agents, I2RS access control policies can also be distributed 748 within a set of I2RS clients or a set of I2RS agents. 750 Requirements: 752 SEC-ENV-REQ 15: I2RS clients should be distributed and act as brokers 753 for applications that share roughly similar 754 permissions. 756 SEC-ENV-REQ 16: I2RS agents should avoid granting extra privileges to 757 their authorized I2RS client. I2RS agents should be 758 shared by I2RS clients with roughly similar 759 permissions. More explicitly, an I2RS agent shared 760 between I2RS clients that are only provided read 761 access to the routing system resources do not need to 762 perform any write access, so the I2RS client should 763 not be provided these accesses. 765 SEC-ENV-REQ 17: I2RS clients and I2RS agents should be able to trace 766 [RFC7922] the various transactions they perform as 767 well as suspicious activities. These logs should be 768 collected regularly and analysed by functions that 769 may be out of the I2RS plane. 771 Explanation: 773 This restriction for distributed I2RS clients to act as brokers only 774 for applications with roughly the same privileges avoids the I2RS 775 client having extra privileges compared to hosted applications, and 776 discourages applications from performing privilege escalation within 777 an I2RS client. For example, suppose an I2RS client requires write 778 access to the resources. It is not recommended to grant the I2RS 779 agent the write access in order to satisfy a unique I2RS client. 780 Instead, the I2RS client that requires write access should be 781 connected to an I2RS agent that is already shared by an I2RS client 782 that requires write access. 784 Access control policies enforcement should be monitored in order to 785 detect violation of the policies or detect an attack. Access control 786 policies enforcement may not be performed by the I2RS client or the 787 I2RS agent as violation may require a more global view of the I2RS 788 access control policies. As a result, consistency check and 789 mitigation may instead be performed by the management plane. 790 However, I2RS clients and I2RS agents play a central role. 792 The I2RS agent can trace transactions that an I2RS client requests it 793 to perform, and to link this to the application via the secondary 794 opaque identifier to the application. This information is placed in 795 a tracing log which is retrieved by management processes. If a 796 particular application is granted a level of privileges it should not 797 have, then this tracing mechanism may detect this security intrusion 798 after the intrusion has occurred. 800 4.1.6. Managing Access Control Policy 802 Access control policies should be implemented so that the policies 803 remain manageable in short and longer term deployments of the I2RS 804 protocol and the I2RS plane. 806 Requirements: 808 SEC-ENV-REQ 18: access control should be managed in an automated way, 809 that is granting or revoking an application should 810 not involve manual configuration over the I2RS plane 811 (I2RS client, I2RS agent, and application). 813 Explanation: 815 Granting or configuring an application with new policy should not 816 require manual configuration of I2RS clients, I2RS agents, or other 817 applications. 819 SEC-ENV-REQ 19: Access control should be scalable when the number of 820 application grows as well as when the number of I2RS 821 clients increases. 823 Explanation: 825 A typical implementation of a local I2RS client access control 826 policies may result in creating manually a system user associated 827 with each application. Such an approach is not likely to scale when 828 the number of applications increases into the hundreds. 830 SEC-ENV-REQ 20: Access control should be dynamically managed and 831 easily updated. 833 Explanation: 835 Although the number of I2RS clients is expected to be lower than the 836 number of applications, as I2RS agents provide access to the routing 837 resource, it is of primary importance that an access can be granted 838 or revoke in an efficient way. 840 SEC-ENV-REQ 21: I2RS clients and I2RS agents should be uniquely 841 identified in the network to enable centralized 842 management of the I2RS access control policies. 844 Explanation: 846 Centralized management of the access control policies of an I2RS 847 plane with network that hosts several I2RS applications, clients and 848 agents requires that each devices can be identified. 850 4.2. I2RS Agent Access Control Policies 852 Overview: 854 The I2RS agent access control restricts routing system resource 855 access to authorized identities - possible access policies may be 856 none, read or write. The initiator of an access request to a routing 857 resource is always an application. However, it remains challenging 858 for the I2RS agent to establish its access control policies based on 859 the application that initiates the request. 861 First, when an I2RS client acts as a broker, the I2RS agent may not 862 be able to authenticate the application. In that sense, the I2RS 863 agent relies on the capability of the I2RS client to authenticate the 864 applications and apply the appropriated I2RS client access control. 866 Second, an I2RS agent may not uniquely identify a piece of software 867 implementing an I2RS client. In fact, an I2RS client may be provided 868 multiple identities which can be associated to different roles or 869 privileges. The I2RS client is left responsible for using them 870 appropriately according to the application. 872 Third, each I2RS client may contact various I2RS agent with different 873 privileges and access control policies. 875 4.2.1. I2RS Agent Access Control 877 This section provides recommendations on the I2RS agent access 878 control policies to keep I2RS access control coherent within the I2RS 879 plane. 881 Requirements: 883 SEC-ENV-REQ 22: I2RS agent access control policies should be 884 primarily based on the I2RS clients as described in 885 [RFC7921]. 887 SEC-ENV-REQ 23: I2RS agent access control policies MAY be based on 888 the application if the application identity has been 889 authenticated by the I2RS client and passed via the 890 secondary identity to the I2RS agent. 892 SEC-ENV-REQ 24: The I2RS agent should know which identity (E.g. 893 system user) performed the latest update of the 894 routing resource. This is true for an identity 895 inside and outside the I2RS plane, so the I2RS agent 896 can appropriately perform an update according to the 897 priorities associated to the requesting identity and 898 the identity that last updated the resource. 900 SEC-ENV-REQ 25: the I2RS agent should have an "I2RS agent overwrite 901 Policy" that indicates how identities can be 902 prioritized. This requirement is also described in 903 section 7.6 of [RFC7921]. Similar requirements exist 904 for components within the I2RS plane, but this is 905 within the scope of the I2RS protocol security 906 requirements [RFC8241]. 908 Explanation: 910 If the I2RS application is authenticated to the I2RS client, and the 911 I2RS client is authenticated to the I2RS agent, and the I2RS client 912 uses the opaque secondary identifier to pass an authenticated 913 identifier to the I2RS agent, then this identifier may be used for 914 access control. However, caution should be taken when using this 915 chain of authentication since the secondary identifier is intended in 916 the I2RS protocol only to aid traceability. 918 From the environment perspective the I2RS agent MUST be aware when 919 the resource has been modified outside the I2RS plane by another 920 plane (management, control, or forwarding). The prioritization 921 between the different planes should set a deterministic policy that 922 allows the collision of two planes (I2RS plane and another plane) to 923 be resolved via an overwrite policy in the I2RS agent. 925 Similar requirements exist for knowledge about identities within the 926 I2RS plane which modify things in the routing system, but this is 927 within the scope of the I2RS protocol's requirements for ephemeral 928 state [RFC8242] and security requirements [RFC8241]. 930 4.2.2. I2RS Client Access Control Policies 932 Overview: 934 The I2RS client access control policies are responsible for 935 authenticating the application managing the privileges for the 936 applications, and enforcing access control to resources by the 937 applications. 939 Requirements: 941 REQ 26: I2RS client should authenticate its applications. If the 942 I2RS client acts as a broker and supports multiple 943 applications, it should authenticate each application. 945 REQ 27: I2RS client should define access control policies associated 946 to each applications. An access to a routing resource by an 947 application should not be forwarded immediately and 948 transparently by the I2RS client based on the I2RS agent 949 access control policies. The I2RS client should first check 950 whether the application has sufficient privileges, and if so 951 send an access request to the I2RS agent. 953 Explanation: 955 If no authentication mechanisms have being provided between the I2RS 956 client and the application, then the I2RS client must be dedicated to 957 a single application. By doing so, application authentication relies 958 on the I2RS authentication mechanisms between the I2RS client and the 959 I2RS agent. 961 If an I2RS client has multiple identities that are associated with 962 different privileges for accessing an I2RS agent(s), the I2RS client 963 access control policies should specify the I2RS client identity with 964 the access control policy. 966 4.2.3. Application and Access Control Policies 968 Overview 970 Applications do not enforce access control policies. Instead these 971 are enforced by the I2RS clients and the I2RS agents. This section 972 provides recommendations for applications in order to ease I2RS 973 access control by the I2RS client and the I2RS agent. 975 Requirements: 977 SEC-ENV-REQ 28: Applications SHOULD be uniquely identified by their 978 associated I2RS clients 980 Explanation: 982 Different application may use different methods (or multiple methods) 983 to communicate with its associated I2RS client, and each application 984 may not use the same form of an application identifier. However, the 985 I2RS client must obtain an identifier for each application. One 986 method for this identification can be a system user id. 988 SEC-ENV-REQ 29: Each application SHOULD be associated to a restricted 989 number of I2RS clients. 991 Explanation: 993 The I2RS client provides access to resource on its behalf and this 994 access should only be granted for trusted applications, or 995 applications with an similar level of trust. This does not prevent 996 an I2RS client to host a large number of applications with the same 997 levels of trust. 999 SEC-ENV-REQ 30: An application SHOULD be provided means and methods 1000 to contact their associated I2RS client. 1002 Explanation: 1004 It is obvious when an I2RS client belongs to the application as part 1005 of a module or a library that the application can communicate with a 1006 I2RS client. Similarly, if the application runs into a dedicated 1007 system with a I2RS client, it is obvious which I2RS client the 1008 application should contact. If the application connects to the I2RS 1009 client remotely, the application needs some means to retrieve the 1010 necessary information to contact its associated I2RS client (e.g. an 1011 IP address or a FQDN). 1013 5. I2RS Application Isolation 1015 A key aspect of the I2RS architecture is the network oriented 1016 application that uses the I2RS high bandwidth programmatic interface 1017 to monitor or change one or more routing systems. I2RS applications 1018 could be control by a single entity or serve various tenants of the 1019 network. If multiple entities use an I2RS application to monitor or 1020 change the network, security policies must preserve the isolation of 1021 each entity's control and not let malicious entities controlling one 1022 I2RS application interfere with other I2RS applications. 1024 This section discusses both security aspects related to 1025 programmability as well as application isolation in the I2RS 1026 architecture. 1028 5.1. Robustness Toward Programmability 1030 Overview 1032 I2RS provides a programmatic interface in and out of the Internet 1033 routing system which provides the following advantages for security: 1035 o the use of automation reduces configuration errors; 1036 o the programmatic interface enables fast network reconfiguration 1037 and agility in adapting to network attacks; and 1039 o monitoring facilities to detect a network attack, and 1040 configuration changes which can help mitigate the network attack. 1042 Programmability allows applications to flexible control which may 1043 cause problems due to: 1045 o applications which belong to different tenants with different 1046 objectives, 1048 o applications which lack coordination resulting in unstable routing 1049 configurations such as oscillations between network 1050 configurations, and creation of loops. For example, one 1051 application may monitor a state and change to positive, and a 1052 second application performs the reverse operation (turns it 1053 negative). This fluctuation can cause a routing system to become 1054 unstable. 1056 The I2RS plane requires data and application isolation to prevent 1057 such situations from happening. However, to guarantee the network 1058 stability constant monitoring and error detection are recommended. 1060 Requirement: 1062 SEC-ENV-REQ 31: The I2RS agents should monitor constantly parts of 1063 the system for which I2RS clients or applications 1064 have provided requests. It should also be able to 1065 detect any I2RS clients or applications causing 1066 problems that may leave the routing system in an 1067 unstable state. 1069 Explanation: 1071 In the least, monitoring consists of logging events and receiving 1072 streams of data. I2RS Plane implementations should monitor the I2RS 1073 applications and I2RS clients for potential problems. The cause for 1074 the I2RS clients or applications providing problematic requests can 1075 be failures in the implementation code or malicious intent. ] 1077 5.2. Application Isolation 1079 5.2.1. DoS 1081 Overview: 1083 Requirements for robustness to DoS attacks have been addressed in the 1084 communication channel section [RFC7921]. This section focuses on 1085 requirements for application isolation that help prevent DoS. 1087 Requirements: 1089 SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS 1090 agent control the resources allocated to each I2RS 1091 client. I2RS clients that act as broker may not be 1092 protected efficiently against these attacks unless 1093 the broker performs resource controls for the hosted 1094 applications. 1096 SEC-ENV-REQ 33: I2RS agent SHOULD not make a response redirection 1097 unless the redirection is previously validated and 1098 agreed by the destination. 1100 SEC-ENV-REQ 34: I2RS Applications should avoid the use of underlying 1101 protocols that are not robust enough to protect 1102 against reflection attacks. 1104 Explanation: 1106 The I2RS interface is used by applications to interact with the 1107 routing states. If the I2RS client is shared between multiple 1108 applications, one application can use the I2RS client to perform DoS 1109 or DDoS attacks on the I2RS agent(s) and through the I2RS agents 1110 attack the network. DoS attack targeting the I2RS agent would 1111 consist in providing requests that keep the I2RS agent busy for a 1112 long time. These attacks on the I2RS agent may involve an 1113 application (requesting through an I2RS Client) heavy computation by 1114 the I2RS agent in order to block operations like disk access. 1116 Some DoS attacks may attack the I2RS Client's reception of 1117 notification and monitoring data streams over the network. Other DoS 1118 attacks may focus on the application directly by performing 1119 reflection attacks to reflect traffic. Such an attack could be 1120 performed by first detecting an application is related to monitoring 1121 the RIB or changing the RIB. Reflection-based DoS may also attack at 1122 various levels in the stack utilizing UDP at the service to redirect 1123 data to a specific repository 1125 I2RS implementation should consider how to protect I2RS against such 1126 attacks. 1128 5.2.2. Application Logic Control 1130 Overview 1132 This section examines how application logic must be designed to 1133 ensure application isolation. 1135 Requirements: 1137 SEC-ENV-REQ 35: Application logic should remain opaque to external 1138 listeners. Application logic may be partly hidden by 1139 encrypting the communication between the I2RS client 1140 and the I2RS agent. Additional ways to obfuscate the 1141 communications may involve sending random messages of 1142 various sizes. Such strategies have to be balanced 1143 with network load. Note that I2RS client broker are 1144 more likely to hide the application logic compared to 1145 I2RS client associated to a single application. 1147 Explanation: 1149 Applications use the I2RS interface in order to update the routing 1150 system. These updates may be driven by behaviour on the forwarding 1151 plane or any external behaviours. In this case, correlating 1152 observation with the I2RS traffic may enable the derivation the 1153 application logic. Once the application logic has been derived, a 1154 malicious application may generate traffic or any event in the 1155 network in order to activate the alternate application. 1157 6. Security Considerations 1159 This whole document is about security requirements for the I2RS 1160 environment. To protect personal privacy, any identifier (I2RS 1161 application identifier, I2RS client identifier, or I2RS agent 1162 identifier) should not contain personal identifiable information. 1164 7. IANA Considerations 1166 No IANA considerations for this requirements. 1168 8. Acknowledgments 1170 A number of people provided a significant amount of helpful comments 1171 and reviews. Among them the authors would like to thank Russ White, 1172 Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, 1173 Alia Atlas, and Linda Dunbar. 1175 9. References 1177 9.1. Normative References 1179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1180 Requirement Levels", BCP 14, RFC 2119, 1181 DOI 10.17487/RFC2119, March 1997, 1182 . 1184 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 1185 Statement for the Interface to the Routing System", 1186 RFC 7920, DOI 10.17487/RFC7920, June 2016, 1187 . 1189 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1190 Nadeau, "An Architecture for the Interface to the Routing 1191 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1192 . 1194 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1195 the Routing System (I2RS) Traceability: Framework and 1196 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1197 2016, . 1199 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1200 for Subscription to YANG Datastores", RFC 7923, 1201 DOI 10.17487/RFC7923, June 2016, 1202 . 1204 [RFC8241] Hares, S., Migault, D., and J. Halpern, "Interface to the 1205 Routing System (I2RS) Security-Related Requirements", 1206 RFC 8241, DOI 10.17487/RFC8241, September 2017, 1207 . 1209 9.2. Informative References 1211 [RFC8242] Haas, J. and S. Hares, "Interface to the Routing System 1212 (I2RS) Ephemeral State Requirements", RFC 8242, 1213 DOI 10.17487/RFC8242, September 2017, 1214 . 1216 [I-D.ietf-netconf-rfc6536bis] 1217 Bierman, A. and M. Bjorklund, "Network Configuration 1218 Protocol (NETCONF) Access Control Model", draft-ietf- 1219 netconf-rfc6536bis-05 (work in progress), September 2017. 1221 [I-D.ietf-netmod-revised-datastores] 1222 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1223 and R. Wilton, "Network Management Datastore 1224 Architecture", draft-ietf-netmod-revised-datastores-04 1225 (work in progress), August 2017. 1227 Authors' Addresses 1229 Daniel Migault 1230 Ericsson 1231 8400 boulevard Decarie 1232 Montreal, QC H4P 2N2 1233 Canada 1235 Phone: +1 514-452-2160 1236 Email: daniel.migault@ericsson.com 1238 Joel Halpern 1239 Ericsson 1241 Email: Joel.Halpern@ericsson.com 1243 Susan Hares 1244 Huawei 1245 7453 Hickory Hill 1246 Saline, MI 48176 1247 USA 1249 Email: shares@ndzh.com