idnits 2.17.1 draft-qi-i2nsf-access-network-usecase-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2015) is 3339 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Wang 3 Internet-Draft X. Zhuang 4 Intended status: Informational China Mobile 5 Expires: September 7, 2015 March 6, 2015 7 Integrated Security with Access Network Use Case 8 draft-qi-i2nsf-access-network-usecase-02 10 Abstract 12 In traditional telecommunication system, operators usually provide 13 general and limited security protection service for users during 14 access (e.g. AKA in 3G/4G network). Now, with the development of 15 network virtualization technology and data center, physical network 16 devices can be replaced by network function softwares which are 17 running on virtual machines and the network function can be flexible 18 and elastic. Operators can provide users with more security services. 19 So this interfaces between operator's network and users are highly 20 desired. These interfaces will be used to request/achieve (Virtual) 21 Network Security Functions from operator's network. This draft 22 describes use cases for using the interface in operator's network 23 environment. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 31, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Use case summary . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Use case for Instantiation and Configuration of Security 63 Service Function . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Use case for Updating Security Service Function . . . . . . . 5 65 6. Use case for Collecting and Feedback of Status of Security 66 Service Function . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. The Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Informative References . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 This draft is a revised version of draft-qi-i2nsf-access-network- 75 usecase and refines the original use cases. In draft-qi-i2nsf-access- 76 network-usecase, an interface between UE and network was described 77 while this draft describes two interfaces.Users can use client to 78 achieve security service of operator via these interfaces. The user 79 can be an enterprise, an enterprise user, administrator of operator 80 and so on. The revisions details as below: 1.For original use case- 81 Interface about sending security configuration information from 82 network to UE: All examples have been deleted and network did not 83 send configuration information to UE via interface. Instead Users 84 will send security service requests to security controller to 85 configure NSF(s). 2.For original use case-Interface about optional 86 security function negotiation between Network and UE: All examples 87 have been deleted and there is no security function negotiation 88 between network and UE. Instead Users will send security service 89 request to security controller to configure NSF(s). 3.For original 90 use case-UE proposed security request to the network: The original 91 interactions between user and network will be more concrete. For 92 example, the original interaction between user and specific network 93 element will be revised into interaction between user's client and 94 security controller. The interaction between specific network element 95 and security function settings will be described in detail. 4.For 96 original section of Abstraction and The Benefits: Corresponding 97 modifications have been made to match revised use cases better. 99 2. Conventions used in this document 101 The section clarifies the intended meaning of specific terms used 102 within this document. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 In this document, these words will appear with that interpretation 109 only when in ALL CAPS. Lower case uses of these words are not to be 110 interpreted as carrying [RFC2119] significance. 112 3. Use case summary 114 This draft describes use cases of users (e.g. enterprise user, 115 operator's administrator and so on) using operators' flexible 116 security services. For example, a user can request a security service 117 through a client (e.g. APP, BSS/OSS, OAM etc.).An operator's network 118 entity(e.g. gateway) can invoke (v)NSF(s) according to user's service 119 request. In order to make the description more clear, we call 120 operator's network entity as security controller. The interaction 121 between entities above(i.e. client, security controller, NSF) can be 122 showed as below: 124 +----------+ 125 +-------+ | | +-------+ 126 | | Interface 1 |Security | Interface 2 | NSF(s)| 127 |Client <--------------> <------------------> | 128 | | |Controller| | | 129 +-------+ | | +-------+ 130 +----------+ 131 Figure 1. Interaction between Entities 133 Interface 1 is used for receiving security requirements from client 134 and translating them into commands that NSF(s) can understand and 135 execute. Moreover, it is also responsible for giving feedback of 136 NSFs' security statistics to client.Interface 2 is used for 137 interacting with NSFs according to commands. Moreover, it is also 138 responsible for receiving the results of commands from NSFs.NSF 139 mentioned in this draft includes virtualized NSF and physical NSF. 141 4. Use case for Instantiation and Configuration of Security Service 142 Function 144 Client sends collected security requirements through interface 1 to 145 the security controller in operator's network which then translates 146 them into a security function or a set of security functions then the 147 corresponding NSFs are instantiated and configured through interface 148 2.For example, an enterprise user A is a tenant of operator data 149 center and wants to filter all TCP data packets flowing to A's 150 network. Such a requirement is sent from client to security 151 controller through interface 1. The security controller translates 152 the requirement into a firewall function and then instantiates a 153 firewall NSF through interface 2. The corresponding filter rule is 154 also configured onto this firewall NSF. 156 5. Use case for Updating Security Service Function 158 User can use client to update security service function, including 159 adding/deleting a security service function and updating 160 configurations at former security service function. For example,a 161 user who has instantiated a security service before wants to enable 162 an IDS service additionally, this requirement will be sent to 163 security controller through interface 1 and be translated and then 164 security controller instantiates and configures an IDS NSF through 165 interface 2. Another example is that if the user A mentioned in use 166 case 1 wants to filter all UDP packets besides TCP packets, client 167 sends this requirement to security controller through interface 1 and 168 then security controller configures translated requirement onto the 169 former firewall NSF. 171 6. Use case for Collecting and Feedback of Status of Security Service 172 Function 174 When users want to get the executing status of security service, they 175 can request the status statistics information of NSF(s) from client. 176 Security controller can collect NSFs' status statistics information 177 through interface 2 and give feedback to client through interface 1, 178 which is helpful for user analyzing or updating security 179 requirements. Users can collect status statistics information of 180 NSF(s) related to their security service and can also be authorized 181 to collect all NSFs' status statistics information for the analysis 182 of big data for network security like the overall security status of 183 the network in operator's data center. 185 7. The Benefits 186 There are numerous benefits by defining such interfaces. Operators 187 could provide more flexible and customized security services for 188 specific users and this would provide more efficient and secure 189 protection to each user. 191 8. IANA Considerations 193 TBD 195 9. Informative References 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 Authors' Addresses 202 Ke Wang 203 China Mobile 204 32 Xuanwumenxi Ave,Xicheng District 205 Beijing 100053 206 China 208 Email: wangkeyj@chinamobile.com 210 Xiaojun Zhuang 211 China Mobile 212 32 Xuanwumenxi Ave, Xicheng District 213 Beijing 100053 214 China 216 Email: zhuangxiaojun@chinamobile.com 218 Minpeng Qi 219 China Mobile 220 32 Xuanwumenxi Ave,Xicheng District 221 Beijing 100053 222 China 224 Email: qiminpeng@chinamobile.com