[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                         S. Hartman
Internet-Draft                                              M. Wasserman
Intended status: Informational                         Painless Security
Expires: October 19, 2013                                       D. Zhang
                                             Huawei Technologies co. ltd
                                                          April 17, 2013

     Security Requirements in the Software Defined Networking Model


   Software defined/driven networks provide new dimensions of
   flexibility in network design.  This document analyzes security
   requirements as we design protocols to support multiple network
   applications on an SDN in an open manner.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 19, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) 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

Hartman, et al.          Expires October 19, 2013               [Page 1]

Internet-Draft          SDN Security Requirements             April 2013

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Moving Beyond a Single Application . . . . . . . . . . . . . .  3
     2.1.  Class 1: Network Sensitive Applications  . . . . . . . . .  3
     2.2.  Class 2: Services for the Network  . . . . . . . . . . . .  4
     2.3.  Class 3: Packaged Network Services . . . . . . . . . . . .  5
   3.  Authentication, Authorization and Multiple Organizations . . .  6
   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Nested Application Security  . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Hartman, et al.          Expires October 19, 2013               [Page 2]

Internet-Draft          SDN Security Requirements             April 2013

1.  Introduction

   This document analyzes the security of SDN architectures as we work
   to build SDN frameworks supporting multiple applications at the same
   time.  The assumption of this protocol is that protocols like
   Openflow will be used between a SDN controller and switches.  However
   this document assumes that there will be additional protocols between
   controllers and between controllers and applications.  That is the
   focus for the current analysis.

2.  Moving Beyond a Single Application

   Openflow defines a protocol between a physical switch and a
   controller.  Several factors motivate a layer between the controller
   and applications.  For example [I-D.nadeau-sdn-problem-statement]
   discusses a model where managed service providers (MSPs) provide
   networking services to applications.  This model involves the
   following attributes that significantly impact SDN security analysis:

   o  An application in one organization may use an MSP in another

   o  MSPs may be nested; one MSP may use the services of another

   o  Privacy concerns may limit what information should be exposed

   o  Applications require significant authorization and policy

   The remainder of this section examines a few classes of applications
   in order to identify characteristics of SDN use cases that affect

2.1.  Class 1: Network Sensitive Applications

   Some applications require particular characteristics from the
   network.  For example an application might need access to ports in a
   particular isolation domain/vlan.  An application might require a
   path with particular characteristics.  An application might require
   that traffic stay within a certain jurisdiction, travel only over
   certain equipment, or similar constraints.  An application might want
   to monitor the cost of certain traffic or flows.  And application
   might require that flows be discarded to mitigate a DOS attack or
   accepted in order to run a service.

   Applications in this class will typically wish to provision aspects
   of the network using some API.  They may wish to collect information
   from the network for monitoring, auditing or accounting.

Hartman, et al.          Expires October 19, 2013               [Page 3]

Internet-Draft          SDN Security Requirements             April 2013

   Applications may not be aware of each others' requests. the SDN
   controller needs to make sure that one application does not
   negatively interact with another.  Isolation of applications may be a
   security requirement.  In this case the controller needs to make sure
   that even a malicious application cannot interact badly with another.

   In most cases authorization will be important.  The network may have
   resources that are not appropriate for one application or another and
   may wish to enforce authorization between them.

   Multiple organizations may be involved within providing network
   services to such an application.  For example, an application may
   request a network connection within a particular isolation domain.
   However that isolation domain may include resources within an
   enterprise, a cloud provider and a transit network between the
   enterprise and cloud provider.  Authorization and authentication are
   likely to be handled by proxies in at least the simpler cases.  For
   example, an application in the enterprise network requests access to
   the application domain from some controller in the enterprise.  That
   controller has necessary credentials to request access from the
   transit network and cloud provider.  Authentication and authorization
   may be more complex when an application in the cloud environment
   requests access to the isolation domain.  Does it contact the
   enterprise controller or does it contact a resource in the cloud that
   has sufficient privilege to grant access to the enterprise aspect of
   the isolation domain.  Debugging of multi-organization environments
   is facilitated by exposing information about all the environments.
   For example it is likely that for monitoring and debugging purposes
   enterprise applications would want visibility into the cloud
   environment and the parts of the transit network that the enterprise
   is allowed to see.  Obviously the transit network and cloud provider
   would want to limit visibility into their internal structure but
   would want to make available information about resources controlled
   by that customer. for example the cloud provider would typically
   allow customers to see their own instances and virtual networks.
   Going through a proxy to authenticate requests for debugging and
   monitoring may not be ideal; it may be desirable for the application
   to collect debugging and monitoring information directly from the
   transit network and cloud provider.  If so, the authentication and
   authorization needs to be flexible enough to permit this.

