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]