Network Working Group                                          E. Lopez
Internet Draft                                                 Fortinet
Intended status: Informational                                 D. Lopez
Expires: December 2015                                       Telefonica
                                                              L. Dunbar
                                                              X. Zhuang
                                                           China Mobile
                                                             J. Parrott
                                                             R Krishnan
                                                               S. Durbha

                                                           June 8, 2015

           Framework for Interface to Network Security Functions

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

xxx, et al.            Expires December 8, 2015                [Page 1]

Internet-Draft              I2NSF Framework                   June 2015

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 8, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.


   In the design of interfaces to allow for the provisioning of network
   security functions (NSFs), a critical consideration is to prevent
   the creation of implied constraints.

   This document makes the recommendation that such interfaces be
   designed from the paradigm of processing packets and flows on the
   network. NSFs ultimately are packet-processing engines that inspect
   packets traversing networks, either directly or in context to
   sessions to which the packet is associated. This document serves as
   the framework for detailed work items for I2NSF.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. Interfaces to Flow-based NSFs..................................4
   4. Reference Models in Managing NSFs..............................6
      4.1. NSF Facing Interface......................................7

xxx, et al.            Expires December 8, 2015                [Page 2]

Internet-Draft              I2NSF Framework                   June 2015

      4.2. Client Facing Interface...................................7
      4.3. Vendor Facing Interface...................................8
      4.4. The network connecting the Security Controller and NSFs...8
      4.5. Interface to vNSFs........................................9
   5. Flow-based NSF Capability Characterization....................10
   6. Security Policies Provisioning to NSFs........................13
      6.1. Capability Layer Provisioning and Monitoring.............13
      6.2. Service Layer Security Policy............................14
   7. Capability Negotiation........................................15
   8. Types of I2NSF clients........................................16
   9. Manageability Considerations..................................16
   10. Security Considerations......................................17
   11. IANA Considerations..........................................17
   12. References...................................................17
      12.1. Normative References....................................17
      12.2. Informative References..................................17
   13. Acknowledgments..............................................18

1. Introduction

   This document describes the framework for Interface to Network
   Security Functions (I2NSF) and defines a reference model along with
   functional components for I2NSF. It also describes how I2NSF
   facilitates Software-defined network (SDN) and Network Function
   Virtualization (NVF) control, while avoiding potential constraints
   which could limit NSFs internal functions.

   The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile])
   call for standard interfaces for customers to control and monitor
   security functions hosted and managed by service providers.

   [I2NSF-Problem] describes the motivation and the problem space for
   Interface to Network Security Functions.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

xxx, et al.            Expires December 8, 2015                [Page 3]

Internet-Draft              I2NSF Framework                   June 2015

   BSS:  Business Support System

   Controller: used interchangeably with Service Provider Security
               Controller or management system throughout this

   FW:   Firewall

   IDS:  Intrusion Detection System

   IPS:  Intrusion Protection System

   NSF:  Network Security Functions, defined by [I2NSF-Problem]

   OSS:  Operation Support System

   vNSF: refers to NSF being instantiated on Virtual Machines.

3. Interfaces to Flow-based NSFs

   The emergence of SDN and NFV has resulted in the need to create
   application programming interfaces (APIs) in support of dynamic
   requests from various applications. Flow-based NSFs [I2NSF-Problem]
   inspects packets in the order as they are received without
   modification to the packets due to the inspection process.

   The Interface to Flow-based NSFs can be generally grouped into three

   1) Configuration - deals with the management and configuration of
   the forwarding functions of the NSF device itself, such as port,
   addresses configurations. Configuration deals with attributes that
   are don't change very much.

   2) Signaling - which represents logging and query functions between
   the NSF and external systems. Signaling API functions may also be
   well defined by other protocols such as SYSLOG, DOTS, etc.

xxx, et al.            Expires December 8, 2015                [Page 4]