2.2.  Class 2: Services for the Network

   An application may provide a service such as a firewall, content
   inspection or intrusion detection to the entire network.  In this
   case, the security model is similar to the security model between the
   SDN controller and switch; there is one key exception that will be
   discussed shortly.  The primary role of the separation between the

Hartman, et al.          Expires October 19, 2013               [Page 4]

Internet-Draft          SDN Security Requirements             April 2013

   SDN controller and application for this class of applications is to
   permit multiple applications to co-exist.  So, isolation of resources
   is still important.

   The security model for this class of application is similar to one of
   the common models for routing protocols and network management.
   Strong defense against outside attacks is required.  It would be a
   significant attack if an attacker could impersonate an authorized
   application and gain the ability to reconfigure or monitor the
   network.  However, inside attacks are not generally considered in
   scope for the threat analysis.

   One key consideration with this type of security model is protecting
   the boundary between inside and outside and supporting multiple zones
   of trust.  As an example, a border firewall application does not need
   the ability to reconfigure the interior of the network or to examine
   traffic inside interior isolation domains not destined for the border
   of the network.  So, even in this model authorizing what resources an
   application is permitted to see and manipulate is important.  This
   contrasts somewhat with the security model between the controller and
   switch, where the controller is permitted to manipulate all OpenFlow
   resources on the switch.

2.3.  Class 3: Packaged Network Services

   This class combines the previous two classes.  Consider an
   application of class 1 that wishes for all traffic leaving a certain
   isolation domain to pass through a particular border firewall
   service.  In effect an application is requesting an instantiation of
   another application be created as a virtual element in the network.
   This class of application permits abstraction and re-use of network
   applications.  There is obvious value in the cloud space.  However
   even within an organization, configuration re-use may have
   significant value.

   To discuss the security we will say that an outer application nests a
   nested application within the network.  The nested application may
   involve network resources (virtual or real) as well as compute and
   other resources.

   This class involves classic security concerns such as authentication
   and authorization.  What applications is the outer application
   permitted to nest?  How is auditing and accounting handled?  The IETF
   SDN architecture needs to permit these questions to be answered in a
   secure manner.

   There may be multiple instances of a nested application, nested into
   either the same or different outer applications.  There are

Hartman, et al.          Expires October 19, 2013               [Page 5]

Internet-Draft          SDN Security Requirements             April 2013

   significant issues related to the sharing of information between
   instances of a nested application.  For example, it is quite common
   for e-mail filtering services to collect information from multiple
   customers in order to better detect unwanted e-mail.  However leaking
   proprietary information from one customer to another would be
   undesirable.  To a large extent appropriate information sharing is a
   matter for application design and is out of scope for the SDN
   architecture.  However the SDN architecture needs to support tracking
   of instance-specific information as well as global information and
   needs to facilitate design of applications that supports isolation of
   instances.  This parallels virtual computing architectures, where the
   decision about how to split a problem is application specific, but
   the virtualization platform provides facilities to share information
   in a controlled manner and to manage large numbers of instances of

   Authentication may be more complex in the nested application
   situation.  The permissions that a nested application has will depend
   on which outer application it is working on-behalf of; the
   authentication approach will need to account for this.

   Multiple organizations may be involved with this class of
   application.  As an example, the nested application may be provided
   by an MSP.  Also, the nested application may use an MSP in providing
   the application.

   Balancing which resources are visible to the outer application will
   be tricky.  As with class 1 applications, debugging argues for
   visibility where possible. however, resources may be shared between
   instances of a nested application.  Also, visibility into the nested
   application might provide proprietary information or provide an
   attacker with potential advantages.  For example, understanding what
   flow filters were in place on a firewall application might expose
   information that would be valuable in getting around the firewall.

   There's a similar concern with the nested application's visibility
   into the outer application.  That visibility can be valuable for
   optimization and debugging.  However, it may provide proprietary
   information or otherwise compromise the privacy goals of the outer

