idnits 2.17.1 draft-ietf-i2nsf-gap-analysis-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 20, 2016) is 2837 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DAR' is mentioned on line 1364, but not defined == Missing Reference: 'DIM' is mentioned on line 1364, but not defined == Unused Reference: 'RFC0791' is defined on line 1836, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-service-topo' is defined on line 1858, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 1884, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-data-model' is defined on line 1899, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1906, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 1917, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l2-network-topology' is defined on line 1922, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 1927, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-l3sm-l3vpn-service-model' is defined on line 1944, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 2117, but no explicit reference was found in the text == Unused Reference: 'RFC4949' is defined on line 2137, but no explicit reference was found in the text == Unused Reference: 'RFC6436' is defined on line 2176, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2nsf-terminology-00 == Outdated reference: A later version (-01) exists of draft-hu-bess-l2vpn-service-yang-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-11 == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-14 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-protocol-security-requirements-06 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-06 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-09 == Outdated reference: A later version (-03) exists of draft-ietf-i2rs-usecase-reqs-summary-01 == Outdated reference: A later version (-18) exists of draft-ietf-i2rs-yang-l2-network-topology-03 == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-04 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-01 == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-02 == Outdated reference: A later version (-19) exists of draft-ietf-l3sm-l3vpn-service-model-05 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-call-home-06 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-04 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-02 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-02 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-19 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-03 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-00 == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-09 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-08 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-00 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-09 == Outdated reference: A later version (-19) exists of draft-ietf-teas-yang-rsvp-03 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-05 == Outdated reference: A later version (-01) exists of draft-li-bess-l3vpn-yang-00 == Outdated reference: A later version (-10) exists of draft-zheng-mpls-lsp-ping-yang-cfg-03 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 0 errors (**), 0 flaws (~~), 44 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF WG S. Hares 3 Internet-Draft R. Moskowitz 4 Intended status: Informational Huawei 5 Expires: January 21, 2017 D. Zhang 6 July 20, 2016 8 Analysis of Existing work for I2NSF 9 draft-ietf-i2nsf-gap-analysis-02.txt 11 Abstract 13 This document analyzes the current state of the art for security 14 management devices and security devices technologies in industries 15 and the existing IETF work/protocols that are relevant to the 16 Interface to Network Security Function (I2NSF). The I2NSF focus is 17 to define data models and interfaces in order to control and monitor 18 the physical and virtual aspects of network security functions. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 21, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. What is I2NSF . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Structure of this Document . . . . . . . . . . . . . . . 4 57 1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5 58 1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5 59 1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 60 2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9 64 2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 10 65 3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13 67 3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 15 68 4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15 70 4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17 71 5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17 72 5.1. Overview of API for Security Group . . . . . . . . . . . 18 73 5.2. Overview of Firewall as a Service . . . . . . . . . . . . 18 74 5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19 75 6. CSA Secure Cloud . . . . . . . . . . . . . . . . . . . . . . 19 76 6.1. CSA Overview . . . . . . . . . . . . . . . . . . . . . . 19 77 6.1.1. CSA Security as a Service (SaaS) . . . . . . . . . . 20 78 6.1.2. Identity Access Management (IAM) . . . . . . . . . . 21 79 6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22 80 6.1.4. Web Security (Web) . . . . . . . . . . . . . . . . . 23 81 6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24 82 6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25 83 6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26 84 6.1.8. Security Information and Event Management(SIEM) . . . 27 85 6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28 86 6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29 87 6.1.11. Network Security Devices . . . . . . . . . . . . . . 30 88 6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31 89 7. IEEE security . . . . . . . . . . . . . . . . . . . . . . . . 31 90 7.1. Port-based Network Access Control [802.1X] . . . . . . . 31 91 7.2. MAC security (802.1AE) . . . . . . . . . . . . . . . . . 32 92 7.3. Secure Device Identity [802.1AR] . . . . . . . . . . . . 33 93 8. In-depth Review of IETF protocols . . . . . . . . . . . . . . 34 94 8.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 34 95 8.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 35 96 8.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 35 97 8.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 8.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 99 8.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 38 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 102 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 105 12.2. Informative References . . . . . . . . . . . . . . . . . 40 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 108 1. Introduction 110 This documents provides a gap analysis for I2NSF. 112 1.1. What is I2NSF 114 A Network Security Function (NSF) ensures integrity, confidentiality 115 and availability of network communications, detects unwanted 116 activity, and/or blocks out or at least mitigates the effects of 117 unwanted activity. NSFs are provided and consumed in increasingly 118 diverse environments. For example, users of NSFs could consume 119 network security services offered on multiple security products 120 hosted one or more service provider,their own enterprises, or a 121 combination of the two. 123 The lack of standard interfaces to control and monitor the behavior 124 of NSFs makes it virtually impossible for security service providers 125 to automate service offerings that utilize different security 126 functions from multiple vendors. 128 The Interface to Network Service Functions (I2NSF) work proposes to 129 standardize a set of software interfaces to control and monitor the 130 physical and virtual NSFs. Since different security vendors support 131 different features and functions, the I2NSF will focus on the flow- 132 based NSFs that provide treatment to packets or flows such found in 133 IPS/IDS devices, web filtering devices, flow filtering devices, deep 134 packet inspection devices, pattern matching inspection devices, and 135 re-mediation devices. 137 There are two layers of interfaces envisioned in the I2NSF approach: 139 o The I2NSF Capability Layer specifies how to control and monitor 140 NSFs at a functional implementation level. This is the focus for 141 this phase of the I2NSF Work. 143 o The I2NSF Service Layer defines how the security policies of 144 clients may be expressed and monitored. The Service Layer is out 145 of scope for this phase of I2NSF's work. 147 For the I2NSF Capability Layer, the I2NSF work proposes an 148 interoperable protocol that passes NSF provisioning rules and 149 orchestration information between the I2NSF client on a network 150 manager and the I2NSF agent on an NSF. It is envisioned that clients 151 of the I2NSF interfaces include management applications, service 152 orchestration systems, network controllers, or user applications that 153 may solicit network security resources. 155 The I2NSF work to define this protocol includes the following work: 157 o defining an informational model that defines the concepts for 158 standardizing the control and monitoring of NSFs, 160 o defining a set of YANG data models from the information model that 161 identifies the data that must be passed, 163 o creating a capability registry (an IANA registry) that identifies 164 the characteristics and behaviours of NSFs in vendor-neutral 165 vocabulary without requiring the NSFs to be standardized. 167 o examining existing secure communication mechanisms to identify the 168 appropriate ones for carrying the data that provisions and 169 monitors information between the NSFs and their management entity 170 (or entities). 172 1.2. Structure of this Document 174 This document provides an analysis of the gaps in the state of art in 175 the following industry forums: 177 IETF working groups (Section 2) 179 ETSI Network Functions Virtualization Industry Specification Group 180 (ETSI NFV ISG), (Section 3) 182 OPNFV Open Source Group (Section 4) 184 Open Stack - Firewall as a service (OpenStack Firewall FaaS) 185 (Section 5) (http://docs.openstack.org/admin-guide-cloud/content/ 186 install_neutron-fwaas-agent.html) 188 Cloud Security Alliance Security (CSA)as a Service (Section 6) 189 (https://cloudsecurityalliance.org/research/secaas/#_overview) 190 In-Depth Review of Some IETF Protocols (Section 7) 192 1.3. Terms and Definitions 194 1.3.1. Requirements Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in RFC 2119, BCP 14 199 [RFC2119] and indicate requirement levels for compliant CoAP. 201 1.3.2. Definitions 203 The following are a few definitions out of the terminology draft 204 utilized in this draft. For additional definitions please see: 205 [I-D.hares-i2nsf-terminology]. 207 Network Security Function (NSF): is a function that is provided as 208 a set of security-related service function. Typically, an NSF may 209 be responsible for detecting unwanted activity and blocking/ 210 mitigating the effect of such unwanted activity in order to fulfil 211 the service requirements. The NSF can help in supporting 212 communication stream integrity and confidentiality. 214 Cloud Data Center (DC): A data center that may/may not be run on 215 the premises of enterprises, but has compute/storage resources 216 that can be requested or purchased by the enterprises. The 217 enterprise is actually getting a virtual data center. The Cloud 218 Security Alliance (CSA) (http://cloudsecurityalliance.org) focuses 219 on adding security to this environment. A specific research topic 220 is security as a service within the cloud data center. 222 Cloud-based security functions: Network Security Functions (NSFs) 223 that may be hosted and managed by service providers or a different 224 administrative entity. 226 Domain: The term Domain in this draft has the following different 227 connotations in different scenarios: 229 * Client--Provider relationship, i.e. client requesting some 230 network security functions from its provider; 232 * Domain A - Domain B relationship, i.e. one operator domain 233 requesting some network security functions from another 234 operator domain; or 236 * Applications -- Network relationship, i.e. an application (e.g. 237 cluster of servers) requesting some functions from network, 238 etc. 240 The domain context is important because it indicates the 241 interactions the security is focused on. 243 I2NSF server/agent: A software instance that implements a network 244 security function that receives provisioning information and 245 requests operational data (e.g. monitoring data) from an I2NSF 246 client. It is also responsible for enforcing the policies that it 247 receives from an I2NSF client. 249 I2NSF client: A security client software that utilizes the I2NSF 250 protocol to read, write or change the provisioning network 251 security device via software interface using the I2NSF protocol 252 (denoted as I2RS Agent) 254 I2NSF Management System: I2NSF Client operates within an network 255 management system which serves as a collections and distribution 256 point for security provisioning and filter data. 258 2. IETF Gap analysis 260 The IETF gap analysis first examines the IETF mechanisms which have 261 been developed to secure the IP traffic flows through a network. 262 Traffic filters have been defined by IETF specifications at the 263 access points, the middle-boxes, or the routing systems. Protocols 264 have been defined to carry provisioning and filtering traffic between 265 a management system and an IP system (router or host system). 266 Current security work (SACM working group (WG), MILE WG, and DOTS WG) 267 is providing correlation of events monitored with the policy set by 268 filters. This section provides a review the filter work, protocols, 269 and security correlation for monitors. 271 2.1. Traffic Filters 273 2.1.1. Overview 275 The earliest filters defined by IETF were access filters which 276 controlled the acceptance of IP packet data flows. Additional policy 277 filters were created as part of the following protocols: 279 o COPS protocol [RFC2748] for controlling access to networks, 281 o Next Steps in Signalling (NSIS) work (architecture: [RFC4080] 282 protocol: [RFC5973]) - for supporting signaling about a data flow 283 along its path, and 285 o Port Control Protocol (PCP) - allows the IPv4/IPv6 host to control 286 how IPv6/IPv4 packets are translated and forwarded by NATS and 287 firewalls. 289 Today NETMOD and I2RS Working groups are specifying additional 290 filters in YANG modules to be used as part of the NETCONF or I2RS 291 enhancement of NETCONF/RESTCONF. 293 Route filtering is outside the scope of the flow filtering, but the 294 flow filtering may be impacted by route filtering. An initial model 295 for routing policy is in [I-D.ietf-rtgwg-policy-model] 297 This section provides an overview of the flow filtering as an 298 introduction to the I2NSF Gap analysis. Additional detail on 299 NETCONF, NETMOD, I2RS, PCP, and NSIS is available in Section 7. 301 2.1.1.1. Data Flow Filters in NETMOD and I2RS 303 The current work on expanding these filters is focused oncombining a 304 configuration and monitoring protocol with YANG data models. 305 [I-D.ietf-netmod-acl-model] provides a set of access list filters 306 which can permit or deny traffic flow based on headers at the MAC 307 Layer, IP Layer, and Transport Layer. The configuration and 308 monitoring protocols which can pass the filters are: NETCONF protocol 309 [RFC6241], RESTCONF [I-D.ietf-netconf-restconf], and the I2RS 310 protocol. The NETCONF and RESTCONF protocols install these filters 311 into forwarding tables. The I2RS protocol uses the ACLs as part of 312 the filters installed in an ephemeral protocol-independent filter- 313 based RIB [I-D.kini-i2rs-fb-rib-info-model] which controls the flow 314 of traffic on interfaces specifically controlled by the I2RS filter- 315 based FIB. 317 netconf 318 +---------------+ / \ +---------------+ 319 | Device: ACLs |-- / \---|Device: ACLS | 320 | I2RS FB RIB | | I2RS FIB RIB | 321 |routing policy | | routing policy| 322 | | | | 323 ===|===============|=============|===============|= 324 +---------------+ data flow +---------------+ 326 Figure 1 328 The I2RS protocol is a programmatic interface to the routing system. 329 At this time, the I2RS is targeted to be extensions to the NETCONF/ 330 RESTCONF protocols to allow the NETCONF/RESTCONF protocol to support 331 a highly programmatic interface with high bandwidth of data, highly 332 reliable notifications, and ephemeral state (see 334 [I-D.ietf-i2rs-architecture]). See Section 7.2 on I2RS for 335 additional details on I2RS. 337 The vocabulary of the [I-D.ietf-netmod-acl-model] is limited, so 338 additional protocol independent filters has been written for the I2RS 339 Filter-Based RIBs in [I-D.hares-i2rs-pkt-eca-data-model]. 341 One thing important to note is that NETCONF and RESTCONF manage 342 device layer YANG models. However, as Figure 2 shows, there are 343 multiple device level, network-wide level, and application level YANG 344 modules. The access lists defined by the device level forwarding 345 table may be impacted by the routing protocols, the I2RS ephemeral 346 protocol independent Filter-Based FIB, or some network-wide security 347 issue (IPS/IDS). 349 +--------------------------------------------+ 350 |Application Network Wide: Intent | 351 +--------------------------------------------+ 352 |Network-wide level: L3SM L3VPN service model| 353 +--------------------------------------------+ 354 |Device level: Protocol Independent: I2RS | 355 | RIB, Topology, Filter-Based RIB | 356 +--------------------------------------------+ 357 |Device Level:Protocol YANG modules | 358 | (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.) 359 +--------------------------------------------+ 360 | Device level: IP and System: NETMOD Models | 361 | (config and oper-state), tunnels, | 362 | forwarding filters | 363 +--------------------------------------------+ 365 Figure 2 Levels of YANG modules 367 2.1.1.2. I2NSF Gap analysis 369 The gap is that none of the current work on these filters considers 370 all the variations of data necessary to do IPS/IDS, web-filters, 371 stateful flow-based filtering, security-based deep packet inspection, 372 or pattern matching with re-mediation. The I2RS Filter-Based RIB 373 work is the closest associated work, but the focus has not been on 374 IDS/IPS, web-filters, security-based deep packet inspection, or 375 pattern matching with re-mediation. 377 The I2RS Working group (I2RS WG) is focused on the routing system so 378 the requisite security expertise for such NSFs (IDP/IPS, Web-filter, 379 security-based deep-packet inspection, etc.) has not been targeted 380 for this WG. 382 Another gap is there is no capability registry (an IANA registry) 383 that identifies the characteristics and behaviours of NSFs in vendor- 384 neutral vocabulary without requiring the NSFs to be standardized. 386 What I2NSF can use from NETCONF/RESTCONF and I2RS 388 I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS 389 proposed enhancement to the NETCONF/RESTCONF protocol. 391 2.1.2. Middle-box Filters 393 2.1.2.1. Midcom 395 Midcom Summary: MIDCOM developed the protocols for applications to 396 communicate with middle boxes. However, MIDCOM have not been used by 397 the industry for a long time. A main reason is that MIDCOM had a lot 398 of IPR encumbered technology and IPR was likely a bigger problem for 399 IETF at that time than it is today. MIDCOM is not specific to SIP. 400 It was very much oriented to NAT/FW devices. SIP was just one 401 application that needed the functionality. MIDCOM is reservation- 402 oriented and there was an expectation that the primary deployment 403 environment would be VoIP and real-time conferencing, including SIP, 404 H.323, and other reservation-oriented protocols. There was an 405 assumption that there would be some authoritative service that would 406 have a view into endpoint sessions and be able to authorize (or not) 407 resource allocation requests. In other words, there is a trust model 408 in MIDCOM that may not be applicable to endpoint-driven requests 409 without some sort of trusted authorization mechanisms/tools. 410 Therefore, there is a specific information model applied to security 411 devices, and security device requests, that was developed in the 412 context of an SNMP MIB. There is also a two-stage reservation model, 413 which was specified in order to allow better resource management. 415 Why I2NSF is Different from Midcom 417 MIDCOM is different from I2NSF because its SNMP scheme does not work 418 with the virtual network security functions (vNSF) management. 420 MidCom RFCs: 422 [RFC3303] - Midcom architecture 424 [RFC5189] - Midcom Protocol Semantics 426 [RFC3304] - Midcom protocol requirements 428 2.1.3. Security Work 430 2.1.3.1. Overview 432 Today's NSFs in security devices can handle flow-based security by 433 providing treatment to packets/flows, such as IPS/IDS, Web filtering, 434 flow filtering, deep packet inspection, or pattern matching and re- 435 mediation. These flow-based security devices are managed and 436 provisioned by network management systems. 438 No standardized set of interoperable interfaces control and manage 439 the NSFs so that a central management system can be used across 440 security devices from multiple Vendors. I2NSF work plan is to 441 standardize a set of interfaces by which control and management of 442 NSFs may be invoked, operated, and monitored by: 444 Creating an information model that defines concepts required for 445 standardizing the control and monitoring of NSFs, and from the 446 information model create data models. (The information model will 447 be used to get early agreement on key technical points.) 449 Creating a capability registry (at IANA) that enables the 450 characteristics and behavior of NSFs to be specified using a 451 vendor-neutral vocabulary without requiring the NSFs themselves to 452 be standardized. 454 Defining the requirements for an I2NSF protocol to pass this 455 traffic. (Ideally by re-using existing protocols.) 457 The flow-filtering configuration and management must fit into the 458 existing security area's work plan. This section considers how the 459 I2NSF fits into the security area work under way in the SACM 460 (Security Automation and Continuous Monitoring), DOTS (DDoS Open 461 Threat Signalling), and MILE (Management Incident Lightweight 462 Exchange). 464 2.1.3.2. Security Work and Filters 466 In the proposed I2NSF work plan, the I2NSF security network 467 management system controls many NSF nodes via the I2NSF Agent. This 468 control of data flows is similar to the COPS example in Section 7.4. 470 +------------+ 471 | I2NSF | 472 | Client | 473 | | 474 | security | 475 | NMS system | 476 +------------+ 477 +-----+ / \ +-----+ 478 |I2NSF|--/ \---|I2NSF| 479 |Agent| |Agent| 480 | | | | 481 | NSF | | NSF | 482 --| ----|------------|-----|----- 483 +-----+ data flow +-----+ 485 Figure 2 487 The other security protocols work to interact within the network to 488 provide additional information in the following way: 490 o SACM [I-D.ietf-sacm-architecture] describes an architecture which 491 tries to determine if the end-point security policies and the 492 reality (denoted as security posture) align. 493 [I-D.ietf-sacm-terminology] defines posture as the configuration 494 and/or status of hardware or software on an endpoint as it 495 pertains to an organization's security policy. Filters can be 496 considered on the configuration or status pieces that needs to be 497 monitored. 499 o DOTS (DDoS Open Threat Signalling) - is working on coordinating 500 the mitigation of DDoS attacks. A part of DDoS attach mitigation 501 is to provide lists of addresses to be filtered via IP header 502 filters. 504 o MILE (Managed Incident Lightweight Exchange) - is working on 505 creating a standardized format for incident and indicator reports, 506 and creating a protocol to transport this information. The 507 incident information MILE collects may cause changes in data-flow 508 filters on one or more NSFs. 510 2.1.3.3. I2NSF interaction 512 The network management system that the I2NSF client resides on may 513 interact with other clients or agents developed for the work ongoing 514 in the SACM, DOTS, and MILES working groups. This section describes 515 how the addition of I2NSF's ability to control and monitor NSF 516 devices is compatible and synergistic with these existing efforts. 518 +----------+ +------+ 519 +--------+ | security |====| DOTS | 520 |SACNM | | NMS | |client|---+ 521 |consumer| |..........|\ +------+ | 522 +--------+==|SACM *1 | \ | 523 +----|repository| \ | 524 | |..........| +-------+ | 525 | | I2NSF | |MILES | | 526 +------|-+ | client | |client | | 527 |SACM | +----------+ +-----:-+ | 528 |Info. | / \ : | 529 |provider| / \ : | 530 +--------+ / \ : | 531 +-----+ / \ +-----+ : | 532 |I2NSF|--/ \---|I2NSF| : | 533 | | | | : | 534 | | |MILES|.: | 535 | | |Agent| | 536 | | |DOTS | | 537 | | |Agent|-------+ 538 --| ----|----------------|-----|----- 539 +-----+ data flow +-----+ 541 *1 - this is the SACM Controller (CR) with 542 its broker/proxy/repository show as 543 described in the SACM architecture. 545 Figure 3 547 Figure 3 provides a diagram of a system in which the I2NSF, SACM, 548 DOTS and MILE client-agent or consumer-broker-provider are deployed 549 together. The following are possible positive interactions these 550 scenario might have: 552 o An security network management system (NMS) can contain a SACM 553 repository and be connected to SACM information providers and SACM 554 consumers. The I2NSF may provide one of the ways to change the 555 forwarding filters. 557 o The security NMS may also be connected to DOTS DDoS clients 558 managing the information and configuring the rules. The I2NSF may 559 provide one of the ways to change forwarding filters. 561 o The MILE client on a security network management system talking to 562 the MILE agent on the node may react to the incidents by using 563 I2NSF to set filters. DOTS creates black-lists, but does not have 564 a complete set of filters. 566 2.1.3.4. Benefits from the Interaction 568 I2NSF's ability to provide a common interoperable and vendor neutral 569 interface may allow the security NMS to use a single change to change 570 filters. SACM provides an information model to describe end-points, 571 but does not link this directly to filters. 573 DOTS creates black-lists based on source and destination IP address, 574 transport port number, protocol ID, and traffic rate. Like ACLs 575 defined NETMOD, the DOTS black-lists are not sufficient for all 576 filters or control desired by the NSF boxes. 578 The incident data captured by MILE will not have enough filter 579 information to provide NSF devices with general services. The I2NSF 580 will be able to handle the MILE incident data and create alerts or 581 reports for other security systems. 583 3. ETSI NFV 585 3.1. ETSI Overview 587 Network Functions Virtualization (NFV) provides service providers 588 with flexibility, cost effective and agility to offer their services 589 to customers. One such service is the network security function 590 which guards the exterior of a service provider or its customers. 591 However, the exterior network beyond the service provider NSFs or its 592 customer's NSFs is becoming extremely narrow as NSFs are becoming 593 more pervasive in any portion of networks (service providers, 594 customers, or access networks). 596 The flexibility and agility of NFV encourages service providers to 597 provide different products to address business trends in their market 598 to provide better service offerings to their end user. A traditional 599 product such as the network security function (NSF) may be broken 600 into multiple virtual devices each hosted from another vendor. In 601 the past, network security devices may have been sourced from a small 602 set of vendors - but in the NFV version of NSF devices, this reduced 603 set of sources will not provide a competitive edge. Due to this 604 market shift, the network security vendors are realizing that the 605 proprietary provisioning protocols and formats of data may be a 606 liability. Out of the NFV work has arisen a desire for a single 607 interoperable network security device provisioning and control 608 protocol. 610 The I2NSF framework is complementary to the NFV and other security 611 frameworks. The I2NSF management protocol will be deployed in 612 networks to provide a common management protocol to manage NSF 613 software/devices whether the devices are physical or virtual. The 614 ETSI NFV security is also deployed along-side other security 615 functions (AAA, SACM, DOTS, or MILE devices) and deep-packet stateful 616 inspections. 618 The ETSI Network Functions Virtualization: NFV security: Security and 619 Trust Guidance document (ETSI NFV SEC 003 1.1.1 (2014-12)) indicates 620 that multiple administrative domains will deployed in carrier 621 networks. One example of these multiple domains is hosting of 622 multiple tenant domains (telecom service providers) on a single 623 infrastructure domain (infrastructure service) as Figure 4 shows. 624 The ETSI Inter-VNFM document (aka Ve-Vnfn) between the element 625 management system and the Virtual network function is the equivalent 626 of the interface between the I2NSF client on a management system and 627 the I2NSF agent on the network security feature VNF. 629 .................... 630 +--: OSS/BSS : 631 | .................... 632 | 633 | +-------------------------+ 634 | | | 635 | | ........ ........ | 636 | | : EMS1 : : EMS : | ETSI inter-VNFM 637 | | ....||... ...||... | (Ve-Vnfn) 638 | | || || ==========I2NSF interface 639 | | ....||... ...||... | 640 | | : VNF1 : : VNF1 : | Tenant domain 641 | | ....||... ...||... | 642 ''''''''||'''''''''||'''''''''' 643 | | ....||..... ...||...... | infrastructure 644 | | :virtual : :virtual : | domain 645 | | :computing: :computing: | with virtual 646 | | ........... ........... | network 647 | | +=====================+ --------- 648 | | | virtualization layer| | 649 | | +=====================+ | 650 | | ........... .......... .......... | 651 |====:computing: :storage : :network : | 652 | :hardware : :hardware: :hardware: | 653 | ........... .......... .......... | 654 | hardware resources | 655 +-----------------------------------+ 657 Figure 4 659 The ETSI proof-of-concept demonstrations have been done for the 660 security proof of concepts: 662 o #16 - NFVIaaS with Secure, SDN controlled WAN Gateway, 664 3.2. I2NSF Gap Analysis 666 The I2NSF protocol/interface can be deployed for security devices 667 along-side the network/host configuration done by NETCONF/RESTCONF or 668 the routing system interface provided by I2RS that handles. 670 In the current NFV-related architecture, there is no interoperable 671 protocol defined between a security manager and various NSF devices 672 to provision security functions. The result is that service 673 providers have to manage the interoperability security manager and 674 different NSF devices using proprietary protocols. In response to 675 this problem, the device manufacturers and the service providers have 676 begun to discuss an I2NSF protocol for interoperable passing of 677 provisioning and filter in formation. 679 Open source work (such as OPNFV) provides a common code base on which 680 providers may start their NFV development work. However, this code 681 base faces the same problem. There is no defacto standard protocol. 683 4. OPNFV 685 The OPNFV (www.opnfv.org) is a carrier-grade integrated, open source 686 platform focused on accelerating the introduction of new Network 687 Functions Virtualization (NFV) products and service. The OPNFV Moon 688 project is focused on adding the security interface for a network 689 management system within the tenant NFVs and the infrastructure NFVs 690 (as shown in Figure 4). This section provides an overview of the 691 OPNFV Moon project and a gap analysis between I2NSF and the OPNFV 692 Moon Project. 694 4.1. OPNFV Moon Project 696 The OPNFV Moon project (https://wiki.opnfv.org) is a security 697 management system. NFV uses cloud computing technologies to 698 virtualize the resources and automate the control. The Moon project 699 is working on a security manager for the cloud computing 700 infrastructure (https://wiki.opnfv.org/moon). The Moon project 701 proposes to provision a set of different cloud resources/services for 702 VNFs (Virtualized Network Functions) while managing the isolation of 703 VNS, protection of VNFs, and monitoring of VNS. Moon is creating a 704 security management system for OPNFV with security managers to 705 protect different layers of the NFV infrastructure. The Moon project 706 is choosing various security project mechanisms "a la carte" to 707 enforcement related security managers. A security management system 708 integrates mechanisms of different security aspects. This project 709 intends propose a security manager that specifies users' security 710 requirements. It will also enforce the security managers through 711 various mechanisms like authorization for access control, firewall 712 for networking, isolation for storage, logging for tractability, etc. 714 The Moon security manager operates a VNF security manager at the ETSI 715 VeVnfm level where the I2NSF protocol is targeted as Figure 5 shows. 716 This figure also shows how the OPNFV VNF Security project mixes the 717 I2NSF level with the device level. 719 The Moon project lists the following gaps in OpenStack: 721 o No centralized control for compute, storage, and networking. Open 722 Stack uses Nova for compute and Swift for object storage. Each 723 system has a configuration file and its own security policy. The 724 system lacks a synchronization mechanism to build a complete 725 secure configuration for OPNFV. 727 o No dynamic control so that if a user obtains the token, so there 728 is no way to obtain control over the user. 730 o No customization or flexibility to allow integration into 731 different vendors, 733 o No fine grained authorization at user level. Authorization is 734 only at the API level. 736 Moon addresses these issues adding authorization, logging, IDS, 737 enforcement of network policy, and storage protection. Moon release 738 C (2016) plans to: 740 o Define an identity federation scenario between OpenStack and 741 OpenDaylight, 743 o Implement an authentication driver in ODL to delegate 744 authentication to OpenStack/Keystone, 746 o Implement a command line tool for administration and testing, 748 o Implement a graphic interface for identity management for both 749 OpenStack and OpenDaylight, 751 o Set up identity federation testbed, 753 o Define identity federation scenarios with other SDN controllers, 754 and 756 o Define authorization federation scenarios with OpenDaylight. 758 Deliverable time frame: Moon Release 3 (mid-year 2016) 760 .................... 761 +--: OSS/BSS : 762 | .................... 763 | 764 | +-------------------------+ 765 | | | 766 | | ........ ........ | 767 | | : EMS1 : : EMS : | ETSI inter-VNFM 768 | | ....||... ...||... | (Ve-Vnfn) 769 | | || || ==========I2NSF interface 770 | | ....||... ...||... | Moon VNF === Moon VNF 771 | | : : : : | Security Security MGR 772 | | : VNF1 : : VNF1 : | 773 | | ....||... ...||... | Tenant domain 774 ''''''''||'''''''''||'''''''''' 775 | | ....||..... ...||...... | infrastructure 776 | | :virtual : :virtual : | domain 777 | | :computing: :computing: | with virtual 778 | | ........... ........... | network 779 | | +=====================+ |-------- 780 | | | virtualization layer| | 781 | | +=====================+ 782 | | =============Moon VNF ===Moon VI 783 | | security project Security MGR 784 | | ........... .......... .......... | 785 |====:computing: :storage : :network : | 786 | :hardware : :hardware: :hardware: | 787 | ........... .......... .......... | 788 | hardware resources | 789 +-----------------------------------+ 791 Figure 5 793 4.2. Gap Analysis for OPNFV Moon Project 795 OpenStack Congress does not provide vendor independent systems. 797 5. OpenStack Security Firewall 799 OpenStack has advanced features of: a) API for managing security 800 groups (http://docs.openstack.org/admin-guide-cloud/content/ 801 section_securitygroups.html) and b) firewalls as a service 802 (http://docs.openstack.org/admin-guide-cloud/content/ 803 fwaas_api_abstractions.html). 805 This section provides an overview of this open stack work, and a gap 806 analysis of how I2NSF provides additional functions 808 5.1. Overview of API for Security Group 810 The security group rules provide ingress and egress traffic filters 811 based on port. The default rule for the group policy drops all 812 ingress traffic and allows all egress traffic. The group policy 813 allows users to add additional groups with additional filters that 814 change the default behaviour. To utilize the security groups, the 815 networking plug-in for OpenStack must implement the security group 816 API. The following plug-ins in OpenStack currently implement this 817 security: ML2, Open vSwitch, Linux Bridge, NEC, and VMware NSX. In 818 addition, the correct firewall driver must be added to make this 819 functional. 821 5.2. Overview of Firewall as a Service 823 Firewall as a service is an early release of an API that allows early 824 adopters to test network implementations. It contains APIs with 825 parameters for firewall rules, firewall policies, and firewall 826 identifiers. The firewall rules include the following information: 828 o identification of rule (id, name, description) 830 o identification tenant rule associated with, 832 o links to installed firewall policy, 834 o IP protocol (TCP, UDP, ICMP, or none) 836 o source and destination IP address 838 o source and destination port 840 o action: allow or deny traffic 842 o status: position and enable/disabled 844 The firewall policies include the following information: 846 o identification of the policy (id, name, description), 848 o identification of tenant associated with, 850 o ordered list of firewall rules, 852 o indication if policy can be seen by tenants other than owner, and 853 o indication if firewall rules have been audited. 855 The firewall table provides the following information: 857 o identification of firewall (id, name, description), 859 o tenant associated with this firewall, 861 o administrative state (up/down), 863 o status (active, down, pending create, pending delete, pending 864 update, pending error) 866 o firewall policy ID this firewall is associated with 868 5.3. I2NSF Gap analysis 870 The OpenStack work is preliminary (security groups and firewall as a 871 service). This work does not allow any of the existing network 872 security vendors provide a management interface. The OpenStack work 873 provides an interesting simple set of filters, and may in the future 874 provide some virtual filter service. However, at this time this open 875 source work does not address the need for a single management 876 interfaces for a variety of security devices. 878 Phase 1 of I2NSF is proposes rules that will include Event-Condition- 879 Action matches (ECA) rules with: 881 packet based matches on L2, L3, and L4 headers and/or specific 882 addresses within these headers, and 884 context based matches on schedule state and schedule. 886 basic ations of deny, permit, and mirror, 888 advanced actions of: IPS signature filtering and URL filtering. 890 [Editorial note: do we need more matches or actions?] 892 6. CSA Secure Cloud 894 6.1. CSA Overview 896 The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org) 897 defined security as a service (SaaS) in their Security as a Service 898 working group (SaaS WG) during 2010-2012. The CSA SaaS group defined 899 ten categories of network security 900 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 901 SecaaS_V1_0.pdf) and provides implementation guidance for each of 902 these ten categories. This section provides an overview of the CSA 903 SaaS working groups documentation and a gap analysis for I2NSF 905 6.1.1. CSA Security as a Service (SaaS) 907 The CSA SaaS working group defined the following ten categories, and 908 provided implementation guidance on these categories: 910 1. Identity Access Management (IAM) 911 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 912 SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) 914 2. Data Loss Prevention (DLP) 915 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 916 SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) 918 3. Web Security (web) 919 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 920 SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf), 922 4. Email Security (email) 923 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 924 SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf), 926 5. Security Assessments 927 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 928 SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf), 930 6. Intrusion Management 931 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 932 SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf), 934 7. Security information and Event Management 935 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 936 SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf), 938 8. Encryption 939 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 940 SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf), 942 9. Business Continuity and Disaster Recovery (BCDR) 943 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 944 SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and 946 10. Network Security 947 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 948 SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf). 950 The sections below give an overview these implementation guidelines. 952 6.1.2. Identity Access Management (IAM) 954 document: 955 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 956 SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) 958 The identity management systems include the following services: 960 o Centralized Directory Services, 962 o Access Management Services, 964 o Identity Management Services, 966 o Identity Federation Services, 968 o Role-Based Access Control Services, 970 o User Access Certification Services, 972 o Privileged User and Access Management, 974 o Separation of Duties Services, and 976 o Identity and Access Reporting Services. 978 The IAM device communications with the security management system 979 that controls the filtering of data. The CSA SaaS IAM specification 980 states that interoperability between IAM devices and secure access 981 network management systems is a problem. This 2012 implementation 982 report confirms there is a gap with IAM. 984 +------------+ +--------+ 985 | IAM device | ---- SLA ------------| secure | 986 | | Access review | access | 987 | | security events | NMS | 988 | | access tracing | | 989 +---||-------+ Audit report +---||---+ 990 || || 991 || +------------------+ || 992 ========== |Filter enforcement|=====|| 993 +------------------+ 994 Figure 6 996 6.1.3. Data Loss Prevention (DLP) 998 Document: 999 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1000 SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) 1002 The data loss prevention (DLP) services must address: 1004 o origination verification, 1006 o integrity of data, 1008 o confidentiality and access control, 1010 o accountability, 1012 o avoiding false positives on detection, and 1014 o privacy concerns. 1016 The CSA SaaS DLP device communications require that it have the 1017 enforcement capabilities to do the following: 1019 alert and log data loss, 1021 delete data on system or passing through, 1023 filter out (block/quarantine) data, 1025 reroute data, 1027 encrypt data 1029 +------------+ +--------+ 1030 | DLP device | ---- SLA ------------| secure | 1031 | | Alert and log | access | 1032 | | delete data | NMS | 1033 | | filter/reroute | | 1034 +---||-------+ encrypt data +---||---+ 1035 || || 1036 || +------------------+ || 1037 ========== |Filter enforcement|=====|| 1038 +------------------+ 1039 Figure 7 1041 6.1.4. Web Security (Web) 1043 Document: 1044 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1045 SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf 1047 The web security services must address: 1049 o Web 2.0/Social Media controls, 1051 o Malware and Anti-Virus controls, 1053 o Data Loss Prevention controls (over Web-based services like Gmail 1054 or Box.net), 1056 o XSS, JavaScript and other web specific attack controls 1058 o Web URL Filtering, 1060 o Policy control and administrative management, 1062 o Bandwidth management and quality of service (QoS) capability, and 1064 o Monitoring of SSL enabled traffic. 1066 The CSA SaaS Web services device communications require that it have 1067 the enforcement capabilities to do the following: 1069 alert and log malware or anti-virus data patterns, 1071 delete data (malware and virus) passing through systems, 1073 filter out (block/quarantine) data, 1075 filter Web URLs, 1077 interact with policy and network management systems, 1079 control bandwidth and QoS of traffic, and 1081 monitor encrypted (SSL enabled) traffic, 1083 All of these features either require the I2NSF standardized I2NSF 1084 client to I2NSF agent to provide multi-vendor interoperability. 1086 +------------+ +--------+ 1087 |Web security| ---- SLA ------------| secure | 1088 | | Alert and log | access | 1089 | | delete data | NMS | 1090 | | filter/reroute data | | 1091 | | ensure bandwidth/QOS | | 1092 | | monitor encrypted | | 1093 | | data | | 1094 +---||-------+ encrypt data +---||---+ 1095 || || 1096 || +------------------+ || 1097 ========== |Filter enforcement|=====|| 1098 +------------------+ 1099 Figure 8 1101 6.1.5. Email Security (email)) 1103 Document: 1104 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1105 SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf 1107 The CSA Document recommends that email security services must 1108 address: 1110 o Common electronic mail components, 1112 o Electronic mail architecture protection, 1114 o Common electronic mail threats, 1116 o Peer authentication, 1118 o Electronic mail message standards, 1120 o Electronic mail encryption and digital signature, 1122 o Electronic mail content inspection and filtering, 1124 o Securing mail clients, and 1126 o Electronic mail data protection and availability assurance 1127 techniques 1129 The CSA SaaS Email security services requires that it have the 1130 enforcement capabilities to do the following: 1132 provide the malware and spam detection and removal, 1133 alert and provide rapid response to email threats, 1135 identify email users and secure remote access to email, 1137 do on-demand provisioning of email services, 1139 filter out (block/quarantine) email data, 1141 know where the email traffic or data is residing (to to regulatory 1142 issues), and 1144 be able to monitor encrypted email, 1146 be able to encrypt email, 1148 be able to retain email records (while abiding with privacy 1149 concerns), and 1151 interact with policy and network management systems. 1153 All of these features require the I2NSF standardized I2NSF client to 1154 I2NSF agent to provide multi-vendor interoperability. 1156 +------------+ +--------+ 1157 | Email | ---- SLA ------------| secure | 1158 | security | alert/log malware | access | 1159 | | alert/log email spam | NMS | 1160 | | filter/reroute data | | 1161 | | ensure bandwidth/QOS | | 1162 | | monitor encrypted | | 1163 | | data | | 1164 +---||-------+ encrypt data +---||---+ 1165 || || 1166 || +------------------+ || 1167 ========== |Filter enforcement|=====|| 1168 +------------------+ 1169 Figure 9 1171 6.1.6. Security Assessment 1173 Document: 1174 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1175 SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf 1177 The CSA SaaS Security assessment indicates that assessments need to 1178 be done on the following devices: 1180 o hypervisor infrastructure, 1181 o network security compliance systems, 1183 o Servers and workstations, 1185 o applications, 1187 o network vulnerabilities systems, 1189 o internal auditor and intrusion detection/prevention systems (IDS/ 1190 IPS), and 1192 o web application systems. 1194 All of these features require the I2NSF working group standardize the 1195 way to pass these assessments to and from the I2NSF client on the 1196 I2NSF management system and the I2NSF Agent. 1198 6.1.7. Intrusion Detection 1200 Document: 1201 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1202 SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf) 1204 The CSA SaaS Intrusion detection management includes intrusion 1205 detection through: devices: 1207 o Network traffic inspection, behavioural analysis, and flow 1208 analysis, 1210 o Operating System, Virtualization Layer, and Host Process Events 1211 monitoring, 1213 o Monitoring of Application Layer Events, and 1215 o Correlation Techniques, and other Distributed and Cloud-Based 1216 Capabilities 1218 Intrusion response includes both: 1220 o Automatic, Manual, or Hybrid Mechanisms, 1222 o Technical, Operational, and Process Mechanisms. 1224 The CSA SaaS recommends the intrusion security management systems 1225 include provisioning and monitoring of all of these types of 1226 intrusion detection or intrusion protection devices. Management of 1227 these systems requires: 1229 Central reporting of events and alerts, 1231 Administrator notification of intrusions, 1233 Mapping of alerts to Cloud-Layer Tenancy, 1235 Cloud sourcing information to prevent false positives in 1236 detection, and 1238 Allowing for redirection of traffic to allow remote storage or 1239 transmission to prevent local evasion. 1241 In order to be able performing these management actions on NSF 1242 devices from different vendors, the intrusion security management 1243 systems need a standard mangement protocol that all the NSF vendors 1244 support. 1246 +------------+ +--------+ 1247 | IDS/IPS | ---- Info ----------| secure | 1248 | security | alert/log intrusion | access | 1249 | | notify administrator | NMS | 1250 | | Map alerts to Tenant | | 1251 | |filter/reroute traffic| | 1252 | | remote data storage | | 1253 +---||-------+ +---||---+ 1254 || || 1255 || +------------------+ || 1256 ========== |Filter enforcement|=====|| 1257 +------------------+ 1258 Figure 10 1260 The I2NSF manager - I2NSF (server/agent) protocol is designed to fill 1261 this gap. 1263 6.1.8. Security Information and Event Management(SIEM) 1265 Document: 1266 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1267 SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf) 1269 The Security Information and Event Management (SIEM) receives data 1270 from a wide range of security systems such as Identity management 1271 systems (IAM), data loss prevention (DLP), web security (Web), email 1272 security (email), intrusion detection/prevision (IDS/IPS)), 1273 encryption, disaster recovery, and network security. The SIEM 1274 combines this data into a single streams. All the requirements for 1275 data to/from these systems are replicated in these systems needs to 1276 give a report to the SIEM system. 1278 A SIEM system would be a prime candidate to have an I2NSF client that 1279 gathers data from an I2NSF Agent associated with these various types 1280 of security systems. The CSA SaaS SIEM functionality document 1281 suggests that one concern is to have standards that allow timely 1282 recording and sharing of data. I2NSF can provide this. 1284 6.1.9. Encryption 1286 Document: 1287 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1288 SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf 1290 The CSA SaaS encryption implementation guidance document considers 1291 how one implements and manages the following security systems: 1293 Key management systems (KMS), control of keys, and key life cycle; 1295 Shared Secret encryption (Symmetric ciphers), 1297 No-Secret or Public Key Encryption (asymmetric ciphers), 1299 Hashing algorithms, 1301 Digital Signature Algorithms, 1303 Key Establishment Schemes, 1305 Protection of Cryptographic Key Material (FIPS 140-2; 140-3), 1307 Interoperability of Encryption Systems, Key Conferencing, Key 1308 Escrow Systems, and others 1310 Application of Encryption for Data at rest, data in transit, and 1311 data in use; 1313 PKI (including certificate revocation "CRL"); 1315 Future application of such technologies as Homomorphic encryption, 1316 Quantum Cryptography, Identity-based Encryption, and others; 1318 Crypto-system Integrity (How bad implementations can under mind a 1319 crypto-system), and 1321 Cryptographic Security Standards and Guidelines 1323 Encryption services typically require that security management 1324 systems be able to provision, monitor, and control the systems that 1325 are being used to encrypt data. This document indicates in the 1326 implementation sections that the standardization of interfaces to/ 1327 from management systems are key to good key management systems, 1328 encryption systems, and crypto-systems. 1330 6.1.10. Business Continuity and Disaster Recovery (BC/DR) 1332 Document: 1333 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1334 SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf 1336 The CSA SaaS Business Continuity and Disaster Recovery (BC/DR) 1337 implementation guidance document considers the systems that implement 1338 the contingency plans and measures designed and implemented to ensure 1339 operational resiliency in the event of any service interruptions. 1340 BC/DR systems includes: 1342 Business Continuity and Disaster Recovery BC/DR as a Service, 1343 including categories such as complete Disaster Recovery as a 1344 Service (DRaaS), and subsets such as file recovery, backup and 1345 archive, 1347 Storage as a Service including object, volume, or block storage; 1349 Cold Site, Warm Site, Hot Site backup plans; 1351 IaaS (Infrastructure as a Service), PaaS (Platform as a Service), 1352 and SaaS (Software as a Service); 1354 Insurance (and insurance reporting programs) 1356 Business Partner Agents (business associate agreements); 1358 System Replication (for high availability); 1360 Fail-back to Live Systems mechanisms and management; 1362 Recovery Time Objective (RTO) and Recovery Point Objective (RPO); 1364 Encryption (data at rest [DAR], data in motion [DIM], field 1365 level); 1367 Realm-based Access Control; 1369 Service-level Agreements (SLA); and 1371 ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370 1373 These BC/DR systems must handle data backup and recovery, server 1374 backup/recovery, and data center (virtual/physical) backup and 1375 recovery. Recovery as a Service (RaaS) means that the BC/DR services 1376 are being handled by management systems outside the enterprise. 1378 BC/DR requires security management systems to be able to communicate 1379 provisioning, monitor, and control those systems that are being used 1380 to back-up and restore data. An interoperable protocol that allows 1381 provision and control of data center's data, servers, and data center 1382 management devices devices is extremely important to this 1383 application. Recovery as a Service (SaaS) indicates that these 1384 services need to be able to be remotely management. 1386 The CSA SaaS BC/BR documents indicate how important a standardized 1387 I2NSF protocol is. 1389 6.1.11. Network Security Devices 1391 Document: 1392 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1393 SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf 1395 The CSA SaaS Network Security implementation recommendation includes 1396 advice on: 1398 How to segment networks, 1400 Network security controls, 1402 Controlling ingress and egress controls such as Firewalls 1403 (Stateful), Content Inspection and Control (Network-based), 1404 Intrusion Detection System/Intrusion Prevention Systems (IDS/IPS), 1405 and Web Application Firewalls, 1407 Secure routing and time, 1409 Denial of Service (DoS) and Distributed Denial of Service (DDoS) 1410 Protection/Mitigation, 1412 Virtual Private Network (VPN) with Multiprotocol Label Switching 1413 (MPLS) Connectivity (over SSL), Internet Protocol Security (IPsec) 1414 VPNs, Virtual Private LAN Service (VPLS), and Ethernet Virtual 1415 Private Line (EVPL), 1417 Threat Management, 1419 Forensic Support, and 1420 Privileged User/Use Monitoring. 1422 These network security systems require provisioning, monitoring, and 1423 the ability for the security management system to subscribe to 1424 receive logs, snapshots of capture data, and time synchronization. 1425 This document states the following: 1427 "It is critical to understand what monitoring APIs are available 1428 from the CSP, and if they match risk and compliance requirements", 1430 "Network security auditors are challenged by the need to track a 1431 server and its identity from creation to deletion. Audit tracking 1432 is challenging in even the most mature cloud environments, but the 1433 challenges are greatly complicated by cloud server sprawl, the 1434 situation where the number of cloud servers being created is 1435 growing more quickly than a cloud environments ability to manage 1436 them." 1438 A valid threat vector for cloud is the API access. Since a 1439 majority of CSPs today support public API interfaces available 1440 within their networks and likely over the Internet." 1442 The CSA SaaS network security indicates that the I2NSF must be secure 1443 so that the I2NSF Client-Agent protocol does not become a valid 1444 threat vector. In additions, the need for the management protocol 1445 like I2NSF is critical in the sprawl of Cloud environment. 1447 6.2. I2NSF Gap Analysis 1449 The CSA Security as a Service (SaaS) document show clearly that there 1450 is a gap between the ability of the CSA SaaS devices to have a vendor 1451 neutral, inoperable protocol that allow the multiple of network 1452 security devices to communicate passing provisioning and 1453 informational data. Each of the 10 implementation agreements points 1454 to this as a shortcoming. Standard I2NSF YANG models and an I2NSF 1455 protocol are needed according to the CSA SaaS documents. 1457 7. IEEE security 1459 7.1. Port-based Network Access Control [802.1X] 1461 802.1x defines encapsulation of Extensible Authentication Protocol 1462 (EAP) [RFC3748] over IEEE 802 (EAP over LAN, or EAPOL). It is widely 1463 deployed on both wired and Wi-Fi Networks. 1465 EAP provides support for security from passwords to challenge- 1466 response tokens and public-key infrastructure certificates. 1468 802.1 has three concepts: 1470 o the supplicant - the user or client who wants to be authenticated 1472 o authentication server - the server doing the authrentication (e.g. 1473 radius server), and 1475 o the authenticator - the device in-between authentication server 1476 and supplicant (e.g. wireless Access Point (AP). 1478 A normal sequence is below: 1480 supplicant authenticator authentication server 1481 =========== =================== ======================== 1482 <---- EAP-Request/Identity 1484 EAP-Response/Identity----> 1485 EAP-Response/Identity---gt; 1486 <---------Challenge 1487 <------Challenge 1489 Challenge 1490 response ---------> 1491 Challenge 1492 Response ---------> 1494 Gap: 1496 This basic service provides access, but today's access use cases are 1497 more complex. IEEE 801.X has ben attched using the Man-in-the-middle 1498 attacks. Another weakness of 802.1X is the speed of the EAP 1499 protocols processing with the radius server. 1501 Note: Editor - more is needed here 1503 7.2. MAC security (802.1AE) 1505 MACsec security secures a link rather than a conversation for 802.1 1506 LANs (VLANs 802.1Q, Provider Bridges 802.1AD). MACsec counters the 1507 802.1X man-in the middle attacks. 1509 MACsec (in 802.1AE) provides MAC-layer encryption over wired networks 1510 by using out-of-band methods for encryption keying. The MACsec Key 1511 Agreement (MKA) Protocol provides the required session keys and 1512 manages the required encryption keys. MKA and MACsec are implemented 1513 after successful authentication using the 802.1x Extensible 1514 Authentication Protocol (EAP) framework. Only hosts link which face 1515 the network can be secured with MACSec. These links connect the host 1516 to the network access devices. 1518 Switch using MACsec accepts either MACsec or non-MACsec frames based 1519 on policy set. The NSF controller can set within the switches 1520 configuration whether MACSec frames are accepted. Accepted MACsec 1521 frames are encrypted and protected with an integrity check value 1522 (ICV). The switch after receiving frames from the client, decrypts 1523 them and calculates the correct ICV by using session keys provided by 1524 MKA. The switch compares that ICV to the ICV within the frame. If 1525 they are not identical, the frame is dropped. The switch also 1526 encrypts and adds an ICV to any frames sent over the secured port 1527 (the access point used to provide the secure MAC service to a client) 1528 using the current session key. 1530 The MKA Protocol manages the encryption keys used by the underlying 1531 MACsec protocol. The basic requirements of MKA are defined in 1532 802.1x-REV. The MKA Protocol extends 802.1x to allow peer discovery 1533 with confirmation of mutual authentication and sharing of MACsec 1534 secret keys to protect data exchanged by the peers. MKA protocol ues 1535 EAP-over-LAN (EAPOL) packet. EAP authentication produces a master 1536 session key (MSK) shared by both partners in the data exchange. 1537 Entering the EAP session ID generates a secure connectivity 1538 association key name (CKN). Because the switch is the authenticator, 1539 and the key serer, it can generating a random 128-bit secure 1540 association key (SAK), which it sends it to the client partner. The 1541 client is never a key server and can only interact with a single MKA 1542 entity, the key server. After key derivation and generati 1544 Gap Analysis: 1546 I2NSF Devices must handle the existence of MSEC within the network. 1548 7.3. Secure Device Identity [802.1AR] 1550 802.1AR does the following: 1552 Supports trail of trust from manufacturer to user, and 1554 Defines how a Secure Device Identifier (DevId) may be 1555 cryptographically bound to a device to support device identity 1556 authentication. 1558 DevIDs are composed of a secure device identifier secret and a 1559 secure device identifier credential. These IDs can be controlled 1560 by the product manufacturer (IDevID, an initially installed 1561 identity) or by the end-user (LDevID, a subsequent locally 1562 significant identity derived from the IDevID). DevIDs cannot be 1563 be changed by the end-user. 1565 One attack mitigation can be to disable support for DeVIDs or 1566 limit to know DeVIDs. 1568 GAP analysis: 1570 I2NSF controllers need to support 802.1AR device management. 1572 8. In-depth Review of IETF protocols 1574 8.1. NETCONF and RESTCONF 1576 The IETF NETCONF working group has developed the basics of the 1577 NETCONF protocol focusing on secure configuration and querying 1578 operational state. The NETCONF protocol [RFC6241] may be run over 1579 TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults 1580 [RFC6243], handling events ([RFC5277] and basic notification 1581 [RFC6470], and filtering writes/reads based on network access control 1582 models (NACM, [RFC6536]). The NETCONF configuration must be 1583 committed to a configuration data store (denoted as config=TRUE). 1584 YANG models identify nodes within a configuration data store or an 1585 operational data store using a XPath expression (document root ---to 1586 --- target source). NETCONF uses an RPC model and provides protocol 1587 for handling configs (get-config, edit-config, copy-config, delete- 1588 config, lock, unlock, get) and sessions (close-session, kill- 1589 session). The NETCONF Working Group has developed RESTCONF, which is 1590 an HTTP-based protocol that provides a programmatic interface for 1591 accessing data defined in YANG, using the data stores defined in 1592 NETCONF. 1594 RESTCONF supports "two edit condition detections" - time stamp and 1595 entity tag. RESTCONF uses URI encoded path expressions. RESTCONF 1596 provides operations to get remote servers options (OPTIONS), retrieve 1597 data headers (HEAD), get data (GET), create resource/invoke operation 1598 (POST), patch data (PATCH), delete resource (DELETE), or query. 1600 RFCs for NETCONF 1602 o NETCONF [RFC6242] 1604 o NETCONF monitoring [RFC6022] 1606 o NETCONF over SSH [RFC6242] 1608 o NETCONF over TLS [RFC5539] 1609 o NETCONF system notification> [RFC6470] 1611 o NETCONF access-control (NACM) [RFC6536] 1613 o RESTCONF [I-D.ietf-netconf-restconf] 1615 o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home] 1617 o RESTCONF collection protocol 1618 [I-D.ietf-netconf-restconf-collection] 1620 o NETCONF Zero Touch Provisioning [I-D.ietf-netconf-zerotouch] 1622 8.2. I2RS Protocol 1624 Based on input from the NETCONF working group, the I2RS working group 1625 decided to re-use the NETCONF or RESTCONF protocols and specify 1626 additions to these protocols rather than create yet another protocol 1627 (YAP). 1629 The required extensions for the I2RS protocol are in the following 1630 drafts: 1632 o [I-D.ietf-i2rs-ephemeral-state], 1634 o [I-D.ietf-i2rs-pub-sub-requirements] (Publication-Subscription 1635 notifications, 1637 o [I-D.ietf-i2rs-traceability] 1639 o [I-D.ietf-i2rs-protocol-security-requirements] 1641 At this time, NETCONF and RESTCONF cannot handle the ephemeral data 1642 store proposed by I2RS, the publication and subscription 1643 requirements, the traceability, or the security requirements for the 1644 transport protocol and message integrity. 1646 8.3. NETMOD YANG modules 1648 NETMOD developed initial YANG models for interfaces [RFC7223]), IP 1649 address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP 1650 Systems ([RFC7317]) with system ID, system time management, DNS 1651 resolver, Radius client, SSH, syslog 1652 ([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]), 1653 and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing 1654 working group (rtgwg) has begun to examine policy for routing and 1655 tunnels. 1657 Protocol specific Working groups have developed YANG models for ISIS 1658 ([I-D.ietf-isis-yang-isis-cfg]), OSPF ([I-D.ietf-ospf-yang]), and BGP 1659 ([I-D.ietf-idr-bgp-model]. 1661 BGP Services YANG models have been proposed for 1663 o EVPN [I-D.brissette-bess-evpn-yang], 1665 o L2VPN [I-D.shah-bess-l2vpn-yang], 1667 o L3VPN [I-D.li-bess-l3vpn-yang] and 1668 [I-D.hu-bess-l2vpn-service-yang], 1670 TEAS working group has proposed [I-D.ietf-teas-yang-te-topo], and 1671 [I-D.ietf-teas-yang-rsvp]. 1673 MPLS/PCE/CCAMP groups have proposed the following Yang modules: 1675 o [I-D.raza-mpls-ldp-mldp-yang] 1677 o [I-D.saad-mpls-static-yang], 1679 o [I-D.zheng-mpls-lsp-ping-yang-cfg], 1681 o [I-D.pkd-pce-pcep-yang], and 1683 o [I-D.zhang-ccamp-transport-ctrlnorth-yang]. 1685 8.4. COPS 1687 One early focus on flow filtering based on policy enforcement of 1688 traffic entering a network is the 1990s COPS [RFC2748] design (PEP 1689 and PDP) as shown in Figure 11. The COPS policy decision points 1690 (PDP) managed network-wide policy (e.g. ACLs) by installing this 1691 policy in policy enforcement points (PEPs) on the edge of the 1692 network. These PEPs had firewall-like functions that control what 1693 data flows into the network at a PEP point, and data flow out of a 1694 network at a PEP. [RFC3084] describes COPS usages for policy 1695 provisioning. 1697 PDP 1698 +-----+ / \ +-----+ 1699 |PEP1 |--/ \---|PEP2 | 1700 | | ACL/policy | | 1701 | | | | 1702 --| ----|------------|-----|----- 1703 +-----+ data flow +-----+ 1705 Figure 11 1707 Why COPS is no longer used 1709 Network security today uses specific devices (IDS/IPS, NAT firewall, 1710 etc.) with specific policies and profiles for each types of device. 1711 No common protocol or policy format exists between the policy manager 1712 (PDP) and security enforcement points. 1714 COPs RFCs: [RFC4261], [RFC2940], [RFC3084], and [RFC3483]. 1716 Why I2NSF is Different from COPS 1718 COPS was a protocol for policy related to Quality of Service (QoS) 1719 and signaling protocols (e.g. RSVP) (security, flow, and others). 1720 I2NSF creates a common protocol between security policy decision 1721 points (SPDP) and security enforcement points (SEP). Today's 1722 security devices currently only use proprietary protocols. 1723 Manufacturers would like a security specific policy enforcement 1724 protocol rather than a generic policy protocol. 1726 8.5. PCP 1728 As indicated by the name, the Port Control Protocol (PCP) enables an 1729 IPv4 or IPv6 host to flexibly manage the IP address and port mapping 1730 information on Network Address Translators (NATs) or firewalls, to 1731 facilitate communication with remote hosts. 1733 PCP RFCs: 1735 [RFC6887] 1737 [RFC7225] 1739 [I-D.ietf-pcp-authentication] 1741 [I-D.ietf-pcp-optimize-keepalives] 1743 [I-D.ietf-pcp-proxy] 1745 Why is I2NSF Different from PCP: 1747 Here are some aspects that I2NSF is different from PCP: 1749 o PCP only supports management of port and address information 1750 rather than any other security functions 1752 8.6. NSIS - Next Steps in Signaling 1754 NSIS aims to standardize an IP signaling protocol (RSVP) along the 1755 data path for end points to request their unique QoS characteristics, 1756 unique FW policies or NAT needs (RFC5973) that are different from the 1757 FW/NAT original settings. The requests are communicated directly to 1758 the FW/NAT devices. NSIS is like east-west protocols that require 1759 all involved devices to fully comply to make it work. 1761 NSIS is path-coupled; it is possible to message every participating 1762 device along a path without having to know its location, or its 1763 location relative to other devices (This is particularly a pressing 1764 issue when one or more NATs present in the network, or when trying to 1765 locate appropriate tunnel endpoints). 1767 clients----I2NSF controller 1768 | client 1769 | 1770 | I2NSF 1771 | server/agent 1772 +--------+ +--------+ +--------+ 1773 | host | |firewall| | host | 1774 |device-1|-------|device-2|-------|device-3| 1775 +--------+ RSVP +--------+ RSVP +--------+ 1776 -----NSIS----------------------- 1778 Why I2NSF is Different from NSIS: 1780 o The I2NSF request does not require all network functions in a path 1781 to comply, but it is a protocol between the I2NSF client and the 1782 I2NSF Agent/Server 1784 o I2NSF defines client (applications) oriented descriptors 1785 (profiles, or attributes) to request/negotiate/validate the 1786 network security functions that are not on the local premises. 1788 Why I2NSF may have higher chance to be deployed than NSIS: 1790 o OpenStack already has a proof-of-concept/preliminary 1791 implementation, but the specification is not complete. IETF can 1792 play an active role to make the specification for I2NSF is 1793 complete. IETF can complete and extend the OpenStack 1794 implementation to provide an interoperable specification that can 1795 meet the needs and requirements of operators and is workable for 1796 suppliers of the technology. The combination of a carefully 1797 designed interoperable IETF specification with an open-source code 1798 development OpenStack will leverage the strengths of the two 1799 communities, and expand the informal ties between the two groups. 1800 A software development cycle has the following components: 1801 architecture, design specification, coding, and interoperability 1802 testing. The IETF can take ownership of the first two steps, and 1803 provide expertise and a good working atmosphere (in hack-a-thons) 1804 in the last two steps for OpenStack or other open-source coders. 1806 o IETF has the expertise in security architecture and design for 1807 interoperable protocols that span controllers/routers, middle- 1808 boxes, and security end-systems. 1810 o IETF has a history of working on interoperable protocols or 1811 virtualized network functions (L2VPN, L3VPN) that are deployed by 1812 operators in large scale devices. IETF has a strong momentum to 1813 create virtualized network functions (see SFC WG in routing) to be 1814 deployed in network boxes. [Note: We need to add SACM and others 1815 here]. 1817 9. IANA Considerations 1819 No IANA considerations exist for this document. 1821 10. Security Considerations 1823 No security considerations are involved with a gap analysis. 1825 11. Contributors 1827 The following people have contributed to this document: Hosnieh 1828 Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive 1829 comments, great suggestions, and valuable insights on alternative 1830 views. 1832 12. References 1834 12.1. Normative References 1836 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1837 DOI 10.17487/RFC0791, September 1981, 1838 . 1840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1841 Requirement Levels", BCP 14, RFC 2119, 1842 DOI 10.17487/RFC2119, March 1997, 1843 . 1845 12.2. Informative References 1847 [I-D.brissette-bess-evpn-yang] 1848 Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh, 1849 T., and I. Hussain, "Yang Data Model for EVPN", draft- 1850 brissette-bess-evpn-yang-01 (work in progress), December 1851 2015. 1853 [I-D.hares-i2nsf-terminology] 1854 Hares, S., Strassner, J., Lopez, D., and L. Xia, "I2NSF 1855 Terminology", draft-hares-i2nsf-terminology-00 (work in 1856 progress), March 2016. 1858 [I-D.hares-i2rs-info-model-service-topo] 1859 Hares, S., Wu, W., Wang, Z., and J. You, "An Information 1860 model for service topology", draft-hares-i2rs-info-model- 1861 service-topo-03 (work in progress), January 2015. 1863 [I-D.hares-i2rs-pkt-eca-data-model] 1864 Hares, S., Wu, Q., and R. White, "Filter-Based Packet 1865 Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data- 1866 model-02 (work in progress), February 2016. 1868 [I-D.hu-bess-l2vpn-service-yang] 1869 hu, f., Chen, R., and J. Yao, "L2VPN Service YANG Model", 1870 draft-hu-bess-l2vpn-service-yang-00 (work in progress), 1871 March 2016. 1873 [I-D.ietf-i2rs-architecture] 1874 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1875 Nadeau, "An Architecture for the Interface to the Routing 1876 System", draft-ietf-i2rs-architecture-11 (work in 1877 progress), December 2015. 1879 [I-D.ietf-i2rs-ephemeral-state] 1880 Haas, J. and S. Hares, "I2RS Ephemeral State 1881 Requirements", draft-ietf-i2rs-ephemeral-state-14 (work in 1882 progress), July 2016. 1884 [I-D.ietf-i2rs-problem-statement] 1885 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1886 Routing System Problem Statement", draft-ietf-i2rs- 1887 problem-statement-11 (work in progress), May 2016. 1889 [I-D.ietf-i2rs-protocol-security-requirements] 1890 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1891 Related Requirements", draft-ietf-i2rs-protocol-security- 1892 requirements-06 (work in progress), May 2016. 1894 [I-D.ietf-i2rs-pub-sub-requirements] 1895 Voit, E., Clemm, A., and A. Prieto, "Requirements for 1896 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 1897 requirements-09 (work in progress), May 2016. 1899 [I-D.ietf-i2rs-rib-data-model] 1900 Wang, L., Ananthakrishnan, H., Chen, M., 1901 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1902 YANG Data Model for Routing Information Base (RIB)", 1903 draft-ietf-i2rs-rib-data-model-06 (work in progress), July 1904 2016. 1906 [I-D.ietf-i2rs-rib-info-model] 1907 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1908 Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work 1909 in progress), July 2016. 1911 [I-D.ietf-i2rs-traceability] 1912 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1913 the Routing System (I2RS) Traceability: Framework and 1914 Information Model", draft-ietf-i2rs-traceability-11 (work 1915 in progress), May 2016. 1917 [I-D.ietf-i2rs-usecase-reqs-summary] 1918 Hares, S. and M. Chen, "Summary of I2RS Use Case 1919 Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 1920 (work in progress), May 2015. 1922 [I-D.ietf-i2rs-yang-l2-network-topology] 1923 Dong, J. and X. Wei, "A YANG Data Model for Layer-2 1924 Network Topologies", draft-ietf-i2rs-yang-l2-network- 1925 topology-03 (work in progress), July 2016. 1927 [I-D.ietf-i2rs-yang-network-topo] 1928 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 1929 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1930 Topologies", draft-ietf-i2rs-yang-network-topo-04 (work in 1931 progress), July 2016. 1933 [I-D.ietf-idr-bgp-model] 1934 Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., 1935 Bansal, D., Clemm, A., Zhdankin, A., Jethanandani, M., and 1936 X. Liu, "BGP Model for Service Provider Networks", draft- 1937 ietf-idr-bgp-model-01 (work in progress), January 2016. 1939 [I-D.ietf-isis-yang-isis-cfg] 1940 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 1941 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 1942 isis-yang-isis-cfg-02 (work in progress), March 2015. 1944 [I-D.ietf-l3sm-l3vpn-service-model] 1945 Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K. 1946 D'Souza, "YANG Data Model for L3VPN service delivery", 1947 draft-ietf-l3sm-l3vpn-service-model-05 (work in progress), 1948 March 2016. 1950 [I-D.ietf-netconf-call-home] 1951 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1952 draft-ietf-netconf-call-home-06 (work in progress), May 1953 2015. 1955 [I-D.ietf-netconf-restconf] 1956 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1957 Protocol", draft-ietf-netconf-restconf-04 (work in 1958 progress), January 2015. 1960 [I-D.ietf-netconf-restconf-collection] 1961 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1962 Collection Resource", draft-ietf-netconf-restconf- 1963 collection-00 (work in progress), January 2015. 1965 [I-D.ietf-netconf-zerotouch] 1966 Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch 1967 Provisioning for NETCONF Call Home (ZeroTouch)", draft- 1968 ietf-netconf-zerotouch-02 (work in progress), March 2015. 1970 [I-D.ietf-netmod-acl-model] 1971 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 1972 "Network Access Control List (ACL) YANG Data Model", 1973 draft-ietf-netmod-acl-model-02 (work in progress), March 1974 2015. 1976 [I-D.ietf-netmod-routing-cfg] 1977 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1978 Management", draft-ietf-netmod-routing-cfg-19 (work in 1979 progress), May 2015. 1981 [I-D.ietf-netmod-syslog-model] 1982 Wildes, C. and K. Sreenivasa, "SYSLOG YANG model", draft- 1983 ietf-netmod-syslog-model-03 (work in progress), March 1984 2015. 1986 [I-D.ietf-ospf-yang] 1987 Yeung, D., Qu, Y., Zhang, J., Bogdanovic, D., and K. 1988 Sreenivasa, "Yang Data Model for OSPF Protocol", draft- 1989 ietf-ospf-yang-00 (work in progress), March 2015. 1991 [I-D.ietf-pcp-authentication] 1992 Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port 1993 Control Protocol (PCP) Authentication Mechanism", draft- 1994 ietf-pcp-authentication-09 (work in progress), May 2015. 1996 [I-D.ietf-pcp-optimize-keepalives] 1997 Reddy, T., Patil, P., Isomaki, M., and D. Wing, 1998 "Optimizing NAT and Firewall Keepalives Using Port Control 1999 Protocol (PCP)", draft-ietf-pcp-optimize-keepalives-06 2000 (work in progress), May 2015. 2002 [I-D.ietf-pcp-proxy] 2003 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 2004 Cheshire, "Port Control Protocol (PCP) Proxy Function", 2005 draft-ietf-pcp-proxy-08 (work in progress), May 2015. 2007 [I-D.ietf-rtgwg-policy-model] 2008 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 2009 "Routing Policy Configuration Model for Service Provider 2010 Networks", draft-ietf-rtgwg-policy-model-00 (work in 2011 progress), September 2015. 2013 [I-D.ietf-sacm-architecture] 2014 Cam-Winget, N., Lorenzin, L., McDonald, I., and l. 2015 loxx@cisco.com, "Secure Automation and Continuous 2016 Monitoring (SACM) Architecture", draft-ietf-sacm- 2017 architecture-05 (work in progress), October 2015. 2019 [I-D.ietf-sacm-terminology] 2020 Birkholz, H., Lu, J., and N. Cam-Winget, "Secure 2021 Automation and Continuous Monitoring (SACM) Terminology", 2022 draft-ietf-sacm-terminology-09 (work in progress), March 2023 2016. 2025 [I-D.ietf-teas-yang-rsvp] 2026 Beeram, V., Saad, T., Gandhi, R., Liu, X., Shah, H., Chen, 2027 X., Jones, R., and B. Wen, "A YANG Data Model for Resource 2028 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp-03 2029 (work in progress), March 2016. 2031 [I-D.ietf-teas-yang-te-topo] 2032 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2033 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 2034 teas-yang-te-topo-05 (work in progress), July 2016. 2036 [I-D.kini-i2rs-fb-rib-info-model] 2037 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 2038 R., Bogdanovic, D., and R. White, "Filter-Based RIB 2039 Information Model", draft-kini-i2rs-fb-rib-info-model-03 2040 (work in progress), February 2016. 2042 [I-D.li-bess-l3vpn-yang] 2043 Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. 2044 Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess- 2045 l3vpn-yang-00 (work in progress), October 2015. 2047 [I-D.pkd-pce-pcep-yang] 2048 Dhody, D., Hardwick, J., Beeram, V., and j. 2049 jefftant@gmail.com, "A YANG Data Model for Path 2050 Computation Element Communications Protocol (PCEP)", 2051 draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. 2053 [I-D.raza-mpls-ldp-mldp-yang] 2054 Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H. 2055 Shah, "YANG Data Model for MPLS LDP and mLDP", draft-raza- 2056 mpls-ldp-mldp-yang-04 (work in progress), July 2016. 2058 [I-D.saad-mpls-static-yang] 2059 Saad, T., Raza, K., Gandhi, R., Liu, X., Beeram, V., Shah, 2060 H., Bryskin, I., Chen, X., Jones, R., and B. Wen, "A YANG 2061 Data Model for MPLS Static LSPs", draft-saad-mpls-static- 2062 yang-03 (work in progress), May 2016. 2064 [I-D.shah-bess-l2vpn-yang] 2065 Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z., 2066 Zhuang, S., Wang, H., Chen, I., Ahmed, S., Bocci, M., 2067 Hardwick, J., Esale, S., Tiruveedhula, K., 2068 tsingh@juniper.net, t., Hussain, I., Wen, B., Walker, J., 2069 Delregno, N., Jalil, L., and M. Joecylyn, "YANG Data Model 2070 for MPLS-based L2VPN", draft-shah-bess-l2vpn-yang-01 (work 2071 in progress), March 2016. 2073 [I-D.zhang-ccamp-transport-ctrlnorth-yang] 2074 Zhang, X., Jing, R., Jian, W., Ryoo, J., Xu, Y., and D. 2075 King, "YANG Models for the Northbound Interface of a 2076 Transport Network Controller: Requirements, Functions, and 2077 a List of YANG Models", draft-zhang-ccamp-transport- 2078 ctrlnorth-yang-00 (work in progress), March 2016. 2080 [I-D.zheng-mpls-lsp-ping-yang-cfg] 2081 Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. 2082 Rahman, "Yang Data Model for LSP-PING", draft-zheng-mpls- 2083 lsp-ping-yang-cfg-03 (work in progress), March 2016. 2085 [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, 2086 R., and A. Sastry, "The COPS (Common Open Policy Service) 2087 Protocol", RFC 2748, DOI 10.17487/RFC2748, January 2000, 2088 . 2090 [RFC2940] Smith, A., Partain, D., and J. Seligson, "Definitions of 2091 Managed Objects for Common Open Policy Service (COPS) 2092 Protocol Clients", RFC 2940, DOI 10.17487/RFC2940, October 2093 2000, . 2095 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 2096 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 2097 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 2098 RFC 3084, DOI 10.17487/RFC3084, March 2001, 2099 . 2101 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 2102 A. Rayhan, "Middlebox communication architecture and 2103 framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, 2104 . 2106 [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, 2107 "Middlebox Communications (midcom) Protocol Requirements", 2108 RFC 3304, DOI 10.17487/RFC3304, August 2002, 2109 . 2111 [RFC3483] Rawlins, D., Kulkarni, A., Bokaemper, M., and K. Chan, 2112 "Framework for Policy Usage Feedback for Common Open 2113 Policy Service with Policy Provisioning (COPS-PR)", 2114 RFC 3483, DOI 10.17487/RFC3483, March 2003, 2115 . 2117 [RFC3484] Draves, R., "Default Address Selection for Internet 2118 Protocol version 6 (IPv6)", RFC 3484, 2119 DOI 10.17487/RFC3484, February 2003, 2120 . 2122 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2123 Levkowetz, Ed., "Extensible Authentication Protocol 2124 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2125 . 2127 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 2128 Bosch, "Next Steps in Signaling (NSIS): Framework", 2129 RFC 4080, DOI 10.17487/RFC4080, June 2005, 2130 . 2132 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 2133 Service (COPS) Over Transport Layer Security (TLS)", 2134 RFC 4261, DOI 10.17487/RFC4261, December 2005, 2135 . 2137 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2138 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 2139 . 2141 [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 2142 Communication (MIDCOM) Protocol Semantics", RFC 5189, 2143 DOI 10.17487/RFC5189, March 2008, 2144 . 2146 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2147 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2148 . 2150 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 2151 RFC 5539, DOI 10.17487/RFC5539, May 2009, 2152 . 2154 [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 2155 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 2156 RFC 5973, DOI 10.17487/RFC5973, October 2010, 2157 . 2159 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 2160 Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010, 2161 . 2163 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2164 and A. Bierman, Ed., "Network Configuration Protocol 2165 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2166 . 2168 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2169 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2170 . 2172 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 2173 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 2174 . 2176 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 2177 Update to the IPv6 Flow Label Specification", RFC 6436, 2178 DOI 10.17487/RFC6436, November 2011, 2179 . 2181 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 2182 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 2183 February 2012, . 2185 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2186 Protocol (NETCONF) Access Control Model", RFC 6536, 2187 DOI 10.17487/RFC6536, March 2012, 2188 . 2190 [RFC6639] King, D., Ed. and M. Venkatesan, Ed., "Multiprotocol Label 2191 Switching Transport Profile (MPLS-TP) MIB-Based Management 2192 Overview", RFC 6639, DOI 10.17487/RFC6639, June 2012, 2193 . 2195 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2196 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2197 DOI 10.17487/RFC6887, April 2013, 2198 . 2200 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2201 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2202 . 2204 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 2205 Port Control Protocol (PCP)", RFC 7225, 2206 DOI 10.17487/RFC7225, May 2014, 2207 . 2209 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2210 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2211 . 2213 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2214 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2215 2014, . 2217 Authors' Addresses 2219 Susan Hares 2220 Huawei 2221 7453 Hickory Hill 2222 Saline, MI 48176 2223 USA 2225 Email: shares@ndzh.com 2227 Bob Moskowitz 2228 Huawei 2229 Oak Park, MI 48237 2231 Email: rgm@labs.htt-consult.com 2233 Dacheng Zhang 2234 Beijing 2235 China 2237 Email: dacheng.zdc@aliabab-inc.com