Analysis of Existing work for I2NSF

This documents provides a gap analysis for I2NSF.

A Network Security Function (NSF) ensures integrity, confidentiality and availability of network communications, detects unwanted activity, and/or blocks out or at least mitigates the effects of unwanted activity. NSFs are provided and consumed in increasingly diverse environments. For example, users of NSFs could consume network security services offered on multiple security products hosted one or more service provider,their own enterprises, or a combination of the two. The lack of standard interfaces to control and monitor the behavior of NSFs makes it virtually impossible for security service providers to automate service offerings that utilize different security functions from multiple vendors. The Interface to Network Service Functions (I2NSF) work proposes to standardize a set of software interfaces to control and monitor the physical and virtual NSFs. Since different security vendors support different features and functions, the I2NSF will focus on the flow-based NSFs that provide treatment to packets or flows such found in IPS/IDS devices, web filtering devices, flow filtering devices, deep packet inspection devices, pattern matching inspection devices, and re-mediation devices. There are two layers of interfaces envisioned in the I2NSF approach: The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. This is the focus for this phase of the I2NSF Work. The I2NSF Service Layer defines how the security policies of clients may be expressed and monitored. The Service Layer is out of scope for this phase of I2NSF’s work. For the I2NSF Capability Layer, the I2NSF work proposes an interoperable protocol that passes NSF provisioning rules and orchestration information between the I2NSF client on a network manager and the I2NSF agent on an NSF. It is envisioned that clients of the I2NSF interfaces include management applications, service orchestration systems, network controllers, or user applications that may solicit network security resources. The I2NSF work to define this protocol includes the following work: defining an informational model that defines the concepts for standardizing the control and monitoring of NSFs, defining a set of YANG data models from the information model that identifies the data that must be passed, creating a capability registry (an IANA registry) that identifies the characteristics and behaviours of NSFs in vendor-neutral vocabulary without requiring the NSFs to be standardized. examining existing secure communication mechanisms to identify the appropriate ones for carrying the data that provisions and monitors information between the NSFs and their management entity (or entities).