Internet-Draft              I2NSF Framework                   June 2015

   3) Provisioning - used to control the rules that govern how packets
   are treated by the NSFs. Due to the lack of standards in the
   definition and operation of these functions, much of the efforts
   towards interface development will be in this area.

   This draft proposes that a provisioning interface to NSFs can be
   developed on a packet-based paradigm. While there are many
   classifications of existing and emerging NSFs, a common trait shared
   by them is in the processing of packets based on the content
   (header/payload) and context (session state, authentication state,
   etc) of received packets.

   An important concept is the fact that attackers do not have
   standards as to how to attack networks, so it is equally important
   not to constrain NSF developers to offering a limited set of
   security functions. Therefore, in constructing standards for
   provisioning interfaces to NSFs, it is equally important to allow
   support for vendor-specific functions, to allow the introduction of
   NSFs that evolve to meet new threats. Proposed standards for
   provisioning interfaces to NSFs should not:

   - Narrowly define NSF categories, or their roles when implemented
   within a network

   - Attempt to impose functional requirements or constraints, either
   directly or indirectly, upon NSF developers

   - Be a limited lowest-common denominator approach, where interfaces
   can only support a limited set of standardized functions, without
   allowing for vendor-specific functions

   - Be seen as endorsing a best-common-practice for the implementation
   of NSFs

   By using a packet-based approach to the design of such provisioning
   interfaces, the goal is to create a workable interface to NSFs which
   aid in their integration within SDN/NFV environments, while avoiding
   potential constraints which could limit their functional

xxx, et al.            Expires December 8, 2015                [Page 5]

Internet-Draft              I2NSF Framework                   June 2015

   Even though security functions come in variety of form factors and
   have different features, provisioning to Flow-based NSFs can be
   categorized by

     - Subject - Match values based on packet data Packet header or
       Packet payload,
     - Object - Match values based on context, e.g. State, time, geo-
       location, etc.,
     - Action- Egress processing, such as Invoke signaling; Packet
       forwarding and/or transformation; Possibility for SDN/NFV
       integration, and
     - Functional Profile - E.g. IPS:<Profile>, signature file, Anti-
       virus file, URL filtering file, etc. Integrated and one-pass
       checks on the content of packets.

   The functional profile or signature file is one of the key
   properties that determine the effectiveness of the NSF, and is
   mostly vendor specific today.

4. Reference Models in Managing NSFs

   This document only focuses on the framework of provisioning and
   monitoring of the flow-based NSFs.

   The following figure shows various interfaces for managing the
   provisioning & monitoring aspects of flow-based NSFs.

xxx, et al.            Expires December 8, 2015                [Page 6]

Internet-Draft              I2NSF Framework                   June 2015

                         |  Client Facing Interface
                   |Service Provider mgmt|              +-------------+
                   | Security Controller | < -------- > | Vendor      |
                   +---------------------+ Vendor Facing|  Sys        |
                                   |         Interface  +-------------+
                                   | NSF Facing Interface
        |                                                |
        |                                                |
   +------+         +------+             +------+       +------+
   + NSF-1+ ------- + NSF-n+             +NSF-1 + ----- +NSF-m +  . . .
   +------+         +------+             +------+       +------+

   Vendor A                                       Vendor B

                         Figure 1: Multiple Interfaces

4.1. NSF Facing Interface

     This is the interface between the Service Provider's management
     system (or Security Controller) and the NSFs that are selected to
     enforce the desired network security. This interface is called
     Capability Interface in the I2NSF context.

4.2. Client Facing Interface

     This interface is for clients or Application Gateway to express
     and monitor security policies for their specific flows. The Client
     Facing interface is called Server Layer Interface in the I2NSF

     A single client layer policy may need multiple NSFs collectively
     together to achieve the enforcement.

xxx, et al.            Expires December 8, 2015                [Page 7]

Internet-Draft              I2NSF Framework                   June 2015

4.3. Vendor Facing Interface

     When service providers have multiple types of security functions
     provided by different vendors, it is necessary to have an
     interface for vendors to register their NSFs indicating what level
     can be provisioned or monitored for each of the categories listed

     The Registration Interface can be static or dynamic. When NSFs are
     upgraded, vendors need to notify the service provider management
     system or controller of the updated capabilities.

4.4. The network connecting the Security Controller and NSFs

     Most NSFs are not directly attached to the Security Controller; it
     is especially true when NSFs are distributed across the network.
     The network that connects the Security Controller with the NSFs
     can be the same network that carry the data traffic, or can be a
     dedicated network for management purpose only. Either case, packet
     loss could happen due to failure, congestion, or other reasons.

     Therefore, the transport mechanism used to carry the control
     messages and monitoring information should provide reliable
     message delivery.  Transport redundancy mechanisms such as
     Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission
     Protocol (SCTP) [RFC3286] will need to be evaluated for
     applicability.  Latency requirements for control message delivery
     must also be evaluated.

     The connection between Security Controller and NSFs could be:

     - Closed environments where there is only one administrative
       domain.  More permissive access controls and lighter validation
       is needed inside the domain because of the protected

     - Open environments where some NSFs (virtual or physical) can be
       hosted in external administrative domains or reached via
       external network domains.  Then more restrictive security

xxx, et al.            Expires December 8, 2015                [Page 8]

