<?xml version="1.0" encoding="iso-8859-1"?>
<!--
     vim: set softtabstop=2 shiftwidth=2 expandtab
     version=20150108
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7491.xml">
]>
<rfc category="info" docName="draft-ietf-i2nsf-client-facing-interface-req-05"
     ipr="trust200902">
  <front>
    <title abbrev="Client Interface Requirements">Requirements for
    Client-Facing Interface to Security Controller</title>

    <author fullname="Rakesh Kumar" initials="R." surname="Kumar">
      <organization>Lilac Cloud</organization>

      <address>
        <postal>
          <street>14435 C Big Basin Way #104</street>

          <city>Saratoga</city>

          <region>CA</region>

          <country>US</country>

          <code>95070</code>
        </postal>

        <email>rakeshkumarcloud@gmail.com</email>
      </address>
    </author>

    <author fullname="Anil Lohiya" initials="A." surname="Lohiya">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1133 Innovation Way</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <country>US</country>

          <code>94089</code>
        </postal>

        <email>alohiya@juniper.net</email>
      </address>
    </author>

    <author fullname="Dave Qi" initials="D." surname="Qi">
      <organization>Bloomberg</organization>

      <address>
        <postal>
          <street>731 Lexington Avenue</street>

          <city>New York</city>

          <region>NY</region>

          <country>US</country>

          <code>10022</code>
        </postal>

        <email>DQI@bloomberg.net</email>
      </address>
    </author>

    <author fullname="Nabil Bitar" initials="N." surname="Bitar">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street>755 Ravendale Drive</street>

          <city>Mountain View</city>

          <region>CA</region>

          <country>US</country>

          <code>94043</code>
        </postal>

        <email>nabil.bitar@nokia.com</email>
      </address>
    </author>

    <author fullname="Senad Palislamovic" initials="S." surname="Palislamovic">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street>755 Ravendale Drive</street>

          <city>Mountain View</city>

          <region>CA</region>

          <country>US</country>

          <code>94043</code>
        </postal>

        <email>senad.palislamovic@nokia.com</email>
      </address>
    </author>

    <author fullname="Liang Xia" initials="L." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <country>China</country>

          <code>210012</code>
        </postal>

        <email>Frank.Xialiang@huawei.com</email>
      </address>
    </author>

    <date year="2018"/>

    <area>Security</area>

    <workgroup>I2NSF Working Group</workgroup>

    <keyword>I2NSF</keyword>

    <abstract>
      <t>This document captures requirements for Client-Facing interface to
      the Security Controller as defined by <xref target="RFC8327"/>. The
      interface is expressed using objects and constructs understood by
      Security Admin as opposed to vendor or device specific expressions
      associated with individual product and feature. This document identifies
      a broad set of requirements needed to express Security Policies based on
      User-constructs which are well understood by the User Community. This
      gives ability to decouple policy definition from policy enforcement on a
      specific security functional element, be it a physical or virtual.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Programming security policies in a network has been a fairly complex
      task that often requires deep knowledge of vendor specific devices and
      features. This has been the biggest challenge for both Service Providers
      and Enterprises, henceforth named as Security Admins in this document.
      This challenge is further amplified due to network virtualization with
      security functions deployed in physical and virtual form factors,
      henceforth named as network security function (NSF) in this document,
      from multiple vendors with proprietary interfaces.</t>

      <t>Even if Security Admin deploys a single vendor solution with one or
      more security appliances across its entire network, it is still very
      difficult to manage Security Policies that requires mapping of business
      needs to complex security features with vendor specific configurations.
      The Security Admin may use vendor provided management systems to
      provision and manage Security Policies. But, the single vendor approach
      is highly restrictive in today's network for following reasons: <list
          style="symbols">
          <t>An organization may not be able to rely on a single vendor
          because the changing security requirements may not align with
          vendor's release cycle.</t>

          <t>A large organization may have a presence across different sites
          and regions; which means, it may not be possible to deploy same
          solution from the same vendor because of regional regulatory and
          compliance policy.</t>

          <t>If and when an organization migrates from one vendor to another,
          it is almost impossible to migrate Security Policies from one vendor
          to another without complex and time consuming manual workflows.</t>

          <t>An organization may deploy multiple security functions in either
          virtual or physical form to attain the flexibility, elasticity,
          performance scale and operational efficiency they require.
          Practically, that often requires different sources (vendor, open
          source) to get the best of breed for a given security function.</t>

          <t>An organization may choose all or part of their assets such as
          routers, switches, firewalls, and overlay-networks as policy
          enforcement points for operational and cost efficiency. It would be
          highly complex to manage policy enforcement with different tool set
          for each type of device.</t>
        </list></t>

      <t>In order to facilitate deployment of Security Policies across
      different vendor provided NSFs, the Interface to Network Security
      Functions (I2NSF) working group in the IETF is defining a Client-Facing
      interface to Security Controller [RFC8327] [I-D.ietf-i2nsf-terminology].
      Deployment facilitation should be agnostic to the type of device, be it
      physical or virtual, or type of enforcement point. Using these
      interfaces, it becomes possible to write different kinds of security
      management applications (e.g. GUI portal, template engine, etc.)
      allowing Security Admin to express Security Policy in an abstract form
      with choice of wide variety of NSF as policy enforcement point. The
      implementation of security management applications or controller is out
      of scope for I2NSF working group.</t>

      <t>This document captures the requirements for Client-Facing interface
      that can be easily used by Security Admin without a need for expertise
      in vendor and device specific feature set. We refer to this as
      "User-construct" based interfaces. To further clarify, in the scope of
      this document, the "User-construct" here does not mean some free-from
      natural language input or an abstract intent such as "I want my traffic
      secure" or "I don't want DDoS attacks in my network"; rather the
      User-construct here means that Security Policies are described using
      expressions such as application names, application groups, device
      groups, user groups etc. with a vocabulary of verbs (e.g., drop, tap,
      throttle), prepositions, conjunctions, conditionals, adjectives, and
      nouns instead of using standard n-tuples from the packet header.</t>
    </section>

    <section anchor="conventions" title="Conventions Used in This Document">
      <t><list style="hanging">
          <t hangText="BSS:">Business Support System</t>

          <t hangText="CLI:">Command Line Interface</t>

          <t hangText="CMDB:">Configuration Management Database</t>

          <t hangText="Controller:">Used interchangeably with Security
          Controller or management system throughout this document</t>

          <t hangText="CRUD:">Create, Retrieve, Update, Delete</t>

          <t hangText="FW:">Firewall</t>

          <t hangText="GUI:">Graphical User Interface</t>

          <t hangText="IDS:">Intrusion Detection System</t>

          <t hangText="IPS:">Intrusion Protection System</t>

          <t hangText="LDAP:">Lightweight Directory Access Protocol</t>

          <t hangText="NSF:">Network Security Function, defined by <xref
          target="RFC8192"/></t>

          <t hangText="OSS:">Operation Support System</t>

          <t hangText="RBAC:">Role Based Access Control</t>

          <t hangText="SIEM:">Security Information and Event Management</t>

          <t hangText="URL:">Universal Resource Locator</t>

          <t hangText="vNSF:">Refers to NSF being instantiated on Virtual
          Machines</t>

          <t hangText="VPN:">Virtual Private Network</t>
        </list></t>
    </section>

    <section anchor="fwk"
             title="Guiding Principle for Client-Facing Interface Definition">
      <t>Client-Facing Interface must ensure that a Security Admin can deploy
      a NSF from any vendor and should still be able to use the same
      consistent interface. In essence, this interface allows a Security Admin
      to express a Security Policy enforced on the NSFs to be independent of
      vendor and its implementation. Henceforth, in this document, we use
      "security policy management interface" interchangeably when we refer to
      Client-Facing interface.</t>

      <section anchor="user-construct" title="User-construct Based Modeling">
        <t>Traditionally, Security Policies have been expressed using vendor
        proprietary interface. The interface is defined by a vendor based on
        proprietary command line text or a GUI based system with
        implementation specific constructs such IP address, protocol and L4-L7
        information. This requires Security Admin to translate their business
        objectives into vendor provided constructs in order to express a
        Security Policy. But, this alone is not sufficient to render a policy
        in the network; the admin must also understand network and application
        design to locate a specific policy enforcement point to make sure
        policy is effective. To further complicate the matters, when changes
        happen in the network topology, the Security Policy may require
        modifications accordingly. This may be a highly manual task based on
        network design and becomes unmanageable in virtualized
        environment.</t>

        <t>The User-construct based framework does not rely on lower level
        semantics due to problem explained above, but rather uses higher level
        constructs such as User-group, Application-group, Device-group,
        Location-group, etcetera. A Security Admin would use these constructs
        to express a security policy instead of proprietary implementation or
        feature specific constructs. The policy defined in such a manner is
        referred to User-construct based policies in this draft. The idea is
        to enable Security Admin to use constructs they understand best in
        expressing Security Policies which simplify their tasks and help
        avoiding human errors in complex security provisioning.</t>
      </section>

      <section anchor="guide"
               title="Basic Rules for Client-Facing Interface Definition">
        <t>The basic rules in defining the Client-Facing interfaces are as
        follows: <list style="symbols">
            <t>Not dependent on a particular network topology or the NSF
            location in the network</t>

            <t>Not forced to express Security Policy with proprietary vendor
            specific interfaces for a given NSF</t>

            <t>Independent of NSF type that will implement a specific Security
            Policy; e.g., the interface remains same no matter if a specific
            Security Policy is enforced on a stateful firewall, IDP, IDS,
            Router or a Switch</t>

            <t>Declarative/Descriptive model instead of
            Imperative/Prescriptive model - What security policy need to be
            expressed (declarative) instead of how it is implemented
            (imperative)</t>

            <t>Not dependent on vendors' implementation or form-factor
            (physical, virtual) of the NSF</t>

            <t>Not dependent on how a NSF becomes operational - network
            connectivity and other hosting requirements.</t>

            <t>Not dependent on NSF control plane implementation (if there is
            one), e.g., cluster of NSFs active as one unified service for
            scale and/ or resilience.</t>

            <t>Not depending on specific data plane implementation of NSF,
            e.g. encapsulation, service function chains.</t>
          </list></t>

        <t>Note that the rules stated above only apply to the Client-Facing
        interface, which a Security Admin would use to express a high level
        policy. These rules do not apply to the lower layers, e.g., Security
        Controller that convert higher level policies into lower level
        constructs. The lower layers may still need some intelligence such as
        topology awareness, capability of the NSF and its functions, supported
        encapsulations etc., to convert and apply the policies accurately on
        the NSF.</t>
      </section>

      <section anchor="models"
               title="Deployment Models for Implementing Security Policies">
        <t>Traditionally, medium and large Enterprises deploy vendor provided
        management systems to create Security Policies and any changes to
        these Security Policies are made manually over time by Security Admin.
        This approach may not be suitable and nor sufficient for modern highly
        automated campus network, and data centers that are largely
        virtualized and rely on various management systems and controllers to
        implement dynamic Security Policies over large number of NSF in the
        network.</t>

        <t>There are two distinct deployment models for Security Controller.
        Although, these have no direct impact on the Client-Facing interface,
        but illustrate the overall Security Policy management framework in an
        organization and how the Client-Facing interface remain same which is
        the main objective of this document. These models are: <list
            style="letters">
            <t>Policy management without an explicit management system for
            control of NSFs. In this deployment, Security Controller acts as a
            NSF management system; it takes information passed over
            Client-Facing interface and translates into data on I2NSF
            NSF-Facing interface. The NSF-Facing interface is implemented by
            NSF vendors; this would usually be done by having an I2NSF agent
            embedded in the NSF. This deployment model is shown in <xref
            target="without"/>. <figure anchor="without"
                title="Deployment without Management System">
                <artwork>
                      
                         RESTful API
                 SUPA or I2NSF Policy Management
                               ^
                               |
 Client-Facing Interface       |
 (Independent of individual    |
  NSFs, devices, and vendors)  |
                               |
                 ------------------------------
                |                              |
                |       Security Controller    |
                |                              |
                 ------------------------------
                      |                 ^
                      |   I2NSF         |
 NSF Interface        |   NSF-Facing    |
 (Specific to NSFs)   |   Interface     |
                  ..............................
                      |                 |
                      v                 |


                -------------     -------------
               | I2NSF Agent |   | I2NSF Agent |
               |-------------|   |-------------|
               |             |---|             |
               |     NSF     |   |     NSF     |
     NSFs      |             |   |             |
 (virtual       -------------\   /-------------
    and               |       \ /       |
 physical)            |        X        |
                      |       / \       |
                -------------/   \-------------
               | I2NSF Agent |   | I2NSF Agent |
               |-------------|   |-------------|
               |             |---|             |
               |     NSF     |   |     NSF     |
               |             |   |             |
                -------------     -------------
                      
                    </artwork>
              </figure></t>

            <t>Policy management with an explicit management system for
            control of NSFs. This model is similar to the model above except
            that Security Controller interacts with a vendor's dedicated
            management system that proxy I2NSF NSF-Facing interfaces as NSF
            may not support NSF-Facing interface. This is a useful model to
            support legacy NSF. This deployment model is shown in <xref
            target="with"/>. <figure anchor="with"
                title="Deployment with Management System or I2NSF Proxy Agent">
                <artwork>
                      
                         RESTful API
                 SUPA or I2NSF Policy Management
                               ^
                               |
 Client-Facing Interface       |
 (Independent of individual    |
  NSFs, devices, and vendors)  |
                               |
                 ------------------------------
                |                              |
                |       Security Controller    |
                |                              |
                 ------------------------------
                      |                 ^
                      |   I2NSF         |
 NSF Interface        |   NSF-Facing    |
 (Specific to NSFs)   |   Interface     |
                  ..............................
                      |                 |
                      v                 |
                 ------------------------------
                |                              |
                |      I2NSF Proxy Agent /     |
                |      Management System       |
                |                              |
                 ------------------------------
                      |                 ^
                      |  Proprietary    |
                      |  Functional     |
                      |  Interface      |
                  ..............................
                      |                 |
                      v                 |

                -------------     -------------
               |             |---|             |
               |     NSF     |   |     NSF     |
     NSFs      |             |   |             |
 (virtual       -------------\   /-------------
    and               |       \ /       |
 physical)            |        X        |
                      |       / \       |
                -------------/   \-------------
               |             |---|             |
               |     NSF     |   |     NSF     |
               |             |   |             |
                -------------     -------------
                      
                    </artwork>
              </figure></t>
          </list></t>

        <t>As mentioned above, these models discussed here don't affect the
        definition of Client-Facing interface, they do give an overall context
        for defining a Security Policy interface based on abstraction. This
        can help in implementing a Security Controller.</t>
      </section>
    </section>

    <section anchor="requirements"
             title="Functional Requirements for the Client-Facing Interface">
      <t>As stated in the guiding principle for defining the I2NSF
      Client-Facing interface, the Security Policies and the Client-Facing
      interface shall be defined from Security Admin's perspective and
      abstracted away from type of NSF, NSF specific implementation,
      controller implementation, network topology, controller NSF-Facing
      interface. Thus, the Security Policy definition shall be declarative,
      expressed using User-construct, and driven by how Security Admin view
      Security Policies from their business needs and objectives.</t>

      <t>Security Controller's' implementation is outside the scope of this
      document and the I2NSF working group.</t>

      <t>In order to express and build security policies, high level
      requirement for Client-Facing interface is as follows: <list
          style="symbols">
          <t>Unified model for various network types (i.e., campus network,
          date center, operator core/metro network, etc)</t>

          <t>Multi-Tenancy</t>

          <t>Authentication and Authorization</t>

          <t>Role-Based Access Control (RBAC)</t>

          <t>Protection from Attacks</t>

          <t>Protection from Misconfiguration</t>

          <t>Policy Lifecycle Management</t>

          <t>Dynamic Policy Endpoint Groups</t>

          <t>Policy Rules</t>

          <t>Policy Actions</t>

          <t>Generic Policy Model</t>

          <t>Policy Conflict Resolution</t>

          <t>Backward Compatibility</t>

          <t>Third-Party Integration</t>

          <t>Telemetry Data</t>
        </list></t>

      <t>The above requirements are by no means a complete list and may not be
      sufficient or required for all use-cases, but should be a good starting
      point for a wide variety of use-cases in Service Provider and Enterprise
      networks.</t>

      <t>A specific implementation may not support all these requirements but
      in order to define a base set of requirements which would works for most
      use-cases, this document will make an attempt to classify these
      requirements in three categories:<list style="hanging">
          <t hangText="MUST:">This means, the requirement must be supported by
          Client-Facing interface.</t>

          <t hangText="RECOMMENDED:">This means, we recommend that
          Client-Facing interface support this requirement since it might be
          applicable to large number of use-cases but some vendor may choose
          to omit if their focus is only certain market segments.</t>

          <t hangText="MAY:">This means, the requirement is not mandatory for
          Client-Facing interface but may be needed for specific
          use-cases.</t>
        </list></t>

      <section anchor="Unified-Model"
               title="Requirement for Unified Model for Various Network Types">
        <t>In terms of security management/control, different network types
        have different focus and requirements. In general, campus network
        focuses more on user and device management, as well as the access
        control among them. But for data center, more focus are putted on the
        east-west traffic control for various application, or workload
        isolation with micro-segmentation.</t>

        <t>Comparing to campus network and DC network, the other network
        types, such as: operator core/metro network, VPN network, are
        relatively simple in terms of security policies but still have their
        own considerations. Despite their different focus on security policy,
        one unified model is still necessary with the benefits of simplicity,
        wide applicability and extensibility. More specifically, the unified
        model here means all the policy objects are constructed with the same
        structured method in the security policies for all the network types.
        </t>

        <t>We classify this requirement in MUST category.</t>
      </section>

      <section anchor="tenancy"
               title="Requirement for Multi-Tenancy in Client-Facing Interface">
        <t>An organization may have internal tenants and might want a
        framework wherein each tenant manages its own Security Policies with
        isolation from other tenants. This requirement may be applicable to
        Service Providers and Large Enterprises so we classify this
        requirement in RECOMMENDED category. If an implement does not support
        this requirement, it must support a default implicit tenant created by
        Security Controller that owns all the Security Policies.</t>

        <t>A Security Admin may be a Cloud Service Provider with multi-tenant
        deployment, where each tenant is a different customer. Each tenant or
        customer must be able to manage its own Security Policies without
        affecting other tenants.</t>

        <t>It should be noted that tenants may have their own tenants, so a
        recursive relation may exist. For instance, a tenant in a Cloud
        Service Provider may have multiple departments or organizations that
        need to manage their own security rules for compliance.</t>

        <t>The following objects are needed to fulfill this requirement:<list
            style="hanging">
            <t hangText="Policy-Tenant:">An entity that owns and manages
            Security Policies applied to its own asset and resources.</t>

            <t hangText="Policy-Administrator:">A user authorized to manage
            the security policies for a Policy-Tenant.</t>

            <t hangText="Policy-User:">A user within a Policy-Tenant who is
            authorized to access certain resources of that tenant according to
            the privileges assigned to it.</t>
          </list></t>
      </section>

      <section anchor="Authentication"
               title="Requirement for Authentication and Authorization of Client-Facing Interface">
        <t>A Security Admin must be authenticated and authorized in order to
        manage Security Policies. We classify this requirement in MUST
        category since without proper authentication and authorization, the
        security posture of entire organization can be easily compromised.</t>

        <t>There must be methods defined for Policy-Administrator to be
        authenticated and authorized to use Security Controller. There are
        several authentication methods available such as OAuth [RFC6749],
        XAuth and X.509 certificate based; the authentication may be mutual or
        single-sided based on business needs and outside the scope of I2NSF.
        In addition, there must be a method o authorize the
        Policy-Administrator to perform certain action. It should be noted
        that, Policy-Administrator authentication and authorization to perform
        actions could be part of Security Controller or outside; this document
        does not mandate any specific implementation but requires that such a
        scheme must be implemented.</t>
      </section>

      <section anchor="RBAC"
               title="Requirement for Role-Based Access Control (RBAC) in Client-Facing Interface">
        <t>A tenant in organization may have multiple users with each user
        given certain privileges. Some user such as "Admin" may have all the
        permission but other may have limited permissions. We classify this
        requirement in RECOMMENDED category since it aligns with Multi-Tenancy
        requirement. If this requirement is not supported, a default privilege
        must be assigned to all the users.</t>

        <t>The following objects are needed to fulfill this requirement:<list
            style="hanging">
            <t hangText="Policy-Authorization-Role:">Defines the permissions
            assigned to a user such as creating and managing policies on
            specified resources. A user may not be allowed to change existing
            policies but only view them.</t>
          </list></t>
      </section>

      <section anchor="Attacks"
               title="Requirement to Protect Client-Facing Interface from Attacks">
        <t>The interface must be protected against attacks from malicious
        clients or a client impersonator. Potential attacks could come from
        Botnets, hosts infected with virus or some unauthorized entities. This
        requirement is highly RECOMMENDED since it may not be needed if the
        entire framework is deployed in very controlled environment. But if
        needed, we recommend that Security Controller uses an out-of-band
        communication channel for Client-Facing interface. In addition, it is
        also recommended that traffic of Client-Facing interface communication
        are encrypted; Furthermore, some straightforward traffic/session
        control mechanisms (i.e., Rate-limit, ACL, White/Black list) can be
        employed on Security Controller to protect against DDoS flooding
        attacks.</t>
      </section>

      <section anchor="Misconfiguration"
               title="Requirement to protect Client-Facing Interface from Misconfiguration">
        <t>There must be measures to protect from mis-configured clients.
        System and policy parameters validations should be implemented to
        detect this. Validation may be based on a set of default parameters or
        custom tuned thresholds such as the number of policy changes
        submitted, number of objects requested in a given time interval, etc.
        We consider this to be a MUST requirement but implementation aspects
        would depend upon each individual API communication.</t>
      </section>

      <section anchor="Lifecycle"
               title="Requirement to Manage Policy Lifecycle with Rich Set of Controls">
        <t>In order to provide more sophisticated and flexible security
        framework, there should be a mechanism so that a policy becomes
        dynamically active/enforced or inactive based on multiple different
        criteria such as Security Admin's manual intervention or some external
        event. We consider requirement listed here to be a MUST for wide
        variety of use-cases.</t>

        <t>One example of dynamic policy management is when Security Admin
        pre-configures all the security policies, but the policies get
        activated or deactivated based on dynamic threat detection. Basically,
        a threat event may activate certain inactive policies, and once a new
        event indicates that the threat has gone away, the policies become
        inactive again.</t>

        <t>There are following ways for dynamically activating policies:</t>

        <t>o The policy may be activated by Security Admin manually using a
        client interface such as GUI or CLI.</t>

        <t>o The policy may be dynamically activated by Security Controller
        upon detecting an external event or an event from I2NSF monitoring
        interface</t>

        <t>o The policy can be configured but gets activated or deactivated
        upon specified timing calendar with Security Policy definition.</t>

        <t>Client-Facing interface should support the following policy
        attributes for policy enforcement: <list style="hanging">
            <t hangText="Admin-Enforced:">A policy, once configured, remains
            active/enforced until removed by Security Admin.</t>

            <t hangText="Time-Enforced:">A policy configuration specifies the
            time profile that determines when the policy is to be
            activated/enforced. Otherwise, it is de-activated.</t>

            <t hangText="Event-Enforced:">A policy configuration specifies the
            event profile that determines when the policy is to be
            activated/enforced. It also specifies the duration attribute of
            that policy once activated based on event. For instance, if the
            policy is activated upon detecting an application flow, the policy
            could be de-activated when the corresponding session is closed or
            the flow becomes inactive for certain time.</t>
          </list></t>

        <t>A policy could be a composite policy, which is composed of many
        rules, and subject to updates and modification. For the policy
        maintenance, enforcement, and audit-ability purposes, it becomes
        important to name and version Security Policy. Thus, the policy
        definition SHALL support policy naming and versioning. In addition,
        the I2NSF Client-Facing interface SHALL support the activation,
        deactivation, programmability, and deletion of policies based on name
        and version. In addition, it should support reporting operational
        state of policies by name and version. For instance, a Security Admin
        may probe Security Controller whether a Security Policy is enforced
        for a tenant and/or a sub-tenant (organization) for audit-ability or
        verification purposes.</t>
      </section>

      <section anchor="endpoint"
               title="Requirement to Define Dynamic Policy Endpoint Group">
        <t>When Security Admin configures a Security Policy, it may have
        requirement to apply this policy to certain subsets of the network.
        The subsets may be identified based on criteria such as Users,
        Devices, and Applications, or combination of them. We refer to such a
        subset of the network as a "Policy Endpoint Group". This requirement
        is the fundamental building block of Client-Facing interface; so
        making it a MUST requirement. But object defined here may not support
        all use-cases and may not be required by everyone so it is left up to
        vendor whether all or partial set of these object is supported.</t>

        <t>One of the biggest challenges for a Security Admin is how to make
        sure that a Security Policy remain effective while constant changes
        are happening to the "Policy Endpoint Group" for various reasons
        (e.g., organizational, network and application changes). If a policy
        is created based on static information such as user names,
        application, or network subnets; then every time this static
        information change, policies need to be updated. For example, if a
        policy is created that allows access to an application only from the
        group of Human Resource users (HR-users group), then each time the
        HR-users group changes, the policy needs to be updated.</t>

        <t>We call these dynamic Policy Endpoint Groups "Metadata Driven
        Groups". The metadata is a tag associated with endpoint information
        such as User, Application, or Device. The mapping from metadata to
        dynamic content could come from a standards-based or proprietary
        tools. Security Controller could use any available mechanisms to
        derive this mapping and to make automatic updates to policy content if
        the mapping information changes. The system SHOULD allow for multiple,
        or sets of tags to be applied to a single endpoint.</t>

        <t>Client-Facing interface must support Policy Endpoint Groups as a
        target for a Security Policy. The following metadata driven groups MAY
        be used for configuring Security Polices: <list style="hanging">
            <t hangText="User-Group:">This group identifies a set of users
            based on a tag or static information such as user-names. The tag
            identifying users, is dynamically derived from systems such as
            Active Directory or LDAP. For example, an organization may have
            different User-groups,such as HR-users, Finance-users,
            Engineering-users, to classify a set of users in each
            department.</t>

            <t hangText="Device-Group:">This group identifies a set of devices
            based on a tag or device information. The tag identifying the
            devices, is dynamically derived from systems such as configuration
            management database (CMDB). For example, a Security Admin may want
            to classify all machines running a particular operating system
            into one group and machines running a different operating system
            into another group.</t>

            <t hangText="Application-Group:">This group identifies a set of
            applications based on a tag or on application names. The tag
            identifying applications, is dynamically derived from systems such
            as CMDB. For example, a Security Admin may want to classify all
            applications running in the Legal department into one group and
            all applications running in the HR department into another group.
            In some cases, the application can semantically associated with a
            VM or a device. However, in other cases, the application may need
            to be associated with a set of identifiers (e.g., transport
            numbers, signature in the application packet payload) that
            identify the application in the corresponding packets. The mapping
            of application names/tags to signatures in the associated
            application packets should be defined and communicated to the NSF.
            The Client-Facing Interface shall support the communication of
            this information.</t>

            <t hangText="Location-Group:">This group identifies a set of
            locations. Tag may correspond 1:1 to location. The tag identifying
            locations is either statically defined or dynamically derived from
            systems such as CMDB. For example, a Security Admin may want to
            classify all sites/locations in a geographic region as one group.
            Note that the location can be both the geographic and abstract
            concept. Some typical examples for the latter case are: branches
            and headquarter for a large enterprise; different data center
            sites; private cloud and public cloud.</t>
          </list></t>
      </section>

      <section anchor="Rules"
               title="Requirement to Express Rich Set of Policy Rules">
        <t>The Policy Rules is a central component of any Security Policy but
        rule requirements may vary based on use-cases and it is hard to define
        a complete set that works for everyone. In order to build a rich
        interface, we are going to take a different approach; we will define
        the building block of rules and let Security Admin build rules using
        these construct so that Security Policies meet their requirements
        divided into the following major categories: <list style="hanging">
            <t hangText="Segmentation policies  :">This set of policies create
            rules for communication between two Endpoint Groups. An
            organization may restrict certain communication between a set of
            user and applications for example. The segmentation policy may be
            a micro-segmentation rule between components of complex
            applications or related to hybrid cloud deployment based on
            location.</t>

            <t hangText="Threat policies:">This set of policies creates rules
            to prevent communication with externally or internally identified
            threats. The threats may be well knows such as threat feeds from
            external sources or dynamically identified by using specialty
            devices in the network.</t>

            <t hangText="Governance and Compliance policies:">This set of
            policies creates rules to implement business requirement such as
            controlling access to internal or external resources for meeting
            regulatory compliance or business objectives.</t>
          </list></t>

        <t>In order to build a generic rule engine to satisfy diverse set of
        Policy Rules, we propose following objects: <list style="hanging">
            <t hangText="Source Policy Endpoint Group:">A source target of the
            Policy Rule. This may be special object "ALL" if all groups meet
            this criteria.</t>

            <t hangText="Destination Policy Endpoint Group:">A destination
            target of the Policy Rule. This may be a special object "ALL", if
            all groups meet this criteria.</t>

            <t hangText="Direction:">By default rules are applied in both
            directions but this object can be used to make rule definition
            uni-directional.</t>

            <t hangText="Threat Group:">An object that represents a set of
            static or dynamic threats such as Botnet, GeoIP, URL feeds or
            virus and malware signatures detected dynamically. This object can
            be used as source or destination target in a rule.</t>

            <t hangText="Match Condition:">An object that represents a set of
            allowed interactions. It could be as simple as group of
            application names or L4 ports allowed between two Endpoint
            Groups.</t>

            <t hangText="Exceptions:">In order to greatly simplify Security
            Admin's task, we should allow to specify exceptions to the match
            criteria. E.g., we could build a rule that allows all traffic
            between two groups except a particular application or threat
            source.</t>

            <t hangText="Actions:">Action is what makes rule and Policy work.
            The Action is defined in details in next section. We RECOMMEND
            that there be a one-to-one mapping between rule and action
            otherwise if multiple rules are associated with one action, it may
            be a difficult to manage Security Policy lifecycle as they
            evolve.</t>
          </list></t>
      </section>

      <section anchor="Actions"
               title="Requirement to Express Rich Set of Policy Actions">
        <t>Security Admin must be able to configure a variety of actions for a
        given Policy Rule. Typically, Security Policy specifies a simple
        action of "deny" or "permit" if a particular condition is matched.
        Although this may be enough for most use-cases, the I2NSF
        Client-Facing interface must provide a more comprehensive set of
        actions so that the interface can be used effectively across various
        security needs.</t>

        <t>Policy action MUST be extensible so that additional policy action
        specifications can easily be added.</t>

        <t>The following list of actions SHALL be supported: <list
            style="hanging">
            <t hangText="Permit:">This action means continue processing the
            next rule or allow the packet to pass if this is the last
            rule.</t>

            <t hangText="Deny:">This action means stop further packet
            processing and drop the packet.</t>

            <t hangText="Drop connection:">This action means stop further
            packet processing, drop the packet, and drop connection (for
            example, by sending a TCP reset).</t>

            <t hangText="Log:">This action means create a log entry whenever a
            rule is matched.</t>

            <t hangText="Authenticate connection:">This action means that
            whenever a new connection is established it should be
            authenticated.</t>

            <t hangText="Quarantine/Redirect:">This action is useful for
            threat remediation purposes. If a security breach or infection
            point is detected, a Security Admin would like to isolate for
            purpose of remediation or controlling attack surface.</t>

            <t hangText="Netflow:">This action creates a Netflow record; Need
            to define Netflow server or local file and version of Netflow.</t>

            <t hangText="Count:">This action counts the packets that meet the
            rule condition.</t>

            <t hangText="Encrypt:">This action encrypts the packets on an
            identified flow. The flow could be over an IPSEC tunnel, or TLS
            session for instance.</t>

            <t hangText="Decrypt:">This action decrypts the packets on an
            identified flow. The flow could be over an IPSEC tunnel, or TLS
            session for instance.</t>

            <t hangText="Throttle:">This action defines shaping a flow or a
            group of flows that match the rule condition to a designated
            traffic profile.</t>

            <t hangText="Mark:">This action defines traffic that matches the
            rule condition by a designated DSCP value and/or VLAN 802.1p Tag
            value.</t>

            <t hangText="Instantiate-NSF:">This action instantiates an NSF
            with a predefined profile. An NSF can be any of the FW, IPS, IDS,
            honeypot, or VPN, etc.</t>
          </list></t>

        <t>The policy actions should support combination of terminating
        actions and non-terminating actions. For example, Syslog and then
        Permit; Count and then Redirect.</t>

        <t>Policy actions SHALL support any L2, L3, L4-L7 policy actions.</t>
      </section>

      <section anchor="Models"
               title="Requirement for Consistent Policy Enforcement">
        <t>As proposed in this document, the Client-Facing interface MUST be
        built using higher-level "User-Constructs" that are independent of
        network design and implementations. In order to achieve this goal, it
        becomes important that Security Controller functionality becomes more
        complex that keep track of various objects that are used to express
        Security Policies. The Security Controller MUST evaluate the Security
        Policies whenever these objects and network topology change to make
        sure that Security Policy is consistently enforced as expressed.</t>

        <t>Although this document does not specify how Security Controller
        achieve this and any implementation challenges. It is assumed that
        once Security Controller uses Client-Facing interface to accept
        Security Policies; it would maintain the security posture as per the
        Security Policies during all changes in network or Endpoints and other
        building blocks of the framework.</t>

        <t>An event must be logged by Security Controller when a Security
        Policy is updated due to changes in it's building blocks such as
        Endpoint Group contents or the Security Policy is moved from one
        enforcement point to another because the Endpoint has moved in the
        network. This may help in debugging and auditing for compliance
        reasons. The Security Admin may optionally receive notifications if
        supported and desired.</t>
      </section>

      <section anchor="Conflict"
               title="Requirement to Detect and Correct Policy Conflicts">
        <t>Client-Facing interface SHALL be able to detect policy "conflicts",
        and SHALL specify methods on how to resolve these "conflicts"</t>

        <t>For example a newly submitted Security Policy could conflict with
        existing Security Policies applied to a set of Policy Endpoint Groups.
        This MUST be detected and Security Admin be allowed for manual
        correction if needed.</t>
      </section>

      <section anchor="Backward"
               title="Requirement for Backward Compatibility">
        <t>It MUST be possible to add new capabilities to Client-Facing
        interface in a backward compatible fashion.</t>
      </section>

      <section anchor="Third-Party"
               title="Requirement for Third-Party Integration">
        <t>The security framework in a network may require the use of some
        special devices such as honeypot, behavioral analytic, or SIEM for
        threat detection; the device may provide threat information such as
        threat feeds, virus signatures, and malicious file hashes.</t>

        <t>The Client-Facing interface must allow Security Admin to include
        these devices under Security Controller's Client-Facing interface so
        that a Security Policy could be expressed using information from such
        devices; basically it allows ability to integrate third part devices
        into the Security Policy framework.</t>
      </section>

      <section anchor="Telemetry"
               title="Requirement to Collect Telemetry Data">
        <t>One of the most important aspect of security is to have visibility
        into the network. As threats become more sophisticated, Security Admin
        must be able to gather different types of telemetry data from various
        NSFs in the network. The collected data could simply be logged or sent
        to security analysis engines for application identification, flow
        context and behavioral analysis, policy violations, and for threat
        detection. Based on the analysis result, the security controller can
        enforce the policy lifecycle management and automatic
        optimization.</t>

        <t>The Client-Facing interface MUST allow Security Admin to collect
        various kinds of data from NSFs. The data source could be syslog, flow
        records, policy violation records, and other available data.</t>

        <t>Client-Facing interface must provide a set of telemetry data
        available to Security Admin from Security Controller. The Security
        Admin should be able to subscribe and receive to this data set.</t>
      </section>
    </section>

    <section anchor="operational_reqs"
             title="Operational Requirements for the Client-Facing Interface">
      <section anchor="api_ver" title="API Versioning">
        <t>Client-Facing interface must support a version number for each
        RESTful API. This is important since Security Controller could be
        deployed by using multiple componenets and different pieces may come
        from different vendors; it is difficult to isolate and debug issues
        without ability to track each component's operational behavior. Even
        if the vendor is same for all the components, it is hard to imagine
        that all pieces would be released in lock step by the vendor.</t>

        <t>Without API versioning, it is hard to debug and figure out issues
        when deploying Security Controller and its components built overtime
        across multiple release cycles. Although API versioning does not
        guarantee that Security Controller would always work but it helps in
        debugging if the problem is caused by an API mismatch.</t>
      </section>

      <section anchor="api_ext" title="API Extensibility">
        <t>Abstraction and standardization of Client-Facing interface is of
        tremendous value to Security Admins as it gives them the flexibility
        of deploying any vendor's NSF without need to redefine their policies
        if or when a NSF is changed.</t>

        <t>If a vendor comes up with new feature or functionality that can't
        be expressed through the currently defined Client-Facing interface,
        there SHALL be a way to extend existing APIs or to create a new API
        that addresses specific vendors's new NSF functionality.</t>
      </section>

      <section anchor="apis_trans" title="APIs and Data Model Transport">
        <t>The APIs for interface SHALL be derived from the YANG based data
        model. The data model for Client-Facing interface must capture all the
        requirements as defined in this document to express a Security Policy.
        The interface between a client and controller must be reliable to
        ensure robust policy enforcement. One such transport mechanism is
        RESTCONF that uses HTTP operations to provide necessary CRUD
        operations for YANG data objects, but any other mechanism can be
        used.</t>
      </section>

      <section anchor="notif" title="Notification and Monitoring">
        <t>Client-Facing interface must allow ability to collect various
        alarms, events, statistics about enforcement and policy violations
        from NSFs in the network. The events and alarms may be associated with
        a specific policy or associated with operating conditions of a
        specific NSF in general. The statistics may be a measure of potential
        Security Policy violations or general data that reflect operational
        behavior of a NSF. The events, alarms and statistics may also be used
        as an input to automate Security Policy lifecycle management.</t>
      </section>

      <section anchor="aff" title="Affinity">
        <t>Client-Facing interface must allow Security Admin to pass any
        additional metadata that a user may want to provide with a Security
        Policy e.g., whether the policy needs to be enforced by a very highly
        secure NSF with Trusted Platform Module (TPM) chip. Another example
        would be, whether or not a policy can be enforced by a multi-tenant
        NSF. This would Security Admin control on operating environment</t>
      </section>

      <section anchor="test" title="Test Interface">
        <t>Client-Facing interface must support ability to test a Security
        Policy before it is enforced e.g., a user may want to verify whether
        the policy creates any potential conflicts with existing policies or
        if there are enough resources and capability to enforce this policy.
        The test interface would provide a mechanism to Security Admin where
        policies could be tested in the actual environment before
        enforcement.</t>
      </section>
    </section>

    <section anchor="sec" title="Security Considerations">
      <t>Client-Facing interface to Security controller must be protected to
      make sure that entire security posture is not compromised. This draft
      mandates that interface must have proper authentication and
      authorization control mechanisms to ward off malicious attacks. The
      draft does not specify a particular mechanism as different organization
      may have different needs based on their specific deployment environment
      and moreover new methods may evolve to better suit contemporary
      requirements.</t>

      <t>Authentication and authorization alone may not be sufficient for
      Client-Facing interface; the interface API must be validated for proper
      input to guard against attacks. The type of checks and verification may
      be specific to each interface API, but a careful consideration must be
      made to ensure that Security Controller is not compromised.</t>

      <t>We recommend that all attack surface must be examined with careful
      consideration of the operating environment and available industry best
      practices must be used such as process and standards to protect security
      controller against malicious or inadvertent attacks.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document requires no IANA actions. RFC Editor: Please remove
      this section before publication.</t>
    </section>

    <section anchor="acks" title="Acknowledgements">
      <t>The authors would like to thank Adrian Farrel, Linda Dunbar and Diego
      R.Lopez from IETF I2NSF WG for helpful discussions and advice.</t>

      <t>The authors would also like to thank Kunal Modasiya, Prakash T.
      Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful
      discussions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.8192"?>

      <?rfc include="reference.RFC.8327"?>
    </references>
  </back>
</rfc>