This document provides an analysis of the gaps in the state of art in the following industry forums: IETF working groups (Section 2) ETSI Network Functions Virtualization Industry Specification Group (ETSI NFV ISG), (Section 3) OPNFV Open Source Group (Section 4) Open Stack - Firewall as a service (OpenStack Firewall FaaS) (Section 5) (http://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-agent.html) Cloud Security Alliance Security (CSA)as a Service (Section 6) (https://cloudsecurityalliance.org/research/secaas/#_overview) In-Depth Review of Some IETF Protocols (Section 7)

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant CoAP.

The following are a few definitions out of the terminology draft utilized in this draft. For additional definitions please see: . is a function that is provided as a set of security-related service function. Typically, an NSF may be responsible for detecting unwanted activity and blocking/ mitigating the effect of such unwanted activity in order to fulfil the service requirements. The NSF can help in supporting communication stream integrity and confidentiality. A data center that may/may not be run on the premises of enterprises, but has compute/storage resources that can be requested or purchased by the enterprises. The enterprise is actually getting a virtual data center. The Cloud Security Alliance (CSA) (http://cloudsecurityalliance.org) focuses on adding security to this environment. A specific research topic is security as a service within the cloud data center. Network Security Functions (NSFs) that may be hosted and managed by service providers or a different administrative entity. The term Domain in this draft has the following different connotations in different scenarios: Client--Provider relationship, i.e. client requesting some network security functions from its provider; Domain A - Domain B relationship, i.e. one operator domain requesting some network security functions from another operator domain; or Applications -- Network relationship, i.e. an application (e.g. cluster of servers) requesting some functions from network, etc. The domain context is important because it indicates the interactions the security is focused on. A software instance that implements a network security function that receives provisioning information and requests operational data (e.g. monitoring data) from an I2NSF client. It is also responsible for enforcing the policies that it receives from an I2NSF client. A security client software that utilizes the I2NSF protocol to read, write or change the provisioning network security device via software interface using the I2NSF protocol (denoted as I2RS Agent) I2NSF Client operates within an network management system which serves as a collections and distribution point for security provisioning and filter data.

The IETF gap analysis first examines the IETF mechanisms which have been developed to secure the IP traffic flows through a network. Traffic filters have been defined by IETF specifications at the access points, the middle-boxes, or the routing systems. Protocols have been defined to carry provisioning and filtering traffic between a management system and an IP system (router or host system). Current security work (SACM working group (WG), MILE WG, and DOTS WG) is providing correlation of events monitored with the policy set by filters. This section provides a review the filter work, protocols, and security correlation for monitors.

The earliest filters defined by IETF were access filters which controlled the acceptance of IP packet data flows. Additional policy filters were created as part of the following protocols: COPS protocol for controlling access to networks, Next Steps in Signalling (NSIS) work (architecture: protocol: ) - for supporting signaling about a data flow along its path, and Port Control Protocol (PCP) - allows the IPv4/IPv6 host to control how IPv6/IPv4 packets are translated and forwarded by NATS and firewalls. Today NETMOD and I2RS Working groups are specifying additional filters in YANG modules to be used as part of the NETCONF or I2RS enhancement of NETCONF/RESTCONF. Route filtering is outside the scope of the flow filtering, but the flow filtering may be impacted by route filtering. An initial model for routing policy is in This section provides an overview of the flow filtering as an introduction to the I2NSF Gap analysis. Additional detail on NETCONF, NETMOD, I2RS, PCP, and NSIS is available in Section 7.

The current work on expanding these filters is focused oncombining a configuration and monitoring protocol with YANG data models. provides a set of access list filters which can permit or deny traffic flow based on headers at the MAC Layer, IP Layer, and Transport Layer. The configuration and monitoring protocols which can pass the filters are: NETCONF protocol , RESTCONF , and the I2RS protocol. The NETCONF and RESTCONF protocols install these filters into forwarding tables. The I2RS protocol uses the ACLs as part of the filters installed in an ephemeral protocol-independent filter-based RIB which controls the flow of traffic on interfaces specifically controlled by the I2RS filter-based FIB.

netconf +---------------+ / \ +---------------+ | Device: ACLs |-- / \---|Device: ACLS | | I2RS FB RIB | | I2RS FIB RIB | |routing policy | | routing policy| | | | | ===|===============|=============|===============|= +---------------+ data flow +---------------+ Figure 1 The I2RS protocol is a programmatic interface to the routing system. At this time, the I2RS is targeted to be extensions to the NETCONF/RESTCONF protocols to allow the NETCONF/RESTCONF protocol to support a highly programmatic interface with high bandwidth of data, highly reliable notifications, and ephemeral state (see ). See Section 7.2 on I2RS for additional details on I2RS. The vocabulary of the is limited, so additional protocol independent filters has been written for the I2RS Filter-Based RIBs in . One thing important to note is that NETCONF and RESTCONF manage device layer YANG models. However, as Figure 2 shows, there are multiple device level, network-wide level, and application level YANG modules. The access lists defined by the device level forwarding table may be impacted by the routing protocols, the I2RS ephemeral protocol independent Filter-Based FIB, or some network-wide security issue (IPS/IDS).

+--------------------------------------------+ |Application Network Wide: Intent | +--------------------------------------------+ |Network-wide level: L3SM L3VPN service model| +--------------------------------------------+ |Device level: Protocol Independent: I2RS | | RIB, Topology, Filter-Based RIB | +--------------------------------------------+ |Device Level:Protocol YANG modules | | (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.) +--------------------------------------------+ | Device level: IP and System: NETMOD Models | | (config and oper-state), tunnels, | | forwarding filters | +--------------------------------------------+ Figure 2 Levels of YANG modules

The gap is that none of the current work on these filters considers all the variations of data necessary to do IPS/IDS, web-filters, stateful flow-based filtering, security-based deep packet inspection, or pattern matching with re-mediation. The I2RS Filter-Based RIB work is the closest associated work, but the focus has not been on IDS/IPS, web-filters, security-based deep packet inspection, or pattern matching with re-mediation. The I2RS Working group (I2RS WG) is focused on the routing system so the requisite security expertise for such NSFs (IDP/IPS, Web-filter, security-based deep-packet inspection, etc.) has not been targeted for this WG. Another gap is there is no capability registry (an IANA registry) that identifies the characteristics and behaviours of NSFs in vendor-neutral vocabulary without requiring the NSFs to be standardized. What I2NSF can use from NETCONF/RESTCONF and I2RS I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS proposed enhancement to the NETCONF/RESTCONF protocol.

Midcom Summary: MIDCOM developed the protocols for applications to communicate with middle boxes. However, MIDCOM have not been used by the industry for a long time. A main reason is that MIDCOM had a lot of IPR encumbered technology and IPR was likely a bigger problem for IETF at that time than it is today. MIDCOM is not specific to SIP. It was very much oriented to NAT/FW devices. SIP was just one application that needed the functionality. MIDCOM is reservation-oriented and there was an expectation that the primary deployment environment would be VoIP and real-time conferencing, including SIP, H.323, and other reservation-oriented protocols. There was an assumption that there would be some authoritative service that would have a view into endpoint sessions and be able to authorize (or not) resource allocation requests. In other words, there is a trust model in MIDCOM that may not be applicable to endpoint-driven requests without some sort of trusted authorization mechanisms/tools. Therefore, there is a specific information model applied to security devices, and security device requests, that was developed in the context of an SNMP MIB. There is also a two-stage reservation model, which was specified in order to allow better resource management. Why I2NSF is Different from Midcom MIDCOM is different from I2NSF because its SNMP scheme does not work with the virtual network security functions (vNSF) management. MidCom RFCs: - Midcom architecture - Midcom Protocol Semantics - Midcom protocol requirements

Today's NSFs in security devices can handle flow-based security by providing treatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and re-mediation. These flow-based security devices are managed and provisioned by network management systems. No standardized set of interoperable interfaces control and manage the NSFs so that a central management system can be used across security devices from multiple Vendors. I2NSF work plan is to standardize a set of interfaces by which control and management of NSFs may be invoked, operated, and monitored by: Creating an information model that defines concepts required for standardizing the control and monitoring of NSFs, and from the information model create data models. (The information model will be used to get early agreement on key technical points.) Creating a capability registry (at IANA) that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized. Defining the requirements for an I2NSF protocol to pass this traffic. (Ideally by re-using existing protocols.) The flow-filtering configuration and management must fit into the existing security area's work plan. This section considers how the I2NSF fits into the security area work under way in the SACM (Security Automation and Continuous Monitoring), DOTS (DDoS Open Threat Signalling), and MILE (Management Incident Lightweight Exchange).

In the proposed I2NSF work plan, the I2NSF security network management system controls many NSF nodes via the I2NSF Agent. This control of data flows is similar to the COPS example in Section 7.4.

+------------+ | I2NSF | | Client | | | | security | | NMS system | +------------+ +-----+ / \ +-----+ |I2NSF|--/ \---|I2NSF| |Agent| |Agent| | | | | | NSF | | NSF | --| ----|------------|-----|----- +-----+ data flow +-----+ Figure 2 The other security protocols work to interact within the network to provide additional information in the following way: SACM describes an architecture which tries to determine if the end-point security policies and the reality (denoted as security posture) align. defines posture as the configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy. Filters can be considered on the configuration or status pieces that needs to be monitored. DOTS (DDoS Open Threat Signalling) - is working on coordinating the mitigation of DDoS attacks. A part of DDoS attach mitigation is to provide lists of addresses to be filtered via IP header filters. MILE (Managed Incident Lightweight Exchange) - is working on creating a standardized format for incident and indicator reports, and creating a protocol to transport this information. The incident information MILE collects may cause changes in data-flow filters on one or more NSFs.

The network management system that the I2NSF client resides on may interact with other clients or agents developed for the work ongoing in the SACM, DOTS, and MILES working groups. This section describes how the addition of I2NSF's ability to control and monitor NSF devices is compatible and synergistic with these existing efforts.

+----------+ +------+ +--------+ | security |====| DOTS | |SACNM | | NMS | |client|---+ |consumer| |..........|\ +------+ | +--------+==|SACM *1 | \ | +----|repository| \ | | |..........| +-------+ | | | I2NSF | |MILES | | +------|-+ | client | |client | | |SACM | +----------+ +-----:-+ | |Info. | / \ : | |provider| / \ : | +--------+ / \ : | +-----+ / \ +-----+ : | |I2NSF|--/ \---|I2NSF| : | | | | | : | | | |MILES|.: | | | |Agent| | | | |DOTS | | | | |Agent|-------+ --| ----|----------------|-----|----- +-----+ data flow +-----+ *1 - this is the SACM Controller (CR) with its broker/proxy/repository show as described in the SACM architecture. Figure 3 Figure 3 provides a diagram of a system in which the I2NSF, SACM, DOTS and MILE client-agent or consumer-broker-provider are deployed together. The following are possible positive interactions these scenario might have: An security network management system (NMS) can contain a SACM repository and be connected to SACM information providers and SACM consumers. The I2NSF may provide one of the ways to change the forwarding filters. The security NMS may also be connected to DOTS DDoS clients managing the information and configuring the rules. The I2NSF may provide one of the ways to change forwarding filters. The MILE client on a security network management system talking to the MILE agent on the node may react to the incidents by using I2NSF to set filters. DOTS creates black-lists, but does not have a complete set of filters.

I2NSF's ability to provide a common interoperable and vendor neutral interface may allow the security NMS to use a single change to change filters. SACM provides an information model to describe end-points, but does not link this directly to filters. DOTS creates black-lists based on source and destination IP address, transport port number, protocol ID, and traffic rate. Like ACLs defined NETMOD, the DOTS black-lists are not sufficient for all filters or control desired by the NSF boxes. The incident data captured by MILE will not have enough filter information to provide NSF devices with general services. The I2NSF will be able to handle the MILE incident data and create alerts or reports for other security systems.

Network Functions Virtualization (NFV) provides service providers with flexibility, cost effective and agility to offer their services to customers. One such service is the network security function which guards the exterior of a service provider or its customers. However, the exterior network beyond the service provider NSFs or its customer's NSFs is becoming extremely narrow as NSFs are becoming more pervasive in any portion of networks (service providers, customers, or access networks). The flexibility and agility of NFV encourages service providers to provide different products to address business trends in their market to provide better service offerings to their end user. A traditional product such as the network security function (NSF) may be broken into multiple virtual devices each hosted from another vendor. In the past, network security devices may have been sourced from a small set of vendors - but in the NFV version of NSF devices, this reduced set of sources will not provide a competitive edge. Due to this market shift, the network security vendors are realizing that the proprietary provisioning protocols and formats of data may be a liability. Out of the NFV work has arisen a desire for a single interoperable network security device provisioning and control protocol. The I2NSF framework is complementary to the NFV and other security frameworks. The I2NSF management protocol will be deployed in networks to provide a common management protocol to manage NSF software/devices whether the devices are physical or virtual. The ETSI NFV security is also deployed along-side other security functions (AAA, SACM, DOTS, or MILE devices) and deep-packet stateful inspections. The ETSI Network Functions Virtualization: NFV security: Security and Trust Guidance document (ETSI NFV SEC 003 1.1.1 (2014-12)) indicates that multiple administrative domains will deployed in carrier networks. One example of these multiple domains is hosting of multiple tenant domains (telecom service providers) on a single infrastructure domain (infrastructure service) as Figure 4 shows. The ETSI Inter-VNFM document (aka Ve-Vnfn) between the element management system and the Virtual network function is the equivalent of the interface between the I2NSF client on a management system and the I2NSF agent on the network security feature VNF.

.................... +--: OSS/BSS : | .................... | | +-------------------------+ | | | | | ........ ........ | | | : EMS1 : : EMS : | ETSI inter-VNFM | | ....||... ...||... | (Ve-Vnfn) | | || || ==========I2NSF interface | | ....||... ...||... | | | : VNF1 : : VNF1 : | Tenant domain | | ....||... ...||... | ''''''''||'''''''''||'''''''''' | | ....||..... ...||...... | infrastructure | | :virtual : :virtual : | domain | | :computing: :computing: | with virtual | | ........... ........... | network | | +=====================+ --------- | | | virtualization layer| | | | +=====================+ | | | ........... .......... .......... | |====:computing: :storage : :network : | | :hardware : :hardware: :hardware: | | ........... .......... .......... | | hardware resources | +-----------------------------------+ Figure 4 The ETSI proof-of-concept demonstrations have been done for the security proof of concepts: #16 - NFVIaaS with Secure, SDN controlled WAN Gateway,

The I2NSF protocol/interface can be deployed for security devices along-side the network/host configuration done by NETCONF/RESTCONF or the routing system interface provided by I2RS that handles. In the current NFV-related architecture, there is no interoperable protocol defined between a security manager and various NSF devices to provision security functions. The result is that service providers have to manage the interoperability security manager and different NSF devices using proprietary protocols. In response to this problem, the device manufacturers and the service providers have begun to discuss an I2NSF protocol for interoperable passing of provisioning and filter in formation. Open source work (such as OPNFV) provides a common code base on which providers may start their NFV development work. However, this code base faces the same problem. There is no defacto standard protocol.

The OPNFV (www.opnfv.org) is a carrier-grade integrated, open source platform focused on accelerating the introduction of new Network Functions Virtualization (NFV) products and service. The OPNFV Moon project is focused on adding the security interface for a network management system within the tenant NFVs and the infrastructure NFVs (as shown in Figure 4). This section provides an overview of the OPNFV Moon project and a gap analysis between I2NSF and the OPNFV Moon Project.

The OPNFV Moon project (https://wiki.opnfv.org) is a security management system. NFV uses cloud computing technologies to virtualize the resources and automate the control. The Moon project is working on a security manager for the cloud computing infrastructure (https://wiki.opnfv.org/moon). The Moon project proposes to provision a set of different cloud resources/services for VNFs (Virtualized Network Functions) while managing the isolation of VNS, protection of VNFs, and monitoring of VNS. Moon is creating a security management system for OPNFV with security managers to protect different layers of the NFV infrastructure. The Moon project is choosing various security project mechanisms “a la carte” to enforcement related security managers. A security management system integrates mechanisms of different security aspects. This project intends propose a security manager that specifies users’ security requirements. It will also enforce the security managers through various mechanisms like authorization for access control, firewall for networking, isolation for storage, logging for tractability, etc. The Moon security manager operates a VNF security manager at the ETSI VeVnfm level where the I2NSF protocol is targeted as Figure 5 shows. This figure also shows how the OPNFV VNF Security project mixes the I2NSF level with the device level. The Moon project lists the following gaps in OpenStack: No centralized control for compute, storage, and networking. Open Stack uses Nova for compute and Swift for object storage. Each system has a configuration file and its own security policy. The system lacks a synchronization mechanism to build a complete secure configuration for OPNFV. No dynamic control so that if a user obtains the token, so there is no way to obtain control over the user. No customization or flexibility to allow integration into different vendors, No fine grained authorization at user level. Authorization is only at the API level. Moon addresses these issues adding authorization, logging, IDS, enforcement of network policy, and storage protection. Moon release C (2016) plans to: Define an identity federation scenario between OpenStack and OpenDaylight, Implement an authentication driver in ODL to delegate authentication to OpenStack/Keystone, Implement a command line tool for administration and testing, Implement a graphic interface for identity management for both OpenStack and OpenDaylight, Set up identity federation testbed, Define identity federation scenarios with other SDN controllers, and Define authorization federation scenarios with OpenDaylight. Deliverable time frame: Moon Release 3 (mid-year 2016)

.................... +--: OSS/BSS : | .................... | | +-------------------------+ | | | | | ........ ........ | | | : EMS1 : : EMS : | ETSI inter-VNFM | | ....||... ...||... | (Ve-Vnfn) | | || || ==========I2NSF interface | | ....||... ...||... | Moon VNF === Moon VNF | | : : : : | Security Security MGR | | : VNF1 : : VNF1 : | | | ....||... ...||... | Tenant domain ''''''''||'''''''''||'''''''''' | | ....||..... ...||...... | infrastructure | | :virtual : :virtual : | domain | | :computing: :computing: | with virtual | | ........... ........... | network | | +=====================+ |-------- | | | virtualization layer| | | | +=====================+ | | =============Moon VNF ===Moon VI | | security project Security MGR | | ........... .......... .......... | |====:computing: :storage : :network : | | :hardware : :hardware: :hardware: | | ........... .......... .......... | | hardware resources | +-----------------------------------+ Figure 5

OpenStack Congress does not provide vendor independent systems.

OpenStack has advanced features of: a) API for managing security groups (http://docs.openstack.org/admin-guide-cloud/content/section_securitygroups.html) and b) firewalls as a service (http://docs.openstack.org/admin-guide-cloud/content/fwaas_api_abstractions.html). This section provides an overview of this open stack work, and a gap analysis of how I2NSF provides additional functions

The security group rules provide ingress and egress traffic filters based on port. The default rule for the group policy drops all ingress traffic and allows all egress traffic. The group policy allows users to add additional groups with additional filters that change the default behaviour. To utilize the security groups, the networking plug-in for OpenStack must implement the security group API. The following plug-ins in OpenStack currently implement this security: ML2, Open vSwitch, Linux Bridge, NEC, and VMware NSX. In addition, the correct firewall driver must be added to make this functional.

Firewall as a service is an early release of an API that allows early adopters to test network implementations. It contains APIs with parameters for firewall rules, firewall policies, and firewall identifiers. The firewall rules include the following information: identification of rule (id, name, description) identification tenant rule associated with, links to installed firewall policy, IP protocol (TCP, UDP, ICMP, or none) source and destination IP address source and destination port action: allow or deny traffic status: position and enable/disabled The firewall policies include the following information: identification of the policy (id, name, description), identification of tenant associated with, ordered list of firewall rules, indication if policy can be seen by tenants other than owner, and indication if firewall rules have been audited. The firewall table provides the following information: identification of firewall (id, name, description), tenant associated with this firewall, administrative state (up/down), status (active, down, pending create, pending delete, pending update, pending error) firewall policy ID this firewall is associated with

The OpenStack work is preliminary (security groups and firewall as a service). This work does not allow any of the existing network security vendors provide a management interface. The OpenStack work provides an interesting simple set of filters, and may in the future provide some virtual filter service. However, at this time this open source work does not address the need for a single management interfaces for a variety of security devices. Phase 1 of I2NSF is proposes rules that will include Event-Condition-Action matches (ECA) rules with: packet based matches on L2, L3, and L4 headers and/or specific addresses within these headers, and context based matches on schedule state and schedule. basic ations of deny, permit, and mirror, advanced actions of: IPS signature filtering and URL filtering. [Editorial note: do we need more matches or actions?]

The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org) defined security as a service (SaaS) in their Security as a Service working group (SaaS WG) during 2010-2012. The CSA SaaS group defined ten categories of network security (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_V1_0.pdf) and provides implementation guidance for each of these ten categories. This section provides an overview of the CSA SaaS working groups documentation and a gap analysis for I2NSF

The CSA SaaS working group defined the following ten categories, and provided implementation guidance on these categories: Identity Access Management (IAM) (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) Data Loss Prevention (DLP) (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) Web Security (web) (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf), Email Security (email) (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf), Security Assessments (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf), Intrusion Management (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf), Security information and Event Management (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf), Encryption (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf), Business Continuity and Disaster Recovery (BCDR) https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and Network Security (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf). The sections below give an overview these implementation guidelines.

document: (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) The identity management systems include the following services: Centralized Directory Services, Access Management Services, Identity Management Services, Identity Federation Services, Role-Based Access Control Services, User Access Certification Services, Privileged User and Access Management, Separation of Duties Services, and Identity and Access Reporting Services. The IAM device communications with the security management system that controls the filtering of data. The CSA SaaS IAM specification states that interoperability between IAM devices and secure access network management systems is a problem. This 2012 implementation report confirms there is a gap with IAM.

+------------+ +--------+ | IAM device | ---- SLA ------------| secure | | | Access review | access | | | security events | NMS | | | access tracing | | +---||-------+ Audit report +---||---+ || || || +------------------+ || ========== |Filter enforcement|=====|| +------------------+ Figure 6

Document: (https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) The data loss prevention (DLP) services must address: origination verification, integrity of data, confidentiality and access control, accountability, avoiding false positives on detection, and privacy concerns. The CSA SaaS DLP device communications require that it have the enforcement capabilities to do the following: alert and log data loss, delete data on system or passing through, filter out (block/quarantine) data, reroute data, encrypt data

+------------+ +--------+ | DLP device | ---- SLA ------------| secure | | | Alert and log | access | | | delete data | NMS | | | filter/reroute | | +---||-------+ encrypt data +---||---+ || || || +------------------+ || ========== |Filter enforcement|=====|| +------------------+ Figure 7

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf The web security services must address: Web 2.0/Social Media controls, Malware and Anti-Virus controls, Data Loss Prevention controls (over Web-based services like Gmail or Box.net), XSS, JavaScript and other web specific attack controls Web URL Filtering, Policy control and administrative management, Bandwidth management and quality of service (QoS) capability, and Monitoring of SSL enabled traffic. The CSA SaaS Web services device communications require that it have the enforcement capabilities to do the following: alert and log malware or anti-virus data patterns, delete data (malware and virus) passing through systems, filter out (block/quarantine) data, filter Web URLs, interact with policy and network management systems, control bandwidth and QoS of traffic, and monitor encrypted (SSL enabled) traffic, All of these features either require the I2NSF standardized I2NSF client to I2NSF agent to provide multi-vendor interoperability.

+------------+ +--------+ |Web security| ---- SLA ------------| secure | | | Alert and log | access | | | delete data | NMS | | | filter/reroute data | | | | ensure bandwidth/QOS | | | | monitor encrypted | | | | data | | +---||-------+ encrypt data +---||---+ || || || +------------------+ || ========== |Filter enforcement|=====|| +------------------+ Figure 8

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf The CSA Document recommends that email security services must address: Common electronic mail components, Electronic mail architecture protection, Common electronic mail threats, Peer authentication, Electronic mail message standards, Electronic mail encryption and digital signature, Electronic mail content inspection and filtering, Securing mail clients, and Electronic mail data protection and availability assurance techniques The CSA SaaS Email security services requires that it have the enforcement capabilities to do the following: provide the malware and spam detection and removal, alert and provide rapid response to email threats, identify email users and secure remote access to email, do on-demand provisioning of email services, filter out (block/quarantine) email data, know where the email traffic or data is residing (to to regulatory issues), and be able to monitor encrypted email, be able to encrypt email, be able to retain email records (while abiding with privacy concerns), and interact with policy and network management systems. All of these features require the I2NSF standardized I2NSF client to I2NSF agent to provide multi-vendor interoperability.

+------------+ +--------+ | Email | ---- SLA ------------| secure | | security | alert/log malware | access | | | alert/log email spam | NMS | | | filter/reroute data | | | | ensure bandwidth/QOS | | | | monitor encrypted | | | | data | | +---||-------+ encrypt data +---||---+ || || || +------------------+ || ========== |Filter enforcement|=====|| +------------------+ Figure 9

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf The CSA SaaS Security assessment indicates that assessments need to be done on the following devices: hypervisor infrastructure, network security compliance systems, Servers and workstations, applications, network vulnerabilities systems, internal auditor and intrusion detection/prevention systems (IDS/IPS), and web application systems. All of these features require the I2NSF working group standardize the way to pass these assessments to and from the I2NSF client on the I2NSF management system and the I2NSF Agent.

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf) The CSA SaaS Intrusion detection management includes intrusion detection through: devices: Network traffic inspection, behavioural analysis, and flow analysis, Operating System, Virtualization Layer, and Host Process Events monitoring, Monitoring of Application Layer Events, and Correlation Techniques, and other Distributed and Cloud-Based Capabilities Intrusion response includes both: Automatic, Manual, or Hybrid Mechanisms, Technical, Operational, and Process Mechanisms. The CSA SaaS recommends the intrusion security management systems include provisioning and monitoring of all of these types of intrusion detection or intrusion protection devices. Management of these systems requires: Central reporting of events and alerts, Administrator notification of intrusions, Mapping of alerts to Cloud-Layer Tenancy, Cloud sourcing information to prevent false positives in detection, and Allowing for redirection of traffic to allow remote storage or transmission to prevent local evasion. In order to be able performing these management actions on NSF devices from different vendors, the intrusion security management systems need a standard mangement protocol that all the NSF vendors support.

+------------+ +--------+ | IDS/IPS | ---- Info ----------| secure | | security | alert/log intrusion | access | | | notify administrator | NMS | | | Map alerts to Tenant | | | |filter/reroute traffic| | | | remote data storage | | +---||-------+ +---||---+ || || || +------------------+ || ========== |Filter enforcement|=====|| +------------------+ Figure 10 The I2NSF manager - I2NSF (server/agent) protocol is designed to fill this gap.

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf) The Security Information and Event Management (SIEM) receives data from a wide range of security systems such as Identity management systems (IAM), data loss prevention (DLP), web security (Web), email security (email), intrusion detection/prevision (IDS/IPS)), encryption, disaster recovery, and network security. The SIEM combines this data into a single streams. All the requirements for data to/from these systems are replicated in these systems needs to give a report to the SIEM system. A SIEM system would be a prime candidate to have an I2NSF client that gathers data from an I2NSF Agent associated with these various types of security systems. The CSA SaaS SIEM functionality document suggests that one concern is to have standards that allow timely recording and sharing of data. I2NSF can provide this.

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf The CSA SaaS encryption implementation guidance document considers how one implements and manages the following security systems: Key management systems (KMS), control of keys, and key life cycle; Shared Secret encryption (Symmetric ciphers), No-Secret or Public Key Encryption (asymmetric ciphers), Hashing algorithms, Digital Signature Algorithms, Key Establishment Schemes, Protection of Cryptographic Key Material (FIPS 140-2; 140-3), Interoperability of Encryption Systems, Key Conferencing, Key Escrow Systems, and others Application of Encryption for Data at rest, data in transit, and data in use; PKI (including certificate revocation “CRL”); Future application of such technologies as Homomorphic encryption, Quantum Cryptography, Identity-based Encryption, and others; Crypto-system Integrity (How bad implementations can under mind a crypto-system), and Cryptographic Security Standards and Guidelines Encryption services typically require that security management systems be able to provision, monitor, and control the systems that are being used to encrypt data. This document indicates in the implementation sections that the standardization of interfaces to/from management systems are key to good key management systems, encryption systems, and crypto-systems.

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf The CSA SaaS Business Continuity and Disaster Recovery (BC/DR) implementation guidance document considers the systems that implement the contingency plans and measures designed and implemented to ensure operational resiliency in the event of any service interruptions. BC/DR systems includes: Business Continuity and Disaster Recovery BC/DR as a Service, including categories such as complete Disaster Recovery as a Service (DRaaS), and subsets such as file recovery, backup and archive, Storage as a Service including object, volume, or block storage; Cold Site, Warm Site, Hot Site backup plans; IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service); Insurance (and insurance reporting programs) Business Partner Agents (business associate agreements); System Replication (for high availability); Fail-back to Live Systems mechanisms and management; Recovery Time Objective (RTO) and Recovery Point Objective (RPO); Encryption (data at rest [DAR], data in motion [DIM], field level); Realm-based Access Control; Service-level Agreements (SLA); and ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370 These BC/DR systems must handle data backup and recovery, server backup/recovery, and data center (virtual/physical) backup and recovery. Recovery as a Service (RaaS) means that the BC/DR services are being handled by management systems outside the enterprise. BC/DR requires security management systems to be able to communicate provisioning, monitor, and control those systems that are being used to back-up and restore data. An interoperable protocol that allows provision and control of data center's data, servers, and data center management devices devices is extremely important to this application. Recovery as a Service (SaaS) indicates that these services need to be able to be remotely management. The CSA SaaS BC/BR documents indicate how important a standardized I2NSF protocol is.