3.  Authentication, Authorization and Multiple Organizations

   In looking at needs of the various classes of applications, support
   for applications and network resources spanning multiple
   organizations appeared as a requirement multiple times.  This
   requirement is interesting from a security standpoint.  This section

Hartman, et al.          Expires October 19, 2013               [Page 6]

Internet-Draft          SDN Security Requirements             April 2013

   explores how authentication and authorization can be handled between

   One approach is for an organization to proxy connections to other
   organizations.  The controller in one organization has credentials on
   behalf of the organization that it uses with other organizations.
   The local application talks to the local controller.  When the
   controller realizes that it needs resources from another organization
   it talks to that organization's controller.  This approach has been
   used fairly effectively in SIP [RFC3261] and other protocols with
   trusted intermediates.  A significant advantage of this approach is
   that it permits the organization to enforce organization-level
   policy.  It also permits the organization to hide information.  For
   example, consider the class 1 example where the enterprise's
   isolation domain is split between a cloud, transit network and domain
   inside the enterprise.  That split might be unimportant to the
   application; the organization's controller might try and present a
   unified network to applications.  In such a case a proxy approach can
   work well.

   The proxy approach has some disadvantages.  There is no end-to-end
   security including integrity or data-origin authentication.  The
   proxy becomes a very sensitive target.  Because of the lack of end-
   to-end integrity, if the proxy is compromised, then the attacker can
   impersonate other network resources from the view of elements behind
   the proxy.  The proxy may make deploying new features more difficult.
   To the extent that the proxy needs to understand a new feature before
   it is used, the proxy makes it more expensive to deploy the feature.

   Another approach is for applications to directly have credentials in
   another organization.  For example, this might work if an application
   wishes to use a particular external MSP.  The advantage of this
   approach is that it provides flexibility to the application.  The
   disadvantage is that it leaves open the question of how the two
   organizations' resources are glued together to form a consistent
   network.  In some cases the application could manage this.  In other
   cases, for example where changes are required in flow tables based on
   dynamic responses from the other organization, this may not be
   practical.  Other disadvantages include increased complexity and
   difficulty in enforcing organization-level policy.

   A third approach is to use some sort of federated/delegated
   authentication approach such as oauth [I-D.ietf-oauth-v2] or ABFAB
   [I-D.ietf-abfab-arch] to permit applications to obtain credentials
   that can be used in other organizations.  This sort of delegation and
   federation could facilitate the following use cases:

Hartman, et al.          Expires October 19, 2013               [Page 7]

Internet-Draft          SDN Security Requirements             April 2013

   o  Permit applications to obtain credentials for debugging and
      monitoring while attaching constraints to those credentials
      limiting resources the application can see

   o  Preset credentials so applications can talk to foreign
      controllers; for example the cloud application talking to the
      enterprise controller to gain access to the enterprise isolation

   o  Permit nested applications to be delegated access to some outer
      application resources

   o  Grant outer applications access to nested application resources
      for debugging, monitoring or application-specific reasons

   Another concern when multiple organizations are involved is auditing
   and accountability.  Digital signatures and other mechanisms can be
   used to provide end-to-end accountability.  However, this needs to be
   balanced against the need to hide information.  It seems like the SDN
   use case may be one where end-to-end accountability is rarely an

