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

Internet Engineering Task Force                                    M. Qi
Internet-Draft                                                 X. Zhuang
Intended status: Informational                              China Mobile
Expires: April 27, 2015                                 October 24, 2014

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

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, the physical network device is
   became a network function software which is running on virtual
   machine and the network functions can be flexible and elastic.  So
   operators can provide more flexible security function to users
   through network function.  In order to provide more flexible security
   function, an interface between operator's network and user should be
   needed.  The interface will be used to request/negotiate/allocate/
   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 April 27, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Qi & Zhuang              Expires April 27, 2015                 [Page 1]
Internet-Draft           Access Network Use Case            October 2014

   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 . . . . . . . . . . . . . .   2
   3.  Interface about sending security configuration
       information from network to UE  . . . . . . . . . . . . . . .   3
   4.  Interface about optional security function negotiation
       between      Network and UE . . . . . . . . . . . . . . . . .   4
   5.  UE proposed security request to the network . . . . . . . . .   4
   6.  The Benefits  . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   In traditional telecommunication system, operators will provide
   security protection function for users when they request to access
   the network, such as authentication, encryption and integrity
   protection function, etc.  However, considering efficiency and costs
   of the network deployment, 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, security function virtualization can help operators to
   provide flexible and reliable security protection service for users
   access.

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

Qi & Zhuang              Expires April 27, 2015                 [Page 2]
Internet-Draft           Access Network Use Case            October 2014

   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.  Interface about sending security configuration information from
    network to UE

   In the traditional telecommunication network, when a user requests to
   access network, operators will provide security service during access
   procedure to ensure that users can securely connect to the
   telecommunications network.  This security solution is not provided
   by the access equipment such as CPE, but by the operator's core
   network equipment (e.g.  MME).  As operators provide such security
   solutions by using physical network equipment, which would cause
   limitation for security service, operators should provide the same
   security function to all users, such as unified authentication
   mechanism (usually pre-shared key based authentication), same
   encryption capabilities and so on.

   But under virtualized environment, the physical network device is as
   network function software which is running on virtual machine and the
   network functions can be flexible and elastic.  So operators can
   provide more flexible security function to users through virtualized
   network function.

   For example, it can provide different authentication function for
   different users.  Authentication mechanism can be provided based on
   pre-shared key or based on certificate.  What is more, it can also
   provide flexible encryption function.  Operators can provide
   encryption by usingnot only encryption algorithms, but also keys with
   different lengths.

   An concrete example is, Internet of Things(IoT)business.  When a
   simple IoT services such as street lighting controlling need connect
   to the network, it only needs to implement simple network
   authentication with users, so it can choose one-way pre-shared key
   based access authentication through the interface like GSM
   authentication.  While for another IoT business, such as home remote
   monitoring, it needs to utilize mutual authentication with pre-shared
   key between network and users.  As a result UMTS access
   authentication would be chosen and applied through the interface.
   For some other kind of more sensitive IoT business, such as automatic
   selling machine, it would need certificate based authentication.  As
   a result, operators need to inform the UE of the configuration
   information, and help UE to make a decision.

Qi & Zhuang              Expires April 27, 2015                 [Page 3]
Internet-Draft           Access Network Use Case            October 2014

   So an interface to sending such configuration is needed.  The list of
   allowed security functions and prohibited security functions should
   be both passed in the interface.

4.  Interface about optional security function negotiation between
    Network and UE

   Under current network access environment, when users want to access
   to the network, operators can only provide necessarily basic security
   functions, which avoids impact to all of users by using advanced
   security functions designed for a specific user.  However, in a
   virtualized network, operators can customize more flexible security
   functions for users.

   For example, if a user does not want to receive spam, operator can
   provide countermeasures like key words filtering function to such
   user; if a user want to keep communication data with high security,
   operator can provide enhanced services based on IDS / IPS.  And if
   users want to have no security requirement to speed up, there is no
   need for operator to provide any security functions.

   In this case, an interface is needed for operators.  It can inform
   the UE about what optional security functions they could provide.

5.  UE proposed security request to the network

   Before the virtualization of the network, UE can only be provided the
   fixed security services provided by operators when access to the
   network, which is mentioned as above.  In a virtualized environment,
   operators has ability to provide more service.  Therefore, UEs get
   new chance to send security services request based on its specific
   requirement to operators.  And operators can fulfill users
   requirement by increasing, updating the corresponding network
   security functions.

   In this case, a new interface is needed.  It can be used by users to
   inform specific network element, like operator-specific gateway.
   Operators can convert the user's functional requirements into the
   corresponding security functions settings, then provide security
   access services in accordance with the required security function.

   There are some kinds of fulfillment of such interface.  For example,
   users don't want to receive abnormal traffic, like advertisement,
   worms, IP detecting flows, etc.  Operators can provide IP address
   filtering capabilities according to the IP address defined
   requirements which have been negotiated with users.  Alternatively,
   according to a list of pre-defined options, users can send the
   functions and configuration requirements in a specific format to the

Qi & Zhuang              Expires April 27, 2015                 [Page 4]
Internet-Draft           Access Network Use Case            October 2014

   operator's gateway, and operator provide services directly according
   to enabling security functions from related requirements.  A concrete
   example is, a user hoping to filter traffic in tcp 21 port sent "tcp
   21 port block on firewall " command directly to the operator gateway,
   then operator send the same command directly to the virtual firewall
   corresponding to users ,after testing the legality of the message.

6.  The Benefits

   It will bring benefits by defining such interface.  Operator could
   send specific security configurations and optional security service
   list to user equipments.  UE could send security policy/function
   request to operators.  Through such interface, operator could provide
   more flexible and tailored security functions for specific user,
   which would lead more efficient and secure protection to each end
   user.

7.  IANA Considerations

   TBD

8.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Minpeng Qi
   China Mobile
   32 Xuanwumenxi Ave,Xicheng District
   Beijing  100053
   China

   Email: qiminpeng@chinamobile.com

   Xiaojun Zhuang
   China Mobile
   32 Xuanwumenxi Ave, Xicheng District
   Beijing  100053
   China

   Email: zhuangxiaojun@chinamobile.com

Qi & Zhuang              Expires April 27, 2015                 [Page 5]