idnits 2.17.00 (12 Aug 2021) /tmp/idnits3215/draft-ietf-i2rs-protocol-security-requirements-17.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 -- The document date (September 29, 2016) is 2053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-01 == Outdated reference: draft-ietf-i2rs-ephemeral-state has been published as RFC 8242 == Outdated reference: draft-ietf-netconf-restconf has been published as RFC 8040 == Outdated reference: draft-ietf-taps-transports has been published as RFC 8095 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational D. Migault 5 Expires: April 2, 2017 J. Halpern 6 Ericsson 7 September 29, 2016 9 I2RS Security Related Requirements 10 draft-ietf-i2rs-protocol-security-requirements-17 12 Abstract 14 This presents security-related requirements for the I2RS protocol 15 which provides a new interface to the routing system described in the 16 I2RS architecture document (RFC7921). The I2RS protocol is a re-use 17 protocol implemented by re-using portions of existing IETF protocols 18 and adding new features to these protocols. The I2RS protocol re- 19 uses security features of a secure transport (E.g. TLS, SSH, DTLS) 20 such as encryption, message integrity, mutual peer authentication, 21 and replay protection. The new I2RS features to consider from a 22 security perspective are: a priority mechanism to handle multi-headed 23 write transactions, an opaque secondary identifier which identifies 24 an application using the I2RS client, and an extremely constrained 25 read-only non-secure transport. This document provides the detailed 26 requirements for these security features. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 2, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2.2. Security Definitions . . . . . . . . . . . . . . . . . . 4 66 2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5 67 3. Security Features and Protocols: Re-used and New . . . . . . 7 68 3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7 69 3.2. New Features Related to Security . . . . . . . . . . . . 8 70 3.3. I2RS Protocol Security Requirements vs. IETF Management 71 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 73 4.1. I2RS Peers(agent and client) Identity Authentication . . 10 74 4.2. Identity Validation Before Role-Based Message Actions . . 11 75 4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12 76 4.4. Multi-Channel Transport: Secure Transport and Insecure 77 Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.5. Management Protocol Security . . . . . . . . . . . . . . 15 79 4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16 80 4.7. Security of the environment . . . . . . . . . . . . . . . 17 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 8.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 The Interface to the Routing System (I2RS) provides read and write 92 access to information and state within the routing system. An I2RS 93 client interacts with one or more I2RS agents to collect information 94 from network routing systems. [RFC7921] describes the architecture 95 of this interface, and this documents assumes the reader is familiar 96 with this architecture and its definitions. Section 2 highlights 97 some of the references the reader is required to be familiar with. 99 The I2RS interface is instantiated by the I2RS protocol connecting an 100 I2RS client and an I2RS agent associated with a routing system. The 101 I2RS protocol is a re-use protocol implemented by re-using portions 102 of existing IETF protocols, and adding new features to these 103 protocols. As a re-use protocol, it can be considered a higher-level 104 protocol since it can be instantiated in multiple management 105 protocols (e.g. NETCONF [RFC6241] or RESTCONF 106 [I-D.ietf-netconf-restconf]) operating over a secure transport. The 107 security for the I2RS protocol comes from the management protocols 108 operating over a a secure transport. 110 This document is part of the requirements for I2RS protocol which 111 also include: 113 o I2RS architecture [RFC7921], 115 o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state], 117 o publication/subscription requirements [RFC7922], and 119 o traceability [RFC7923]. 121 Since the I2RS "higher-level" protocol changes the interface to the 122 routing systems, it is important that implementers understand the new 123 security requirements for the environment the I2RS protocol operates 124 in. These security requirements for the I2RS environment are 125 specified in [I-D.ietf-i2rs-security-environment-reqs]; and the 126 summary of the I2RS protocol security environment is found in the 127 I2RS Architecture [RFC7920]. 129 I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which 130 support encryption, message integrity, peer authentication, and key 131 distribution protocols. Optionally, implementers may utilize AAA 132 protocols (Radius over TLS or Diameter over TLS) to securely 133 distribute identity information. 135 Section 3 provides an overview of security features and protocols 136 being re-used (section 3.1) and the new security features being 137 required (section 3.2). Section 3 also explores how existing and new 138 security features and protocols would be paired with existing IETF 139 management protocols (section 3.3). 141 The new features I2RS extends to these protocols are a priority 142 mechanism to handle multi-headed writes, an opaque secondary 143 identifier to allow traceability of an application utilizing a 144 specific I2RS client to communicate with an I2RS agent, and insecure 145 transport constrained to be utilized only for read-only data, which 146 may include publically available data (e.g. public BGP Events, public 147 telemetry information, web service availability) and some legacy 148 data. 150 Section 4 provides the I2RS protocol security requirements by the 151 following security features: 153 o peer identity authentication (section 4.1), 155 o peer identity validation before role-based message actions 156 (section 4.2) 158 o peer identity and client redundancy (section 4.3), 160 o multi-channel transport requirements: Secure transport and 161 insecure Transport (section 4.4), 163 o management protocol security requirements (section 4.5), 165 o role-based security (section 4.6), 167 o security environment (section 4.7) 169 Protocols designed to be I2RS higher-layer protocols need to fulfill 170 these security requirements. 172 2. Definitions 174 2.1. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 2.2. Security Definitions 182 This document utilizes the definitions found in the following 183 documents: [RFC4949] and [RFC7921] 184 Specifically, this document utilizes the following definitions from 185 [RFC4949]: 187 o access control, 189 o authentication, 191 o data confidentiality, 193 o data integrity, 195 o data privacy, 197 o identity, 199 o identifier, 201 o mutual authentication, 203 o role, 205 o role-based access control, 207 o security audit trail, and 209 o trust. 211 [RFC7922] describes traceability for I2RS interface and the I2RS 212 protocol. Traceability is not equivalent to a security audit trail 213 or simple logging of information. A security audit trail may utilize 214 traceability information. 216 This document also requires that the user is familiar with the 217 pervasive security requirements in [RFC7258]. 219 2.3. I2RS Specific Definitions 221 The document utilizes the following concepts from the I2RS 222 architecture: [RFC7921]: 224 o I2RS client, I2RS agent, and I2RS protocol (section 2), 226 o I2RS higher-layer protocol (section 7.2) 228 o scope: read scope, notification scope, and write scope (section 229 2), 231 o identity and scope of the identity (section 2), 232 o roles or security rules (section 2), 234 o identity and scope, and secondary identity (section 2), 236 o routing system/subsytem (section 2), 238 o I2RS assumed security environment (section 4), 240 o I2RS identity and authorization (section 4.1), 242 o I2RS authorization, scope of Authorization in I2RS client and 243 agent (section 4.2), 245 o client redundancy with a single client identity (section 4.3), 247 o restrictions on I2RS in personal devices (section 4.4), 249 o communication channels and I2RS high-layer protocol (section 7.2), 251 o active communication versus connectivity (section 7.5), 253 o multi-headed control (section 7.8), and 255 o transaction, message, multi-message atomicity (section 7.9). 257 This document assumes the reader is familar with these terms. 259 This document discusses the security of the multiple I2RS 260 communication channels which operate over the higher-layer I2RS 261 protocol. The higher-layer I2RS protocol combines a secure transport 262 and I2RS contextual information, and re-uses IETF protocols and data 263 models to create the secure transport and the I2RS data-model driven 264 contextual information. To describe how the I2RS high-layer protocol 265 combines other protocols into the I2RS higher-layer protocol, the 266 following terms are used: 268 I2RS component protocols 270 Protocols which are re-used and combined to create the I2RS 271 protocol. 273 I2RS secure-transport component protocols 275 The I2RS secure transport protocols that support the I2RS higher- 276 layer protocol. 278 I2RS management component protocols 279 The I2RS management protocol which provide the management 280 information context. 282 I2RS AAA component protocols 284 The I2RS AAA protocols supporting the I2RS higher-layer protocol. 286 The I2RS higher-layer protocol requires implementation of a I2RS 287 secure-transport component protocol and the I2RS management component 288 protocol. The I2RS AAA component protocol is optional. 290 3. Security Features and Protocols: Re-used and New 292 3.1. Security Protocols Re-Used by the I2RS Protocol 294 I2RS requires a secure transport protocol and key distribution 295 protocols. The secure transport features required by I2RS are peer 296 authentication, confidentiality, data integrity, and replay 297 protection for I2RS messages. According to 298 [I-D.ietf-taps-transports], the secure transport protocols which 299 support peer authentication, confidentiality, data integrity, and 300 replay protection are the following: 302 1. TLS [RFC5246] over TCP or SCTP, 304 2. DTLS over UDP with replay detection and anti-DoS stateless cookie 305 mechanism required for the I2RS protocol, and the I2RS protocol 306 allow DTLS options of record size negotiation and and conveyance 307 of "don't" fragment bits to be optional in deployments. 309 3. HTTP over TLS (over TCP or SCTP), and 311 4. HTTP over DTLS (with the requirements and optional features 312 specified above in item 2). 314 The following protocols would need to be extended to provide 315 confidentiality, data integrity, peer authentication, and key 316 distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML 317 layer (over SCTP). These protocols will need extensions to run over 318 a secure transport (TLS or DTLS) (see section 3.3 for details). 320 The specific type of key management protocols an I2RS secure 321 transport uses depends on the transport. Key management protocols 322 utilized for the I2RS protocols SHOULD support automatic rotation. 324 An I2RS implementer may use AAA protocols over secure transport to 325 distribute the identities for I2RS client and I2RS agent and role 326 authorization information. Two AAA protocols are: Diameter [RFC6733] 327 and Radius [RFC2865]. To provide the best security I2RS peer 328 identities, the AAA protocols MUST be run over a secure transport 329 (Diameter over secure transport (TLS over TCP) [RFC6733]), Radius 330 over a secure transport (TLS) [RFC6614]). 332 3.2. New Features Related to Security 334 The new features are priority, an opaque secondary identifier, and an 335 insecure protocol for read-only data constrained to specific standard 336 usages. The I2RS protocol allows multi-headed control by several 337 I2RS clients. This multi-headed control is based on the assumption 338 that the operator deploying the I2RS clients, I2RS agents, and the 339 I2rs protocol will coordinate the read, write, and notification scope 340 so the I2RS clients will not contend for the same write scope. 341 However, just in case there is an unforseen overlap of I2RS clients 342 attempting to write a particular piece of data, the I2RS architecture 343 [RFC7921] provides the concept of each I2RS client having a priority. 344 The I2RS client with the highest priority will have its write 345 succeed. This document specifies requirements for this new concept 346 of priority. 348 The opaque secondary identifier identifies an application which is 349 using the I2RS client to I2RS agent communication to manage the 350 routing system. The secondary identifier is opaque to the I2RS 351 protocol. In order to protect personal privacy, the secondary 352 identifier should not contain personal identifiable information. 354 The last new feature related to I2RS security is the ability to allow 355 non-confidential data to be transferred over a non-secure transport. 356 It is expected that most I2RS data models will describe information 357 that will be transferred with confidentiality. Therefore, any model 358 which transfers data over a non-secure transport is marked. The use 359 of a non-secure transport is optional, and an implementer SHOULD 360 create knobs that allow data marked as non-confidential to be sent 361 over a secure transport. 363 Non-confidential data can only be read or notification scope 364 transmission of events. Non-confidential data cannot be write scope 365 or notification scope configuration. An example of non-confidential 366 data is the telemetry information that is publically known (e.g. BGP 367 route-views data or web site status data) or some legacy data (e.g. 368 interface) which cannot be transported in secure transport. The IETF 369 I2RS Data models MUST indicate in the data model the specific data 370 which is non-confidential. 372 Most I2RS data models will expect that the information described in 373 the model will be transferred with confidentiality. 375 3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols 377 Table 1 below provides a partial list of the candidate management 378 protocols and the secure transports each one of the support. One 379 column in the table indicates the transport protocol will need I2RS 380 security extensions. 382 Mangement 383 Protocol Transport Protocol I2RS Extensions 384 ========= ===================== ================= 385 NETCONF TLS over TCP (*1) None required (*2) 387 RESTCONF HTTP over TLS with None required (*2) 388 X.509v3 certificates, 389 certificate validation, 390 mutual authentication: 391 1) authenticated 392 server identity, 393 2) authenticated 394 client identity 395 (*1) 397 FORCES TML over SCTP Needs extension to 398 (*1) TML to run TML over 399 TLS over SCTP, or 400 DTLS with options for 401 replay protection 402 and anti-DoS stateless 403 cookie mechanism. 404 (DTLS record size 405 negotiation and conveyance 406 of "don't" fragment 407 bits are optional). 408 The IPSEC mechanism is 409 not sufficient for 410 I2RS traveling over 411 multiple hops 412 (router + link) (*2) 414 IPFIX SCTP, TCP, UDP Needs to extension 415 TLS or DTLS for to support TLS or 416 secure client (*1) DTLS with options for 417 replay protection 418 and anti-DoS stateless 419 cookie mechanism. 420 (DTLS record size 421 negotiation and conveyance 422 of "don't" fragment 423 bits are optional). 425 *1 - Key management protocols 426 MUST support appropriate key rotation. 428 *2 - Identity and Role authorization distributed 429 by Diameter or Radius MUST use Diameter over TLS 430 or Radius over TLS. 432 4. Security-Related Requirements 434 This section discusses security requirements based on the following 435 security functions: 437 o peer identity authentication (section 4.1), 439 o Peer Identity validation before Role-based Message Actions 440 (section 4.2) 442 o peer identity and client redundancy (section 4.3), 444 o multi-channel transport requirements: Secure transport and 445 insecure Transport (section 4.4), 447 o management protocol security requirements (section 4.5), 449 o role-based security (section 4.6), 451 o security environment (section 4.7) 453 The I2RS Protocol depends upon a secure transport layer for peer 454 authentication, data integrity, confidentiality, and replay 455 protection. The optional insecure transport can only be used 456 restricted set of publically data available (events or information) 457 or a select set of legacy data. Data passed over the insecure 458 transport channel MUST NOT contain any data which identifies a 459 person. 461 4.1. I2RS Peers(agent and client) Identity Authentication 463 The following requirements specify the security requirements for Peer 464 Identity Authentication for the I2RS protocol: 466 o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an 467 identity, and at least one unique identifier that uniquely 468 identifies each party in the I2RS protocol context. 470 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 471 mutual identification of the I2RS client and I2RS agent. 473 o SEC-REQ-03: Identifier distribution and the loading of these 474 identifiers into I2RS agent and I2RS client SHOULD occur outside 475 the I2RS protocol prior to the I2RS protocol establishing a 476 connection between I2RS client and I2RS agent. AAA protocols MAY 477 be used to distribute these identifiers, but other mechanism can 478 be used. 480 Explanation: 482 These requirements specify the requirements for I2RS peer (I2RS agent 483 and I2RS client) authentication. A secure transport (E.g. TLS) will 484 authenticate based on these identities, but these identities are 485 identities for the I2RS management layer. An AAA protocol 486 distributing I2RS identity information SHOULD transport its 487 information over a secure transport. 489 4.2. Identity Validation Before Role-Based Message Actions 491 The requirements for I2RS clients with Secure Connections are the 492 following: 494 SEC-REQ-04: An I2RS agent receiving a request from an I2RS client 495 MUST confirm that the I2RS client has a valid identity. 497 SEC-REQ-05: An I2RS client receiving an I2RS message over a secure 498 transport MUST confirm that the I2RS agent has a valid identifier. 500 SEC-REQ-06: An I2RS agent receiving an I2RS message over an 501 insecure transport MUST confirm that the content is suitable for 502 transfer over such a transport. 504 Explanation: 506 Each I2RS client has a scope based on its identity and the security 507 roles (read, write, or events) associated with that identity, and 508 that scope must be considered in processing an I2RS messages sent on 509 a communication channel. An I2RS communication channel may utilize 510 multiple transport sessions, or establish a transport session and 511 then close the transport session. Therefore, it is important that 512 the I2RS peers are operating utilizing valid peer identities when a 513 message is processed rather than checking if a transport session 514 exists. 516 During the time period when a secure transport session is active, the 517 I2RS agent SHOULD assume that the I2RS client's identity remains 518 valid. Similarly, while a secure connection exists that included 519 validating the I2RS agent's identity and a message is received via 520 that connection, the I2RS client SHOULD assume that the I2RS agent's 521 identity remains valid. 523 The definition of what constitutes a valid identity or a valid 524 identifier MUST be defined by the I2RS protocol. 526 4.3. Peer Identity, Priority, and Client Redundancy 528 Requirements: 530 SEC-REQ-07: Each I2RS Identifier MUST be associated with just one 531 priority. 533 SEC-REQ-08: Each Identifier is associated with one secondary 534 identifier during a particular I2RS transaction (e.g. read/write 535 sequence), but the secondary identifier may vary during the time a 536 connection between the I2RS client and I2RS agent is active. 538 Explanation: 540 The I2RS architecture also allows multiple I2RS clients with unique 541 identities to connect to an I2RS agent (section 7.8). The I2RS 542 deployment using multiple clients SHOULD coordinate this multi-headed 543 control of I2RS agents by I2RS clients so no conflict occurs in the 544 write scope. However, in the case of conflict on a write scope 545 variable, the error resolution mechanisms defined by the I2RS 546 architecture multi-headed control ([RFC7921], section 7.8) allow the 547 I2RS agent to deterministically choose one I2RS client. The I2RS 548 client with highest priority is given permission to write the 549 variable, and the second client receives an error message. 551 A single I2RS client may be associated with multiple applications 552 with different tasks (e.g. weekly configurations or emergency 553 configurations). The secondary identity is an opaque value that the 554 I2RS client passes to the I2RS agent so that this opaque value can be 555 placed in the tracing file or event stream to identify the 556 application using the I2RS client to I2RS agent communication. The 557 I2RS client is trusted to simply assert the secondary identifier. 559 One example of the use of the secondary identity is the situation 560 where an operator of a network has two applications that use an I2RS 561 client. The first application is a weekly configuration application 562 that uses the I2RS protocol to change configurations. The second 563 application is an application that allows operators to makes 564 emergency changes to routers in the network. Both of these 565 applications use the same I2RS client to write to an I2RS agent. In 566 order for traceability to determine which application (weekly 567 configuration or emergency) wrote some configuration changes to a 568 router, the I2RS client sends a different opaque value for each of 569 the applications. The weekly configuration secondary opaque value 570 could be "xzzy-splot" and the emergency secondary opaque value could 571 be "splish-splash". 573 A second example is if the I2RS client is used for monitoring of 574 critical infrastructure. The operator of a network using the I2RS 575 client may desire I2RS client redundancy where the monitoring 576 application wth the I2RS client is deployed on two different boxes 577 with the same I2RS client identity (see [RFC7921] section 4.3) These 578 two monitoring applications pass to the I2RS client whether the 579 application is the primary or back up application, and the I2RS 580 client passes this information in the I2RS secondary identitifier as 581 the figure below shows. The primary applications secondary 582 identifier is "primary-monitoring", and the backup application 583 secondary identifier is "backup-monitoring". The I2RS tracing 584 information will include the secondary identifier information along 585 with the transport information in the tracing file in the agent. 587 Example 2: Primary and Backup Application for Monitoring 588 Identification sent to agent 590 Application A--I2RS client--Secure transport(#1) 591 [I2RS identity 1, secondary identifier: "primary-monitoring"]--> 593 Application B--I2RS client--Secure transport(#2) 594 [I2RS identity 1, secondary identifier: "backup-monitoring"]--> 596 Figure 1 598 4.4. Multi-Channel Transport: Secure Transport and Insecure Transport 600 Requirements: 602 SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a 603 secure transport and optionally MAY be able to transfer data over 604 a non-secure transport. The default transport is a secure 605 transport, and this secure transport is mandatory to implement 606 (MTI) in all I2RS agents, and in any I2RS client which: a) 607 performs a Write scope transaction which is sent to the I2RS agent 608 or b): configures an Event Scope transaction. This secure 609 transport is mandatory to use (MTU) on any I2RS client's Write 610 transaction or the configuration of an Event Scope transaction. 612 SEC-REQ-10: The secure transport MUST provide data 613 confidentiality, data integrity, and practical replay prevention. 615 SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD 616 implement mechanisms that mitigate DoS attacks. For the secure 617 transport, this means the secure transport must support DoS 618 prevention. For the insecure transport protocol, the I2RS higher- 619 layer protocol MUST contain a transport management layer that 620 considers the detection of DoS attacks and provides a warning over 621 a secure-transport channel. 623 SEC-REQ-12: A secure transport MUST be associated with a key 624 management solution that can guarantee that only the entities 625 having sufficient privileges can get the keys to encrypt/decrypt 626 the sensitive data. 628 SEC-REQ-13: A machine-readable mechanism to indicate that a data- 629 model contains non-confidential data MUST be provided. A non- 630 secure transport MAY be used to publish only read scope or 631 notification scope data if the associated data model indicates 632 that that data is non-confidential. 634 SEC-REQ-14: The I2RS protocol MUST be able to support multiple 635 secure transport sessions providing protocol and data 636 communication between an I2RS agent and an I2RS client. However, 637 a single I2RS agent to I2RS client connection MAY elect to use a 638 single secure transport session or a single non-secure transport 639 session conforming the requirements above. 641 SEC-REQ-15: Deployment configuration knobs SHOULD be created to 642 allow operators to send "non-confidential" Read scope (data or 643 Event streams) over a secure transport. 645 SEC-REQ-16: The I2RS protocol makes use of both secure and 646 insecure transports, but this use MUST NOT be done in any way that 647 weakens the secure transport protocol used in the I2RS protocol or 648 other contexts that do not have this requirement for mixing secure 649 and insecure modes of operation. 651 Explanation: 653 The I2RS architecture defines three scopes: read, write, and 654 notification scope. Insecure data can only be used for read scope 655 and notification scope of "non-confidential data". The configuration 656 of ephemeral data in the I2RS agent uses either write scope for data 657 or write scope for configuration of event notification streams. The 658 requirement to use secure transport for configuration prevents 659 accidental or malevolent entities from altering the I2RS routing 660 system through the I2RS agent. 662 It is anticipated that the passing of most I2RS ephemeral state 663 operational status SHOULD be done over a secure transport. 665 In most circumstances the secure transport protocol will be 666 associated with a key management system. Most deployments of the 667 I2RS protocol will allow for automatic key management systems. Since 668 the data models for the I2RS protocol will control key routing 669 functions, it is important that deployments of I2RS use automatic key 670 management systems. 672 Per BCP107 [RFC4107] while key management system SHOULD be automatic, 673 the systems MAY be manual in the following scenarios: 675 a) The environment has limited bandwidth or high round-trip times. 677 b) The information being protected has low value. 679 c) The total volume of traffic over the entire lifetime of the 680 long-term session key will be very low. 682 d) The scale of the deployment is limited. 684 Operators deploying the I2RS protocol selecting manual key management 685 SHOULD consider both short and medium term plans. Deploying 686 automatic systems initially may save effort over the long-term. 688 4.5. Management Protocol Security 690 Requirements: 692 SEC-REQ-17: In a critical infrastructure, certain data within 693 routing elements is sensitive and read/write operations on such 694 data SHOULD be controlled in order to protect its confidentiality. 695 To achieve this, higher-layer protocols MUST utilize a secure 696 transport, and SHOULD provide access control functions to protect 697 confidentiality of the data. 699 SEC-REQ-18: An integrity protection mechanism for I2RS MUST be 700 provided that will be able to ensure the following: 702 1) the data being protected is not modified without detection 703 during its transportation, 705 2) the data is actually from where it is expected to come from, 706 and 707 3) the data is not repeated from some earlier interaction the 708 higher layer protocol (best effort). 710 The I2RS higher-layer protocol operating over a secure transport 711 provides this integrity. The I2RS higher-layer protocol operating 712 over an insecure transport SHOULD provide some way for the client 713 receiving non-confidential read-scoped or event-scoped data over 714 the insecure connection to detect when the data integrity is 715 questionable; and in the event of a questionable data integrity 716 the I2RS client should disconnect the insecure transport 717 connection. 719 SEC-REQ-19: The I2RS higher-layer protocol MUST provide a 720 mechanism for message traceability (requirements in [RFC7922]) 721 that supports the tracking higher-layer functions run across 722 secure connection or a non-secure transport. 724 Explanation: 726 Most carriers do not want a router's configuration and data flow 727 statistics known by hackers or their competitors. While carriers may 728 share peering information, most carriers do not share configuration 729 and traffic statistics. To achieve this, the I2RS higher-layer 730 protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for 731 sensitive data needs to be provided; and the confidentiality 732 protection on such data during transportation needs to be enforced. 734 Integrity of data is important even if the I2RS protocol is sending 735 non-confidential data over an insecure connection. The ability to 736 trace I2RS protocol messages that enact I2RS transactions provides a 737 minimal aid to helping operators check how messages enact 738 transactions on a secure or insecure transport. Contextual checks on 739 specific non-confidential data sent over a insecure connection may 740 indicate the data has been modified. 742 4.6. Role-Based Data Model Security 744 The I2RS Architecture [RFC7921] specifies access control by "role" 745 where role is a method of making access control more manageable by 746 creating a grouping of users so that access control can be specified 747 for a role rather than for each of the individuals. Therefore, I2RS 748 role specifies the access control for a group as being read, write, 749 or notification. 751 SEC-REQ-20: The rules around what I2RS security role is permitted 752 to access and manipulate what information over a secure transport 753 (which protects the data in transit) SHOULD ensure that data of 754 any level of sensitivity is reasonably protected from being 755 observed by those without permission to view it, so that privacy 756 requirements are met. 758 SEC-REQ-21: Role security MUST work when multiple transport 759 connections are being used between the I2RS client and I2RS agent 760 as the I2RS architecture [RFC7921] describes. 762 Sec-REQ-22: If an I2RS agents or an I2RS client is tightly 763 correlated with a person, then the I2RS protocol and data models 764 SHOULD provide additional security that protects the person's 765 privacy. 767 Explanation: 769 I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF) 770 to pass messages in order to enact I2RS transactions. Role Security 771 must secure data (sensitivity and normal data) in a router even when 772 it is operating over multiple connections at the same time. NETCONF 773 can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP 774 over a secure transport (TLS). SCTP [RFC4960] provides security for 775 multiple streams plus end-to-end transport of data. Some I2RS 776 functions may wish to operate over DTLS which runs over UDP 777 ([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]). 779 Please note the security of the application to I2RS client connection 780 is outside of the I2RS protocol or I2RS interface. 782 While I2RS clients are expected to be related to network devices and 783 not individual people, if an I2RS client ran on a person's phone, 784 then privacy protection to anonymize any data relating to a person's 785 identity or location would be needed. 787 A variety of forms of managemen may set policy on roles: "operator- 788 applied knobs", roles that restrict personal access, data-models with 789 specific "privacy roles", and access filters. 791 4.7. Security of the environment 793 The security for the implementation of a protocol also considers the 794 protocol environment. The environmental security requirements are 795 found in: [I-D.ietf-i2rs-security-environment-reqs]. 797 5. Security Considerations 799 This is a document about security requirements for the I2RS protocol 800 and data modules. Security considerations for the I2RS protocol 801 include both the protocol and the security environment. 803 6. IANA Considerations 805 This draft is requirements, and does not request anything of IANA. 807 7. Acknowledgement 809 The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 810 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 811 Atlas, and Jeff Haas for their contributions to the I2RS security 812 requirements discussion and this document. The authors would like to 813 thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia 814 Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their 815 review of these requirements. 817 8. References 819 8.1. Normative References 821 [I-D.ietf-i2rs-security-environment-reqs] 822 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 823 Security Requirements", draft-ietf-i2rs-security- 824 environment-reqs-01 (work in progress), April 2016. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 832 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 833 June 2005, . 835 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 836 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 837 . 839 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 840 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 841 2014, . 843 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 844 Nadeau, "An Architecture for the Interface to the Routing 845 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 846 . 848 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 849 the Routing System (I2RS) Traceability: Framework and 850 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 851 2016, . 853 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 854 for Subscription to YANG Datastores", RFC 7923, 855 DOI 10.17487/RFC7923, June 2016, 856 . 858 8.2. Informative References 860 [I-D.ietf-i2rs-ephemeral-state] 861 Haas, J. and S. Hares, "I2RS Ephemeral State 862 Requirements", draft-ietf-i2rs-ephemeral-state-18 (work in 863 progress), September 2016. 865 [I-D.ietf-netconf-restconf] 866 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 867 Protocol", draft-ietf-netconf-restconf-17 (work in 868 progress), September 2016. 870 [I-D.ietf-taps-transports] 871 Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 872 provided by IETF transport protocols and congestion 873 control mechanisms", draft-ietf-taps-transports-11 (work 874 in progress), July 2016. 876 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 877 "Remote Authentication Dial In User Service (RADIUS)", 878 RFC 2865, DOI 10.17487/RFC2865, June 2000, 879 . 881 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 882 RFC 4960, DOI 10.17487/RFC4960, September 2007, 883 . 885 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 886 (TLS) Protocol Version 1.2", RFC 5246, 887 DOI 10.17487/RFC5246, August 2008, 888 . 890 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 891 Security (DTLS) Extension to Establish Keys for the Secure 892 Real-time Transport Protocol (SRTP)", RFC 5764, 893 DOI 10.17487/RFC5764, May 2010, 894 . 896 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 897 Time-Based One-Time Password Algorithm", RFC 6238, 898 DOI 10.17487/RFC6238, May 2011, 899 . 901 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 902 and A. Bierman, Ed., "Network Configuration Protocol 903 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 904 . 906 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 907 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 908 January 2012, . 910 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 911 Protocol (NETCONF) Access Control Model", RFC 6536, 912 DOI 10.17487/RFC6536, March 2012, 913 . 915 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 916 "Transport Layer Security (TLS) Encryption for RADIUS", 917 RFC 6614, DOI 10.17487/RFC6614, May 2012, 918 . 920 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 921 Ed., "Diameter Base Protocol", RFC 6733, 922 DOI 10.17487/RFC6733, October 2012, 923 . 925 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 926 Statement for the Interface to the Routing System", 927 RFC 7920, DOI 10.17487/RFC7920, June 2016, 928 . 930 Authors' Addresses 932 Susan Hares 933 Huawei 934 7453 Hickory Hill 935 Saline, MI 48176 936 USA 938 Email: shares@ndzh.com 939 Daniel Migault 940 Ericsson 941 8400 boulevard Decarie 942 Montreal, QC HAP 2N2 943 Canada 945 Email: daniel.migault@ericsson.com 947 Joel Halpern 948 Ericsson 949 US 951 Email: joel.halpern@ericsson.com