Analysis of Existing work for I2NSF

The following sections describes compares the current work in the IETF with the I2NSF. To provide an easier way of reviewing this work, the working groups in the IETF are addressed via Areas of work. The work of each working group (WG) is summarize and compared with I2NSF.

Summary of Anima ANIMA (Autonomic Networking Integrated Model and Approach) introduces a control paradigm where network processes, driven by objectives (or intent), coordinate their local decisions, autonomically translate them into local actions, and adapt them automatically according to various sources of information including external information and protocol information bases. ANIMA first step to is develop the platform that these autonomic network processes can run on. ANIMA will develop protocols to achieve auto discovery among management system and devices. The listed drafts proposed include: The configuration discovery and negotiation protocol designed to be a generic platform, which is independent from the negotiation contents. There are also security aspects being discussed in the ANIMA drafts such as secure messages and keys which are passed among the discovered parties. Diagram of Anima: (TBD) Anima drafts Anima has no WG drafts Why I2NSF is different than ANIMA I2NSF is to develop application /user oriented policies (the attributes, the profiles, or the descriptors) of the network security functions that clients can request/query from 3rd party providers.

COPS had a design of Policy Enforcement Points (PEP), and policy Decision Points (PDP) as shown in figure 3. These decision points controlled flow from PEP to PEP. Why COPS is no longer used Security in the network in 2015 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. As described above, the security policy enforcement has security policy decision points (SPDP) and security enforcement points (SEP). Today's security Policy Decision points exist where policy and services come together in a convenient place to push out SEP. COPs RFCs: , , ,, , Why I2NSF is different COPS COPS was a protocol for all policy (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 proprietary protocols. Manufacturers wold like a security specific policy enforcement protocol rather than a generic policy protocol.

Summary of IETF NETCONF WG 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 , nd 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 datastore 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 datastores defined in NETCONF. RESTCONF supports “two edit condition detections” – time stamp and entity tag. RESTCONF uses a 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. At this time, RESTCONF does not handle the ephemeral datastore proposed by I2RS (see Routing Area) at this time (see I2RS working group for details on I2RS). RESTCONF also does not promise to provide the real-time programmatic interface I2RS requires. 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 ( merge of and with the bgp policy proposed multiple Working groups (idr and rtgwg)). BGP Services yang models have been proposed for PPB EVPN (), EVPN (), L3VPN (), and multicast MPLS/BGP IP VPNs ().

netconf +-------------+ / \ +----------+ |Device:config|-- / \---|Device: | |operational | | Config | |state (oper) | | oper, ACL| | ACL, policy | | routing | | for Routing)| | Policy | --| ------------|-------------|----------|----- +-------------+ data flow +----------+ Figure 4 NETCONF and RESTCONF manage device layer yang models. However as figure 5 shows, there are multiple levels of device levels, network-wide level, and application level yang modules.

+--------------------------------------------+ |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 | +--------------------------------------------+ Figure 5 levels of Yang modules 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 How I2NSF is different than NETCONF NETCONF and RESTCONF are protocol for configuration of routing and IP devices, and monitoring of operational state. I2NSF seeks to create an interoperable protocol to pass security provisioning and filtesr. What I2NSF can use from NETCONF I2NSF should consider using NETCONF/RESTCONF protocol for capability layer to communicate the security data models to the designated security functions.