Internet-Draft              I2NSF Framework                   June 2015

       controls are required over the I2NSF interface.  The information
       over the I2NSF interfaces must use trusted channels, such as
       TLS, SASL, or the combination of the two.

     Over the Open Environment, I2NSF needs to provide the identity
     frameworks and federations models for authentication and

4.5. Interface to vNSFs

     Even though there is no difference between virtual network
     security functions (vNSF) and physical NSFs from policy
     provisioning perspective, there are some unique characteristics in
     interfacing to the vNSFs:

     - There could be multiple instantiations of one single NSF being
       distributed across network. When different instantiations are
       visible to the Security Controller, different policies may be
       applied to different instantiations of one single NSF.
     - When multiple instantiations of one single NSF appear as one
       single entity to the Security Controller, the policy
       provisioning has to be sent to the NSF's sub-controller, which
       in turn disseminate the polices to the corresponding
       instantiations of the NSF, as shown in the figure below. See
       Figure 2 below.
     - Policies to one vNSF may need to be retrieved and move to
       another vNSF of the same type when client flows are moved from
       one vNSF to another.
     - Multiple vNSFs may share the same physical platform
     - There may be scenarios where multiple vNSFs collectively perform
       the security policies needed.

xxx, et al.            Expires December 8, 2015                [Page 9]

Internet-Draft              I2NSF Framework                   June 2015

                          | Security Controller    |
                                   ^        ^
                                   |        |
                       +-----------+        +------------+
                       |                                 |
                       v                                 v
    + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +
    |  NSF-A  +--------------+      |  |  NSF-B  +--------------+      |
    |         |Sub Controller|      |  |         |sub Controller|      |
    |         +--------------+      |  |         +--------------+      |
    | + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
    | |+---------+     +---------+| |  | |+---------+     +---------+| |
    | || NSF-A#1 | ... |  NSF-A#n|| |  | ||  NSF-B#1| ... |  NSF-B#m|| |
    | |+---------+     +---------+| |  | |+---------+     +---------+| |
    | |         NSF-A cluster     | |  | |          NSF-B cluster    | |
    | + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
    + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +

                Figure 2: Cluster of NSF Instantiations Management

5. Flow-based NSF Capability Characterization

   There are many types of flow-based NSFs. To prevent constraints on
   NSF vendors' creativity and innovation, this document recommends the
   Flow-based NSF interfaces to be designed from the paradigm of
   processing packets on the network. Flow-based NSFs ultimately are
   packet-processing engines that inspect packets traversing networks,
   either directly or in context to sessions to which the packet is

   Flow-based NSFs differ in the depth of packet header or payload they
   can inspect, the various session/context states they can maintain,
   the specific profiles and the actions they can apply. Accordingly,
   the NSF capabilities are characterized by the level of packet
   processing and context that a NSF supports, the profiles and the
   actions that the NSF can apply.

   Vendors can register their NSFs using the Subject-Object-Action-
   Function categories described in Section 2, with detailed
   specification of each category as shown in the table below:

xxx, et al.            Expires December 8, 2015               [Page 10]

Internet-Draft              I2NSF Framework                   June 2015

     |         Subject Capability Index                          |
     | Layer 2       | Layer 2 header fields:                    |
     | Header        | Source/Destination/s-VID/c-VID/EtherType/.|
     |               |                                           |
     | Layer 3       | Layer  header fields:                     |
     |               |            protocol                       |
     | IPv4 Header   |            port                           |
     |               |            src port                       |
     |               |            dscp                           |
     |               |            length                         |
     |               |            flags                          |
     |               |            ttl                            |
     |               |                                           |
     | IPv6 Header   |                                           |
     |               |            addr                           |
     |               |            protocol/nh                    |
     |               |            src port                       |
     |               |            length                         |
     |               |            traffic class                  |
     |               |            hop limit                      |
     |               |            flow label                     |
     |               |                                           |
     | TCP           |            Port                           |
     | SCTP          |            syn                            |
     | DCCP          |            ack                            |
     |               |            fin                            |
     |               |            rst                            |
     |               |          ? psh                            |
     |               |          ? urg                            |
     |               |          ? window                         |
     |               |            sockstress                     |
     | UDP           |                                           |
     |               |            flood abuse                    |
     |               |            fragment abuse                 |
     |               |            Port                           |
     | HTTP layer    |                                           |
     |               |          | hash collision                 |
     |               |          | http - get flood               |
     |               |          | http - post flood              |
     |               |          | http - random/invalid url      |
     |               |          | http - slowloris               |
     |               |          | http - slow read               |
     |               |          | http - r-u-dead-yet (rudy)     |
     |               |          | http - malformed request       |
     |               |          | http - xss                     |

