idnits 2.17.1 draft-ietf-i2nsf-gap-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (April 4, 2016) is 2944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DAR' is mentioned on line 1359, but not defined == Missing Reference: 'DIM' is mentioned on line 1359, but not defined == Unused Reference: 'RFC0791' is defined on line 1716, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-service-topo' is defined on line 1738, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 1764, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-data-model' is defined on line 1779, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 1797, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l2-network-topology' is defined on line 1802, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 1807, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-l3sm-l3vpn-service-model' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 1997, but no explicit reference was found in the text == Unused Reference: 'RFC4949' is defined on line 2012, but no explicit reference was found in the text == Unused Reference: 'RFC6436' is defined on line 2051, 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-05 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-protocol-security-requirements-03 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-05 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-05 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-08 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-traceability-07 == 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-02 == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-02 == 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-04 == Outdated reference: A later version (-01) exists of draft-li-bess-l3vpn-yang-00 == Outdated reference: A later version (-06) exists of draft-pkd-pce-pcep-yang-05 == Outdated reference: A later version (-04) exists of draft-raza-mpls-ldp-mldp-yang-03 == Outdated reference: A later version (-03) exists of draft-saad-mpls-static-yang-02 == 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 (~~), 50 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: October 6, 2016 D. Zhang 6 April 4, 2016 8 Analysis of Existing work for I2NSF 9 draft-ietf-i2nsf-gap-analysis-01.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 October 6, 2016. 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 . . . . . . . . . . . . . . . . . . . . 9 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. In-depth Review of IETF protocols . . . . . . . . . . . . . . 31 90 7.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 31 91 7.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 32 92 7.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 33 93 7.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 34 94 7.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 7.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 35 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 101 11.2. Informative References . . . . . . . . . . . . . . . . . 37 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 104 1. Introduction 106 This documents provides a gap analysis for I2NSF. 108 1.1. What is I2NSF 110 A Network Security Function (NSF) ensures integrity, confidentiality 111 and availability of network communications, detects unwanted 112 activity, and/or blocks out or at least mitigates the effects of 113 unwanted activity. NSFs are provided and consumed in increasingly 114 diverse environments. For example, users of NSFs could consume 115 network security services offered on multiple security products 116 hosted one or more service provider,their own enterprises, or a 117 combination of the two. 119 The lack of standard interfaces to control and monitor the behavior 120 of NSFs makes it virtually impossible for security service providers 121 to automate service offerings that utilize different security 122 functions from multiple vendors. 124 The Interface to Network Service Functions (I2NSF) work proposes to 125 standardize a set of software interfaces to control and monitor the 126 physical and virtual NSFs. Since different security vendors support 127 different features and functions, the I2NSF will focus on the flow- 128 based NSFs that provide treatment to packets or flows such found in 129 IPS/IDS devices, web filtering devices, flow filtering devices, deep 130 packet inspection devices, pattern matching inspection devices, and 131 re-mediation devices. 133 There are two layers of interfaces envisioned in the I2NSF approach: 135 o The I2NSF Capability Layer specifies how to control and monitor 136 NSFs at a functional implementation level. This is the focus for 137 this phase of the I2NSF Work. 139 o The I2NSF Service Layer defines how the security policies of 140 clients may be expressed and monitored. The Service Layer is out 141 of scope for this phase of I2NSF's work. 143 For the I2NSF Capability Layer, the I2NSF work proposes an 144 interoperable protocol that passes NSF provisioning rules and 145 orchestration information between the I2NSF client on a network 146 manager and the I2NSF agent on an NSF. It is envisioned that clients 147 of the I2NSF interfaces include management applications, service 148 orchestration systems, network controllers, or user applications that 149 may solicit network security resources. 151 The I2NSF work to define this protocol includes the following work: 153 o defining an informational model that defines the concepts for 154 standardizing the control and monitoring of NSFs, 156 o defining a set of YANG data models from the information model that 157 identifies the data that must be passed, 159 o creating a capability registry (an IANA registry) that identifies 160 the characteristics and behaviours of NSFs in vendor-neutral 161 vocabulary without requiring the NSFs to be standardized. 163 o examining existing secure communication mechanisms to identify the 164 appropriate ones for carrying the data that provisions and 165 monitors information between the NSFs and their management entity 166 (or entities). 168 1.2. Structure of this Document 170 This document provides an analysis of the gaps in the state of art in 171 the following industry forums: 173 IETF working groups (Section 2) 175 ETSI Network Functions Virtualization Industry Specification Group 176 (ETSI NFV ISG), (Section 3) 178 OPNFV Open Source Group (Section 4) 180 Open Stack - Firewall as a service (OpenStack Firewall FaaS) 181 (Section 5) (http://docs.openstack.org/admin-guide-cloud/content/ 182 install_neutron-fwaas-agent.html) 184 Cloud Security Alliance Security (CSA)as a Service (Section 6) 185 (https://cloudsecurityalliance.org/research/secaas/#_overview) 187 In-Depth Review of Some IETF Protocols (Section 7) 189 1.3. Terms and Definitions 191 1.3.1. Requirements Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119, BCP 14 196 [RFC2119] and indicate requirement levels for compliant CoAP. 198 1.3.2. Definitions 200 The following are a few definitions out of the terminology draft 201 utilized in this draft. For additional definitions please see: 202 [I-D.hares-i2nsf-terminology]. 204 Network Security Function (NSF): is a function that is provided as 205 a set of security-related service function. Typically, an NSF may 206 be responsible for detecting unwanted activity and blocking/ 207 mitigating the effect of such unwanted activity in order to fulfil 208 the service requirements. The NSF can help in supporting 209 communication stream integrity and confidentiality. 211 Cloud Data Center (DC): A data center that may/may not be run on 212 the premises of enterprises, but has compute/storage resources 213 that can be requested or purchased by the enterprises. The 214 enterprise is actually getting a virtual data center. The Cloud 215 Security Alliance (CSA) (http://cloudsecurityalliance.org) focuses 216 on adding security to this environment. A specific research topic 217 is security as a service within the cloud data center. 219 Cloud-based security functions: Network Security Functions (NSFs) 220 that may be hosted and managed by service providers or a different 221 administrative entity. 223 Domain: The term Domain in this draft has the following different 224 connotations in different scenarios: 226 * Client--Provider relationship, i.e. client requesting some 227 network security functions from its provider; 229 * Domain A - Domain B relationship, i.e. one operator domain 230 requesting some network security functions from another 231 operator domain; or 233 * Applications -- Network relationship, i.e. an application (e.g. 234 cluster of servers) requesting some functions from network, 235 etc. 237 The domain context is important because it indicates the 238 interactions the security is focused on. 240 I2NSF server/agent: A software instance that implements a network 241 security function that receives provisioning information and 242 requests operational data (e.g. monitoring data) from an I2NSF 243 client. It is also responsible for enforcing the policies that it 244 receives from an I2NSF client. 246 I2NSF client: A security client software that utilizes the I2NSF 247 protocol to read, write or change the provisioning network 248 security device via software interface using the I2NSF protocol 249 (denoted as I2RS Agent) 251 I2NSF Management System: I2NSF Client operates within an network 252 management system which serves as a collections and distribution 253 point for security provisioning and filter data. 255 2. IETF Gap analysis 257 The IETF gap analysis first examines the IETF mechanisms which have 258 been developed to secure the IP traffic flows through a network. 259 Traffic filters have been defined by IETF specifications at the 260 access points, the middle-boxes, or the routing systems. Protocols 261 have been defined to carry provisioning and filtering traffic between 262 a management system and an IP system (router or host system). 263 Current security work (SACM working group (WG), MILE WG, and DOTS WG) 264 is providing correlation of events monitored with the policy set by 265 filters. This section provides a review the filter work, protocols, 266 and security correlation for monitors. 268 2.1. Traffic Filters 270 2.1.1. Overview 272 The earliest filters defined by IETF were access filters which 273 controlled the acceptance of IP packet data flows. Additional policy 274 filters were created as part of the following protocols: 276 o COPS protocol [RFC2748] for controlling access to networks, 278 o Next Steps in Signalling (NSIS) work (architecture: [RFC4080] 279 protocol: [RFC5973]) - for supporting signaling about a data flow 280 along its path, and 282 o Port Control Protocol (PCP) - allows the IPv4/IPv6 host to control 283 how IPv6/IPv4 packets are translated and forwarded by NATS and 284 firewalls. 286 Today NETMOD and I2RS Working groups are specifying additional 287 filters in YANG modules to be used as part of the NETCONF or I2RS 288 enhancement of NETCONF/RESTCONF. 290 Route filtering is outside the scope of the flow filtering, but the 291 flow filtering may be impacted by route filtering. An initial model 292 for routing policy is in [I-D.ietf-rtgwg-policy-model] 294 This section provides an overview of the flow filtering as an 295 introduction to the I2NSF Gap analysis. Additional detail on 296 NETCONF, NETMOD, I2RS, PCP, and NSIS is available in Section 7. 298 2.1.1.1. Data Flow Filters in NETMOD and I2RS 300 The current work on expanding these filters is focused oncombining a 301 configuration and monitoring protocol with YANG data models. 302 [I-D.ietf-netmod-acl-model] provides a set of access list filters 303 which can permit or deny traffic flow based on headers at the MAC 304 Layer, IP Layer, and Transport Layer. The configuration and 305 monitoring protocols which can pass the filters are: NETCONF protocol 306 [RFC6241], RESTCONF [I-D.ietf-netconf-restconf], and the I2RS 307 protocol. The NETCONF and RESTCONF protocols install these filters 308 into forwarding tables. The I2RS protocol uses the ACLs as part of 309 the filters installed in an ephemeral protocol-independent filter- 310 based RIB [I-D.kini-i2rs-fb-rib-info-model] which controls the flow 311 of traffic on interfaces specifically controlled by the I2RS filter- 312 based FIB. 314 netconf 315 +---------------+ / \ +---------------+ 316 | Device: ACLs |-- / \---|Device: ACLS | 317 | I2RS FB RIB | | I2RS FIB RIB | 318 |routing policy | | routing policy| 319 | | | | 320 ===|===============|=============|===============|= 321 +---------------+ data flow +---------------+ 323 Figure 1 325 The I2RS protocol is a programmatic interface to the routing system. 326 At this time, the I2RS is targeted to be extensions to the NETCONF/ 327 RESTCONF protocols to allow the NETCONF/RESTCONF protocol to support 328 a highly programmatic interface with high bandwidth of data, highly 329 reliable notifications, and ephemeral state (see 330 [I-D.ietf-i2rs-architecture]). See Section 7.2 on I2RS for 331 additional details on I2RS. 333 The vocabulary of the [I-D.ietf-netmod-acl-model] is limited, so 334 additional protocol independent filters has been written for the I2RS 335 Filter-Based RIBs in [I-D.hares-i2rs-pkt-eca-data-model]. 337 One thing important to note is that NETCONF and RESTCONF manage 338 device layer YANG models. However, as Figure 2 shows, there are 339 multiple device level, network-wide level, and application level YANG 340 modules. The access lists defined by the device level forwarding 341 table may be impacted by the routing protocols, the I2RS ephemeral 342 protocol independent Filter-Based FIB, or some network-wide security 343 issue (IPS/IDS). 345 +--------------------------------------------+ 346 |Application Network Wide: Intent | 347 +--------------------------------------------+ 348 |Network-wide level: L3SM L3VPN service model| 349 +--------------------------------------------+ 350 |Device level: Protocol Independent: I2RS | 351 | RIB, Topology, Filter-Based RIB | 352 +--------------------------------------------+ 353 |Device Level:Protocol YANG modules | 354 | (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.) 355 +--------------------------------------------+ 356 | Device level: IP and System: NETMOD Models | 357 | (config and oper-state), tunnels, | 358 | forwarding filters | 359 +--------------------------------------------+ 361 Figure 2 Levels of YANG modules 363 2.1.1.2. I2NSF Gap analysis 365 The gap is that none of the current work on these filters considers 366 all the variations of data necessary to do IPS/IDS, web-filters, 367 stateful flow-based filtering, security-based deep packet inspection, 368 or pattern matching with re-mediation. The I2RS Filter-Based RIB 369 work is the closest associated work, but the focus has not been on 370 IDS/IPS, web-filters, security-based deep packet inspection, or 371 pattern matching with re-mediation. 373 The I2RS Working group (I2RS WG) is focused on the routing system so 374 the requisite security expertise for such NSFs (IDP/IPS, Web-filter, 375 security-based deep-packet inspection, etc.) has not been targeted 376 for this WG. 378 Another gap is there is no capability registry (an IANA registry) 379 that identifies the characteristics and behaviours of NSFs in vendor- 380 neutral vocabulary without requiring the NSFs to be standardized. 382 What I2NSF can use from NETCONF/RESTCONF and I2RS 384 I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS 385 proposed enhancement to the NETCONF/RESTCONF protocol. 387 2.1.2. Middle-box Filters 389 2.1.2.1. Midcom 391 Midcom Summary: MIDCOM developed the protocols for applications to 392 communicate with middle boxes. However, MIDCOM have not been used by 393 the industry for a long time. A main reason is that MIDCOM had a lot 394 of IPR encumbered technology and IPR was likely a bigger problem for 395 IETF at that time than it is today. MIDCOM is not specific to SIP. 396 It was very much oriented to NAT/FW devices. SIP was just one 397 application that needed the functionality. MIDCOM is reservation- 398 oriented and there was an expectation that the primary deployment 399 environment would be VoIP and real-time conferencing, including SIP, 400 H.323, and other reservation-oriented protocols. There was an 401 assumption that there would be some authoritative service that would 402 have a view into endpoint sessions and be able to authorize (or not) 403 resource allocation requests. In other words, there is a trust model 404 in MIDCOM that may not be applicable to endpoint-driven requests 405 without some sort of trusted authorization mechanisms/tools. 406 Therefore, there is a specific information model applied to security 407 devices, and security device requests, that was developed in the 408 context of an SNMP MIB. There is also a two-stage reservation model, 409 which was specified in order to allow better resource management. 411 Why I2NSF is Different from Midcom 413 MIDCOM is different from I2NSF because its SNMP scheme does not work 414 with the virtual network security functions (vNSF) management. 416 MidCom RFCs: 418 [RFC3303] - Midcom architecture 420 [RFC5189] - Midcom Protocol Semantics 422 [RFC3304] - Midcom protocol requirements 424 2.1.3. Security Work 425 2.1.3.1. Overview 427 Today's NSFs in security devices can handle flow-based security by 428 providing treatment to packets/flows, such as IPS/IDS, Web filtering, 429 flow filtering, deep packet inspection, or pattern matching and re- 430 mediation. These flow-based security devices are managed and 431 provisioned by network management systems. 433 No standardized set of interoperable interfaces control and manage 434 the NSFs so that a central management system can be used across 435 security devices from multiple Vendors. I2NSF work plan is to 436 standardize a set of interfaces by which control and management of 437 NSFs may be invoked, operated, and monitored by: 439 Creating an information model that defines concepts required for 440 standardizing the control and monitoring of NSFs, and from the 441 information model create data models. (The information model will 442 be used to get early agreement on key technical points.) 444 Creating a capability registry (at IANA) that enables the 445 characteristics and behavior of NSFs to be specified using a 446 vendor-neutral vocabulary without requiring the NSFs themselves to 447 be standardized. 449 Defining the requirements for an I2NSF protocol to pass this 450 traffic. (Ideally by re-using existing protocols.) 452 The flow-filtering configuration and management must fit into the 453 existing security area's work plan. This section considers how the 454 I2NSF fits into the security area work under way in the SACM 455 (Security Automation and Continuous Monitoring), DOTS (DDoS Open 456 Threat Signalling), and MILE (Management Incident Lightweight 457 Exchange). 459 2.1.3.2. Security Work and Filters 461 In the proposed I2NSF work plan, the I2NSF security network 462 management system controls many NSF nodes via the I2NSF Agent. This 463 control of data flows is similar to the COPS example in Section 7.4. 465 +------------+ 466 | I2NSF | 467 | Client | 468 | | 469 | security | 470 | NMS system | 471 +------------+ 472 +-----+ / \ +-----+ 473 |I2NSF|--/ \---|I2NSF| 474 |Agent| |Agent| 475 | | | | 476 | NSF | | NSF | 477 --| ----|------------|-----|----- 478 +-----+ data flow +-----+ 480 Figure 2 482 The other security protocols work to interact within the network to 483 provide additional information in the following way: 485 o SACM [I-D.ietf-sacm-architecture] describes an architecture which 486 tries to determine if the end-point security policies and the 487 reality (denoted as security posture) align. 488 [I-D.ietf-sacm-terminology] defines posture as the configuration 489 and/or status of hardware or software on an endpoint as it 490 pertains to an organization's security policy. Filters can be 491 considered on the configuration or status pieces that needs to be 492 monitored. 494 o DOTS (DDoS Open Threat Signalling) - is working on coordinating 495 the mitigation of DDoS attacks. A part of DDoS attach mitigation 496 is to provide lists of addresses to be filtered via IP header 497 filters. 499 o MILE (Managed Incident Lightweight Exchange) - is working on 500 creating a standardized format for incident and indicator reports, 501 and creating a protocol to transport this information. The 502 incident information MILE collects may cause changes in data-flow 503 filters on one or more NSFs. 505 2.1.3.3. I2NSF interaction 507 The network management system that the I2NSF client resides on may 508 interact with other clients or agents developed for the work ongoing 509 in the SACM, DOTS, and MILES working groups. This section describes 510 how the addition of I2NSF's ability to control and monitor NSF 511 devices is compatible and synergistic with these existing efforts. 513 +----------+ +------+ 514 +--------+ | security |====| DOTS | 515 |SACNM | | NMS | |client|---+ 516 |consumer| |..........|\ +------+ | 517 +--------+==|SACM *1 | \ | 518 +----|repository| \ | 519 | |..........| +-------+ | 520 | | I2NSF | |MILES | | 521 +------|-+ | client | |client | | 522 |SACM | +----------+ +-----:-+ | 523 |Info. | / \ : | 524 |provider| / \ : | 525 +--------+ / \ : | 526 +-----+ / \ +-----+ : | 527 |I2NSF|--/ \---|I2NSF| : | 528 | | | | : | 529 | | |MILES|.: | 530 | | |Agent| | 531 | | |DOTS | | 532 | | |Agent|-------+ 533 --| ----|----------------|-----|----- 534 +-----+ data flow +-----+ 536 *1 - this is the SACM Controller (CR) with 537 its broker/proxy/repository show as 538 described in the SACM architecture. 540 Figure 3 542 Figure 3 provides a diagram of a system in which the I2NSF, SACM, 543 DOTS and MILE client-agent or consumer-broker-provider are deployed 544 together. The following are possible positive interactions these 545 scenario might have: 547 o An security network management system (NMS) can contain a SACM 548 repository and be connected to SACM information providers and SACM 549 consumers. The I2NSF may provide one of the ways to change the 550 forwarding filters. 552 o The security NMS may also be connected to DOTS DDoS clients 553 managing the information and configuring the rules. The I2NSF may 554 provide one of the ways to change forwarding filters. 556 o The MILE client on a security network management system talking to 557 the MILE agent on the node may react to the incidents by using 558 I2NSF to set filters. DOTS creates black-lists, but does not have 559 a complete set of filters. 561 2.1.3.4. Benefits from the Interaction 563 I2NSF's ability to provide a common interoperable and vendor neutral 564 interface may allow the security NMS to use a single change to change 565 filters. SACM provides an information model to describe end-points, 566 but does not link this directly to filters. 568 DOTS creates black-lists based on source and destination IP address, 569 transport port number, protocol ID, and traffic rate. Like ACLs 570 defined NETMOD, the DOTS black-lists are not sufficient for all 571 filters or control desired by the NSF boxes. 573 The incident data captured by MILE will not have enough filter 574 information to provide NSF devices with general services. The I2NSF 575 will be able to handle the MILE incident data and create alerts or 576 reports for other security systems. 578 3. ETSI NFV 580 3.1. ETSI Overview 582 Network Functions Virtualization (NFV) provides service providers 583 with flexibility, cost effective and agility to offer their services 584 to customers. One such service is the network security function 585 which guards the exterior of a service provider or its customers. 586 However, the exterior network beyond the service provider NSFs or its 587 customer's NSFs is becoming extremely narrow as NSFs are becoming 588 more pervasive in any portion of networks (service providers, 589 customers, or access networks). 591 The flexibility and agility of NFV encourages service providers to 592 provide different products to address business trends in their market 593 to provide better service offerings to their end user. A traditional 594 product such as the network security function (NSF) may be broken 595 into multiple virtual devices each hosted from another vendor. In 596 the past, network security devices may have been sourced from a small 597 set of vendors - but in the NFV version of NSF devices, this reduced 598 set of sources will not provide a competitive edge. Due to this 599 market shift, the network security vendors are realizing that the 600 proprietary provisioning protocols and formats of data may be a 601 liability. Out of the NFV work has arisen a desire for a single 602 interoperable network security device provisioning and control 603 protocol. 605 The I2NSF framework is complementary to the NFV and other security 606 frameworks. The I2NSF management protocol will be deployed in 607 networks to provide a common management protocol to manage NSF 608 software/devices whether the devices are physical or virtual. The 609 ETSI NFV security is also deployed along-side other security 610 functions (AAA, SACM, DOTS, or MILE devices) and deep-packet stateful 611 inspections. 613 The ETSI Network Functions Virtualization: NFV security: Security and 614 Trust Guidance document (ETSI NFV SEC 003 1.1.1 (2014-12)) indicates 615 that multiple administrative domains will deployed in carrier 616 networks. One example of these multiple domains is hosting of 617 multiple tenant domains (telecom service providers) on a single 618 infrastructure domain (infrastructure service) as Figure 4 shows. 619 The ETSI Inter-VNFM document (aka Ve-Vnfn) between the element 620 management system and the Virtual network function is the equivalent 621 of the interface between the I2NSF client on a management system and 622 the I2NSF agent on the network security feature VNF. 624 .................... 625 +--: OSS/BSS : 626 | .................... 627 | 628 | +-------------------------+ 629 | | | 630 | | ........ ........ | 631 | | : EMS1 : : EMS : | ETSI inter-VNFM 632 | | ....||... ...||... | (Ve-Vnfn) 633 | | || || ==========I2NSF interface 634 | | ....||... ...||... | 635 | | : VNF1 : : VNF1 : | Tenant domain 636 | | ....||... ...||... | 637 ''''''''||'''''''''||'''''''''' 638 | | ....||..... ...||...... | infrastructure 639 | | :virtual : :virtual : | domain 640 | | :computing: :computing: | with virtual 641 | | ........... ........... | network 642 | | +=====================+ --------- 643 | | | virtualization layer| | 644 | | +=====================+ | 645 | | ........... .......... .......... | 646 |====:computing: :storage : :network : | 647 | :hardware : :hardware: :hardware: | 648 | ........... .......... .......... | 649 | hardware resources | 650 +-----------------------------------+ 652 Figure 4 654 The ETSI proof-of-concept demonstrations have been done for the 655 security proof of concepts: 657 o #16 - NFVIaaS with Secure, SDN controlled WAN Gateway, 659 3.2. I2NSF Gap Analysis 661 The I2NSF protocol/interface can be deployed for security devices 662 along-side the network/host configuration done by NETCONF/RESTCONF or 663 the routing system interface provided by I2RS that handles. 665 In the current NFV-related architecture, there is no interoperable 666 protocol defined between a security manager and various NSF devices 667 to provision security functions. The result is that service 668 providers have to manage the interoperability security manager and 669 different NSF devices using proprietary protocols. In response to 670 this problem, the device manufacturers and the service providers have 671 begun to discuss an I2NSF protocol for interoperable passing of 672 provisioning and filter in formation. 674 Open source work (such as OPNFV) provides a common code base on which 675 providers may start their NFV development work. However, this code 676 base faces the same problem. There is no defacto standard protocol. 678 4. OPNFV 680 The OPNFV (www.opnfv.org) is a carrier-grade integrated, open source 681 platform focused on accelerating the introduction of new Network 682 Functions Virtualization (NFV) products and service. The OPNFV Moon 683 project is focused on adding the security interface for a network 684 management system within the tenant NFVs and the infrastructure NFVs 685 (as shown in Figure 4). This section provides an overview of the 686 OPNFV Moon project and a gap analysis between I2NSF and the OPNFV 687 Moon Project. 689 4.1. OPNFV Moon Project 691 The OPNFV Moon project (https://wiki.opnfv.org) is a security 692 management system. NFV uses cloud computing technologies to 693 virtualize the resources and automate the control. The Moon project 694 is working on a security manager for the cloud computing 695 infrastructure (https://wiki.opnfv.org/moon). The Moon project 696 proposes to provision a set of different cloud resources/services for 697 VNFs (Virtualized Network Functions) while managing the isolation of 698 VNS, protection of VNFs, and monitoring of VNS. Moon is creating a 699 security management system for OPNFV with security managers to 700 protect different layers of the NFV infrastructure. The Moon project 701 is choosing various security project mechanisms "a la carte" to 702 enforcement related security managers. A security management system 703 integrates mechanisms of different security aspects. This project 704 intends propose a security manager that specifies users' security 705 requirements. It will also enforce the security managers through 706 various mechanisms like authorization for access control, firewall 707 for networking, isolation for storage, logging for tractability, etc. 709 The Moon security manager operates a VNF security manager at the ETSI 710 VeVnfm level where the I2NSF protocol is targeted as Figure 5 shows. 711 This figure also shows how the OPNFV VNF Security project mixes the 712 I2NSF level with the device level. 714 The Moon project lists the following gaps in OpenStack: 716 o No centralized control for compute, storage, and networking. Open 717 Stack uses Nova for compute and Swift for object storage. Each 718 system has a configuration file and its own security policy. The 719 system lacks a synchronization mechanism to build a complete 720 secure configuration for OPNFV. 722 o No dynamic control so that if a user obtains the token, so there 723 is no way to obtain control over the user. 725 o No customization or flexibility to allow integration into 726 different vendors, 728 o No fine grained authorization at user level. Authorization is 729 only at the API level. 731 Moon addresses these issues adding authorization, logging, IDS, 732 enforcement of network policy, and storage protection. Moon release 733 C (2016) plans to: 735 o Define an identity federation scenario between OpenStack and 736 OpenDaylight, 738 o Implement an authentication driver in ODL to delegate 739 authentication to OpenStack/Keystone, 741 o Implement a command line tool for administration and testing, 743 o Implement a graphic interface for identity management for both 744 OpenStack and OpenDaylight, 746 o Set up identity federation testbed, 748 o Define identity federation scenarios with other SDN controllers, 749 and 751 o Define authorization federation scenarios with OpenDaylight. 753 Deliverable time frame: Moon Release 3 (mid-year 2016) 755 .................... 756 +--: OSS/BSS : 757 | .................... 758 | 759 | +-------------------------+ 760 | | | 761 | | ........ ........ | 762 | | : EMS1 : : EMS : | ETSI inter-VNFM 763 | | ....||... ...||... | (Ve-Vnfn) 764 | | || || ==========I2NSF interface 765 | | ....||... ...||... | Moon VNF === Moon VNF 766 | | : : : : | Security Security MGR 767 | | : VNF1 : : VNF1 : | 768 | | ....||... ...||... | Tenant domain 769 ''''''''||'''''''''||'''''''''' 770 | | ....||..... ...||...... | infrastructure 771 | | :virtual : :virtual : | domain 772 | | :computing: :computing: | with virtual 773 | | ........... ........... | network 774 | | +=====================+ |-------- 775 | | | virtualization layer| | 776 | | +=====================+ 777 | | =============Moon VNF ===Moon VI 778 | | security project Security MGR 779 | | ........... .......... .......... | 780 |====:computing: :storage : :network : | 781 | :hardware : :hardware: :hardware: | 782 | ........... .......... .......... | 783 | hardware resources | 784 +-----------------------------------+ 786 Figure 5 788 4.2. Gap Analysis for OPNFV Moon Project 790 OpenStack Congress does not provide vendor independent systems. 792 5. OpenStack Security Firewall 794 OpenStack has advanced features of: a) API for managing security 795 groups (http://docs.openstack.org/admin-guide-cloud/content/ 796 section_securitygroups.html) and b) firewalls as a service 797 (http://docs.openstack.org/admin-guide-cloud/content/ 798 fwaas_api_abstractions.html). 800 This section provides an overview of this open stack work, and a gap 801 analysis of how I2NSF provides additional functions 803 5.1. Overview of API for Security Group 805 The security group rules provide ingress and egress traffic filters 806 based on port. The default rule for the group policy drops all 807 ingress traffic and allows all egress traffic. The group policy 808 allows users to add additional groups with additional filters that 809 change the default behaviour. To utilize the security groups, the 810 networking plug-in for OpenStack must implement the security group 811 API. The following plug-ins in OpenStack currently implement this 812 security: ML2, Open vSwitch, Linux Bridge, NEC, and VMware NSX. In 813 addition, the correct firewall driver must be added to make this 814 functional. 816 5.2. Overview of Firewall as a Service 818 Firewall as a service is an early release of an API that allows early 819 adopters to test network implementations. It contains APIs with 820 parameters for firewall rules, firewall policies, and firewall 821 identifiers. The firewall rules include the following information: 823 o identification of rule (id, name, description) 825 o identification tenant rule associated with, 827 o links to installed firewall policy, 829 o IP protocol (TCP, UDP, ICMP, or none) 831 o source and destination IP address 833 o source and destination port 835 o action: allow or deny traffic 837 o status: position and enable/disabled 839 The firewall policies include the following information: 841 o identification of the policy (id, name, description), 843 o identification of tenant associated with, 845 o ordered list of firewall rules, 847 o indication if policy can be seen by tenants other than owner, and 848 o indication if firewall rules have been audited. 850 The firewall table provides the following information: 852 o identification of firewall (id, name, description), 854 o tenant associated with this firewall, 856 o administrative state (up/down), 858 o status (active, down, pending create, pending delete, pending 859 update, pending error) 861 o firewall policy ID this firewall is associated with 863 5.3. I2NSF Gap analysis 865 The OpenStack work is preliminary (security groups and firewall as a 866 service). This work does not allow any of the existing network 867 security vendors provide a management interface. The OpenStack work 868 provides an interesting simple set of filters, and may in the future 869 provide some virtual filter service. However, at this time this open 870 source work does not address the need for a single management 871 interfaces for a variety of security devices. 873 Phase 1 of I2NSF is proposes rules that will include Event-Condition- 874 Action matches (ECA) rules with: 876 packet based matches on L2, L3, and L4 headers and/or specific 877 addresses within these headers, and 879 context based matches on schedule state and schedule. 881 basic ations of deny, permit, and mirror, 883 advanced actions of: IPS signature filtering and URL filtering. 885 [Editorial note: do we need more matches or actions?] 887 6. CSA Secure Cloud 889 6.1. CSA Overview 891 The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org) 892 defined security as a service (SaaS) in their Security as a Service 893 working group (SaaS WG) during 2010-2012. The CSA SaaS group defined 894 ten categories of network security 895 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 896 SecaaS_V1_0.pdf) and provides implementation guidance for each of 897 these ten categories. This section provides an overview of the CSA 898 SaaS working groups documentation and a gap analysis for I2NSF 900 6.1.1. CSA Security as a Service (SaaS) 902 The CSA SaaS working group defined the following ten categories, and 903 provided implementation guidance on these categories: 905 1. Identity Access Management (IAM) 906 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 907 SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) 909 2. Data Loss Prevention (DLP) 910 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 911 SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) 913 3. Web Security (web) 914 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 915 SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf), 917 4. Email Security (email) 918 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 919 SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf), 921 5. Security Assessments 922 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 923 SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf), 925 6. Intrusion Management 926 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 927 SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf), 929 7. Security information and Event Management 930 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 931 SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf), 933 8. Encryption 934 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 935 SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf), 937 9. Business Continuity and Disaster Recovery (BCDR) 938 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 939 SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and 941 10. Network Security 942 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 943 SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf). 945 The sections below give an overview these implementation guidelines. 947 6.1.2. Identity Access Management (IAM) 949 document: 950 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 951 SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) 953 The identity management systems include the following services: 955 o Centralized Directory Services, 957 o Access Management Services, 959 o Identity Management Services, 961 o Identity Federation Services, 963 o Role-Based Access Control Services, 965 o User Access Certification Services, 967 o Privileged User and Access Management, 969 o Separation of Duties Services, and 971 o Identity and Access Reporting Services. 973 The IAM device communications with the security management system 974 that controls the filtering of data. The CSA SaaS IAM specification 975 states that interoperability between IAM devices and secure access 976 network management systems is a problem. This 2012 implementation 977 report confirms there is a gap with IAM. 979 +------------+ +--------+ 980 | IAM device | ---- SLA ------------| secure | 981 | | Access review | access | 982 | | security events | NMS | 983 | | access tracing | | 984 +---||-------+ Audit report +---||---+ 985 || || 986 || +------------------+ || 987 ========== |Filter enforcement|=====|| 988 +------------------+ 989 Figure 6 991 6.1.3. Data Loss Prevention (DLP) 993 Document: 994 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 995 SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) 997 The data loss prevention (DLP) services must address: 999 o origination verification, 1001 o integrity of data, 1003 o confidentiality and access control, 1005 o accountability, 1007 o avoiding false positives on detection, and 1009 o privacy concerns. 1011 The CSA SaaS DLP device communications require that it have the 1012 enforcement capabilities to do the following: 1014 alert and log data loss, 1016 delete data on system or passing through, 1018 filter out (block/quarantine) data, 1020 reroute data, 1022 encrypt data 1024 +------------+ +--------+ 1025 | DLP device | ---- SLA ------------| secure | 1026 | | Alert and log | access | 1027 | | delete data | NMS | 1028 | | filter/reroute | | 1029 +---||-------+ encrypt data +---||---+ 1030 || || 1031 || +------------------+ || 1032 ========== |Filter enforcement|=====|| 1033 +------------------+ 1034 Figure 7 1036 6.1.4. Web Security (Web) 1038 Document: 1039 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1040 SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf 1042 The web security services must address: 1044 o Web 2.0/Social Media controls, 1046 o Malware and Anti-Virus controls, 1048 o Data Loss Prevention controls (over Web-based services like Gmail 1049 or Box.net), 1051 o XSS, JavaScript and other web specific attack controls 1053 o Web URL Filtering, 1055 o Policy control and administrative management, 1057 o Bandwidth management and quality of service (QoS) capability, and 1059 o Monitoring of SSL enabled traffic. 1061 The CSA SaaS Web services device communications require that it have 1062 the enforcement capabilities to do the following: 1064 alert and log malware or anti-virus data patterns, 1066 delete data (malware and virus) passing through systems, 1068 filter out (block/quarantine) data, 1070 filter Web URLs, 1072 interact with policy and network management systems, 1074 control bandwidth and QoS of traffic, and 1076 monitor encrypted (SSL enabled) traffic, 1078 All of these features either require the I2NSF standardized I2NSF 1079 client to I2NSF agent to provide multi-vendor interoperability. 1081 +------------+ +--------+ 1082 |Web security| ---- SLA ------------| secure | 1083 | | Alert and log | access | 1084 | | delete data | NMS | 1085 | | filter/reroute data | | 1086 | | ensure bandwidth/QOS | | 1087 | | monitor encrypted | | 1088 | | data | | 1089 +---||-------+ encrypt data +---||---+ 1090 || || 1091 || +------------------+ || 1092 ========== |Filter enforcement|=====|| 1093 +------------------+ 1094 Figure 8 1096 6.1.5. Email Security (email)) 1098 Document: 1099 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1100 SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf 1102 The CSA Document recommends that email security services must 1103 address: 1105 o Common electronic mail components, 1107 o Electronic mail architecture protection, 1109 o Common electronic mail threats, 1111 o Peer authentication, 1113 o Electronic mail message standards, 1115 o Electronic mail encryption and digital signature, 1117 o Electronic mail content inspection and filtering, 1119 o Securing mail clients, and 1121 o Electronic mail data protection and availability assurance 1122 techniques 1124 The CSA SaaS Email security services requires that it have the 1125 enforcement capabilities to do the following: 1127 provide the malware and spam detection and removal, 1128 alert and provide rapid response to email threats, 1130 identify email users and secure remote access to email, 1132 do on-demand provisioning of email services, 1134 filter out (block/quarantine) email data, 1136 know where the email traffic or data is residing (to to regulatory 1137 issues), and 1139 be able to monitor encrypted email, 1141 be able to encrypt email, 1143 be able to retain email records (while abiding with privacy 1144 concerns), and 1146 interact with policy and network management systems. 1148 All of these features require the I2NSF standardized I2NSF client to 1149 I2NSF agent to provide multi-vendor interoperability. 1151 +------------+ +--------+ 1152 | Email | ---- SLA ------------| secure | 1153 | security | alert/log malware | access | 1154 | | alert/log email spam | NMS | 1155 | | filter/reroute data | | 1156 | | ensure bandwidth/QOS | | 1157 | | monitor encrypted | | 1158 | | data | | 1159 +---||-------+ encrypt data +---||---+ 1160 || || 1161 || +------------------+ || 1162 ========== |Filter enforcement|=====|| 1163 +------------------+ 1164 Figure 9 1166 6.1.6. Security Assessment 1168 Document: 1169 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1170 SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf 1172 The CSA SaaS Security assessment indicates that assessments need to 1173 be done on the following devices: 1175 o hypervisor infrastructure, 1176 o network security compliance systems, 1178 o Servers and workstations, 1180 o applications, 1182 o network vulnerabilities systems, 1184 o internal auditor and intrusion detection/prevention systems (IDS/ 1185 IPS), and 1187 o web application systems. 1189 All of these features require the I2NSF working group standardize the 1190 way to pass these assessments to and from the I2NSF client on the 1191 I2NSF management system and the I2NSF Agent. 1193 6.1.7. Intrusion Detection 1195 Document: 1196 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1197 SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf) 1199 The CSA SaaS Intrusion detection management includes intrusion 1200 detection through: devices: 1202 o Network traffic inspection, behavioural analysis, and flow 1203 analysis, 1205 o Operating System, Virtualization Layer, and Host Process Events 1206 monitoring, 1208 o Monitoring of Application Layer Events, and 1210 o Correlation Techniques, and other Distributed and Cloud-Based 1211 Capabilities 1213 Intrusion response includes both: 1215 o Automatic, Manual, or Hybrid Mechanisms, 1217 o Technical, Operational, and Process Mechanisms. 1219 The CSA SaaS recommends the intrusion security management systems 1220 include provisioning and monitoring of all of these types of 1221 intrusion detection or intrusion protection devices. Management of 1222 these systems requires: 1224 Central reporting of events and alerts, 1226 Administrator notification of intrusions, 1228 Mapping of alerts to Cloud-Layer Tenancy, 1230 Cloud sourcing information to prevent false positives in 1231 detection, and 1233 Allowing for redirection of traffic to allow remote storage or 1234 transmission to prevent local evasion. 1236 In order to be able performing these management actions on NSF 1237 devices from different vendors, the intrusion security management 1238 systems need a standard mangement protocol that all the NSF vendors 1239 support. 1241 +------------+ +--------+ 1242 | IDS/IPS | ---- Info ----------| secure | 1243 | security | alert/log intrusion | access | 1244 | | notify administrator | NMS | 1245 | | Map alerts to Tenant | | 1246 | |filter/reroute traffic| | 1247 | | remote data storage | | 1248 +---||-------+ +---||---+ 1249 || || 1250 || +------------------+ || 1251 ========== |Filter enforcement|=====|| 1252 +------------------+ 1253 Figure 10 1255 The I2NSF manager - I2NSF (server/agent) protocol is designed to fill 1256 this gap. 1258 6.1.8. Security Information and Event Management(SIEM) 1260 Document: 1261 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1262 SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf) 1264 The Security Information and Event Management (SIEM) receives data 1265 from a wide range of security systems such as Identity management 1266 systems (IAM), data loss prevention (DLP), web security (Web), email 1267 security (email), intrusion detection/prevision (IDS/IPS)), 1268 encryption, disaster recovery, and network security. The SIEM 1269 combines this data into a single streams. All the requirements for 1270 data to/from these systems are replicated in these systems needs to 1271 give a report to the SIEM system. 1273 A SIEM system would be a prime candidate to have an I2NSF client that 1274 gathers data from an I2NSF Agent associated with these various types 1275 of security systems. The CSA SaaS SIEM functionality document 1276 suggests that one concern is to have standards that allow timely 1277 recording and sharing of data. I2NSF can provide this. 1279 6.1.9. Encryption 1281 Document: 1282 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1283 SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf 1285 The CSA SaaS encryption implementation guidance document considers 1286 how one implements and manages the following security systems: 1288 Key management systems (KMS), control of keys, and key life cycle; 1290 Shared Secret encryption (Symmetric ciphers), 1292 No-Secret or Public Key Encryption (asymmetric ciphers), 1294 Hashing algorithms, 1296 Digital Signature Algorithms, 1298 Key Establishment Schemes, 1300 Protection of Cryptographic Key Material (FIPS 140-2; 140-3), 1302 Interoperability of Encryption Systems, Key Conferencing, Key 1303 Escrow Systems, and others 1305 Application of Encryption for Data at rest, data in transit, and 1306 data in use; 1308 PKI (including certificate revocation "CRL"); 1310 Future application of such technologies as Homomorphic encryption, 1311 Quantum Cryptography, Identity-based Encryption, and others; 1313 Crypto-system Integrity (How bad implementations can under mind a 1314 crypto-system), and 1316 Cryptographic Security Standards and Guidelines 1318 Encryption services typically require that security management 1319 systems be able to provision, monitor, and control the systems that 1320 are being used to encrypt data. This document indicates in the 1321 implementation sections that the standardization of interfaces to/ 1322 from management systems are key to good key management systems, 1323 encryption systems, and crypto-systems. 1325 6.1.10. Business Continuity and Disaster Recovery (BC/DR) 1327 Document: 1328 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1329 SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf 1331 The CSA SaaS Business Continuity and Disaster Recovery (BC/DR) 1332 implementation guidance document considers the systems that implement 1333 the contingency plans and measures designed and implemented to ensure 1334 operational resiliency in the event of any service interruptions. 1335 BC/DR systems includes: 1337 Business Continuity and Disaster Recovery BC/DR as a Service, 1338 including categories such as complete Disaster Recovery as a 1339 Service (DRaaS), and subsets such as file recovery, backup and 1340 archive, 1342 Storage as a Service including object, volume, or block storage; 1344 Cold Site, Warm Site, Hot Site backup plans; 1346 IaaS (Infrastructure as a Service), PaaS (Platform as a Service), 1347 and SaaS (Software as a Service); 1349 Insurance (and insurance reporting programs) 1351 Business Partner Agents (business associate agreements); 1353 System Replication (for high availability); 1355 Fail-back to Live Systems mechanisms and management; 1357 Recovery Time Objective (RTO) and Recovery Point Objective (RPO); 1359 Encryption (data at rest [DAR], data in motion [DIM], field 1360 level); 1362 Realm-based Access Control; 1364 Service-level Agreements (SLA); and 1366 ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370 1368 These BC/DR systems must handle data backup and recovery, server 1369 backup/recovery, and data center (virtual/physical) backup and 1370 recovery. Recovery as a Service (RaaS) means that the BC/DR services 1371 are being handled by management systems outside the enterprise. 1373 BC/DR requires security management systems to be able to communicate 1374 provisioning, monitor, and control those systems that are being used 1375 to back-up and restore data. An interoperable protocol that allows 1376 provision and control of data center's data, servers, and data center 1377 management devices devices is extremely important to this 1378 application. Recovery as a Service (SaaS) indicates that these 1379 services need to be able to be remotely management. 1381 The CSA SaaS BC/BR documents indicate how important a standardized 1382 I2NSF protocol is. 1384 6.1.11. Network Security Devices 1386 Document: 1387 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1388 SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf 1390 The CSA SaaS Network Security implementation recommendation includes 1391 advice on: 1393 How to segment networks, 1395 Network security controls, 1397 Controlling ingress and egress controls such as Firewalls 1398 (Stateful), Content Inspection and Control (Network-based), 1399 Intrusion Detection System/Intrusion Prevention Systems (IDS/IPS), 1400 and Web Application Firewalls, 1402 Secure routing and time, 1404 Denial of Service (DoS) and Distributed Denial of Service (DDoS) 1405 Protection/Mitigation, 1407 Virtual Private Network (VPN) with Multiprotocol Label Switching 1408 (MPLS) Connectivity (over SSL), Internet Protocol Security (IPsec) 1409 VPNs, Virtual Private LAN Service (VPLS), and Ethernet Virtual 1410 Private Line (EVPL), 1412 Threat Management, 1414 Forensic Support, and 1415 Privileged User/Use Monitoring. 1417 These network security systems require provisioning, monitoring, and 1418 the ability for the security management system to subscribe to 1419 receive logs, snapshots of capture data, and time synchronization. 1420 This document states the following: 1422 "It is critical to understand what monitoring APIs are available 1423 from the CSP, and if they match risk and compliance requirements", 1425 "Network security auditors are challenged by the need to track a 1426 server and its identity from creation to deletion. Audit tracking 1427 is challenging in even the most mature cloud environments, but the 1428 challenges are greatly complicated by cloud server sprawl, the 1429 situation where the number of cloud servers being created is 1430 growing more quickly than a cloud environments ability to manage 1431 them." 1433 A valid threat vector for cloud is the API access. Since a 1434 majority of CSPs today support public API interfaces available 1435 within their networks and likely over the Internet." 1437 The CSA SaaS network security indicates that the I2NSF must be secure 1438 so that the I2NSF Client-Agent protocol does not become a valid 1439 threat vector. In additions, the need for the management protocol 1440 like I2NSF is critical in the sprawl of Cloud environment. 1442 6.2. I2NSF Gap Analysis 1444 The CSA Security as a Service (SaaS) document show clearly that there 1445 is a gap between the ability of the CSA SaaS devices to have a vendor 1446 neutral, inoperable protocol that allow the multiple of network 1447 security devices to communicate passing provisioning and 1448 informational data. Each of the 10 implementation agreements points 1449 to this as a shortcoming. Standard I2NSF YANG models and an I2NSF 1450 protocol are needed according to the CSA SaaS documents. 1452 7. In-depth Review of IETF protocols 1454 7.1. NETCONF and RESTCONF 1456 The IETF NETCONF working group has developed the basics of the 1457 NETCONF protocol focusing on secure configuration and querying 1458 operational state. The NETCONF protocol [RFC6241] may be run over 1459 TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults 1460 [RFC6243], handling events ([RFC5277] and basic notification 1461 [RFC6470], and filtering writes/reads based on network access control 1462 models (NACM, [RFC6536]). The NETCONF configuration must be 1463 committed to a configuration data store (denoted as config=TRUE). 1464 YANG models identify nodes within a configuration data store or an 1465 operational data store using a XPath expression (document root ---to 1466 --- target source). NETCONF uses an RPC model and provides protocol 1467 for handling configs (get-config, edit-config, copy-config, delete- 1468 config, lock, unlock, get) and sessions (close-session, kill- 1469 session). The NETCONF Working Group has developed RESTCONF, which is 1470 an HTTP-based protocol that provides a programmatic interface for 1471 accessing data defined in YANG, using the data stores defined in 1472 NETCONF. 1474 RESTCONF supports "two edit condition detections" - time stamp and 1475 entity tag. RESTCONF uses URI encoded path expressions. RESTCONF 1476 provides operations to get remote servers options (OPTIONS), retrieve 1477 data headers (HEAD), get data (GET), create resource/invoke operation 1478 (POST), patch data (PATCH), delete resource (DELETE), or query. 1480 RFCs for NETCONF 1482 o NETCONF [RFC6242] 1484 o NETCONF monitoring [RFC6022] 1486 o NETCONF over SSH [RFC6242] 1488 o NETCONF over TLS [RFC5539] 1490 o NETCONF system notification> [RFC6470] 1492 o NETCONF access-control (NACM) [RFC6536] 1494 o RESTCONF [I-D.ietf-netconf-restconf] 1496 o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home] 1498 o RESTCONF collection protocol 1499 [I-D.ietf-netconf-restconf-collection] 1501 o NETCONF Zero Touch Provisioning [I-D.ietf-netconf-zerotouch] 1503 7.2. I2RS Protocol 1505 Based on input from the NETCONF working group, the I2RS working group 1506 decided to re-use the NETCONF or RESTCONF protocols and specify 1507 additions to these protocols rather than create yet another protocol 1508 (YAP). 1510 The required extensions for the I2RS protocol are in the following 1511 drafts: 1513 o [I-D.ietf-i2rs-ephemeral-state], 1515 o [I-D.ietf-i2rs-pub-sub-requirements] (Publication-Subscription 1516 notifications, 1518 o [I-D.ietf-i2rs-traceability] 1520 o [I-D.ietf-i2rs-protocol-security-requirements] 1522 At this time, NETCONF and RESTCONF cannot handle the ephemeral data 1523 store proposed by I2RS, the publication and subscription 1524 requirements, the traceability, or the security requirements for the 1525 transport protocol and message integrity. 1527 7.3. NETMOD YANG modules 1529 NETMOD developed initial YANG models for interfaces [RFC7223]), IP 1530 address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP 1531 Systems ([RFC7317]) with system ID, system time management, DNS 1532 resolver, Radius client, SSH, syslog 1533 ([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]), 1534 and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing 1535 working group (rtgwg) has begun to examine policy for routing and 1536 tunnels. 1538 Protocol specific Working groups have developed YANG models for ISIS 1539 ([I-D.ietf-isis-yang-isis-cfg]), OSPF ([I-D.ietf-ospf-yang]), and BGP 1540 ([I-D.ietf-idr-bgp-model]. 1542 BGP Services YANG models have been proposed for 1544 o EVPN [I-D.brissette-bess-evpn-yang], 1546 o L2VPN [I-D.shah-bess-l2vpn-yang], 1548 o L3VPN [I-D.li-bess-l3vpn-yang] and 1549 [I-D.hu-bess-l2vpn-service-yang], 1551 TEAS working group has proposed [I-D.ietf-teas-yang-te-topo], and 1552 [I-D.ietf-teas-yang-rsvp]. 1554 MPLS/PCE/CCAMP groups have proposed the following Yang modules: 1556 o [I-D.raza-mpls-ldp-mldp-yang] 1557 o [I-D.saad-mpls-static-yang], 1559 o [I-D.zheng-mpls-lsp-ping-yang-cfg], 1561 o [I-D.pkd-pce-pcep-yang], and 1563 o [I-D.zhang-ccamp-transport-ctrlnorth-yang]. 1565 7.4. COPS 1567 One early focus on flow filtering based on policy enforcement of 1568 traffic entering a network is the 1990s COPS [RFC2748] design (PEP 1569 and PDP) as shown in Figure 11. The COPS policy decision points 1570 (PDP) managed network-wide policy (e.g. ACLs) by installing this 1571 policy in policy enforcement points (PEPs) on the edge of the 1572 network. These PEPs had firewall-like functions that control what 1573 data flows into the network at a PEP point, and data flow out of a 1574 network at a PEP. [RFC3084] describes COPS usages for policy 1575 provisioning. 1577 PDP 1578 +-----+ / \ +-----+ 1579 |PEP1 |--/ \---|PEP2 | 1580 | | ACL/policy | | 1581 | | | | 1582 --| ----|------------|-----|----- 1583 +-----+ data flow +-----+ 1585 Figure 11 1587 Why COPS is no longer used 1589 Network security today uses specific devices (IDS/IPS, NAT firewall, 1590 etc.) with specific policies and profiles for each types of device. 1591 No common protocol or policy format exists between the policy manager 1592 (PDP) and security enforcement points. 1594 COPs RFCs: [RFC4261], [RFC2940], [RFC3084], and [RFC3483]. 1596 Why I2NSF is Different from COPS 1598 COPS was a protocol for policy related to Quality of Service (QoS) 1599 and signaling protocols (e.g. RSVP) (security, flow, and others). 1600 I2NSF creates a common protocol between security policy decision 1601 points (SPDP) and security enforcement points (SEP). Today's 1602 security devices currently only use proprietary protocols. 1603 Manufacturers would like a security specific policy enforcement 1604 protocol rather than a generic policy protocol. 1606 7.5. PCP 1608 As indicated by the name, the Port Control Protocol (PCP) enables an 1609 IPv4 or IPv6 host to flexibly manage the IP address and port mapping 1610 information on Network Address Translators (NATs) or firewalls, to 1611 facilitate communication with remote hosts. 1613 PCP RFCs: 1615 [RFC6887] 1617 [RFC7225] 1619 [I-D.ietf-pcp-authentication] 1621 [I-D.ietf-pcp-optimize-keepalives] 1623 [I-D.ietf-pcp-proxy] 1625 Why is I2NSF Different from PCP: 1627 Here are some aspects that I2NSF is different from PCP: 1629 o PCP only supports management of port and address information 1630 rather than any other security functions 1632 7.6. NSIS - Next Steps in Signaling 1634 NSIS aims to standardize an IP signaling protocol (RSVP) along the 1635 data path for end points to request their unique QoS characteristics, 1636 unique FW policies or NAT needs (RFC5973) that are different from the 1637 FW/NAT original settings. The requests are communicated directly to 1638 the FW/NAT devices. NSIS is like east-west protocols that require 1639 all involved devices to fully comply to make it work. 1641 NSIS is path-coupled; it is possible to message every participating 1642 device along a path without having to know its location, or its 1643 location relative to other devices (This is particularly a pressing 1644 issue when one or more NATs present in the network, or when trying to 1645 locate appropriate tunnel endpoints). 1647 clients----I2NSF controller 1648 | client 1649 | 1650 | I2NSF 1651 | server/agent 1652 +--------+ +--------+ +--------+ 1653 | host | |firewall| | host | 1654 |device-1|-------|device-2|-------|device-3| 1655 +--------+ RSVP +--------+ RSVP +--------+ 1656 -----NSIS----------------------- 1658 Why I2NSF is Different from NSIS: 1660 o The I2NSF request does not require all network functions in a path 1661 to comply, but it is a protocol between the I2NSF client and the 1662 I2NSF Agent/Server 1664 o I2NSF defines client (applications) oriented descriptors 1665 (profiles, or attributes) to request/negotiate/validate the 1666 network security functions that are not on the local premises. 1668 Why I2NSF may have higher chance to be deployed than NSIS: 1670 o OpenStack already has a proof-of-concept/preliminary 1671 implementation, but the specification is not complete. IETF can 1672 play an active role to make the specification for I2NSF is 1673 complete. IETF can complete and extend the OpenStack 1674 implementation to provide an interoperable specification that can 1675 meet the needs and requirements of operators and is workable for 1676 suppliers of the technology. The combination of a carefully 1677 designed interoperable IETF specification with an open-source code 1678 development OpenStack will leverage the strengths of the two 1679 communities, and expand the informal ties between the two groups. 1680 A software development cycle has the following components: 1681 architecture, design specification, coding, and interoperability 1682 testing. The IETF can take ownership of the first two steps, and 1683 provide expertise and a good working atmosphere (in hack-a-thons) 1684 in the last two steps for OpenStack or other open-source coders. 1686 o IETF has the expertise in security architecture and design for 1687 interoperable protocols that span controllers/routers, middle- 1688 boxes, and security end-systems. 1690 o IETF has a history of working on interoperable protocols or 1691 virtualized network functions (L2VPN, L3VPN) that are deployed by 1692 operators in large scale devices. IETF has a strong momentum to 1693 create virtualized network functions (see SFC WG in routing) to be 1694 deployed in network boxes. [Note: We need to add SACM and others 1695 here]. 1697 8. IANA Considerations 1699 No IANA considerations exist for this document. 1701 9. Security Considerations 1703 No security considerations are involved with a gap analysis. 1705 10. Contributors 1707 The following people have contributed to this document: Hosnieh 1708 Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive 1709 comments, great suggestions, and valuable insights on alternative 1710 views. 1712 11. References 1714 11.1. Normative References 1716 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1717 DOI 10.17487/RFC0791, September 1981, 1718 . 1720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1721 Requirement Levels", BCP 14, RFC 2119, 1722 DOI 10.17487/RFC2119, March 1997, 1723 . 1725 11.2. Informative References 1727 [I-D.brissette-bess-evpn-yang] 1728 Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh, 1729 T., and I. Hussain, "Yang Data Model for EVPN", draft- 1730 brissette-bess-evpn-yang-01 (work in progress), December 1731 2015. 1733 [I-D.hares-i2nsf-terminology] 1734 Hares, S., Strassner, J., Lopez, D., and L. Xia, "I2NSF 1735 Terminology", draft-hares-i2nsf-terminology-00 (work in 1736 progress), March 2016. 1738 [I-D.hares-i2rs-info-model-service-topo] 1739 Hares, S., Wu, W., Wang, Z., and J. You, "An Information 1740 model for service topology", draft-hares-i2rs-info-model- 1741 service-topo-03 (work in progress), January 2015. 1743 [I-D.hares-i2rs-pkt-eca-data-model] 1744 Hares, S., Wu, Q., and R. White, "Filter-Based Packet 1745 Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data- 1746 model-02 (work in progress), February 2016. 1748 [I-D.hu-bess-l2vpn-service-yang] 1749 hu, f., Chen, R., and J. Yao, "L2VPN Service YANG Model", 1750 draft-hu-bess-l2vpn-service-yang-00 (work in progress), 1751 March 2016. 1753 [I-D.ietf-i2rs-architecture] 1754 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1755 Nadeau, "An Architecture for the Interface to the Routing 1756 System", draft-ietf-i2rs-architecture-11 (work in 1757 progress), December 2015. 1759 [I-D.ietf-i2rs-ephemeral-state] 1760 Haas, J. and S. Hares, "I2RS Ephemeral State 1761 Requirements", draft-ietf-i2rs-ephemeral-state-05 (work in 1762 progress), March 2016. 1764 [I-D.ietf-i2rs-problem-statement] 1765 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1766 Routing System Problem Statement", draft-ietf-i2rs- 1767 problem-statement-10 (work in progress), February 2016. 1769 [I-D.ietf-i2rs-protocol-security-requirements] 1770 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1771 Related Requirements", draft-ietf-i2rs-protocol-security- 1772 requirements-03 (work in progress), March 2016. 1774 [I-D.ietf-i2rs-pub-sub-requirements] 1775 Voit, E., Clemm, A., and A. Prieto, "Requirements for 1776 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 1777 requirements-05 (work in progress), February 2016. 1779 [I-D.ietf-i2rs-rib-data-model] 1780 Wang, L., Ananthakrishnan, H., Chen, M., 1781 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1782 YANG Data Model for Routing Information Base (RIB)", 1783 draft-ietf-i2rs-rib-data-model-05 (work in progress), 1784 March 2016. 1786 [I-D.ietf-i2rs-rib-info-model] 1787 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1788 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 1789 in progress), October 2015. 1791 [I-D.ietf-i2rs-traceability] 1792 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1793 the Routing System (I2RS) Traceability: Framework and 1794 Information Model", draft-ietf-i2rs-traceability-07 (work 1795 in progress), February 2016. 1797 [I-D.ietf-i2rs-usecase-reqs-summary] 1798 Hares, S. and M. Chen, "Summary of I2RS Use Case 1799 Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 1800 (work in progress), May 2015. 1802 [I-D.ietf-i2rs-yang-l2-network-topology] 1803 Dong, J. and X. Wei, "A YANG Data Model for Layer-2 1804 Network Topologies", draft-ietf-i2rs-yang-l2-network- 1805 topology-02 (work in progress), December 2015. 1807 [I-D.ietf-i2rs-yang-network-topo] 1808 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 1809 and H. Ananthakrishnan, "A Data Model for Network 1810 Topologies", draft-ietf-i2rs-yang-network-topo-02 (work in 1811 progress), December 2015. 1813 [I-D.ietf-idr-bgp-model] 1814 Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., 1815 Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. 1816 Liu, "BGP Model for Service Provider Networks", draft- 1817 ietf-idr-bgp-model-01 (work in progress), January 2016. 1819 [I-D.ietf-isis-yang-isis-cfg] 1820 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 1821 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 1822 isis-yang-isis-cfg-02 (work in progress), March 2015. 1824 [I-D.ietf-l3sm-l3vpn-service-model] 1825 Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K. 1826 D'Souza, "YANG Data Model for L3VPN service delivery", 1827 draft-ietf-l3sm-l3vpn-service-model-05 (work in progress), 1828 March 2016. 1830 [I-D.ietf-netconf-call-home] 1831 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1832 draft-ietf-netconf-call-home-06 (work in progress), May 1833 2015. 1835 [I-D.ietf-netconf-restconf] 1836 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1837 Protocol", draft-ietf-netconf-restconf-04 (work in 1838 progress), January 2015. 1840 [I-D.ietf-netconf-restconf-collection] 1841 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1842 Collection Resource", draft-ietf-netconf-restconf- 1843 collection-00 (work in progress), January 2015. 1845 [I-D.ietf-netconf-zerotouch] 1846 Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch 1847 Provisioning for NETCONF Call Home (ZeroTouch)", draft- 1848 ietf-netconf-zerotouch-02 (work in progress), March 2015. 1850 [I-D.ietf-netmod-acl-model] 1851 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 1852 "Network Access Control List (ACL) YANG Data Model", 1853 draft-ietf-netmod-acl-model-02 (work in progress), March 1854 2015. 1856 [I-D.ietf-netmod-routing-cfg] 1857 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1858 Management", draft-ietf-netmod-routing-cfg-19 (work in 1859 progress), May 2015. 1861 [I-D.ietf-netmod-syslog-model] 1862 Wildes, C. and K. Sreenivasa, "SYSLOG YANG model", draft- 1863 ietf-netmod-syslog-model-03 (work in progress), March 1864 2015. 1866 [I-D.ietf-ospf-yang] 1867 Yeung, D., Qu, Y., Zhang, J., Bogdanovic, D., and K. 1868 Sreenivasa, "Yang Data Model for OSPF Protocol", draft- 1869 ietf-ospf-yang-00 (work in progress), March 2015. 1871 [I-D.ietf-pcp-authentication] 1872 Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port 1873 Control Protocol (PCP) Authentication Mechanism", draft- 1874 ietf-pcp-authentication-09 (work in progress), May 2015. 1876 [I-D.ietf-pcp-optimize-keepalives] 1877 Reddy, T., Patil, P., Isomaki, M., and D. Wing, 1878 "Optimizing NAT and Firewall Keepalives Using Port Control 1879 Protocol (PCP)", draft-ietf-pcp-optimize-keepalives-06 1880 (work in progress), May 2015. 1882 [I-D.ietf-pcp-proxy] 1883 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 1884 Cheshire, "Port Control Protocol (PCP) Proxy Function", 1885 draft-ietf-pcp-proxy-08 (work in progress), May 2015. 1887 [I-D.ietf-rtgwg-policy-model] 1888 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 1889 "Routing Policy Configuration Model for Service Provider 1890 Networks", draft-ietf-rtgwg-policy-model-00 (work in 1891 progress), September 2015. 1893 [I-D.ietf-sacm-architecture] 1894 Cam-Winget, N., Lorenzin, L., McDonald, I., and l. 1895 loxx@cisco.com, "Secure Automation and Continuous 1896 Monitoring (SACM) Architecture", draft-ietf-sacm- 1897 architecture-05 (work in progress), October 2015. 1899 [I-D.ietf-sacm-terminology] 1900 Birkholz, H., Lu, J., and N. Cam-Winget, "Secure 1901 Automation and Continuous Monitoring (SACM) Terminology", 1902 draft-ietf-sacm-terminology-09 (work in progress), March 1903 2016. 1905 [I-D.ietf-teas-yang-rsvp] 1906 Beeram, V., Saad, T., Gandhi, R., Liu, X., Shah, H., Chen, 1907 X., Jones, R., and B. Wen, "A YANG Data Model for Resource 1908 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp-03 1909 (work in progress), March 2016. 1911 [I-D.ietf-teas-yang-te-topo] 1912 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1913 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 1914 teas-yang-te-topo-04 (work in progress), March 2016. 1916 [I-D.kini-i2rs-fb-rib-info-model] 1917 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 1918 R., Bogdanovic, D., and R. White, "Filter-Based RIB 1919 Information Model", draft-kini-i2rs-fb-rib-info-model-03 1920 (work in progress), February 2016. 1922 [I-D.li-bess-l3vpn-yang] 1923 Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. 1924 Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess- 1925 l3vpn-yang-00 (work in progress), October 2015. 1927 [I-D.pkd-pce-pcep-yang] 1928 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1929 YANG Data Model for Path Computation Element 1930 Communications Protocol (PCEP)", draft-pkd-pce-pcep- 1931 yang-05 (work in progress), January 2016. 1933 [I-D.raza-mpls-ldp-mldp-yang] 1934 Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H. 1935 Shah, "YANG Data Model for MPLS LDP and mLDP", draft-raza- 1936 mpls-ldp-mldp-yang-03 (work in progress), March 2016. 1938 [I-D.saad-mpls-static-yang] 1939 Raza, K., Gandhi, R., Liu, X., Beeram, V., Saad, T., Chen, 1940 X., Jones, R., and B. Wen, "A YANG Data Model for MPLS 1941 Base and Static LSPs", draft-saad-mpls-static-yang-02 1942 (work in progress), March 2016. 1944 [I-D.shah-bess-l2vpn-yang] 1945 Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z., 1946 Zhuang, S., Wang, H., Chen, I., Ahmed, S., Bocci, M., 1947 Hardwick, J., Esale, S., Tiruveedhula, K., Singh, T., 1948 Hussain, I., Wen, B., Walker, J., Delregno, N., Jalil, L., 1949 and M. Joecylyn, "YANG Data Model for MPLS-based L2VPN", 1950 draft-shah-bess-l2vpn-yang-01 (work in progress), March 1951 2016. 1953 [I-D.zhang-ccamp-transport-ctrlnorth-yang] 1954 Zhang, X., Jing, R., Jian, W., Ryoo, J., Xu, Y., and D. 1955 King, "YANG Models for the Northbound Interface of a 1956 Transport Network Controller: Requirements, Functions, and 1957 a List of YANG Models", draft-zhang-ccamp-transport- 1958 ctrlnorth-yang-00 (work in progress), March 2016. 1960 [I-D.zheng-mpls-lsp-ping-yang-cfg] 1961 Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. 1962 Rahman, "Yang Data Model for LSP-PING", draft-zheng-mpls- 1963 lsp-ping-yang-cfg-03 (work in progress), March 2016. 1965 [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, 1966 R., and A. Sastry, "The COPS (Common Open Policy Service) 1967 Protocol", RFC 2748, DOI 10.17487/RFC2748, January 2000, 1968 . 1970 [RFC2940] Smith, A., Partain, D., and J. Seligson, "Definitions of 1971 Managed Objects for Common Open Policy Service (COPS) 1972 Protocol Clients", RFC 2940, DOI 10.17487/RFC2940, October 1973 2000, . 1975 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 1976 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 1977 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 1978 RFC 3084, DOI 10.17487/RFC3084, March 2001, 1979 . 1981 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1982 A. Rayhan, "Middlebox communication architecture and 1983 framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, 1984 . 1986 [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, 1987 "Middlebox Communications (midcom) Protocol Requirements", 1988 RFC 3304, DOI 10.17487/RFC3304, August 2002, 1989 . 1991 [RFC3483] Rawlins, D., Kulkarni, A., Bokaemper, M., and K. Chan, 1992 "Framework for Policy Usage Feedback for Common Open 1993 Policy Service with Policy Provisioning (COPS-PR)", 1994 RFC 3483, DOI 10.17487/RFC3483, March 2003, 1995 . 1997 [RFC3484] Draves, R., "Default Address Selection for Internet 1998 Protocol version 6 (IPv6)", RFC 3484, 1999 DOI 10.17487/RFC3484, February 2003, 2000 . 2002 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 2003 Bosch, "Next Steps in Signaling (NSIS): Framework", 2004 RFC 4080, DOI 10.17487/RFC4080, June 2005, 2005 . 2007 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 2008 Service (COPS) Over Transport Layer Security (TLS)", 2009 RFC 4261, DOI 10.17487/RFC4261, December 2005, 2010 . 2012 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2013 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 2014 . 2016 [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 2017 Communication (MIDCOM) Protocol Semantics", RFC 5189, 2018 DOI 10.17487/RFC5189, March 2008, 2019 . 2021 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2022 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2023 . 2025 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 2026 RFC 5539, DOI 10.17487/RFC5539, May 2009, 2027 . 2029 [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 2030 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 2031 RFC 5973, DOI 10.17487/RFC5973, October 2010, 2032 . 2034 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 2035 Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010, 2036 . 2038 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2039 and A. Bierman, Ed., "Network Configuration Protocol 2040 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2041 . 2043 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2044 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2045 . 2047 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 2048 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 2049 . 2051 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 2052 Update to the IPv6 Flow Label Specification", RFC 6436, 2053 DOI 10.17487/RFC6436, November 2011, 2054 . 2056 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 2057 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 2058 February 2012, . 2060 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2061 Protocol (NETCONF) Access Control Model", RFC 6536, 2062 DOI 10.17487/RFC6536, March 2012, 2063 . 2065 [RFC6639] King, D., Ed. and M. Venkatesan, Ed., "Multiprotocol Label 2066 Switching Transport Profile (MPLS-TP) MIB-Based Management 2067 Overview", RFC 6639, DOI 10.17487/RFC6639, June 2012, 2068 . 2070 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2071 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2072 DOI 10.17487/RFC6887, April 2013, 2073 . 2075 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2076 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2077 . 2079 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 2080 Port Control Protocol (PCP)", RFC 7225, 2081 DOI 10.17487/RFC7225, May 2014, 2082 . 2084 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2085 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2086 . 2088 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2089 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2090 2014, . 2092 Authors' Addresses 2094 Susan Hares 2095 Huawei 2096 7453 Hickory Hill 2097 Saline, MI 48176 2098 USA 2100 Email: shares@ndzh.com 2102 Bob Moskowitz 2103 Huawei 2104 Oak Park, MI 48237 2106 Email: rgm@labs.htt-consult.com 2108 Dacheng Zhang 2109 Beijing 2110 China 2112 Email: dacheng.zdc@aliabab-inc.com