Network Working Group L. Dunbar
Internet Draft Huawei
Intended status: Informational D. Lopez
Expires: December 2015 Telefonica
X. Zhuang
China Mobile
J. Parrott
BT
R Krishnan
Brocade
S. Durbha
CableLabs
June 3, 2015
Framework for Interface to Network Security Functions
draft-merged-i2nsf-framework-01.txt
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt
xxx, et al. Expires December 3, 2015 [Page 1]
Internet-Draft I2NSF Framework June 2015
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 3, 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
(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 described in the Simplified BSD License.
Abstract
This document describes the framework for Interface to Network
Security Functions and defines a reference model along with
functional components.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Reference Models in Managing NSFs..............................4
3.1. NSF Facing Interface......................................5
3.2. Client Facing Interface...................................5
3.3. Vendor Facing Interface...................................5
3.4. The network connecting the Security Controller and NSFs...6
3.5. Interface to vNSFs........................................7
4. Flow-based NSF Capability Characterization.....................8
5. Security Policies Provisioning to NSFs........................11
5.1. Capability Layer Provisioning and Monitoring.............11
5.2. Service Layer Security Policy............................12
6. Capability Negotiation........................................13
xxx, et al. Expires December 3, 2015 [Page 2]
Internet-Draft I2NSF Framework June 2015
7. Types of I2NSF clients........................................14
8. Manageability Considerations..................................14
9. Security Considerations.......................................14
10. IANA Considerations..........................................15
11. References...................................................15
11.1. Normative References....................................15
11.2. Informative References..................................15
12. Acknowledgments..............................................16
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 SDN/NFV 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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.
BSS: Business Support System
Controller: used interchangeably with Service Provider Security
Controller or management system throughout this
document.
FW: Firewall
xxx, et al. Expires December 3, 2015 [Page 3]
Internet-Draft I2NSF Framework June 2015
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. Reference Models in Managing NSFs
As described by [Packet-based-NSF], NSFs management can be generally
grouped into three types: Configuration, Signaling, and
Provisioning. 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.
Client/AppGW
|
| 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
xxx, et al. Expires December 3, 2015 [Page 4]
Internet-Draft I2NSF Framework June 2015
3.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.
3.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
context.
A single client layer policy may need multiple NSFs collectively
together to achieve the enforcement.
3.3. Vendor Facing Interface
Even though security functions come in variety of form factors and
have different features, [Packet-based-NSF] advocates that the
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.
xxx, et al. Expires December 3, 2015 [Page 5]
Internet-Draft I2NSF Framework June 2015
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.
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
above.
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.
3.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
environment.
xxx, et al. Expires December 3, 2015 [Page 6]
Internet-Draft I2NSF Framework June 2015
- 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
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
Authorization.
3.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 3, 2015 [Page 7]
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
4. Flow-based NSF Capability Characterization
There are many types of flow-based NSFs. To prevent constraints on
NSF vendors' creativity and innovation, [Packet-Based-NSF]
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 associated.
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 by [Packet-based-NSF], with detailed
specification of each category as shown in the table below:
xxx, et al. Expires December 3, 2015 [Page 8]
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 3, 2015 [Page 9]
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 3, 2015 [Page 10]
Internet-Draft I2NSF Framework June 2015
5. 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
5.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 3, 2015 [Page 11]
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-
MODEL].
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.
5.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-
20:00]
xxx, et al. Expires December 3, 2015 [Page 12]
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
confidentiality]
o remove tracking data from Facebook [website =
*.facebook.com]
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.
[I2NSF-Demo] describes an implementation of translating a set of
Service Layer policies to the Capability Layer instructions to NSFs.
6. 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 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 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 3, 2015 [Page 13]
Internet-Draft I2NSF Framework June 2015
7. 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
8. Manageability Considerations
Management of NSFs usually include configuration of devices,
signaling and policy provisioning. I2NSF will only focus on the
policy provisioning part.
9. 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).
xxx, et al. Expires December 3, 2015 [Page 14]
Internet-Draft I2NSF Framework June 2015
10. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove
this section before publication.
11. References
11.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.
11.2. Informative References
[Packet-Based-NSF] E. Lopez, "Packet-Based Paradigm For Interfaces
to NSFs", <draft-lopez-i2nsf-packet-00>, in-progress,
March 2015.
[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
[ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL)
YANG Data Model", <draft-ietf-net-acl-model-00>, Nov 2014.
xxx, et al. Expires December 3, 2015 [Page 15]
Internet-Draft I2NSF Framework June 2015
[gs_NFV] ETSI NFV Group Specification, Network Functions
Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1,
2013.
[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.
12. Acknowledgments
Acknowledgements to xxx for his review and contributions.
This document was prepared using 2-Word-v2.0.template.dot.
xxx, et al. Expires December 3, 2015 [Page 16]
Internet-Draft I2NSF Framework June 2015
Authors' Addresses
Diego Lopez
Telefonica
Email: diego.r.lopez@telefonica.com
XiaoJun Zhuang
China Mobile
Email: zhuangxiaojun@chinamobile.com
Linda Dunbar
Huawei
Email: Linda.Dunbar@huawei.com
Joe Parrott
BT
Email: joe.parrott@bt.com
Ramki Krishnan
Brocade
Email: ramk@brocade.com
Seetharama Rao Durbha
CableLabs
Email: S.Durbha@cablelabs.com
xxx, et al. Expires December 3, 2015 [Page 17]