Document: https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf The CSA SaaS Network Security implementation recommendation includes advice on: How to segment networks, Network security controls, Controlling ingress and egress controls such as Firewalls (Stateful), Content Inspection and Control (Network-based), Intrusion Detection System/Intrusion Prevention Systems (IDS/IPS), and Web Application Firewalls, Secure routing and time, Denial of Service (DoS) and Distributed Denial of Service (DDoS) Protection/Mitigation, Virtual Private Network (VPN) with Multiprotocol Label Switching (MPLS) Connectivity (over SSL), Internet Protocol Security (IPsec) VPNs, Virtual Private LAN Service (VPLS), and Ethernet Virtual Private Line (EVPL), Threat Management, Forensic Support, and Privileged User/Use Monitoring. These network security systems require provisioning, monitoring, and the ability for the security management system to subscribe to receive logs, snapshots of capture data, and time synchronization. This document states the following: "It is critical to understand what monitoring APIs are available from the CSP, and if they match risk and compliance requirements", "Network security auditors are challenged by the need to track a server and its identity from creation to deletion. Audit tracking is challenging in even the most mature cloud environments, but the challenges are greatly complicated by cloud server sprawl, the situation where the number of cloud servers being created is growing more quickly than a cloud environments ability to manage them." A valid threat vector for cloud is the API access. Since a majority of CSPs today support public API interfaces available within their networks and likely over the Internet." The CSA SaaS network security indicates that the I2NSF must be secure so that the I2NSF Client-Agent protocol does not become a valid threat vector. In additions, the need for the management protocol like I2NSF is critical in the sprawl of Cloud environment.

