idnits 2.17.1 draft-ahn-i2nsf-communications-security-use-case-01.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 65 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services' is defined on line 345, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF T. Ahn 2 Internet Draft S. Lee 3 Intended status: Informational K. Kim 4 Expires: April 30, 2017 U. Kim 5 KT 6 October 31, 2016 8 Use Cases for the Communications Security using Interface to Network 9 Security Functions 10 draft-ahn-i2nsf-communications-security-use-case-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 1,2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 47 Internet-Draft Use Cases for the Communication Security November 48 2016 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 This document provides use cases for the IP-based communications 57 security using Interface to Network Security Functions (I2NSF). The 58 use cases in this document cover the detection and prevention of the 59 illegal authentication, call of VoIP/VoLTE and spam message. 61 Table of Contents 63 1. Introduction ................................................ 2 64 2. Conventions used in this document ............................ 2 65 3. Use Cases ................................................... 3 66 3.1. Framework of the I2NSF communication security ........... 3 67 3.2. Use Case of Voice Call Security ......................... 4 68 3.3. Use Case of prevention of VoIP/VoLTE device scanning ..... 5 69 3.4. Use Case of prevention of spam messages ................. 6 70 4. Security Considerations ...................................... 7 71 5. IANA Considerations ......................................... 7 72 6. Conclusions ................................................. 7 73 7. References .................................................. 7 74 7.1. Normative References .................................... 7 75 7.2. Informative References .................................. 8 76 8. Acknowledgments ............................................. 8 78 1. Introduction 80 As VoLTE is a crucial service for telecommunication operators, it 81 becomes more important to provide secure voice and messaging 82 communication services. VoLTE and VoIP are based on IP, attacks such 83 as compromising the telephony application or re-routing the IP 84 signal can be happened. 86 This document describes IP-based communications security use cases 87 for Interface to Network Security Functions (I2NSF) such as VoIP, 88 VoLTE and messaging service. 90 2. Conventions used in this document 92 VoLTE: Voice over LTE 94 SND: Software defined Network 96 Internet-Draft Use Cases for the Communication Security November 97 2016 99 NSF: Network Security Function 101 I2NSF: Interface to Network Security Functions 103 3. Use Cases 105 3.1. Framework of the I2NSF communication security 107 +-----------------------------------------------------+ 108 | I2NSF Client | 109 | (Communications Security Service Manager) | 110 | | 111 +----------+------------------------------------------+ 112 | 113 | Client Facing Interface 114 | 115 +----------+----------+ +-------------+ 116 | Communications | | Developer's | 117 | Security Controller | | Mgnt System | 118 +---------------+-----+ <---------> +-------------+ 119 | Registration Interface 120 | 121 | NSF Facing Interface 122 | 123 +----------+------------------+------------------+ 124 | | | 125 | | | 126 +---+--------------+ +---------+--------+ +----+------------+ 127 | VoIP | | VoLTE | | Messaging | 128 | Security Function| | Security Function| |Security Function| 129 +------------------+ +------------------+ +-----------------+ 130 | | | 131 +-------------------------+----------------------+ 132 | 133 +---------------------+-------------------+ 134 | | 135 +-------+----------+ +--------+--------+ 136 | SDN-Enabled | | Non-SDN | 137 | Network | | Network | 138 +------------------+ +-----------------+ 140 Figure 1 I2NSF Framework for Communications Security 142 Internet-Draft Use Cases for the Communication Security November 143 2016 145 3.2. Use Case of Voice Call Security 147 The procedure of VoIP/VoLTE voice call security operations is as 148 follows: 150 1. Communications Security Manager(I2NSF Client) sends rules to 151 Communication Security Controller to block packets or flows that 152 match conditions that operators configure. In voice call security, 153 those rules can be prevention of the Caller ID spoofing or DDoS 154 attack. 156 2. Communication Security Controller creates and sends the data 157 model that the Communication Security Function can understand. 158 The data model includes the Events, Conditions and Actions. In 159 this use case Events can be originating call by user action and 160 Conditions can be IP address and port of origination and 161 termination device, User-Agent of device, media information of 162 device such as SDP(Session Description Protocol) and call state 163 such as call setup state, conversation state. Actions can be 164 packet or flow permit, drop, forward to Communication Security 165 Controller or updating and applying Communication Security 166 Profile. 168 3. Communication Security Function applies the rules which are sent 169 in forms of data model from the Security Controller. After 170 applying the rules, it monitors the flows and packets. If the 171 underlay network is SDN-enabled network, it requests the SDN 172 controller to apply the security rules with APIs. The SDN 173 switches monitor requested events and when the events match the 174 rule, they drop, permit, mirror or forward to the SDN controller. 176 4. When Communication Security Function detects the flows or packets 177 that meet the Conditions, it performs Actions that Communication 178 Security Controller defines with data model. In case of Caller ID 179 spoofing prevention, Communication Security Function mirrors the 180 packets to Communication Security Controller and Communication 181 Security Controller determine whether they are manipulated or not 182 with the combination of IP address of the call, Caller-ID, and 183 URIs of the call. 185 5. If Communication Security Controller determines that the 186 forwarded packets must be dropped, it updates the policy rule or 187 Communication Security Profile to drop the packet and send the 188 update rules to Communication Security Function. 190 Internet-Draft Use Cases for the Communication Security November 191 2016 193 6. Communication Security Function updates the rule of data model 194 and performs the Actions that Communication Security Controller 195 defines. In case of Caller ID spoofing, Communication Security 196 Function tears down the call. 198 3.3. Use Case of prevention of VoIP/VoLTE device scanning 200 The procedure of detection and prevention of VoIP/VoLTE device 201 scanning to find vulnerable to hacking is as follows: 203 1. Communications Security Manager(I2NSF Client) sends rules to 204 Communication Security Controller to block packets or flows that 205 try to scan the VoIP/VoLTE devices that are vulnerable to hacking 206 for fraud call. In this case, those rules can be prevention of 207 the scanning of customer's communication devices. 209 2. Communication Security Controller creates and sends the data 210 model that includes the Events, Conditions and Actions. In this 211 use case Events can be originating call by user action and 212 Conditions can be statistics of accumulated call attempt counts 213 from each source IP address or each originating phone number, 214 signal message type such as INVITE, OPTIONS, REGISTER in SIP. 215 Actions can be packet or flow permit, drop, forward to 216 Communication Security Controller or updating and applying 217 Communication Security Profile. 219 3. Communication Security Function applies the rules which are sent 220 in forms of data model from the Security Controller. After 221 applying the rules, it monitors the flows and packets. To monitor 222 the statistics of the packet or call attempt count, Communication 223 Security Function needs the Statistics Processor. Statistics 224 Processor counts packets and calls from each source IP address or 225 originating number within specific duration such as per minute, 226 hour or day. 228 4. When Communication Security Function detects the flows or packets 229 that meet the Conditions, it performs Actions that Communication 230 Security Controller defines with data model. In case of device 231 scanning prevention, Communication Security Function manages the 232 statistics. When a statistics matches the threshold value, 233 Communication Security Function forwards the packets to 234 Communication Security Controller and Communication Security 235 Controller determine whether they are packets for the device 236 scanning or not with the statistics of the accumulated packet or 237 call count within specific time duration. 239 Internet-Draft Use Cases for the Communication Security November 240 2016 242 5. If Communication Security Controller determines that the 243 forwarded packets are for device scanning, it updates the policy 244 rule or Communication Security Profile to drop the packets and 245 send the update rules to Communication Security Function. 247 6. Communication Security Function updates the rule of data model 248 and performs the Actions that Communication Security Controller 249 defines. In case of device scanning, Communication Security 250 Function drops the packets. 252 3.4. Use Case of prevention of spam messages 254 The procedure of detection and prevention of spam messages such as 255 SMS, MMS is as follows: 257 1. Communications Security Manager(I2NSF Client) sends rules to 258 Communication Security Controller to block packets or flows that 259 sends spam messages. In this case, those rules can be blocking of 260 the messages that exceed the threshold message sending count or 261 contain the banned terms. 263 2. Communication Security Controller creates and sends the data 264 model that includes the Events, Conditions and Actions. In this 265 use case Events can be sending message by user action and 266 Conditions can be statistics of accumulated message sending 267 counts from each source IP address or each originating phone 268 number and terms in the message within specified range of the 269 message packet. Actions can be packet or flow permit, drop, 270 forward to Communication Security Controller or updating and 271 applying Communication Security Profile and Signature file. 273 3. Communication Security Function applies the rules which are sent 274 in forms of data model from the Security Controller. After 275 applying the rules, it monitors the flows and packets. To monitor 276 the message sending statistics, Communication Security Function 277 needs the Statistics Processor. Statistics Processor counts 278 message sending counts from each source IP address or originating 279 number within specific duration such as per minute, hour or day. 280 Also Communication Security Function checks the message content 281 whether it contains the banned terms within specified range of 282 the message packet. 284 Internet-Draft Use Cases for the Communication Security November 285 2016 287 4. When Communication Security Function detects the flows or packets 288 that meet the Conditions, it performs Actions that Communication 289 Security Controller defines with data model. In case of device 290 spam message prevention, Communication Security Function manages 291 the statistics. When a statistics matches the threshold value, 292 Communication Security Function forwards the packets to 293 Communication Security Controller. Communication Security 294 Controller determines whether they are packets for the spam or 295 not with the statistics. 297 5. If Communication Security Controller determines that the 298 forwarded packets are for spam, it updates the policy rule or 299 Communication Security Profile to drop the packets and send the 300 update rules to Communication Security Function. 302 6. Communication Security Function updates the rule of data model 303 and performs the Actions that Communication Security Controller 304 defines. In case of spam prevention, Communication Security 305 Function drops the packets and updates the Signature file adding 306 the new banned terms. 308 4. Security Considerations 310 TBD 312 5. IANA Considerations 314 No IANA considerations exist for this document. 316 6. Conclusions 318 This document provides use cases for the IP-based communications 319 security using Interface to Network Security Functions (I2NSF). The 320 use cases in this document cover the detection and prevention of the 321 illegal authentication, call of VoIP/VoLTE and spam message. 323 7. References 325 7.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 Internet-Draft Use Cases for the Communication Security November 331 2016 333 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 334 Syntax Specifications: ABNF", RFC 2234, Internet Mail 335 Consortium and Demon Internet Ltd., November 1997. 337 7.2. Informative References 339 [I-D. hares-i2nsf-problem-and-use-cases] 341 Hares, S., Zhang, D., Moskowitz, R., and H. Rafiee, 342 " I2NSF Problem Statement and Use cases", draft-ietf- 343 i2nsf-problem-and-use-cases-02 , October 2016. 345 [I-D.jeong-i2nsf-sdn-security-services] 347 Jeong, J., Kim, H., and P. Jung-Soo, "Requirements for 348 Security Services based on Software-Defined Networking", 349 draft-jeong-i2nsf-sdn-security-services-01 (work in 350 progress), March 2015. 352 8. Acknowledgments 354 This document was prepared using 2-Word-v2.0.template.dot. 356 Authors' Addresses 358 Taejin Ahn 359 KT 360 KT Infra R&D Lab 361 Korea 363 Phone: +82 10 6750 6828 364 Email: taejin.ahn@kt.com 366 Internet-Draft Use Cases for the Communication Security November 367 2016 369 Sehui Lee 370 KT 371 KT Infra R&D Lab 372 Korea 374 Phone: +82 10 5114 7988 375 Email: sehuilee@kt.com 377 Kyoungyoul Kim 378 KT 379 KT Infra R&D Lab 380 Korea 382 Phone: +82 10 3485 6342 383 Email: kyoungyoul.kim@kt.com 385 Utae Kim 386 KT 387 KT Infra R&D Lab 388 Korea 390 Phone: +82 10 9893 7474 391 Email: utae.kim@kt.com