xxx, et al.            Expires December 8, 2015               [Page 11]

Internet-Draft              I2NSF Framework                   June 2015

     |               |          | https - ssl session exhaustion |
     | IETF PCP      | Configurable                              |
     |               | Ports                                     |
     |               |                                           |
     | IETF TRAM     | profile                                   |
     |               |                                           |
     |               |                                           |

     |      Object (context) matching Capability Index           |
     | Session       |   Session state,                          |
     |               |   bidirectional state                     |
     |               |                                           |
     | Time          |   time span                               |
     |               |   days, minutes, seconds,                 |
     |               |   Events                                  |
     | Events        |   Event URL, variables                    |

     |      Action Capability Index                              |
     | Ingress port  |   SFC header termination ,                |
     |               |   Pass                                    |
     | Egress        |   Deny                                    |
     |               |   Mirror                                  |
     |               |   Functional call                         |
     |               |   Encap various header                    |

     |      Functional profile Index                             |
     | Profile types |   Name, type, or                          |
     | Signature     |   Flexible Profile/signature URL          |
     |               | Command for Controller to enable/disable  |
     |               |                                           |

xxx, et al.            Expires December 8, 2015               [Page 12]

Internet-Draft              I2NSF Framework                   June 2015

6. Security Policies Provisioning to NSFs

             |             App Gateway                  |
             |       (e.g. Video conference Ctrl        |
             | Admin, OSS/BSS, or Service Orchestration |
                         I2NSF     |Service Layer Security Policy
                    |        Security Controller    |
                         I2NSF     |Capability Layer Security Policy
                           |     Adapter      |
                           | virtual/physical |
                           |       NSFs       |
               Figure 3: Multiple Layers of I2NSF interfaces

6.1. Capability Layer Provisioning and Monitoring

   The Capability Layer is to express the explicit provisioning rules
   to individual NSFs and methods to monitor the execution status of
   those functions.

   This requires the definition of an information model, along with one
   or more data models, to express the provisioning rules, which are
   derived from the client facing security policies.

   This layer will leverage the existing protocols and data models
   defined by I2RS, Netconf, and NETMOD.

   [ACL-MODEL] is for expressing the Access Control List supported by
   most routers/switches that forward packets based on packets' L2, L3,
   or sometimes L4 headers. The actions for Access Control List include
   Pass, Drop, or Redirect.

xxx, et al.            Expires December 8, 2015               [Page 13]

Internet-Draft              I2NSF Framework                   June 2015

   The functional profiles (or signatures) for NSFs are not present in
   [ACL-MODEL] because the functional profiles are unique to specific
   NSFs. Most vendors' IPS/IDS, and HoneyPot have their proprietary
   functions/profiles. One of the goals of I2NSF is to have common
   envelop format for exchanging or sharing profiles among different
   organizations to achieve more effective protection against threats.

   The "subject" of the policies not only includes the matching
   criteria specified by [ACL-MODEL] but also the L4-L7 fields
   depending on the NSF selected.

   The I2NSF Capability Layer has to specify the "Object" (i.e. the
   states/contexts surrounding the packets).

   The I2NSF "actions" are similar to the actions specified by [ACL-

   This layer also includes the policy monitoring of the individual
   NSFs and fault management of the policy execution. In NFV
   environment, policy consistency among multiple security function
   instances is very critical because security policies are no longer
   maintained by one central security devices, but instead are enforced
   by multiple security functions instantiated at various locations.

6.2. Service Layer Security Policy

   This layer is for customers or Application Gateway to express &
   monitor the needed security policies for their specific flows.

   Customers may not have security skills. As such, they are not able
   to express requirements or security policies that are precise
   enough. Usually these customers are expressing expectations (that
   can be viewed as loose security requirements). Customers may also
   express guidelines such as which critical communications are to be
   preserved during critical events, which hosts are to service even
   during severe security attacks, etc.

   Here are some examples of Service Oriented Security Policies:

          o Pass FW/IPS for Subscriber "xxx" with Port "y"
          o enable basic parental control
          o enable "school protection control"
          o allow Internet traffic from 8:30 to 20:00 [time = 8:30-

xxx, et al.            Expires December 8, 2015               [Page 14]

Internet-Draft              I2NSF Framework                   June 2015

          o scan email for malware detection [check type = malware]
            protect traffic to corporate network with integrity and
            confidentiality [protection type = integrity AND
          o remove tracking data from Facebook [website =
          o my son is allowed to access facebook from 18:30 to 20:00

   One Service Layer Security Policy may need multiple security
   functions at various locations to achieve the enforcement. Service
   layer Security Policy may need to be updated by users or Application
   Gateway when user's service requirements have been changed.

   I2NSF will not standardize the Service Layer security policies. IETF
   SUPA - Shared Unified Policy Automation, if approved and chartered,
   seems to be a good candidate to play in this space. [I2NSF-Demo]
   describes an implementation of translating a set of Service Layer
   policies to the Capability Layer instructions to NSFs.

7. Capability Negotiation

     When a NSF can't perform the desired provisioning due to resource
     constraint, it has to inform the controller.

     The protocol needed for this security function/capability
     negotiation may be somewhat correlated to the dynamic service
     parameter negotiation procedure [RFC7297]. The Connectivity
     Provisioning Profile (CPP) template documented in RFC7297, even
     though currently covering only Connectivity (but includes security
     clauses such as isolation requirements, non-via nodes, etc.),
     could be extended as a basis for the negotiation procedure.
     Likewise, the companion Connectivity Provisioning Negotiation
     Protocol (CPNP) could be a candidate to proceed with the
     negotiation procedure.

     The "security as a service" would be a typical example of the kind
     of (CPP-based) negotiation procedures that could take place
     between a corporate customer and a service provider. However, more
     security specific parameters have to be considered by this
     proposed work.

xxx, et al.            Expires December 8, 2015               [Page 15]

Internet-Draft              I2NSF Framework                   June 2015

8. Types of I2NSF clients

   It is envisioned that I2NSF clients include:

   - Application Gateway:

        -                 For example, Video Conference Mgr/Controller needs to
          dynamically inform some FW/IPS/IDS security functions on
          special policies based specific fields in the packets for the
          specific encrypted flows for a certain time span. Otherwise,
          some flows can't go through the FW/IPS/IDS because the
          payload is encrypted.

   - Security Administrators

          - Enterprise
          - Operator Management System dynamically update, monitor and
            verify the security policies to security functions
          - Third party system
          - management system

   - Security functions send requests for more sophisticated functions
     upon detecting something suspicious

9. Manageability Considerations

     Management of NSFs usually include
        -               life cycle management and resource management of vNSFs

        -               configuration of devices, such as address configuration,
          device internal attributes configuration, etc,

        -               signaling, and

        -               policy provisioning.

     I2NSF will only focus on the policy provisioning part, i.e. the
     last bullet listed above.

xxx, et al.            Expires December 8, 2015               [Page 16]

Internet-Draft              I2NSF Framework                   June 2015

10. Security Considerations

     Having a secure access to control and monitor NSFs is crucial for
     hosted security service. Therefore, proper secure communication
     channels have to be carefully specified for carrying the
     controlling and monitoring information between the NSFs and their
     management entity (or entities).

11. IANA Considerations

   This document requires no IANA actions. RFC Editor: Please remove
   this section before publication.

12. References

12.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile",
             RFC7297, April 2014.

 12.2. Informative References

   [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM
             Interface to Virtualized Security Services", <draft-
             pastor-i2nsf-access-usecases-00>, Oct 2014.

   [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", <draft-
             zarny-i2nsf-data-center-use-cases-00>, Oct 2014.

   [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access
             Network Use Case", <draft-qi-i2nsf-access-network-usecase-
             00>, Oct 2014

   [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security
             Functions Problem Statement", <draft-dunbar-i2nsf-problem-
             statement-01>, Jan 2015

xxx, et al.            Expires December 8, 2015               [Page 17]

Internet-Draft              I2NSF Framework                   June 2015

   [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL)
             YANG Data Model", <draft-ietf-net-acl-model-00>, Nov 2014.

   [gs_NFV] ETSI NFV Group Specification, Network Functions
             Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1,

   [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall",
             Network World, 11 November 2011

   [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services
             in Mobile Network", IETF87 Berlin, July 29, 2013.

   [I2NSF-Demo] Y. Xie, et al, "Interface to Network Security Functions
             Demo Outline Design", <draft-xie-i2nsf-demo-outline-
             design-00>, April 2015.

13. Acknowledgments

   Acknowledgements to xxx for his review and contributions.

   This document was prepared using

xxx, et al.            Expires December 8, 2015               [Page 18]

Internet-Draft              I2NSF Framework                   June 2015

Authors' Addresses

   Edward Lopez
   899 Kifer Road
   Sunnyvale, CA 94086
   Phone: +1 703 220 0988

   Diego Lopez

   XiaoJun Zhuang
   China Mobile

   Linda Dunbar

   Joe Parrott

   Ramki Krishnan

   Seetharama Rao Durbha

xxx, et al.            Expires December 8, 2015               [Page 19]