The CSA Security as a Service (SaaS) document show clearly that there is a gap between the ability of the CSA SaaS devices to have a vendor neutral, inoperable protocol that allow the multiple of network security devices to communicate passing provisioning and informational data. Each of the 10 implementation agreements points to this as a shortcoming. Standard I2NSF YANG models and an I2NSF protocol are needed according to the CSA SaaS documents.

802.1x defines encapsulation of Extensible Authentication Protocol (EAP) over IEEE 802 (EAP over LAN, or EAPOL). It is widely deployed on both wired and Wi-Fi Networks. EAP provides support for security from passwords to challenge-response tokens and public-key infrastructure certificates. 802.1 has three concepts: the supplicant - the user or client who wants to be authenticated authentication server - the server doing the authrentication (e.g. radius server), and the authenticator - the device in-between authentication server and supplicant (e.g. wireless Access Point (AP). A normal sequence is below:

supplicant authenticator authentication server =========== =================== ======================== <---- EAP-Request/Identity EAP-Response/Identity----> EAP-Response/Identity---gt; <---------Challenge <------Challenge Challenge response ---------> Challenge Response ---------> Gap: This basic service provides access, but today's access use cases are more complex. IEEE 801.X has ben attched using the Man-in-the-middle attacks. Another weakness of 802.1X is the speed of the EAP protocols processing with the radius server. Note: Editor - more is needed here

MACsec security secures a link rather than a conversation for 802.1 LANs (VLANs 802.1Q, Provider Bridges 802.1AD). MACsec counters the 802.1X man-in the middle attacks. MACsec (in 802.1AE) provides MAC-layer encryption over wired networks by using out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) Protocol provides the required session keys and manages the required encryption keys. MKA and MACsec are implemented after successful authentication using the 802.1x Extensible Authentication Protocol (EAP) framework. Only hosts link which face the network can be secured with MACSec. These links connect the host to the network access devices. Switch using MACsec accepts either MACsec or non-MACsec frames based on policy set. The NSF controller can set within the switches configuration whether MACSec frames are accepted. Accepted MACsec frames are encrypted and protected with an integrity check value (ICV). The switch after receiving frames from the client, decrypts them and calculates the correct ICV by using session keys provided by MKA. The switch compares that ICV to the ICV within the frame. If they are not identical, the frame is dropped. The switch also encrypts and adds an ICV to any frames sent over the secured port (the access point used to provide the secure MAC service to a client) using the current session key. The MKA Protocol manages the encryption keys used by the underlying MACsec protocol. The basic requirements of MKA are defined in 802.1x-REV. The MKA Protocol extends 802.1x to allow peer discovery with confirmation of mutual authentication and sharing of MACsec secret keys to protect data exchanged by the peers. MKA protocol ues EAP-over-LAN (EAPOL) packet. EAP authentication produces a master session key (MSK) shared by both partners in the data exchange. Entering the EAP session ID generates a secure connectivity association key name (CKN). Because the switch is the authenticator, and the key serer, it can generating a random 128-bit secure association key (SAK), which it sends it to the client partner. The client is never a key server and can only interact with a single MKA entity, the key server. After key derivation and generati Gap Analysis: I2NSF Devices must handle the existence of MSEC within the network.

