[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                                  K. Wang
Internet-Draft                                                 X. Zhuang
Intended status: Informational                              China Mobile
Expires: September 7, 2015                                 March 6, 2015


            Integrated Security with Access Network Use Case
                draft-qi-i2nsf-access-network-usecase-02

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, physical network
   devices can be replaced by network function softwares which are
   running on virtual machines and the network function can be flexible
   and elastic. Operators can provide users with more security services.
   So this interfaces between operator's network and users are highly
   desired.  These interfaces will be used to request/achieve (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       Expires September 7, 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 and refines the original use cases. In draft-qi-i2nsf-access-
   network-usecase, an interface between UE and network was described
   while this draft describes two interfaces.Users can use client to
   achieve security service of operator via these interfaces. The user
   can be an enterprise, an enterprise user, administrator of operator
   and so on. The revisions details 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. Instead Users
   will send security service requests 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. Instead Users will send security service
   request to security controller to configure NSF(s). 3.For original



Wang &Zhuang &Qi       Expires September 7, 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 into interaction between user's client and
   security controller. The interaction between specific network element
   and security function settings will be described in detail. 4.For
   original section of Abstraction and The Benefits: Corresponding
   modifications have been made to match revised use cases better.

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

   This draft describes use cases of users (e.g. enterprise user,
   operator's administrator and so on) using operators' flexible
   security services. For example, a user can request a security service
   through a client (e.g. APP, BSS/OSS, OAM etc.).An operator's network
   entity(e.g. gateway) can invoke (v)NSF(s) according to user's service
   request. In order to make the description more clear, we call
   operator's network entity as security controller. The interaction
   between entities above(i.e. client, security controller, NSF) can be
   showed as below:

                       +----------+
+-------+              |          |                  +-------+
|       |  Interface 1 |Security  |   Interface 2    | NSF(s)|
|Client <-------------->          <------------------>       |
|       |              |Controller|                  |       |
+-------+              |          |                  +-------+
                       +----------+
            Figure 1. Interaction between Entities

   Interface 1 is used for receiving security requirements from client
   and translating them into commands that NSF(s) can understand and
   execute. Moreover, it is also responsible for giving feedback of
   NSFs' security statistics to client.Interface 2 is used for
   interacting with NSFs according to commands. Moreover, it is also



Wang &Zhuang &Qi       Expires September 7, 2015                [Page 3]


Internet-Draft          Access Network Use Case            February 2015


   responsible for receiving the results of commands from NSFs.NSF
   mentioned in this draft includes virtualized NSF and physical NSF.

4.  Use case for Instantiation and Configuration of Security Service
   Function

   Client sends collected security requirements through interface 1 to
   the security controller in operator's network which then translates
   them into a security function or a set of security functions then the
   corresponding NSFs are instantiated and configured through interface
   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. The 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,a
   user who has instantiated a security service before wants to enable
   an IDS service additionally, this 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 NSFs' 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 NSFs' 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



Wang &Zhuang &Qi       Expires September 7, 2015                [Page 4]


Internet-Draft          Access Network Use Case            February 2015


   There are numerous benefits by defining such interfaces. Operators
   could provide more flexible and customized security services for
   specific users and this would provide more efficient and secure
   protection to each user.

8.  IANA Considerations

   TBD

9.  Informative References

   [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











Wang &Zhuang &Qi       Expires September 7, 2015                [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/