Internet Engineering Task Force K. Wang
Internet-Draft X. Zhuang
Intended status: Informational China Mobile
Expires: August 31, 2015 February 27, 2015
Integrated Security with Access Network Use Case
draft-qi-i2nsf-access-network-usecase-01
Abstract
In traditional telecommunication system, operators usually provide
general and limited security protection service for users during
access (e.g. AKA in 3G/4G network). Now, with the development of
network virtualization technology and data center, the physical
network device is became a network function software which is running
on virtual machine of server and the network functions can be
flexible and elastic. So operators can provide more flexible security
function to users. In order to provide more flexible security
service, interfaces between operator's network and user should be
needed. These interfaces will be used to request/achieve operate
(Virtual) Network Security Functions from operator's network. This
draft describes use cases for using the interface in operator's
network environment.
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 August 31, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang &Zhuang &Qi &Liu Expires August 31, 2015 [Page 1]
Internet-Draft Access Network Use Case February 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Use case summary . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use case for Instantiation and Configuration of Security
Service Function . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use case for Updating Security Service Function . . . . . . . 5
6. Use case for Collecting and Feedback of Status of Security
Service Function . . . . . . . . . . . . . . . . . . . . . . . 5
7. The Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This draft is a revised version of draft-qi-i2nsf-access-network-
usecase. This draft refines the original use case to more concrete.
In draft-qi-i2nsf-access-network-usecase, an interface between UE and
network was described. This draft describes two interfaces, user can
use client to achieve security service of operator via these
interfaces. The user can be an enterprise, an enterprise user,
administrator of operator etc. The detailed revisions are as below:
1.For original use case-Interface about sending security
configuration information from network to UE: All examples have been
deleted and network did not send configuration information to UE via
interface. User will send security service request to security
controller to configure NSF(s). 2.For original use case-Interface
about optional security function negotiation between Network and
UE: All examples have been deleted and there is no security function
negotiation between network and UE. User will send security service
request to security controller to configure NSF(s). 3.For original
Wang &Zhuang &Qi &Liu Expires August 31, 2015 [Page 2]
Internet-Draft Access Network Use Case February 2015
use case-UE proposed security request to the network: The original
interactions between user and network will be more concrete. For
example, the original interaction between user and specific network
element will be revised interaction between user's client and
security controller. The interaction specific network element and
security function settings will be described in detail. 4.For
original section of Abstraction and The Benefits: In order to better
match with revised use cases, they have been refined also.
2. Conventions used in this document
The section clarifies the intended meaning of specific terms used
within 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 [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 [RFC2119] significance.
3. Use case summary
With the development of virtualization and NFV, operators can provide
more flexible security services and users wish to get more customized
security services.This draft describes users(e.g. enterprise users,
BSS/OSS and so on) using operators' flexible security services
through client.Reference model is as followed,
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <--------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 1. Reference Model for using Operator's security service
4. Use case for Instantiation and Configuration of Security Service
Function
Client sends collected security requirements through interface 1 to
security controller in operator's network which then translates them
into a security function or a set of security functions then the
corresponding vNSFs are instantiated and configured through interface
Wang &Zhuang &Qi &Liu Expires August 31, 2015 [Page 3]
Internet-Draft Access Network Use Case February 2015
2.For example, an enterprise user A is a tenant of operator data
center and wants to filter all TCP data packets flowing to A's
network. Such a requirement is sent from client to security
controller through interface 1. Security controller translates the
requirement into a firewall function and then instantiates a firewall
NSF through interface 2. The corresponding filter rule is also
configured onto this firewall NSF.
5. Use case for Updating Security Service Function
User can use client to update security service function, including
adding/deleting a security service function and updating
configurations at former security service function. For example, if
client collects a requirement of enabling an IDS service from the
user who has instantiated a security service, the requirement will be
sent to security controller through interface 1 and be translated and
then security controller instantiates and configures an IDS NSF
through interface 2. Another example is that if the user A mentioned
in use case 1 wants to filter all UDP packets besides TCP packets,
client sends this requirement to security controller through
interface 1 and then security controller configures translated
requirement onto the former firewall NSF.
6. Use case for Collecting and Feedback of Status of Security Service
Function
When users want to get the executing status of security service, they
can request the status statistics information of NSF(s) from client.
Security controller can collect vNSFs' status statistics information
through interface 2 and give feedback to client through interface 1,
which is helpful for user analyzing or updating security
requirements. Users can collect status statistics information of
NSF(s) related to their security service and can also be authorized
to collect all vNSFs' status statistics information for the analysis
of big data for network security like the overall security status of
the network in operator's data center.
7. The Benefits
It will bring benefits by defining such interfaces. Operator could
provide more flexible and tailored security service for specific user
which would lead more efficient and secure protection to each user.
8. IANA Considerations
TBD
9. Informative References
Wang &Zhuang &Qi &Liu Expires August 31, 2015 [Page 4]
Internet-Draft Access Network Use Case February 2015
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Ke Wang
China Mobile
32 Xuanwumenxi Ave,Xicheng District
Beijing 100053
China
Email: wangkeyj@chinamobile.com
Xiaojun Zhuang
China Mobile
32 Xuanwumenxi Ave, Xicheng District
Beijing 100053
China
Email: zhuangxiaojun@chinamobile.com
Minpeng Qi
China Mobile
32 Xuanwumenxi Ave,Xicheng District
Beijing 100053
China
Email: qiminpeng@chinamobile.com
Fuwen Liu
China Mobile
32 Xuanwumenxi Ave,Xicheng District
Beijing 100053
China
Email: liufuwen@chinamobile.com
Wang &Zhuang &Qi &Liu Expires August 31, 2015 [Page 5]