idnits 2.17.1 draft-ietf-i2nsf-gap-analysis-00.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 (February 2, 2016) is 3005 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DAR' is mentioned on line 1325, but not defined == Missing Reference: 'DIM' is mentioned on line 1325, but not defined == Unused Reference: 'RFC0791' is defined on line 1663, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-service-topo' is defined on line 1679, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 1695, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-data-model' is defined on line 1710, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 1728, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l2-network-topology' is defined on line 1733, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 1738, but no explicit reference was found in the text == Unused Reference: 'I-D.l3vpn-service-yang' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: 'I-D.zhang-i2rs-l1-topo-yang-model' is defined on line 1851, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 1903, but no explicit reference was found in the text == Unused Reference: 'RFC4949' is defined on line 1918, but no explicit reference was found in the text == Unused Reference: 'RFC6436' is defined on line 1957, but no explicit reference was found in the text == 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-02 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-09 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-protocol-security-requirements-02 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-04 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-04 == 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-06 == 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 (-42) exists of draft-ietf-isis-yang-isis-cfg-02 == 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 (-05) exists of draft-ietf-sacm-architecture-03 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-06 == Outdated reference: A later version (-03) exists of draft-kini-i2rs-fb-rib-info-model-02 == Outdated reference: A later version (-07) exists of draft-liu-bess-mvpn-yang-00 == Outdated reference: A later version (-02) exists of draft-shaikh-idr-bgp-model-01 == Outdated reference: A later version (-01) exists of draft-zhuang-bess-l3vpn-yang-00 -- 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: Standards Track Huawei 5 Expires: August 5, 2016 D. Zhang 6 February 2, 2016 8 Analysis of Existing work for I2NSF 9 draft-ietf-i2nsf-gap-analysis-00.txt 11 Abstract 13 This document analyzes the status of the arts in industries and the 14 existing IETF work/protocols that are relevant to the Interface to 15 Network Security Function (I2NSF). The I2NSF focus is to define data 16 models and interfaces in order to control and monitor the physical 17 and virtual aspects of network security functions. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 5, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. What is I2NSF . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Structure of this Document . . . . . . . . . . . . . . . 4 56 1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5 57 1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5 58 1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 59 2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9 63 2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 9 64 3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13 66 3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 14 67 4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15 69 4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17 70 5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17 71 5.1. Overview of API for Security Group . . . . . . . . . . . 18 72 5.2. Overview of Firewalls as a Service . . . . . . . . . . . 18 73 5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19 74 6. CSA Secure Cloud . . . . . . . . . . . . . . . . . . . . . . 19 75 6.1. CSA Overview . . . . . . . . . . . . . . . . . . . . . . 19 76 6.1.1. CSA Security as a Service(SaaS) . . . . . . . . . . . 20 77 6.1.2. Identity Access Management (IAM) . . . . . . . . . . 21 78 6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22 79 6.1.4. Web security(Web)) . . . . . . . . . . . . . . . . . 23 80 6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24 81 6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25 82 6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26 83 6.1.8. Security Information and Event Management(SEIM) . . . 27 84 6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28 85 6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29 86 6.1.11. Network Security Devices . . . . . . . . . . . . . . 30 87 6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31 88 7. In-depth Review of IETF protocols . . . . . . . . . . . . . . 31 89 7.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 31 90 7.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 32 91 7.3. NETMOD Yang modules . . . . . . . . . . . . . . . . . . . 33 92 7.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 7.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 94 7.6. NSIS - Next steps in Signalling . . . . . . . . . . . . . 35 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 100 11.2. Informative References . . . . . . . . . . . . . . . . . 37 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 103 1. Introduction 105 This documents provides a gap analysis for I2NSF. 107 1.1. What is I2NSF 109 The Network Security Function (NSF) in a network ensures integrity, 110 confidentiality and availability of network communications, detects 111 unwanted activity, and blocks out or at least mitigates the effects 112 of unwanted activity. NSF devices are provided and consumed in 113 increasingly diverse environments. For example, users of NSFs could 114 consume network security services offered on multiple security 115 products hosted one or more service provider,their own enterprises, 116 or a combination of the two. 118 The lack of standard interfaces to control and monitor the behaviour 119 of NSFs, makes it virtually impossible for security service providers 120 to automate service offerings that utilize different security 121 functions from multiple vendors. 123 The Interface to NSF devices (I2NSF) work proposes to standardize a 124 set of software interfaces and data modules to control and monitor 125 the physical and virtual NSFs. Since different security vendors 126 support different features and functions, the I2NSF will focus on the 127 flow-based NSFs that provide treatment to packets or flows such found 128 in IPS/IDS devices, web filtering devices, flow filtering devices, 129 deep packet inspection devices, pattern matching inspection devices, 130 and re-mediation devices. 132 There are two layers of interfaces envisioned in the I2NSF approach: 134 o The I2NSF Capability Layer specifies how to control and monitor 135 NSFs at a functional implementation level. This the focus for 136 this phase of the I2NSF Work. 138 o The I2NSF Service Layer defines how the security policies of 139 clients may be expressed and monitored. The Service Layer is out 140 of scope for this phase of I2NSF's work. 142 For the I2NSF capability layer, the I2NSF work proposes an 143 interoperable protocol that passes NSF provisioning rules and 144 orchestration information between I2NSF client on a network manager 145 and I2NSF agent on an NSF device. It is envisioned that clients of 146 the I2NSF interfaces include management applications, service 147 orchestration systems, network controllers, or user applications that 148 may solicit network security resources. 150 The I2NSF work to define this protocol includes the following work: 152 o defining an informational model that defines the concepts for 153 standardizing the control and monitoring of NSFs, 155 o defining a set of Yang data models from the information model that 156 identifies the data that must be passed, 158 o creating a capability registry (an IANA registry) that identifies 159 the characteristics and behaviours of NSFs in vendor-neutral 160 vocabulary without requiring the NSFs to be standardized. 162 o examining existing secure communication mechanisms to identify the 163 appropriate ones for carrying the data that provisions and 164 monitors information between the NSFs and their management entity 165 (or entities). 167 1.2. Structure of this Document 169 This document provides a analysis of the gaps in the state of art in 170 the following industry forums: 172 IETF working groups (section 2) 174 ETSI Network Functions Virtualization Industry Specification Group 175 (ETSI NFV ISG), (section 3) 177 OPNFV Open Source Group (section 4) 179 Open Stack - Firewall as a service (OpenStack Firewall FaaS) 180 (section 5) (http://docs.openstack.org/admin-guide-cloud/content/ 181 install_neutron-fwaas-agent.html) 183 Cloud Security Alliance Security (CSA)as a Service (section 6) 184 (https://cloudsecurityalliance.org/research/secaas/#_overview) 186 In-Depth Review of Some IETF Protocols (section 7) 188 1.3. Terms and Definitions 190 1.3.1. Requirements Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119, BCP 14 195 [RFC2119] and indicate requirement levels for compliant CoAP. 197 1.3.2. Definitions 199 NSF: Network security function. An NSF is a function that that 200 detects unwanted activity and blocks/mitigates the effect of such 201 unwanted activity in order to support availability of a network. 202 In addition, the NSF can help in supporting communication stream 203 integrity and confidentiality. 205 Cloud Data Center (DC): A data center that is not on premises of 206 enterprises, but has compute/storage resources that can be 207 requested or purchased by the enterprises. The enterprise is 208 actually getting a virtual data center. The Cloud Security 209 Alliance (CSA) (http://cloudsecurityalliance.org) focus on adding 210 security to this environment. A specific research topic is 211 security as a service within the cloud data center. 213 Cloud-based security functions: Network Security Function (NSF) 214 hosted and managed by service providers or different 215 administrative entity. 217 Domain: The term Domain in this draft has the following different 218 connotations in different scenarios: 220 * Client--Provider relationship, i.e. client requesting some 221 network security functions from its provider; 223 * Domain A - Domain B relationship, i.e. one operator domain 224 requesting some network security functions from another 225 operator domain; or 227 * Applications -- Network relationship, i.e. an application (e.g. 228 cluster of servers) requesting some functions from network, 229 etc. 231 The domain context is important because it indicates the 232 interactions the security is focused on. 234 I2NSF agent: a piece of software in a device that implements a 235 network security function which receives provisioning information 236 and requests for operational data (monitoring data) across the 237 I2NSF protocol from an I2NSF client. 239 I2NSF client: A security client software that utilizes the I2NSF 240 protocol to read, write or change the provisioning network 241 security device via software interface using the I2NSF protocol 242 (denoted as I2RS Agent) 244 I2NSF Management System: I2NSF client operates within an network 245 management system which serves as a collections and distribution 246 point for security provisioning and filter data. This management 247 system is denoted as I2NS management system in this document. 249 Virtual Security Function: is a security function that can be 250 requested by one domain but may be owned or managed by another 251 domain. 253 2. IETF Gap analysis 255 The IETF gap analysis first examines the IETF mechanisms which have 256 been developed to secure the IP traffic flows through a network. 257 Traffic filters have been defined by IETF specifications at the 258 access points, the middle-boxes, or the routing systems. Protocols 259 have been defined to carry provisioning and filtering traffic between 260 a management system and an IP system (router or host system). 261 Current security work (SACM working group (WG), MILE WG, and DOTS WG) 262 is providing correlation of events monitored with the policy set by 263 filters. This section provides a review the filter work, protocols, 264 and security correlation for monitors. 266 2.1. Traffic Filters 268 2.1.1. Overview 270 The earliest filters defined by IETF were access filters which 271 controlled the acceptance of IP packet data flows. Additional policy 272 filters were created as part of the following protocols: 274 o COPS protocol [RFC2748] for controlling access to networks, 276 o Next steps in Signalling (NSIS) work (architecture: [RFC4080] 277 protocol: [RFC5973]), and 279 o the Port Control Protocol (PCP) to enables IPv4 to IPv6 flexible 280 address and port mapping for NATs and Firewalls, 282 Today NETMOD and I2RS Working groups are specifying additional 283 filters in Yang modules to be used as part of the NETCONF or I2RS 284 enhancement of NETCONF/RESTCONF. 286 The routing filtering is outside the scope of the flow filtering, but 287 flow filtering may be impacted by route filtering. An initial model 288 for the routing policy is in [I-D.shaikh-rtgwg-policy-model] 290 This section provides an overview of the flow filtering as an 291 introduction to the I2NSF GAP analysis. Additional detail on 292 NETCONF, NETMOD, I2RS, PCP, and NSIS is available in the Detailed 293 I2NSF analysis. 295 2.1.1.1. Data Flow Filters in NETMOD and I2RS 297 The current work on expanding these filters is focused oncombining a 298 configuration and monitoring protocol with Yang data models. 299 [I-D.ietf-netmod-acl-model] provides a set of access lists filters 300 which can permit or deny traffic flow based on headers at the MAC, IP 301 layer, and Transport layer. The configuration and monitoring 302 protocols which can pass the filters are: NETCONF protocol [RFC6241], 303 RESTCONF [I-D.ietf-netconf-restconf], and the I2RS protocol. The 304 NETCONF and RESTCONF protocols install these filters into forwarding 305 tables. The I2RS protocol uses the ACLs as part of the filters 306 installed in an ephemeral protocol-independent filter-based RIB 307 [I-D.kini-i2rs-fb-rib-info-model] which controls the flow of traffic 308 on interfaces specifically controlled by the I2RS filter-based FIB. 310 netconf 311 +---------------+ / \ +---------------+ 312 | Device: ACLs |-- / \---|Device: ACLS | 313 | I2RS FB RIB | | I2RS FIB RIB | 314 |routing policy | | routing policy| 315 | | | | 316 ===|===============|=============|===============|= 317 +---------------+ data flow +---------------+ 319 Figure 1 321 The I2RS protocol is a programmatic interface to the routing system. 322 At this time, the I2RS is targeted to be extensions to the NETCONF/ 323 RESTCONF protocols to allow the NETCONF/RESTCONF protocol to support 324 a highly programmatic interface with high bandwidth of data, highly 325 reliable notifications, and ephemeral state (see 326 [I-D.ietf-i2rs-architecture]). Please see the background section on 327 I2RS for additional details on the requirements for this extension to 328 the NETCONF/RESTCONF protocol suite. 330 The vocabulary set in [I-D.ietf-netmod-acl-model] is limited, so 331 additional protocol independent filters were written for the I2RS 332 Filter-Based RIBs in [I-D.hares-i2rs-bnp-eca-data-model]. 334 One thing important to note is that NETCONF and RESTCONF manage 335 device layer yang models. However, as figure 2 shows, there are 336 multiple device level, network-wide level, and application level yang 337 modules. The access lists defined by the device level forwarding 338 table may be impacted by the routing protocols, the I2RS ephemeral 339 protocol independent Filter-Based FIB, or some network-wide security 340 issue (IPS/IDS). 342 +--------------------------------------------+ 343 |Application Network Wide: Intent | 344 +--------------------------------------------+ 345 |Network-wide level: L3SM L3VPN service model| 346 +--------------------------------------------+ 347 |Device level: Protocol Independent: I2RS | 348 | RIB, Topology, Filter-Based RIB | 349 +--------------------------------------------+ 350 |Device Level:Protocol Yang modules | 351 | (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.) 352 +--------------------------------------------+ 353 | Device level: IP and System: NETMOD Models | 354 | (config and oper-state), tunnels, | 355 | forwarding filters | 356 +--------------------------------------------+ 358 Figure 2 levels of Yang modules 360 2.1.1.2. I2NSF Gap analysis 362 The gap is that none of the current work on these filters considers 363 all the variations of data necessary to do IPS/IDS, web-filters, 364 stateful flow-based filtering, security-based deep packet inspection, 365 or pattern matching with re-mediation. The I2RS Filter-Based RIB 366 work is the closest associated work, but the focus has not been on 367 IDS/IPS, web-filters, security-based deep packet inspection, or 368 pattern matching with re-mediation. 370 The I2RS Working group (I2RS WG) is focused on the routing system so 371 security expertise for these IDP/IPS, Web-filter, security-based 372 deep-packet inspection has not been targeted for this WG. 374 Another gap is there is no capability registry (an IANA registry) 375 that identifies the characteristics and behaviours of NSFs in vendor- 376 neutral vocabulary without requiring the NSFs to be standardized. 378 What I2NSF can use from NETCONF/RESTCONF and I2RS 380 I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS 381 proposed enhancement to the NETCONF/RESTCONF protocol. 383 2.1.2. Middle-box Filters 385 2.1.2.1. Midcom 387 Midcom Summary: MIDCOM developed the protocols for applications to 388 communicate with middle boxes. However, MIDCOM have not used by the 389 industry for a long time. This is because there was a lot of IPR 390 encumbered technology and IPR was likely a bigger problem for IETF 391 than it is today. MIDCOM is not specific to SIP. It was very much 392 oriented to NAT/FW devices. SIP was just one application that needed 393 the functionality. MIDCOM is reservation-oriented and there was an 394 expectation that the primary deployment environment would be VoIP and 395 real-time conferencing, including SIP, H.323, and other reservation- 396 oriented protocols. There was an assumption that there would be some 397 authoritative service that would have a view into endpoint sessions 398 and be able to authorize (or not) resource allocation requests. In 399 other word, there's a trust model there that may not be applicable to 400 endpoint-driven requests without some sort of trusted authorization 401 mechanisms/tools. Therefore, there is a specific information model 402 applied to security devices, and security device requests, that was 403 developed in the context of an SNMP MIB. There is also a two-stage 404 reservation model, which was specified in order to allow better 405 resource management. 407 Why I2NSF is different than Midcom 409 MIDCOM is different than I2NSF because its SNMP scheme doesn't work 410 with the virtual network security functions (vNSF) management. 412 MidCom RFCs: 414 [RFC3303] - Midcom architecture 416 [RFC5189] - Midcom Protocol Semantics 418 [RFC3304] - Midcom protocol requirements 420 2.1.3. Security Work 421 2.1.3.1. Overview 423 Today's NSFs in security devices can handle flow-based security by 424 providing treatment to packets/flows, such as IPS/IDS, Web filtering, 425 flow filtering, deep packet inspection, or pattern matching and re- 426 mediation. These flow-based security devices are managed and 427 provisioned by network management systems. 429 No standardized set of interoperable interfaces control and manage 430 the NSFs so that a central management system can be used across 431 security devices from multiple Vendors. I2NSF work plan is to 432 standardize a set of interfaces by which control and management of 433 NSFs may be invoked, operated, and monitored by: 435 creating an information model that defines concepts required for 436 standardizing the control and monitoring of NSFs, and from the 437 information model create data models. (The information model will 438 be used to get early agreement on key technical points.) 440 creating a capability registry (at IANA) that enables the 441 characteristics and behavior of NSFs to be specified using a 442 vendor-neutral vocabulary without requiring the NSFs themselves to 443 be standardized. 445 define the requirements for an I2NSF protocol to pass this 446 traffic. (Hopefully re-using existing protocols.) 448 The flow-filtering configuration and management must fit into the 449 existing security area's work plan. This section considers how the 450 I2NSF fits into the security area work under way in the SACM 451 (security automation and control), DOTS (DDoS Open Threat 452 Signalling), and MILE (Management Incident Lightweight Exchange). 454 2.1.3.2. Security Work and Filters 456 In the proposed I2NSF work plan, the I2NSF security network 457 management system controls many NSF nodes via the I2NSF Agent. This 458 control of data flows is similar to the COPS example in section x.x. 460 +------------+ 461 | I2NSF | 462 | Client | 463 | | 464 | security | 465 | NMS system | 466 +------------+ 467 +-----+ / \ +-----+ 468 |I2NSF|--/ \---|I2NSF| 469 |Agent| |Agent| 470 | | | | 471 | NSF | | NSF | 472 --| ----|------------|-----|----- 473 +-----+ data flow +-----+ 475 Figure 2 477 The other security protocols work to interact within the network to 478 provide additional information in the following way: 480 o SACM [I-D.ietf-sacm-architecture] describes an architecture which 481 tries to determine if the end-point security policies and the 482 reality (denoted as security posture) align. 483 [I-D.ietf-sacm-terminology] defines posture as the configuration 484 and/or status of hardware or software on an endpoint as it 485 pertains to an organization's security policy. Filters can be 486 considered on the configuration or status pieces that needs to be 487 monitored. 489 o DOTS (DDoS Open Threat Signalling) - is working on coordinating 490 the mitigation of DDoS attacks. A part of DDoS attach mitigation 491 is to provide lists of addresses to be filtered via IP header 492 filters. 494 o MILE (Managed Incident LIghtweight Exchange) - is working on 495 creating a standardized format for incident and indicator reports, 496 and creating a protocol to transport this information. The 497 incident information MILE collects may cause changes in data-flow 498 filters on one or more NSFs. 500 2.1.3.3. I2NSF interaction 502 The network management system that the I2NSF client resides on may 503 interact with other clients or agents developed for the work ongoing 504 in the SACM, DOTS, and MILES working groups. This section describes 505 how the addition of I2NSF's ability to control and monitor NSF 506 devices is compatible and synergistic with these existing efforts. 508 +----------+ +------+ 509 +--------+ | security |====| DOTS | 510 |SACNM | | NMS | |client|---+ 511 |consumer| |..........|\ +------+ | 512 +--------+==|SACM *1 | \ | 513 +----|repository| \ | 514 | |..........| +-------+ | 515 | | I2NSF | |MILES | | 516 +------|-+ | client | |client | | 517 |SACM | +----------+ +-----:-+ | 518 |Info. | / \ : | 519 |provider| / \ : | 520 +--------+ / \ : | 521 +-----+ / \ +-----+ : | 522 |I2NSF|--/ \---|I2NSF| : | 523 | | | | : | 524 | | |MILES|.: | 525 | | |Agent| | 526 | | |DOTS | | 527 | | |Agent|-------+ 528 --| ----|----------------|-----|----- 529 +-----+ data flow +-----+ 531 *1 - this is the SACM Controller (CR) with 532 its broker/proxy/repository show as 533 described in the SACM architecture. 535 Figure 3 537 Figure 3 provides a diagram of a system the I2NSF, SACM, DOTS and 538 MILES client-agent or consumer-broker-provider are deployed together. 539 The following are possible positive interactions these scenario might 540 have: 542 o An security network management system (NMS) can contain a SACM 543 repository and be connected to SACM information provider and a 544 SACM consumer. The I2NSF may provide one of the ways to change 545 the forwarding filters. 547 o The security NMS may also be connected to DOTS DDoS clients 548 managing the information and configuring the rules. The I2NSF may 549 provide one of the ways to change forwarding filters. 551 o The MILES client on a security network management system talking 552 to the MILES agent on the node may react to the incidents by using 553 I2NSF to set filters. DOTS creates black-lists, but does not have 554 a complete set of filters. 556 2.1.3.4. Benefits from the Interaction 558 I2NSF's ability to provide a common interoperable and vendor neutral 559 interface may allow the security NMS to use a single change to change 560 filters. SACM provides an information model to describe end-points, 561 but does not link this directly to filters. 563 DOTS creates black-lists based on source and destination IP address, 564 transport port number, protocol ID, and traffic rate. Like NETMOD's, 565 ACLS are not sufficient for all filters or control desired by the NSF 566 boxes. 568 The incident data captured by MILES will not have enough filter 569 information to provide NSF devices with general services. The I2NSF 570 will be able to handle the MILE incident data and create alerts or 571 reports for other security systems. 573 3. ETSI NFV 575 3.1. ETSI Overview 577 Network Function Virtualization (NFV) provides the service providers 578 with flexibility, cost effective and agility to offer their services 579 to customers. One such service is the network security function 580 which guards the exterior of a service provider or its customers. 582 The flexibility and agility of NFV encourages service providers to 583 provide different products to address business trends in their market 584 to provide better service offerings to their end user. A traditional 585 product such as the network security function (NSF) may be broken 586 into multiple virtual devices each hosted from another vendor. In 587 the past, network security devices may have been single sourced from 588 a small set of vendors - but in the NFV version of NSF devices, this 589 reduced set of sources will not provide a competitive edge. Due to 590 this market shift, the network security device vendors are realizing 591 that the proprietary provisioning protocols and formats of data may 592 be a liability. Out of the NFV work has arisen a desire for a single 593 interoperable network security device provisioning and control 594 protocol. 596 The I2NSF will be deployed along networks using other security and 597 NFV technology. As section 3 described, the NFV NSF security is 598 deployed along side other security functions (AAA, SACM, DOTS, and 599 MILE devices) or deep-packet-inspection. The ETSI Network Functions 600 Virtualization: NFV security: Security and Trust guidance document 601 (ETSI NFV SEC 003 1.1.1 (2014-12)) indicates that multiple 602 administrative domains will deployed in carrier networks. One 603 example of these multiple domains is hosting of multiple tenant 604 domains (telecom service providers) on a single infrastructure domain 605 (infrastructure service) as figure 4 shows. The ETSI Inter inter- 606 VNFM document (aka Ve-Vnfn) between the element management system and 607 the Virtual network function is the equivalent of the interface 608 between the I2NSF client on a management system and the I2NSF agent 609 on the network security feature VNF. 611 .................... 612 +--: OSS/BSS : 613 | .................... 614 | 615 | +-------------------------+ 616 | | | 617 | | ........ ........ | 618 | | : EMS1 : : EMS : | ETSI inter-VNFM 619 | | ....||... ...||... | (Ve-Vnfn) 620 | | || || ==========I2NSF interface 621 | | ....||... ...||... | 622 | | : VNF1 : : VNF1 : | Tenant domain 623 | | ....||... ...||... | 624 ''''''''||'''''''''||'''''''''' 625 | | ....||..... ...||...... | infrastructure 626 | | :virtual : :virtual : | domain 627 | | :computing: :computing: | with virtual 628 | | ........... ........... | network 629 | | +=====================+ --------- 630 | | | virtualization layer| | 631 | | +=====================+ | 632 | | ........... .......... .......... | 633 |====:computing: :storage : :network : | 634 | :hardware : :hardware: :hardware: | 635 | ........... .......... .......... | 636 | hardware resources | 637 +-----------------------------------+ 639 figure 4 641 The ETSI proof of concept work has worked on the following security 642 proof of concepts: 644 o #16 - NFVIaas with Secure, SDN controlled WAN Gateway, 646 3.2. I2NSF Gap Analysis 648 The I2NSF will be deployed on top of virtual computing linked 649 together by virtual routers configured by NETCONF/RESTCONF or I2RS 650 which provision and monitoring the L1, L2, l3 and service pathways 651 through the network. 653 In the NFV-related productions, the current architecture does not 654 have a protocol to maintain an interoperability provisioning from 655 I2NSF client to I2NSF agent. The result is that service providers 656 have to manage the interoperability using private protocols. In 657 response to this problem, the device manufacturers and the service 658 providers have begun to discuss an I2NSF protocol for interoperable 659 passing of provisioning and filter in formation. 661 Open source work (such as OPNFV) provides a common code base for 662 providers to start their NFV work from. However, this code base 663 faces the same problem. There is no defacto standard protocol. 665 4. OPNFV 667 The OPNFV (www.opnfv.org) is a carrier-grade integrated, open source 668 platform focused on accelerating the introduction of new Network 669 Function Virtualization (NFV) products and service. The OPNFV Moon 670 project is focused on adding the security interface for a network 671 management system within the Tenant NFVs and the infrastructure NFVs 672 (as shown in figure 4). This section provides an overview of the 673 OPNFV Moon project and a gap analysis between I2NSF and the OPNFV 674 Moon Project. 676 4.1. OPNFV Moon Project 678 The OPNFV moon project (https://wiki.opnfv.org) is a security 679 management system. NFV uses cloud computing technologies to 680 virtualize the resources and automate the control. The Moon project 681 is working on a security manager for the Cloud computing 682 infrastructure (https://wiki.opnfv.org/moon). The Moon project 683 proposes to provision a set of different cloud resources/services for 684 VNFs (Virtualized Network Functions) while managing the isolation of 685 VNS, protection of VNFs, and monitoring of VNS. Moon is creating a 686 security management system for OPNFV with security managers to 687 protect different layers of the NFV infrastructure. The Moon project 688 is choosing various security project mechanisms "a la cart" to 689 enforcement related security managers. A security management system 690 integrates mechanisms of different security aspects. This project 691 will first propose a security manager that specifies users' security 692 requirements. It will also enforce the security managers through 693 various mechanisms like authorization for access control, firewall 694 for networking, isolation for storage, logging for tractability, etc. 696 The Moon security manager operates a VNF security manager at the ETSI 697 VeVnfm level where the I2NSF protocol is targeted as figure 5 shows. 698 This figure also shows how the OPNFV VNF Security project mixes the 699 I2NSF level with the device level. 701 The Moon project lists the following gaps in OpenStack: 703 o No centralized control for compute, storage, and networking. Open 704 Stack uses Nova for computing and Swift for software. Each system 705 has a configuration file and its own security policy. This lacks 706 the synchronization mechanism to build a complete secure 707 configuration for OPNF. 709 o No dynamic control so that if a user obtains the token, the is no 710 way to obtain control over the user. 712 o No customization or flexibility to allow integration into 713 different vendors, 715 o No fine grain authorization at user level. Authorization is only 716 at the API 718 Moon addresses these issues adding authorization, logging, IDS, 719 enforcement of network policy, and storage protection. Moon is based 720 on OpenStack Keystone. 722 Deliverable time frame: 2S 2015 723 .................... 724 +--: OSS/BSS : 725 | .................... 726 | 727 | +-------------------------+ 728 | | | 729 | | ........ ........ | 730 | | : EMS1 : : EMS : | ETSI inter-VNFM 731 | | ....||... ...||... | (Ve-Vnfn) 732 | | || || ==========I2NSF interface 733 | | ....||... ...||... | Moon VNF === Moon VNF 734 | | : : : : | Security Security MGR 735 | | : VNF1 : : VNF1 : | 736 | | ....||... ...||... | Tenant domain 737 ''''''''||'''''''''||'''''''''' 738 | | ....||..... ...||...... | infrastructure 739 | | :virtual : :virtual : | domain 740 | | :computing: :computing: | with virtual 741 | | ........... ........... | network 742 | | +=====================+ |-------- 743 | | | virtualization layer| | 744 | | +=====================+ 745 | | =============Moon VNF ===Moon VI 746 | | security project Security MGR 747 | | ........... .......... .......... | 748 |====:computing: :storage : :network : | 749 | :hardware : :hardware: :hardware: | 750 | ........... .......... .......... | 751 | hardware resources | 752 +-----------------------------------+ 754 figure 5 756 4.2. Gap Analysis for OPNFV Moon Project 758 OpenStack congress does not provide vendor independent systems. 760 5. OpenStack Security Firewall 762 OpenStack has advanced features of: a) API for managing security 763 groups (http://docs.openstack.org/admin-guide-cloud/content/ 764 section_securitygroups.html) and b) firewalls as a service 765 (http://docs.openstack.org/admin-guide-cloud/content/ 766 fwaas_api_abstractions.html). 768 This section provides an overview of this open stack work, and a gap 769 analysis of how I2NSF provides additional functions 771 5.1. Overview of API for Security Group 773 The security group with the security group rules provides ingress and 774 egress traffic filters based on port. The default group drops all 775 ingress traffic and allows all egress traffic. The groups with 776 additional filters are added to change this behaviour. To utilize 777 the security groups, the networking plug-in for Open Stack must 778 implement the security group API. The following plug-ins in 779 OpenSTsack currently implement this security: ML2, Open vSwitch, 780 Linux Bridge, NEC, and VMware NSX. In addition, the correct firewall 781 driver must be added to make this functional. 783 5.2. Overview of Firewalls as a Service 785 Firewall as a service is an early release of an API that allows early 786 adopters to test network implementations. It contains APIs with 787 parameters for firewall rules, firewall policies, and firewall 788 identifiers. The firewall rules include the following information: 790 o identification of rule (id, name, description) 792 o identification tenant rule associated with, 794 o links to installed firewall policy, 796 o IP protocol (tcp, udp, icmp, none) 798 o source and destination IP address 800 o source and destination port 802 o action: allow or deny traffic 804 o status: position and enable/disabled 806 The firewall policies include the following information: 808 o identification of the policy (id, name, description), 810 o identification of tenant associated with, 812 o ordered list of firewall rules, 814 o indication if policy can be seen by tenants other than owner, and 816 o indication if firewall rules have been audited. 818 The firewall table provides the following information: 820 o identification of firewall (id, name, description), 822 o tenant associated with this firewall, 824 o administrative state (up/down), 826 o status (active, down, pending create, pending delete, pending 827 update, pending error) 829 o firewall policy ID this firewall is associated with 831 5.3. I2NSF Gap analysis 833 The OpenStack work is preliminary (security groups and firewall as a 834 service). This work does not allow any of the existing network 835 security vendors provide a management interface. Security devices 836 take time to be tested for functionality and their detection of 837 security issues. The OpenStack work provides an interesting simple 838 set of filters, and may in the future provide some virtual filter 839 service. However, at this time this open source work does not 840 address the single management interfaces for a variety of security 841 devices. 843 I2NSF is proposing rules that will include Event-Condition-matches 844 (ECA) with the following matches 846 packet based matches on L2, L3, and L4 headers and/or specific 847 addresses within these headers, 849 context based matches on schedule state and schedule, [Editor: 850 Need more details here.] 852 The I2NSF is proposing action for these ECA policies of: 854 basic actions of deny, permit, and mirror, 856 advanced actions of: IPS signature filtering and URL filtering. 858 6. CSA Secure Cloud 860 6.1. CSA Overview 862 The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org) 863 defined security as a service (SaaS) in their Security as a Service 864 working group (SaaS WG) during 2010-2012. The CSA SaaS group defined 865 ten categories of network security 866 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 867 SecaaS_V1_0.pdf) and provides implementation guidance for each of 868 these ten categories This section provides an overview of the CSA 869 SaaS working groups documentation and a Gap analysis for I2NSF 871 6.1.1. CSA Security as a Service(SaaS) 873 The CSA SaaS working group defined the following ten categories, and 874 provided implementation guidance on these categories: 876 1. Identity Access Management (IAM) 877 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 878 SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) 880 2. Data Loss Prevention (DLP) 881 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 882 SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) 884 3. Web Security (web) 885 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 886 SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf), 888 4. Email Security (email) 889 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 890 SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf), 892 5. Security Assessments 893 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 894 SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf), 896 6. Intrusion Management 897 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 898 SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf), 900 7. Security information and Event Management 901 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 902 SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf), 904 8. Encryption 905 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 906 SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf), 908 9. Business Continuity and Disaster Recovery (BCDR) 909 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 910 SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and 912 10. Network Security 913 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 914 SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf). 916 The sections below give an overview these implementation guidances 918 6.1.2. Identity Access Management (IAM) 920 document: 921 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 922 SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) 924 The identity management systems include the following services: 926 o Centralized Directory Services, 928 o Access Management Services, 930 o Identity Management Services, 932 o Identity Federation Services, 934 o Role-Based Access Control Services, 936 o User Access Certification Services, 938 o Privileged User and Access Management, 940 o Separation of Duties Services, and 942 o Identity and Access Reporting Services. 944 The IAM device communications with the security management system 945 that controls the filtering of data. The CSA SaaS IAM specification 946 states that interoperability between IAM devices and secure access 947 network management systems is a a problem. This 2012 implementation 948 report confirms there is a gap with I2NSF 950 +------------+ +--------+ 951 | IAM device | ---- SLA ------------| secure | 952 | | Access review | access | 953 | | security events | NMS | 954 | | access tracing | | 955 +---||-------+ Audit report +---||---+ 956 || || 957 || +------------------+ || 958 ========== |Filter enforcement|=====|| 959 +------------------+ 960 Figure 6 962 6.1.3. Data Loss Prevention (DLP) 964 Document: 965 (https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 966 SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) 968 The data loss prevention (DLP)services must address: 970 o origination verification, 972 o integrity of data, 974 o confidentiality and access control, 976 o accountability, 978 o avoiding false positives on detection, and 980 o privacy concerns. 982 The CSA SaaS DLP device communications require that it have the 983 enforcement capabilities to do the following: 985 alert and log data loss, 987 delete data on system or passing through, 989 filter out (block/quarantine) data, 991 reroute data, 993 encrypt data 995 +------------+ +--------+ 996 | DLP device | ---- SLA ------------| secure | 997 | | Alert and log | access | 998 | | delete data | NMS | 999 | | filter/reroute | | 1000 +---||-------+ encrypt data +---||---+ 1001 || || 1002 || +------------------+ || 1003 ========== |Filter enforcement|=====|| 1004 +------------------+ 1005 Figure 7 1007 6.1.4. Web security(Web)) 1009 Document: 1010 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1011 SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf 1013 The web security services must address: 1015 o Web 2.0/Social Media controls, 1017 o Malware and Anti-Virus controls, 1019 o Data Loss Prevention controls (over Web-based services like Gmail 1020 or Box.net), 1022 o XSS, JavaScript and other web specific attack controls 1024 o Web URL Filtering, 1026 o Policy control and administrative management, 1028 o Bandwidth management and quality of service (QoS) capability, and 1030 o Monitoring of SSL enabled traffic. 1032 The CSA SaaS Web services device communications require that it have 1033 the enforcement capabilities to do the following: 1035 alert and log malware or anti-virus data patterns, 1037 delete data (malware and virus) passing through systems, 1039 filter out (block/quarantine) data, 1041 filter Web URLs, 1043 interact with policy and network management systems, 1045 control bandwidth and QoS of traffic, and 1047 monitor encrypted (SSL enabled) traffic, 1049 All of these features either require the I2NSF standardized I2NSF 1050 client to I2NSF agent to provide multi-vendor interoperability. 1052 +------------+ +--------+ 1053 |Web security| ---- SLA ------------| secure | 1054 | | Alert and log | access | 1055 | | delete data | NMS | 1056 | | filter/reroute data | | 1057 | | ensure bandwdith/QOS | | 1058 | | monitor encrypted | | 1059 | | data | | 1060 +---||-------+ encrypt data +---||---+ 1061 || || 1062 || +------------------+ || 1063 ========== |Filter enforcement|=====|| 1064 +------------------+ 1065 Figure 8 1067 6.1.5. Email Security (email)) 1069 Document: 1070 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1071 SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf 1073 The CSA Document recommends that email security services must 1074 address: 1076 o Common electronic mail components, 1078 o Electronic mail architecture protection, 1080 o Common electronic mail threats, 1082 o Peer authentication, 1084 o Electronic mail message standards, 1086 o Electronic mail encryption and digital signature, 1088 o Electronic mail content inspection and filtering, 1090 o Securing mail clients, and 1092 o Electronic mail data protection and availability assurance 1093 techniques 1095 The CSA SaaS Email security services requires that it have the 1096 enforcement capabilities to do the following: 1098 provide the malware and spam detection and removal, 1099 alert and provide rapid response to email threats, 1101 identify email users and secure remote access to email, 1103 do on-demand provisioning of email services, 1105 filter out (block/quarantine) email data, 1107 know where the email traffic or data is residing (to to regulatory 1108 issues), and 1110 be able to monitor encrypted email, 1112 be able to encrypt email, 1114 be able to retain email records (while abiding with privacy 1115 concerns), and 1117 interact with policy and network management systems. 1119 All of these features require the I2NSF standardized I2NSF client to 1120 I2NSF agent to provide multi-vendor interoperability. 1122 +------------+ +--------+ 1123 | Email | ---- SLA ------------| secure | 1124 | security | alert/log malware | access | 1125 | | alert/log email spam | NMS | 1126 | | filter/reroute data | | 1127 | | ensure bandwidth/QOS | | 1128 | | monitor encrypted | | 1129 | | data | | 1130 +---||-------+ encrypt data +---||---+ 1131 || || 1132 || +------------------+ || 1133 ========== |Filter enforcement|=====|| 1134 +------------------+ 1135 Figure 9 1137 6.1.6. Security Assessment 1139 Document: 1140 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1141 SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf 1143 The CSA SaaS Security assessment indicates that assessments need to 1144 be done on the following devices: 1146 o hypervisor infrastructure, 1147 o network security compliance systems, 1149 o Servers and workstations, 1151 o applications, 1153 o network vulnerabilities systems, 1155 o internal auditor and intrusion detection/prevention systems (IDS/ 1156 IPS), and 1158 o web application systems. 1160 All of these features require the I2NSF working group standardize the 1161 way to pass these assessments to and from the I2NSF client on the 1162 I2NSF management system and the I2NSF Agent. 1164 6.1.7. Intrusion Detection 1166 Document: 1167 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1168 SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf) 1170 The CSA SaaS Intrusion detection management includes intrusion 1171 detection through: devices: 1173 o Network traffic inspection, behavioural analysis, and flow 1174 analysis, 1176 o Operating System, Virtualization Layer, and Host Process Events 1177 monitoring, 1179 o monitoring of Application Layer Events, and 1181 o Correlation Techniques, and other Distributed and Cloud-Based 1182 Capabilities 1184 Intrusion response includes both: 1186 o Automatic, Manual, or Hybrid Mechanisms, 1188 o Technical, Operational, and Process Mechanisms. 1190 The CSA SaaS recommends the intrusion security management systems 1191 include provisioning and monitoring of all of these types of 1192 intrusion detection (IDS) or intrusion protection devices. The 1193 management of these systems requires also requires: 1195 Central reporting of events and alerts, 1197 administrator notification of intrusions, 1199 Mapping of alerts to Cloud-Layer Tenancy, 1201 Cloud sourcing information to prevent false positives in 1202 detection, and 1204 allowing for redirection of traffic to allow remote storage or 1205 transmission to prevent local evasion. 1207 All of these features require the I2NSF standardized I2NSF client to 1208 I2NSF agent to provide multi-vendor interoperability. 1210 +------------+ +--------+ 1211 | IDS/IPS | ---- Info ----------| secure | 1212 | security | alert/log intrusion | access | 1213 | | notify administrator | NMS | 1214 | | Map alerts to Tenant | | 1215 | |filter/reroute traffic| | 1216 | | remote data storage | | 1217 +---||-------+ +---||---+ 1218 || || 1219 || +------------------+ || 1220 ========== |Filter enforcement|=====|| 1221 +------------------+ 1222 Figure 10 1224 6.1.8. Security Information and Event Management(SEIM) 1226 Document: 1227 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1228 SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf) 1230 The Security Information and Event Management (SEIM) receives data 1231 from a wide range of security systems such as Identity management 1232 systems (IAM), data loss prevention (DLP), web security (Web), email 1233 security (email), intrusion detection/prevision (IDS/IPS)), 1234 encryption, disaster recovery, and network security. The SEIM 1235 combines this data into a single streams. All the requirements for 1236 data to/from these systems are replicated in these systems needs to 1237 give a report to the SIEM system. 1239 A SIEM system would be prime candidate to have a I2NSF client that 1240 gathers data from an I2NSF Agent associated with these various types 1241 of security systems. The CSA SaaS SIEM functionality document 1242 suggests that one concern is to have standards that allow timely 1243 recording and sharing of data. I2NSF can provide this. 1245 6.1.9. Encryption 1247 Document: 1248 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1249 SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf 1251 The CSA SaaS Encryption implementation guidance document considers 1252 how one implements and manages the following security systems: 1254 key management systems (KMS), control of keys, and key life cycle; 1256 Shared Secret encryption (Symmetric ciphers), 1258 No-Secret or Public Key Encryption (asymmetric ciphers), 1260 hashing algorithms, 1262 Digital Signature Algorithms, 1264 Key Establishment Schemes, 1266 Protection of Cryptographic Key Material (FIPS 140-2; 140-3), 1268 Interoperability of Encryption Systems, Key Conferencing, Key 1269 Escrow Systems, and others 1271 application of Encryption for Data at rest, data in transit, and 1272 data in use; 1274 PKI (including certificate revocation "CRL"); 1276 Future application of such technologies as Homomorphic encryption, 1277 Quantum Cryptography, Identitybased Encryption, and others; 1279 Crypto-system Integrity (How bad implementations can under mind a 1280 crypto-system), and 1282 Cryptographic Security Standards and Guidelines 1284 The wide variety of encryption services require the security 1285 management systems be able to provision, monitor, and control the 1286 systems that are being used to encrypt data. This document indicates 1287 in the implementation sections that the standardization of interfaces 1288 to/from management systems are key to good key management systems, 1289 encryption systems, and crypto-systems. 1291 6.1.10. Business Continuity and Disaster Recovery (BC/DR) 1293 Document: 1294 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1295 SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf 1297 The CSA SaaS Business Continuity and Disaster Recovery (BC/DR) 1298 implementation guidance document considers the systems that implement 1299 the the contingency plans and measures designed and implemented to 1300 ensure operational resiliency in the event of any service 1301 interruptions. BC/DR systems includes: 1303 Business Continuity and Disaster Recovery BC/DR as a service, 1304 including categories such as complete Disaster Recovery as a 1305 Service (DRaaS), and subsets such as file recovery, backup and 1306 archive, 1308 Storage as a Service including object, volume, or block storage; 1310 old Site, Warm Site, Hot Site backup plans; 1312 IaaS (Infrastructure as a Service), PaaS (Platform as a Service), 1313 and SaaS (Software as a Service); 1315 Insurance (and insurance reporting programs) 1317 Business Partner Agents (business associate agreements); 1319 System Replication (for high availability); 1321 Fail-back to Live Systems mechanisms and management; 1323 Recovery Time Objective (RTO) and Recovery Point Objective (RPO); 1325 Encryption (data at rest [DAR], data in motion [DIM], field 1326 level); 1328 Realm-based Access Control; 1330 Service-level Agreements (SLA); and 1332 ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370 1334 These BC/DR systems must handle data backup and recovery, server 1335 backup/recovery, and data center (virtual/physical) backup and 1336 recovery. Recovery as a service (RaaS) means that the BC/DR services 1337 are being handled by management systems outside the enterprise. 1339 The wide variety of BC/DR requires the security management systems to 1340 be able to communicate provisioning, monitor, and control those 1341 systems that are being used to back-up and restore data. An 1342 interoperable protocol that allows provision and control of data 1343 center's data, servers, and data center management devices devices is 1344 extremely important to this application. Recovery as a Service 1345 (SaaS) indicates that these services need to be able to be remotely 1346 management. 1348 The CSA SaaS BC/BR documents indicate how important a standardized 1349 I2NSF protocol is. 1351 6.1.11. Network Security Devices 1353 Document: 1354 https://downloads.cloudsecurityalliance.org/initiatives/secaas/ 1355 SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf 1357 The CSA SaaS Network Security implementation recommendation includes 1358 advice on: 1360 How to segment networks, 1362 Network security controls, 1364 Controlling ingress and egress controls such as Firewalls 1365 (Stateful), Content Inspection and Control (Network-based), 1366 Intrusion Detection System/Intrusion Prevention Systems (IDS/IPS), 1367 and Web Application Firewalls, 1369 Secure routing and time, 1371 Denial of Service (DoS) and Distributed Denial of Service (DDoS) 1372 Protection/Mitigation, 1374 Virtual Private Network (VPN) with Multiprotocol Label Switching 1375 (MPLS) Connectivity (over SSL), Internet Protocol Security (IPsec) 1376 VPNs, Virtual Private LAN Service (VPLS), and Ethernet Virtual 1377 Private Line (EVPL), 1379 Threat Management, 1381 Forensic Support, and 1383 Privileged User/Use Monitoring. 1385 These network security systems require provisioning, monitoring, and 1386 the ability for the security management system to subscribe to 1387 receive logs, snapshots of capture data, and time synchronization. 1388 This document states the following: 1390 "It is critical to understand what monitoring APIs are available 1391 from the CSP, and if they match risk and compliance requirements", 1393 "Network security auditors are challenged by the need to track a 1394 server and its identity from creation to deletion. Audit tracking 1395 is challenging in even the most mature cloud environments, but the 1396 challenges are greatly complicated by cloud server sprawl, the 1397 situation where the number of cloud servers being created is 1398 growing more quickly than a cloud environments ability to manage 1399 them." 1401 A valid threat vector for cloud is the API access. Since a 1402 majority of CSPs today support public API interfaces available 1403 within their networks and likely over the Internet." 1405 The CSA SaaS network security indicates that the I2NSF must be secure 1406 so that the I2NSF Client-Agent protocol does not become a valid 1407 threat vector. In additions, the need for the management protocol 1408 like I2NSF is critical in the sprawl of Cloud environment. 1410 6.2. I2NSF Gap Analysis 1412 The CSA Security as a Service (SaaS) document show clearly that there 1413 is a gap between the ability of the CSA SaaS devices to have a vendor 1414 neutral, inoperable protocol that allow the multiple of network 1415 security devices to communicate passing provisioning and 1416 informational data. Each of the 10 implementation agreements points 1417 to this as a shortage. The I2NSF yang models and protocol is needed 1418 according to the CSA SaaS documents. 1420 7. In-depth Review of IETF protocols 1422 7.1. NETCONF and RESTCONF 1424 The IETF NETCONF working group has developed the basics of the 1425 NETCONF protocol focusing on secure configuration and querying 1426 operational state. The NETCONF protocol [RFC6241] may be run over 1427 TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults 1428 [RFC6243], handling events ([RFC5277] and basic notification 1429 [RFC6470], and filtering writes/reads based on network access control 1430 models (NACM, [RFC6536]). The NETCONF configuration must be 1431 committed to a configuration data store (denoted as config=TRUE). 1432 Yang models identify nodes within a configuration data store or an 1433 operational data store using a XPath expression (document root ---to 1434 --- target source). NETCONF uses an RPC model and provides protocol 1435 for handling configs (get-config, edit-config, copy-config, delete- 1436 config, lock, unlock, get) and sessions (close-session, kill- 1437 session). The NETCONF Working Group has developed RESTCONF, which is 1438 an HTTP-based protocol that provides a programmatic interface for 1439 accessing data defined in YANG, using the datastores defined in 1440 NETCONF. 1442 RESTCONF supports "two edit condition detections" - time stamp and 1443 entity tag. RESTCONF uses a URI encoded path expressions. RESTCONF 1444 provides operations to get remote servers options (OPTIONS), retrieve 1445 data headers (HEAD), get data (GET), create resource/invoke operation 1446 (POST), patch data (PATCH), delete resource (DELETE), or query. 1448 RFCs for NETCONF 1450 o NETCONF [RFC6242] 1452 o NETCONF monitoring [RFC6022] 1454 o NETCONF over SSH [RFC6242] 1456 o NETCONF over TLS [RFC5539] 1458 o NETCONF system notification> [RFC6470] 1460 o NETCONF access-control (NACM) [RFC6536] 1462 o RESTCONF [I-D.ietf-netconf-restconf] 1464 o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home] 1466 o RESTCONF collection protocol 1467 [I-D.ietf-netconf-restconf-collection] 1469 o NETCONF Zero Touch Provisioning [I-D.ietf-netconf-zerotouch] 1471 7.2. I2RS Protocol 1473 Based on input from the NETCONF working group, the I2RS working group 1474 decided to re-use the NETCONF or RESTCONF protocols and specify 1475 additions to these protocols rather than create yet another protocol 1476 (YAP). 1478 The required extensions for the I2RS protocol are in the following 1479 drafts: 1481 o [I-D.ietf-i2rs-ephemeral-state], 1482 o [I-D.ietf-i2rs-pub-sub-requirements] (Publication-Subscription 1483 notifications, 1485 o [I-D.ietf-i2rs-traceability] 1487 o [I-D.ietf-i2rs-protocol-security-requirements] 1489 At this time, NETCONF and RESTCONF cannot handle the ephemeral data 1490 store proposed by I2RS, the publication and subscription 1491 requirements, the traceability, or the security requirements for the 1492 transport protocol and message integrity. 1494 7.3. NETMOD Yang modules 1496 NETMOD developed initial Yang models for interfaces [RFC7223]), IP 1497 address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP 1498 Systems ([RFC7317]) with system ID, system time management, DNS 1499 resolver, Radius client, SSH, syslog 1500 ([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]), 1501 and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing 1502 working group (rtgwg) has begun to examine policy for routing and 1503 tunnels. 1505 Protocol specific Working groups have developed yang models for ISIS 1506 ([I-D.ietf-isis-yang-isis-cfg]), OSPF ([I-D.ietf-ospf-yang]), and BGP 1507 ( merge of [I-D.shaikh-idr-bgp-model] and [I-D.zhdankin-idr-bgp-cfg] 1508 with the bgp policy proposed multiple Working groups (idr and 1509 rtgwg)). BGP Services yang models have been proposed for PPB EVPN 1510 ([I-D.tsingh-bess-pbb-evpn-yang-cfg]), EVPN 1511 ([I-D.zhuang-bess-evpn-yang]), L3VPN ([I-D.zhuang-bess-l3vpn-yang]), 1512 and multicast MPLS/BGP IP VPNs ([I-D.liu-bess-mvpn-yang]). 1514 7.4. COPS 1516 One early focus on flow filtering based on policy enforcement of 1517 traffic entering a network is the 1990s COPS [RFC2748] design (PEP 1518 and PDP) as shown in figure 1. The Policy decision point kept 1519 network-wide policy (E.g. ACLs) and sent it to Policy enforcements 1520 who then would control what data flows between the two These decision 1521 points controlled data flow from PEP to PEP. [RFC3084] describes 1522 COPS use for policy provisioning. 1524 PDP 1525 +-----+ / \ +-----+ 1526 |PEP1 |--/ \---|PEP2 | 1527 | | ACL/policy | | 1528 | | | | 1529 --| ----|------------|-----|----- 1530 +-----+ data flow +-----+ 1532 Figure 11 1534 COPS had a design of Policy Enforcement Points (PEP), and policy 1535 Decision Points (PDP) as shown in figure 11. These decision points 1536 controlled flow from PEP to PEP. 1538 Why COPS is no longer used 1540 Security in the network in 2015 uses specific devices (IDS/IPS, NAT 1541 firewall, etc) with specific policies and profiles for each types of 1542 device. No common protocol or policy format exists between the 1543 policy manager (PDP) and security enforcement points. 1545 COPs RFCs: [RFC4261], [RFC2940], , [RFC3084], , [RFC3483] 1547 Why I2NSF is different COPS 1549 COPS was a protocol for policy related to Quality of Service (QoS) 1550 and signalling protocols (e.g. RSVP) (security, flow, and others). 1551 I2NSF creates a common protocol between security policy decision 1552 points (SPDP) and security enforcement points (SEP). Today's 1553 security devices currently only use proprietary protocols. 1554 Manufacturers would like a security specific policy enforcement 1555 protocol rather than a generic policy protocol. 1557 7.5. PCP 1559 As indicated by the name, the Port Control Protocol (PCP) enables an 1560 IPv4 or IPv6 host to flexibly manage the IP address and port mapping 1561 information on Network Address Translators (NATs) or firewalls, to 1562 facilitate communication with remote hosts. 1564 PCP RFCs: 1566 [RFC6887] 1568 [RFC7225] 1570 [I-D.ietf-pcp-authentication] 1572 [I-D.ietf-pcp-optimize-keepalives] 1574 [I-D.ietf-pcp-proxy] 1576 Why is I2NSF different from PCP: 1578 Here are some aspects that I2NSF is different from PCP: 1580 o PCP only supports the management of port and address information 1581 rather than any other security functions 1583 o Cover the proxy, firewall and NAT box proposals in I2NSF 1585 7.6. NSIS - Next steps in Signalling 1587 NSIS is for standardizing an IP signalling protocol (RSVP) along data 1588 path for end points to request its unique QoS characteristics, unique 1589 FW policies or NAT needs (RFC5973) that are different from the FW/NAT 1590 original setting. The requests are communicated directly to the FW/ 1591 NAT devices. NSIS is like east-west protocols that require all 1592 involved devices to fully comply to make it work. 1594 NSIS is path-coupled, it is possible to message every participating 1595 device along a path without having to know its location, or its 1596 location relative to other devices (this is particularly a pressing 1597 issue when you've got one or more NATs present in the network, or 1598 when trying to locate appropriate tunnel endpoints). 1600 A diagram should be added here showing I2NSF and NSIS 1602 Why I2NSF is different than NSIS: 1604 o The I2NSF requests from clients do not go directly to network 1605 security devices, but instead to controller or orchestrator that 1606 can translate the application/user oriented policies to the 1607 involved devices in the interface that they support. 1609 o The I2NSF request does not require all network functions in a path 1610 to comply, but it is a protocol between the I2NSF client and the 1611 I2NSF Agent in the controller and orchestrator 1613 o I2NSF defines client (applications) oriented descriptors 1614 (profiles, or attributes) to request/negotiate/validate the 1615 network security functions that are not on the local premises. 1617 Why we belief I2NSF has a higher chance to be deployed than NSIS: 1619 o Open Stack already has a proof-of-concept/preliminary 1620 implementation, but the specification is not complete. IETF can 1621 play an active role to make the specification for I2NSF is 1622 complete. IETF can complete and extend the OpenStack 1623 implementation to provide an interoperable specification that can 1624 meet the needs and requirements of operators and is workable for 1625 suppliers of the technology. The combination of a carefully 1626 designed interoperable IETF specification with an open-source code 1627 development Open Stack will leverage the strengths of the two 1628 communities, and expand the informal ties between the two groups. 1629 A software development cycle has the following components: 1630 architecture, design specification, coding, and interoperability 1631 testing. The IETF can take ownership of the first two steps, and 1632 provide expertise and a good working atmosphere (in hack-a-thons) 1633 in the last two steps for OpenSTack or other open-source coders. 1635 o IETF has the expertise in security architecture and design for 1636 interoperable protocols that span controllers/routers, middle- 1637 boxes, and security end-systems. 1639 o IETF has a history of working on interoperable protocols or 1640 virtualized network functions (L2VPN, L3VPN) that are deployed by 1641 operators in large scale devices. IETF has a strong momentum to 1642 create virtualized network functions (see SFC WG in routing) to be 1643 deployed in network boxes. [Note: We need to add SACM and others 1644 here]. 1646 8. IANA Considerations 1648 No IANA considerations exist for this document. 1650 9. Security Considerations 1652 No security considerations are involved with a gap analysis. 1654 10. Contributors 1656 The following people have contributed to this document: Hosnieh 1657 Rafiee. 1659 11. References 1661 11.1. Normative References 1663 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1664 DOI 10.17487/RFC0791, September 1981, 1665 . 1667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1668 Requirement Levels", BCP 14, RFC 2119, 1669 DOI 10.17487/RFC2119, March 1997, 1670 . 1672 11.2. Informative References 1674 [I-D.hares-i2rs-bnp-eca-data-model] 1675 Hares, S., Wu, Q., and R. White, "An Information Model for 1676 Basic Network Policy and Filter Rules", draft-hares-i2rs- 1677 bnp-eca-data-model-03 (work in progress), January 2016. 1679 [I-D.hares-i2rs-info-model-service-topo] 1680 Hares, S., Wu, W., Wang, Z., and J. You, "An Information 1681 model for service topology", draft-hares-i2rs-info-model- 1682 service-topo-03 (work in progress), January 2015. 1684 [I-D.ietf-i2rs-architecture] 1685 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1686 Nadeau, "An Architecture for the Interface to the Routing 1687 System", draft-ietf-i2rs-architecture-11 (work in 1688 progress), December 2015. 1690 [I-D.ietf-i2rs-ephemeral-state] 1691 Haas, J. and S. Hares, "I2RS Ephemeral State 1692 Requirements", draft-ietf-i2rs-ephemeral-state-02 (work in 1693 progress), September 2015. 1695 [I-D.ietf-i2rs-problem-statement] 1696 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1697 Routing System Problem Statement", draft-ietf-i2rs- 1698 problem-statement-09 (work in progress), January 2016. 1700 [I-D.ietf-i2rs-protocol-security-requirements] 1701 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1702 Related Requirements", draft-ietf-i2rs-protocol-security- 1703 requirements-02 (work in progress), December 2015. 1705 [I-D.ietf-i2rs-pub-sub-requirements] 1706 Voit, E., Clemm, A., and A. Prieto, "Requirements for 1707 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 1708 requirements-04 (work in progress), January 2016. 1710 [I-D.ietf-i2rs-rib-data-model] 1711 Wang, L., Ananthakrishnan, H., Chen, M., 1712 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1713 YANG Data Model for Routing Information Base (RIB)", 1714 draft-ietf-i2rs-rib-data-model-04 (work in progress), 1715 November 2015. 1717 [I-D.ietf-i2rs-rib-info-model] 1718 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1719 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 1720 in progress), October 2015. 1722 [I-D.ietf-i2rs-traceability] 1723 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1724 the Routing System (I2RS) Traceability: Framework and 1725 Information Model", draft-ietf-i2rs-traceability-06 (work 1726 in progress), January 2016. 1728 [I-D.ietf-i2rs-usecase-reqs-summary] 1729 Hares, S. and M. Chen, "Summary of I2RS Use Case 1730 Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 1731 (work in progress), May 2015. 1733 [I-D.ietf-i2rs-yang-l2-network-topology] 1734 Dong, J. and X. Wei, "A YANG Data Model for Layer-2 1735 Network Topologies", draft-ietf-i2rs-yang-l2-network- 1736 topology-02 (work in progress), December 2015. 1738 [I-D.ietf-i2rs-yang-network-topo] 1739 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 1740 and H. Ananthakrishnan, "A Data Model for Network 1741 Topologies", draft-ietf-i2rs-yang-network-topo-02 (work in 1742 progress), December 2015. 1744 [I-D.ietf-isis-yang-isis-cfg] 1745 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 1746 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 1747 isis-yang-isis-cfg-02 (work in progress), March 2015. 1749 [I-D.ietf-netconf-call-home] 1750 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1751 draft-ietf-netconf-call-home-06 (work in progress), May 1752 2015. 1754 [I-D.ietf-netconf-restconf] 1755 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1756 Protocol", draft-ietf-netconf-restconf-04 (work in 1757 progress), January 2015. 1759 [I-D.ietf-netconf-restconf-collection] 1760 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1761 Collection Resource", draft-ietf-netconf-restconf- 1762 collection-00 (work in progress), January 2015. 1764 [I-D.ietf-netconf-zerotouch] 1765 Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch 1766 Provisioning for NETCONF Call Home (ZeroTouch)", draft- 1767 ietf-netconf-zerotouch-02 (work in progress), March 2015. 1769 [I-D.ietf-netmod-acl-model] 1770 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 1771 "Network Access Control List (ACL) YANG Data Model", 1772 draft-ietf-netmod-acl-model-02 (work in progress), March 1773 2015. 1775 [I-D.ietf-netmod-routing-cfg] 1776 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1777 Management", draft-ietf-netmod-routing-cfg-19 (work in 1778 progress), May 2015. 1780 [I-D.ietf-netmod-syslog-model] 1781 Wildes, C. and K. Sreenivasa, "SYSLOG YANG model", draft- 1782 ietf-netmod-syslog-model-03 (work in progress), March 1783 2015. 1785 [I-D.ietf-ospf-yang] 1786 Yeung, D., Qu, Y., Zhang, J., Bogdanovic, D., and K. 1787 Sreenivasa, "Yang Data Model for OSPF Protocol", draft- 1788 ietf-ospf-yang-00 (work in progress), March 2015. 1790 [I-D.ietf-pcp-authentication] 1791 Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port 1792 Control Protocol (PCP) Authentication Mechanism", draft- 1793 ietf-pcp-authentication-09 (work in progress), May 2015. 1795 [I-D.ietf-pcp-optimize-keepalives] 1796 Reddy, T., Patil, P., Isomaki, M., and D. Wing, 1797 "Optimizing NAT and Firewall Keepalives Using Port Control 1798 Protocol (PCP)", draft-ietf-pcp-optimize-keepalives-06 1799 (work in progress), May 2015. 1801 [I-D.ietf-pcp-proxy] 1802 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 1803 Cheshire, "Port Control Protocol (PCP) Proxy Function", 1804 draft-ietf-pcp-proxy-08 (work in progress), May 2015. 1806 [I-D.ietf-sacm-architecture] 1807 Cam-Winget, N., Lorenzin, L., McDonald, I., and l. 1808 loxx@cisco.com, "Secure Automation and Continuous 1809 Monitoring (SACM) Architecture", draft-ietf-sacm- 1810 architecture-03 (work in progress), March 2015. 1812 [I-D.ietf-sacm-terminology] 1813 Waltermire, D., Montville, A., Harrington, D., Cam-Winget, 1814 N., Lu, J., Ford, B., and M. Kaeo, "Terminology for 1815 Security Assessment", draft-ietf-sacm-terminology-06 (work 1816 in progress), February 2015. 1818 [I-D.kini-i2rs-fb-rib-info-model] 1819 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 1820 R., Bogdanovic, D., Tantsura, J., and R. White, "Filter- 1821 Based RIB Information Model", draft-kini-i2rs-fb-rib-info- 1822 model-02 (work in progress), October 2015. 1824 [I-D.l3vpn-service-yang] 1825 Litkowski, S., Shakir, R., Tomotaki, L., and K. D'Souza, 1826 "YANG Data Model for L3VPN service delivery", draft-l3vpn- 1827 service-yang-00 (work in progress), February 2015. 1829 [I-D.liu-bess-mvpn-yang] 1830 Liu, Y. and F. Guo, "Yang Data Model for Multicast in 1831 MPLS/BGP IP VPNs", draft-liu-bess-mvpn-yang-00 (work in 1832 progress), April 2015. 1834 [I-D.shaikh-idr-bgp-model] 1835 Shaikh, A., D'Souza, K., Bansal, D., and R. Shakir, "BGP 1836 Model for Service Provider Networks", draft-shaikh-idr- 1837 bgp-model-01 (work in progress), March 2015. 1839 [I-D.shaikh-rtgwg-policy-model] 1840 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 1841 "Routing Policy Configuration Model for Service Provider 1842 Networks", draft-shaikh-rtgwg-policy-model-01 (work in 1843 progress), July 2015. 1845 [I-D.tsingh-bess-pbb-evpn-yang-cfg] 1846 Tiruveedhula, K., Singh, T., Sajassi, A., Kumar, D., and 1847 L. Jalil, "YANG Data Model for PBB EVPN protocol", draft- 1848 tsingh-bess-pbb-evpn-yang-cfg-00 (work in progress), March 1849 2015. 1851 [I-D.zhang-i2rs-l1-topo-yang-model] 1852 Zhang, X., Rao, B., and X. Liu, "A YANG Data Model for 1853 Layer 1 Network Topology", draft-zhang-i2rs-l1-topo-yang- 1854 model-01 (work in progress), March 2015. 1856 [I-D.zhdankin-idr-bgp-cfg] 1857 Alex, A., Patel, K., Clemm, A., Hares, S., Jethanandani, 1858 M., and X. Liu, "Yang Data Model for BGP Protocol", draft- 1859 zhdankin-idr-bgp-cfg-00 (work in progress), January 2015. 1861 [I-D.zhuang-bess-evpn-yang] 1862 Zhuang, S. and Z. Li, "Yang Model for Ethernet VPN", 1863 draft-zhuang-bess-evpn-yang-00 (work in progress), 1864 December 2014. 1866 [I-D.zhuang-bess-l3vpn-yang] 1867 Zhuang, S. and Z. Li, "Yang Data Model for BGP/MPLS IP 1868 VPNs", draft-zhuang-bess-l3vpn-yang-00 (work in progress), 1869 December 2014. 1871 [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, 1872 R., and A. Sastry, "The COPS (Common Open Policy Service) 1873 Protocol", RFC 2748, DOI 10.17487/RFC2748, January 2000, 1874 . 1876 [RFC2940] Smith, A., Partain, D., and J. Seligson, "Definitions of 1877 Managed Objects for Common Open Policy Service (COPS) 1878 Protocol Clients", RFC 2940, DOI 10.17487/RFC2940, October 1879 2000, . 1881 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 1882 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 1883 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 1884 RFC 3084, DOI 10.17487/RFC3084, March 2001, 1885 . 1887 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1888 A. Rayhan, "Middlebox communication architecture and 1889 framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, 1890 . 1892 [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, 1893 "Middlebox Communications (midcom) Protocol Requirements", 1894 RFC 3304, DOI 10.17487/RFC3304, August 2002, 1895 . 1897 [RFC3483] Rawlins, D., Kulkarni, A., Bokaemper, M., and K. Chan, 1898 "Framework for Policy Usage Feedback for Common Open 1899 Policy Service with Policy Provisioning (COPS-PR)", 1900 RFC 3483, DOI 10.17487/RFC3483, March 2003, 1901 . 1903 [RFC3484] Draves, R., "Default Address Selection for Internet 1904 Protocol version 6 (IPv6)", RFC 3484, 1905 DOI 10.17487/RFC3484, February 2003, 1906 . 1908 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1909 Bosch, "Next Steps in Signaling (NSIS): Framework", 1910 RFC 4080, DOI 10.17487/RFC4080, June 2005, 1911 . 1913 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 1914 Service (COPS) Over Transport Layer Security (TLS)", 1915 RFC 4261, DOI 10.17487/RFC4261, December 2005, 1916 . 1918 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1919 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1920 . 1922 [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 1923 Communication (MIDCOM) Protocol Semantics", RFC 5189, 1924 DOI 10.17487/RFC5189, March 2008, 1925 . 1927 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1928 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 1929 . 1931 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 1932 RFC 5539, DOI 10.17487/RFC5539, May 2009, 1933 . 1935 [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1936 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1937 RFC 5973, DOI 10.17487/RFC5973, October 2010, 1938 . 1940 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 1941 Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010, 1942 . 1944 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1945 and A. Bierman, Ed., "Network Configuration Protocol 1946 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1947 . 1949 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1950 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1951 . 1953 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 1954 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 1955 . 1957 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 1958 Update to the IPv6 Flow Label Specification", RFC 6436, 1959 DOI 10.17487/RFC6436, November 2011, 1960 . 1962 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 1963 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 1964 February 2012, . 1966 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1967 Protocol (NETCONF) Access Control Model", RFC 6536, 1968 DOI 10.17487/RFC6536, March 2012, 1969 . 1971 [RFC6639] King, D., Ed. and M. Venkatesan, Ed., "Multiprotocol Label 1972 Switching Transport Profile (MPLS-TP) MIB-Based Management 1973 Overview", RFC 6639, DOI 10.17487/RFC6639, June 2012, 1974 . 1976 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1977 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1978 DOI 10.17487/RFC6887, April 2013, 1979 . 1981 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1982 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1983 . 1985 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1986 Port Control Protocol (PCP)", RFC 7225, 1987 DOI 10.17487/RFC7225, May 2014, 1988 . 1990 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1991 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1992 . 1994 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1995 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1996 2014, . 1998 Authors' Addresses 2000 Susan Hares 2001 Huawei 2002 7453 Hickory Hill 2003 Saline, MI 48176 2004 USA 2006 Email: shares@ndzh.com 2008 Bob Moskowitz 2009 Huawei 2010 Oak Park, MI 48237 2012 Email: rgm@labs.htt-consult.com 2014 Dacheng Zhang 2015 Beijing 2016 China 2018 Email: dacheng.zdc@aliabab-inc.com