4.  Security Requirements

   This section captures a variety of security requirements for layers
   on top of SDN controllers.  These requirements are based on the
   discussion of potential applications as well as multi-organization

   REQ1: Authentication is REQUIRED to the controller.  Authentication
   SHOULD support existing credentials that are likely to be used in the

   REQ2: The interface to the SDN controller MUST support authorizing
   specific network resources to applications and manipulating the
   authorizations of applications.

   REQ3: The SDN controller MUST provide facilities to isolate one
   application from another.  XXX more discussion of this

   REQ 4: The SDN controller interface MUST support a controller acting
   as a proxy on behalf of applications.

   REQ 4a: The SDN interface SHOULD support a way of associating an
   audit ID or other tracking ID so that requests can be correlated with
   an original application when a proxy acts on behalf of an

Hartman, et al.          Expires October 19, 2013               [Page 8]

Internet-Draft          SDN Security Requirements             April 2013

   REQ 5: The SDN controller interface MUST provide mechanisms for
   operators and applications to enforce privacy.

   REQ 6: The SDN controller interface MUST support delegating access to
   a subset of resources; as part of delegation new authorization and
   privacy constraints MAY be supplied.  This supports the security
   needs of the debugging use case, aspects of the nested application
   use case, and facilitates other inter-organization uses.

4.1.  Nested Application Security

   This section captures requirements for nested application support.

   REQ N1: The SDN controller interface MUST support controlling
   authorization for what nested applications an outer application can

   REQ N2: The controller MUST separate authorizations held by one
   instance of a nested application from authorizations help by other
   instances of the same nested application.  This is more about defense
   from bugs and operational mistakes than maintaining isolation of
   authorizations even if the nested application tries to circumvent the
   authorizations.  However, it should be possible to write a nested
   application that maintains isolation sufficiently that compromise of
   one instance of the application will not lead to compromise of other
   instances.  Obviously doing so places constraints on what resources
   need to be duplicated between instances of an application.

   REQ N3: The SDN controller interface SHOULD provide outer
   applications a way to learn a nested application's policy for sharing
   information between instances.

   REQ N4: Nested applications MUST be able to authenticate on behalf of
   a specific outer application.  This facilitates authorization,
   accounting and auditing.

   REQ N5: Nested applications MUST be able to specify privacy policy
   for what resources are visible to the outer application.

   REQ N6: Outer applications MUST be able to specify privacy policy and
   authorizations with regard to what outer resources the nested
   application can interact with.

5.  Security Considerations

   This document provides discussion of the security implications of SDN
   architectures supporting multiple applications.

Hartman, et al.          Expires October 19, 2013               [Page 9]

Internet-Draft          SDN Security Requirements             April 2013

6.  IANA Considerations

   IANA is requested to make the internet secure.  Note to someone: re-
   word this section before IANA reviews it.

7.  Informative References

              Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
              Schaad, "Application Bridging for Federated Access Beyond
              Web (ABFAB) Architecture", draft-ietf-abfab-arch-03 (work
              in progress), July 2012.

              Hardt, D., "The OAuth 2.0 Authorization Framework",
              draft-ietf-oauth-v2-31 (work in progress), August 2012.

              Nadeau, T. and P. Pan, "Software Driven Networks Problem
              Statement", draft-nadeau-sdn-problem-statement-01 (work in
              progress), October 2011.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

Authors' Addresses

   Sam Hartman
   Painless Security

   Email: hartmans-ietf@mit.edu

   Painless Security

   Email: mrw@painless-security.com

Hartman, et al.          Expires October 19, 2013               [Page 10]

Internet-Draft          SDN Security Requirements             April 2013

   Dacheng Zhang
   Huawei Technologies co. ltd
   Huawei Building No.3 Xinxi Rd., Shang-Di Information Industrial Base Hai-Dian District, Beijing

   Email: zhangdacheng@huawei.com

Hartman, et al.          Expires April 18, 2013                [Page 11]