802.1AR does the following: Supports trail of trust from manufacturer to user, and Defines how a Secure Device Identifier (DevId) may be cryptographically bound to a device to support device identity authentication. DevIDs are composed of a secure device identifier secret and a secure device identifier credential. These IDs can be controlled by the product manufacturer (IDevID, an initially installed identity) or by the end-user (LDevID, a subsequent locally significant identity derived from the IDevID). DevIDs cannot be be changed by the end-user. One attack mitigation can be to disable support for DeVIDs or limit to know DeVIDs. GAP analysis: I2NSF controllers need to support 802.1AR device management.

The IETF NETCONF working group has developed the basics of the NETCONF protocol focusing on secure configuration and querying operational state. The NETCONF protocol may be run over TLS or SSH (. NETCONF can be expanded to defaults , handling events ( and basic notification , and filtering writes/reads based on network access control models (NACM, ). The NETCONF configuration must be committed to a configuration data store (denoted as config=TRUE). YANG models identify nodes within a configuration data store or an operational data store using a XPath expression (document root ---to --- target source). NETCONF uses an RPC model and provides protocol for handling configs (get-config, edit-config, copy-config, delete-config, lock, unlock, get) and sessions (close-session, kill-session). The NETCONF Working Group has developed RESTCONF, which is an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the data stores defined in NETCONF. RESTCONF supports “two edit condition detections” – time stamp and entity tag. RESTCONF uses URI encoded path expressions. RESTCONF provides operations to get remote servers options (OPTIONS), retrieve data headers (HEAD), get data (GET), create resource/invoke operation (POST), patch data (PATCH), delete resource (DELETE), or query. RFCs for NETCONF NETCONF NETCONF monitoring NETCONF over SSH NETCONF over TLS NETCONF system notification> NETCONF access-control (NACM) RESTCONF NETCONF-RESTCONF call home RESTCONF collection protocol NETCONF Zero Touch Provisioning

Based on input from the NETCONF working group, the I2RS working group decided to re-use the NETCONF or RESTCONF protocols and specify additions to these protocols rather than create yet another protocol (YAP). The required extensions for the I2RS protocol are in the following drafts: , (Publication-Subscription notifications, At this time, NETCONF and RESTCONF cannot handle the ephemeral data store proposed by I2RS, the publication and subscription requirements, the traceability, or the security requirements for the transport protocol and message integrity.

NETMOD developed initial YANG models for interfaces ), IP address (), IPv6 Router advertisement (), IP Systems () with system ID, system time management, DNS resolver, Radius client, SSH, syslog (), ACLS (), and core routing blocks ( The routing working group (rtgwg) has begun to examine policy for routing and tunnels. Protocol specific Working groups have developed YANG models for ISIS (), OSPF (), and BGP (. BGP Services YANG models have been proposed for EVPN , L2VPN , L3VPN and , TEAS working group has proposed , and . MPLS/PCE/CCAMP groups have proposed the following Yang modules: , , , and .

One early focus on flow filtering based on policy enforcement of traffic entering a network is the 1990s COPS design (PEP and PDP) as shown in Figure 11. The COPS policy decision points (PDP) managed network-wide policy (e.g. ACLs) by installing this policy in policy enforcement points (PEPs) on the edge of the network. These PEPs had firewall-like functions that control what data flows into the network at a PEP point, and data flow out of a network at a PEP. describes COPS usages for policy provisioning.

PDP +-----+ / \ +-----+ |PEP1 |--/ \---|PEP2 | | | ACL/policy | | | | | | --| ----|------------|-----|----- +-----+ data flow +-----+ Figure 11 Why COPS is no longer used Network security today uses specific devices (IDS/IPS, NAT firewall, etc.) with specific policies and profiles for each types of device. No common protocol or policy format exists between the policy manager (PDP) and security enforcement points. COPs RFCs: , , , and . Why I2NSF is Different from COPS COPS was a protocol for policy related to Quality of Service (QoS) and signaling protocols (e.g. RSVP) (security, flow, and others). I2NSF creates a common protocol between security policy decision points (SPDP) and security enforcement points (SEP). Today's security devices currently only use proprietary protocols. Manufacturers would like a security specific policy enforcement protocol rather than a generic policy protocol.

As indicated by the name, the Port Control Protocol (PCP) enables an IPv4 or IPv6 host to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts. PCP RFCs: Why is I2NSF Different from PCP: Here are some aspects that I2NSF is different from PCP: PCP only supports management of port and address information rather than any other security functions

NSIS aims to standardize an IP signaling protocol (RSVP) along the data path for end points to request their unique QoS characteristics, unique FW policies or NAT needs (RFC5973) that are different from the FW/NAT original settings. The requests are communicated directly to the FW/NAT devices. NSIS is like east-west protocols that require all involved devices to fully comply to make it work. NSIS is path-coupled; it is possible to message every participating device along a path without having to know its location, or its location relative to other devices (This is particularly a pressing issue when one or more NATs present in the network, or when trying to locate appropriate tunnel endpoints).

clients----I2NSF controller | client | | I2NSF | server/agent +--------+ +--------+ +--------+ | host | |firewall| | host | |device-1|-------|device-2|-------|device-3| +--------+ RSVP +--------+ RSVP +--------+ -----NSIS----------------------- Why I2NSF is Different from NSIS: The I2NSF request does not require all network functions in a path to comply, but it is a protocol between the I2NSF client and the I2NSF Agent/Server I2NSF defines client (applications) oriented descriptors (profiles, or attributes) to request/negotiate/validate the network security functions that are not on the local premises. Why I2NSF may have higher chance to be deployed than NSIS: OpenStack already has a proof-of-concept/preliminary implementation, but the specification is not complete. IETF can play an active role to make the specification for I2NSF is complete. IETF can complete and extend the OpenStack implementation to provide an interoperable specification that can meet the needs and requirements of operators and is workable for suppliers of the technology. The combination of a carefully designed interoperable IETF specification with an open-source code development OpenStack will leverage the strengths of the two communities, and expand the informal ties between the two groups. A software development cycle has the following components: architecture, design specification, coding, and interoperability testing. The IETF can take ownership of the first two steps, and provide expertise and a good working atmosphere (in hack-a-thons) in the last two steps for OpenStack or other open-source coders. IETF has the expertise in security architecture and design for interoperable protocols that span controllers/routers, middle-boxes, and security end-systems. IETF has a history of working on interoperable protocols or virtualized network functions (L2VPN, L3VPN) that are deployed by operators in large scale devices. IETF has a strong momentum to create virtualized network functions (see SFC WG in routing) to be deployed in network boxes. [Note: We need to add SACM and others here].

No IANA considerations exist for this document.

No security considerations are involved with a gap analysis.

The following people have contributed to this document: Hosnieh Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive comments, great suggestions, and valuable insights on alternative views.