Network Working Group L. Dunbar
Internet Draft Huawei
Intended status: Informational D. Lopez
Expires: October 2015 Telefonica
X. Zhuang
China Mobile
J. Parrott
BT
R Krishnan
Brocade
S. Durbha
CableLabs
April 21, 2015
Framework for Interface to Network Security Functions
draft-merged-i2nsf-framework-00.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 October 21, 2015 [Page 1]
Internet-Draft I2NSF Framework April 2015
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 21, 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. Multiple Interfaces to NSF.....................................4
3.1. Interface A - Registration Interface......................5
3.2. Interface B - Service Layer Policy Interface..............6
3.3. Interface C - Functional Layer Interface..................6
4. Security Function Capability Registration......................7
5. Security Policies at Service Layer and Function Layer.........10
5.1. Security Policies Service Layer..........................10
5.2. Security Policies at Functional Layer....................11
6. Types of I2NSF clients........................................12
7. Types of Access...............................................12
8. Manageability Considerations..................................13
xxx, et al. Expires October 21, 2015 [Page 2]
Internet-Draft I2NSF Framework April 2015
9. Security Considerations.......................................13
10. Conclusion and Recommendation................................13
11. IANA Considerations..........................................14
12. References...................................................14
12.1. Normative References....................................14
12.2. Informative References..................................14
13. Acknowledgments..............................................15
1. Introduction
This document describes the framework for Interface to Network
Security Functions and defines a reference model along with
functional components at various I2NSF interfaces. The goal is to
create a workable interface to NSFs which aid in their integration
within SDN/NFV environment, while avoiding potential constraints
which could limit their functional capabilities.
The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile])
call for standard interfaces for customers to utilize 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
FW: Firewall
IDS: Intrusion Detection System
IPS: Intrusion Protection System
xxx, et al. Expires October 21, 2015 [Page 3]
Internet-Draft I2NSF Framework April 2015
NBI: Northbound Interface. "Northbound" can be ambiguous because
"northbound" to entity A can be southbound to entity B.
So we try to avoid using "northbound" in I2NSF.
NSF: Network Security Functions
OSS: Operation Support System
3. Multiple Interfaces to NSF
From the security functions management perspective, three types of
interfaces are needed for customers to request their security
policies which are effectively enforced by a collection of NSFs
(potentially from different vendors):
- Capability Registration,
- Service Layer Security Policies, and
- Functional Layer security policies.
From the I2NSF perspective, there is no difference between virtual
network security functions (vNSF) and physical network security
functions. However, in the environment where "vNSF" are deployed,
there is more likelihood that the users/clients security policies
are enforced by a collection of NSFs distributed throughout the
network.
xxx, et al. Expires October 21, 2015 [Page 4]
Internet-Draft I2NSF Framework April 2015
Client/AppGW
|
| Interface B
+-----+---------------+
|Service Provider mgmt| +-------------+
| Security Controller | < -------- > | Vendor |
+---------------------+ Interface A | Sys |
| +-------------+
|
| Interface C
|
+------------------------------------------------+
| |
| |
+------+ +------+ +------+ +------+
+ SF-1 + ------- + SF-n + + SF-1 + ----- + SF-m + . . .
+------+ +------+ +------+ +------+
Vendor A Vendor B
Figure 1: Multiple Interfaces
3.1. Interface A - Registration Interface
Even though security functions come in variety of form factors and
have different features, [Packet-based-NSF] advocates that the
flow based security functions 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
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 October 21, 2015 [Page 5]
Internet-Draft I2NSF Framework April 2015
The functional profile is vendor specific and differentiates
vendor unique innovation.
When service providers have multiple types of security functions
provided by different vendors, vendors can register their security
functions capabilities indicating the available policies that can
be provisioned or monitored for each of the categories listed
above.
3.2. Interface B - Service Layer Policy Interface
This interface is for clients or Application Gateway to express
and monitor security policies for their specific flows.
A single client layer or service layer policy may need multiple
security functions collectively together to achieve the
enforcement.
3.3. Interface C - Functional Layer Interface
A set of security functions may be needed to enforce the Service
Layer Security Policies requested by the users/clients. The
service providers' OSS or Security Controller have to terminate
the user level security policies, select a set of the security
functions collectively together to enforce the user requested
security policies, and set the specific security policies to each
function being selected.
The Functional Layer Interface is between the Service Provider's
OSS (or its Security Controller) and the security functions that
are selected to accomplish the Service Layer Policies requested by
users.
Because there are so many security functions, the Network Security
functions under I2NSF consideration start with Packet Based
Security Functions, commonly supported by FW/IDS/IPS/WebFilter.
xxx, et al. Expires October 21, 2015 [Page 6]
Internet-Draft I2NSF Framework April 2015
4. Security Function Capability Registration
There are many types of network security functions. To prevent
constraints on NSF vendors' creativity and innovation, [Packet-
Based-NSF] recommends the NSF interfaces to be designed from the
paradigm of processing packets 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.
Network Security functions differ in the depth of packet header or
payload they can inspect, the various session/context states they
can maintain, and the actions or specific profiles they can apply.
Therefore, the NSF capabilities are characterized by the level of
packet processing and context that a NSF supports, the actions and
profiles that the NSF can apply.
Vendors can register their provided security functions using the
Subject-Object-Action-Function categories described by [Packet-
based-NSF].
+-----------------------------------------------------------+
| Subject Capability Index |
+---------------+-------------------------------------------+
| Layer 2 | Layer 2 header fields: |
| Header | Source/Destination/s-VID/c-VID/EtherType/.|
| | |
|---------------+-------------------------------------------+
| Layer 3 | Layer header fields: |
| | protocol |
| IPv4 objects | port |
| | src port |
| | dscp |
| | length |
| | flags |
| | ttl |
| | |
| IPv6 Object | |
| | addr |
| | protocol/nh |
| | src port |
| | length |
| | traffic class |
xxx, et al. Expires October 21, 2015 [Page 7]
Internet-Draft I2NSF Framework April 2015
| | 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 |
| | | 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 |
xxx, et al. Expires October 21, 2015 [Page 8]
Internet-Draft I2NSF Framework April 2015
+---------------+-------------------------------------------+
| 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 | Vendor specific |
| | Flexible Profile URL |
| | Accept external |
| | |
+---------------+-------------------------------------------+
xxx, et al. Expires October 21, 2015 [Page 9]
Internet-Draft I2NSF Framework April 2015
5. Security Policies at Service Layer and Function Layer
+------------------------------------------+
| App Gateway |
| (e.g. Video conference Ctrl |
| Admin, OSS/BSS, or Service Orchestration |
+---------------------+--------------------+
I2NSF |Security Policy at Service Layer
|
+--------------+----------------+
| Network/Security Controller |
+--------------+----------------+
I2NSF |Security Policy at Functional Layer
|
+------------------+
| Adapter |
+------------------+
| virtual/physical |
|Security Functions|
+------------------+
Figure 1: Multiple Layers of I2NSF interfaces
5.1. Security Policies Service Layer
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 October 21, 2015 [Page 10]
Internet-Draft I2NSF Framework April 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.
This layer will leverage the existing protocols in NETCONF or
RESTconf.
5.2. Security Policies at Functional Layer
Security Policies at Functional Layer is to express the explicit
policies to individual security functions 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 policies, which are derived from
the Service Layer interface commands
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.
The "subject" of the I2NSF functional layer not only includes the
matching criteria specified by [ACL-MODEL] but also the L4-L7 fields
depending on the NSF selected.
The I2NSF functional 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].
The functional profiles for I2NSF are not present in [ACL-MODEL]
because the functional profiles are unique to specific NSFs.
xxx, et al. Expires October 21, 2015 [Page 11]
Internet-Draft I2NSF Framework April 2015
Most vendors' IPS/IDS, and HoneyPot have their proprietary
functions/profiles.
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. 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
7. Types of Access
Depending on the relationship between I2NSF clients and their
security functions providers, there could be different types of
access:
xxx, et al. Expires October 21, 2015 [Page 12]
Internet-Draft I2NSF Framework April 2015
- 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.
Integration with existing identity management systems is also
possible.
- Open environments where some network security functions (virtual
or physical) can be hosted in external administrative domains, and
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.
8. Manageability Considerations
TBD.
9. Security Considerations
TBD
10. Conclusion and Recommendation
xxx, et al. Expires October 21, 2015 [Page 13]
Internet-Draft I2NSF Framework April 2015
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
[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 October 21, 2015 [Page 14]
Internet-Draft I2NSF Framework April 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
13. Acknowledgments
Acknowledgements to xxx for his review and contributions.
This document was prepared using 2-Word-v2.0.template.dot.
xxx, et al. Expires October 21, 2015 [Page 15]
Internet-Draft I2NSF Framework April 2015
Authors' Addresses
Linda Dunbar
Huawei
Email: Linda.Dunbar@huawei.com
Diego Lopez
Telefonica
Email: diego.r.lopez@telefonica.com
XiaoJun Zhuang
China Mobile
Email: zhuangxiaojun@chinamobile.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 October 21, 2015 [Page 16]