Beyond the device level yang models for network elements, protocol’s configuration, operational status, or ephemeral state (I2RS), there is the goal of a full system configuration allows deployment of services across networks. Services are built from a combination of network element and protocol configuration, but are specified to service users in more abstract terms. The Layer Three Virtual Private Network Service Model (L3SM) working group is a short-lived WG tasked to create a YANG data model that describes a L3VPN service (a L3VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. This L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. A separate process is responsible for mapping this L3VPN service model (see figure 4) onto the protocols and network elements depending on how the network operator chooses to realize the service. The starting point for this L3VPN model is . Status and Relevance IETF L3SM working is an approved IETF working group with a draft written by authors who are operators at BT, Orange, Verizon, and ATT. This network-wide service model is at a network-wide level of service.

NeMo provides a simple transaction based Intent-based NBI, enabling applications to create, modify and takedown virtual networks built on virtual nodes with policy-controlled flows. The NeMo Intent NBI allows an application to communicate with a controller, providing the following group of commands: entity group: (un)node (un)link, (un)flow capabilities: (un)policy, query, notification, connect, disconnect, commit, and withdraw, model: Node Model, Link Model, and Link model. An application exchanges NeMo commands, using the REST Protocol to a controller running a Nemo language processing engine, to instruct the controller to set up a virtual network of nodes and links with flow policy to control the data flows across the network links. NeMo uses an application’s view of the compute, storage, and network to allow an application to set any grouping of compute, storage, or network as a virtual node. This allows the application to decide what constitutes a compute node and what constitute a link and a flow. From the application’s viewpoint, it intends to connect two or more nodes in a network. It does not matter to the application if the node is a single virtual machine (VM) or a cluster of interconnected compute and storage devices with many network connections. NeMo’s NBI API hides this complexity, making the application’s commands prescriptive and simple. The Nemo language engine in the controller is associated with a model that allows a group of applications to have a set of pre-loaded definitions (model semantics) for nodes, flows, or policy. For example, a company nodes could be defined along with the necessary flows for accounting traffic or big-data transfers. NEMO Documents Intent Common Information Model (and definitions), NEMO (NEtwork MOdeling Language), Yang Data Model for Intent-Based NEMO Requirements for Intent language(description, not title) Relevance to I2NSF The Intent-based or Declarative policy may be an aspect of the I2NSF customer requests. It is not directly related to the I2NSF Client to I2NSF Agent protocol passing provisioning work. Status of Nemo In 2014, the NEMO project provided an early proof-of-concept code demos (Layer123, CNV2015, IETF92) for an Intent-Based interface that uses a domain specific language. Nemo is moving this work into two open Source projects (ODL Nemo, OPNFV Movie) and work at IETF’s open-source projects.

The IETF SUPA (Simplified Use of Policy Abstractions) BOF is proposing an IETF Working Group to develop a set of information models for defining standardized policy rules at different levels of abstraction, and will show how to map these (technology-independent) forms into YANG data models. The BOF introduces the concepts of multi-level (multiple levels of abstraction) (similar to figure 5) and multi-technology (e.g., IP, VPNs, MPLS) network abstractions to address the current separation between development and deployment operations. Multiple levels of abstraction enable common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using diverse components and technologies to implement a network service. Three information models are envisioned: A generic information model that defines concepts needed by policy management independent of the form and content of the policy. A more specific information model that refines the generic information model to specify how to build policy rules of the event-condition-action paradigm. A more specific information model that refines the generic information model to specify how to build policy rules that declaratively specify what goals to achieve (but not how to achieve those goals). The set of generic policy information models in SUPA's work will be mapped to a set of concrete YANG data models. These data models will provide a set of core YANG modules that define how to manage and communicate policies, expressed using the event-condition-action paradigm or the declarative goal-oriented paradigm, between systems. The SUPA BOF/WG plans to focus in the first phase of its work on completing the set of information models required to construct an extensible, policy-based framework. These information models will lead to a set of core YANG data models for a policy-based management framework to monitor and control network services. The working group will use the distributed data center (DDC) use case, which includes the dynamic policy-driven provisioning and operation of inter-datacenter (inter-dc) virtual private networks (VPNs) of various types, as a means to validate that the generic policy-framework is implementable and usable. I2NSF versus SUPA BOF work I2NSF is focus on passing policies between I2NSF client and I2NSF Agent in an interoperable format. The SUPA policies are more generic policies (Prescriptive Event-Condition-Action and declarative/Intent-based. The protocol between the I2NSF Client and I2NSF agent is specific to the security policies. If SUPA was completed now, it might provide wisdom for the I2NSF interoperable protocol. With SUPA running in parallel, the generic models may or may not provide timely advise to structure I2NSF 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 support the management of port and address information rather than any other security functions We must cover the proxy, firewall and NAT box proposals in I2NSF

Midcom Summary: summary TBD MidCom RFCs: RFCs Why I2NSF is different than Midcom TBD explanation of differences

Summary of I2RS The IETF I2RS Working group is working on an interface to the routing system that facilitates a real-time or event driven interaction with the routing system through a collection of protocol-based control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or by notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and among multiple interactions with the routing system. The I2RS interfaces co-exist with existing configuration and management systems and interface that focus on configuring, managing, or monitoring information on the routing system in a device. A short description of the problem that I2RS is trying to solve can be found in It is envisioned that users of the I2RS interfaces will be management applications, network controllers, and user applications that make specific demands on the network. The use case requirements are described in for protocol independent RIBs, topologies, and filter-rules and for protocol dependent use cases for BGP, OSPF, ISIS, CCNE, SFC, traffic steering, MPLS-TE, MPLS-LDP, Mobile Backhaul(MBB) uses, large data flows, large data collection systems, and CDNI. The I2RS Architecture states the I2RS will be data-model driven. I2RS has three protocol independent models: I2RS RIB (, I2RS Topology models (generic, L1, L2, L3, and service topology) Generic topolgoy L1 topology , L2 Topology ", L3 Topology (draft-ietf-i2rs-yang-l3-topo-00"), and service topology model . Filter-Based RIB topology . The I2RS WG has a policy of re-use of existing technology where possible. One of the potential re-uses is the enhancement of the NETCONF protocol , or RESTCONF , and the use of the netmod (RFC6020) for the data models. In June 2015, I2RS is finalizing the requirements for changes in the netconf protocol. Existing requirements include: requirements for I2RS’s ephemeral state that provides writing/reading of real-time state, requirements for traceability framework and information model described in , requirements for subscriptions to datastores , and mutual authentication requirements and transport requirements (draft pending). I2RS modules have been proposed for ephemeral state for protocol dependent units for OSPF, ISIS, BGP, MPLS-TE, MPLS-LDP, SFC forwarding, and SFC filter-based rules. Pre-standard implementations of I2RS protocol exist in Juniper and other vendors. Why I2NSF is different than I2NSF I2NSF focus is on an interoperable protocol that passes policy between the I2NSF client and the I2NSF AGent. The I2RS client passes ephemeral state for configuration and operational state for protocol and protocol-independent yang modules. A part of this state may be the routing policy that applies to a routing agent. The specific policies for a network security devices are not consider in I2RS at this time. What I2NSF can use from I2RS I2NSF may want to use I2RS ephemeral state (configuration and operational) as it manages, monitors, or handles NSF devices. The I2NSF may want to re-use I2RS protocol or modules to pass this ephemeral state. I2RS Status Status and Relevance IETF I2RS is nearing the end of its initial definition cycle for protocol independent yang models and its protocol requirements for NETCONF Working Group. If protocol additions to netconf’s protocol and netmod’s yang modules for the I2RS ephemeral state can be finalized in June, then early implementation of the I2RS code may appear in the summer with the IETF hack-a-thon. Movement of I2RS code is possible into ODL, Cisco, Juniper, Ericsson, Huawei, Brocade, Dell and PacketDesign as authors from these companies have joined together to create the I2RS drafts. An I2RS interface into all routers will provide a programmatic interface for many routing stacks.

Summary of SFC: IETF SFC is about mechanism of chaining together service functions; IETF SFC treats all those Service Functions as black box. This means that the SFC mechanism do not care what actions those functions are performing. SFC defines the SFC header to carry Metadata with payload to those functions. But SFC mechanism do not specify what content is encoded in the metadata. diagram of SFC: TBD SFC RFCs (TBD) Why I2NSF is different: I2NSF is targeted to define the descriptor (the actual rules and policies) of the network security functions needed and the negotiation scheme.

NSIS is for standardizing an IP signaling protocol (RSVP) along data path for end points to request its unique QoS characteristics, unique FW policies or NAT needs (RFC5973) that are different from the FW/NAT original setting. 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 you've got one or more NATs present in the network, or when trying to locate appropriate tunnel endpoints). A diagram should be added here showing I2NSF and NSIS Why I2NSF is different than NSIS: The I2NSF requests form clients do not go directly to network security devices, but instead to controller or orchestrator that can translate the application/user oriented policies to the involved devices in the interface that they support. 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 in the controller and orchestrator I2NSF defines clients (applications) oriented descriptors (profiles, or attributes) to request/negotiate/validate the network security functions that are not on the local premises. Why we belief I2NSF has a higher chance to be deployed than NSIS: Open Stack 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 complete. IETF can complete and extend the OpenStack implementation to provide an interoperable specification that can be needs and requirements of operators that is workable for suppliers of the technology. The combination of an carefully designed interoperable IETF specification with an open-source code development Open Stack 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].

VNFpool is about the reliability and availability of the virtualized network functions. But none of them address how service functions are requested, or how service functions are fulfilled. drawing for VNF-Pool RFCs for VNF-Pool Why I2NSF is different than the VNFPool BOF Proposal VNFpool does not cover the protocol for provisioning a NSF (e.g. rules for the requested FW) from the I2NSF clients to I2NSF Agent. VNFPool examined a way to provide an interoperable protocol manage the VNF pools from different vendors. With VNFpool (as well as SFC), NSF functions (such as Firewall function) are treated as a black box, that is treated in same way as Video Optimization function.