I2NSF T. Ahn Internet Draft S. Lee Intended status: Informational K. Kim Expires: April 30, 2017 U. Kim KT October 31, 2016 Use Cases for the Communications Security using Interface to Network Security Functions draft-ahn-i2nsf-communications-security-use-case-01.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 1,2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Expires April 1, 2017 [Page 1] Internet-Draft Use Cases for the Communication Security November 2016 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. Abstract This document provides use cases for the IP-based communications security using Interface to Network Security Functions (I2NSF). The use cases in this document cover the detection and prevention of the illegal authentication, call of VoIP/VoLTE and spam message. Table of Contents 1. Introduction ................................................ 2 2. Conventions used in this document ............................ 2 3. Use Cases ................................................... 3 3.1. Framework of the I2NSF communication security ........... 3 3.2. Use Case of Voice Call Security ......................... 4 3.3. Use Case of prevention of VoIP/VoLTE device scanning ..... 5 3.4. Use Case of prevention of spam messages ................. 6 4. Security Considerations ...................................... 7 5. IANA Considerations ......................................... 7 6. Conclusions ................................................. 7 7. References .................................................. 7 7.1. Normative References .................................... 7 7.2. Informative References .................................. 8 8. Acknowledgments ............................................. 8 1. Introduction As VoLTE is a crucial service for telecommunication operators, it becomes more important to provide secure voice and messaging communication services. VoLTE and VoIP are based on IP, attacks such as compromising the telephony application or re-routing the IP signal can be happened. This document describes IP-based communications security use cases for Interface to Network Security Functions (I2NSF) such as VoIP, VoLTE and messaging service. 2. Conventions used in this document VoLTE: Voice over LTE SND: Software defined Network Ahn, et al. Expires April 1, 2017 [Page 2] Internet-Draft Use Cases for the Communication Security November 2016 NSF: Network Security Function I2NSF: Interface to Network Security Functions 3. Use Cases 3.1. Framework of the I2NSF communication security +-----------------------------------------------------+ | I2NSF Client | | (Communications Security Service Manager) | | | +----------+------------------------------------------+ | | Client Facing Interface | +----------+----------+ +-------------+ | Communications | | Developer's | | Security Controller | | Mgnt System | +---------------+-----+ <---------> +-------------+ | Registration Interface | | NSF Facing Interface | +----------+------------------+------------------+ | | | | | | +---+--------------+ +---------+--------+ +----+------------+ | VoIP | | VoLTE | | Messaging | | Security Function| | Security Function| |Security Function| +------------------+ +------------------+ +-----------------+ | | | +-------------------------+----------------------+ | +---------------------+-------------------+ | | +-------+----------+ +--------+--------+ | SDN-Enabled | | Non-SDN | | Network | | Network | +------------------+ +-----------------+ Figure 1 I2NSF Framework for Communications Security Ahn, et al. Expires April 1, 2017 [Page 3] Internet-Draft Use Cases for the Communication Security November 2016 3.2. Use Case of Voice Call Security The procedure of VoIP/VoLTE voice call security operations is as follows: 1. Communications Security Manager(I2NSF Client) sends rules to Communication Security Controller to block packets or flows that match conditions that operators configure. In voice call security, those rules can be prevention of the Caller ID spoofing or DDoS attack. 2. Communication Security Controller creates and sends the data model that the Communication Security Function can understand. The data model includes the Events, Conditions and Actions. In this use case Events can be originating call by user action and Conditions can be IP address and port of origination and termination device, User-Agent of device, media information of device such as SDP(Session Description Protocol) and call state such as call setup state, conversation state. Actions can be packet or flow permit, drop, forward to Communication Security Controller or updating and applying Communication Security Profile. 3. Communication Security Function applies the rules which are sent in forms of data model from the Security Controller. After applying the rules, it monitors the flows and packets. If the underlay network is SDN-enabled network, it requests the SDN controller to apply the security rules with APIs. The SDN switches monitor requested events and when the events match the rule, they drop, permit, mirror or forward to the SDN controller. 4. When Communication Security Function detects the flows or packets that meet the Conditions, it performs Actions that Communication Security Controller defines with data model. In case of Caller ID spoofing prevention, Communication Security Function mirrors the packets to Communication Security Controller and Communication Security Controller determine whether they are manipulated or not with the combination of IP address of the call, Caller-ID, and URIs of the call. 5. If Communication Security Controller determines that the forwarded packets must be dropped, it updates the policy rule or Communication Security Profile to drop the packet and send the update rules to Communication Security Function. Ahn, et al. Expires April 1, 2017 [Page 4] Internet-Draft Use Cases for the Communication Security November 2016 6. Communication Security Function updates the rule of data model and performs the Actions that Communication Security Controller defines. In case of Caller ID spoofing, Communication Security Function tears down the call. 3.3. Use Case of prevention of VoIP/VoLTE device scanning The procedure of detection and prevention of VoIP/VoLTE device scanning to find vulnerable to hacking is as follows: 1. Communications Security Manager(I2NSF Client) sends rules to Communication Security Controller to block packets or flows that try to scan the VoIP/VoLTE devices that are vulnerable to hacking for fraud call. In this case, those rules can be prevention of the scanning of customer's communication devices. 2. Communication Security Controller creates and sends the data model that includes the Events, Conditions and Actions. In this use case Events can be originating call by user action and Conditions can be statistics of accumulated call attempt counts from each source IP address or each originating phone number, signal message type such as INVITE, OPTIONS, REGISTER in SIP. Actions can be packet or flow permit, drop, forward to Communication Security Controller or updating and applying Communication Security Profile. 3. Communication Security Function applies the rules which are sent in forms of data model from the Security Controller. After applying the rules, it monitors the flows and packets. To monitor the statistics of the packet or call attempt count, Communication Security Function needs the Statistics Processor. Statistics Processor counts packets and calls from each source IP address or originating number within specific duration such as per minute, hour or day. 4. When Communication Security Function detects the flows or packets that meet the Conditions, it performs Actions that Communication Security Controller defines with data model. In case of device scanning prevention, Communication Security Function manages the statistics. When a statistics matches the threshold value, Communication Security Function forwards the packets to Communication Security Controller and Communication Security Controller determine whether they are packets for the device scanning or not with the statistics of the accumulated packet or call count within specific time duration. Ahn, et al. Expires April 1, 2017 [Page 5] Internet-Draft Use Cases for the Communication Security November 2016 5. If Communication Security Controller determines that the forwarded packets are for device scanning, it updates the policy rule or Communication Security Profile to drop the packets and send the update rules to Communication Security Function. 6. Communication Security Function updates the rule of data model and performs the Actions that Communication Security Controller defines. In case of device scanning, Communication Security Function drops the packets. 3.4. Use Case of prevention of spam messages The procedure of detection and prevention of spam messages such as SMS, MMS is as follows: 1. Communications Security Manager(I2NSF Client) sends rules to Communication Security Controller to block packets or flows that sends spam messages. In this case, those rules can be blocking of the messages that exceed the threshold message sending count or contain the banned terms. 2. Communication Security Controller creates and sends the data model that includes the Events, Conditions and Actions. In this use case Events can be sending message by user action and Conditions can be statistics of accumulated message sending counts from each source IP address or each originating phone number and terms in the message within specified range of the message packet. Actions can be packet or flow permit, drop, forward to Communication Security Controller or updating and applying Communication Security Profile and Signature file. 3. Communication Security Function applies the rules which are sent in forms of data model from the Security Controller. After applying the rules, it monitors the flows and packets. To monitor the message sending statistics, Communication Security Function needs the Statistics Processor. Statistics Processor counts message sending counts from each source IP address or originating number within specific duration such as per minute, hour or day. Also Communication Security Function checks the message content whether it contains the banned terms within specified range of the message packet. Ahn, et al. Expires April 1, 2017 [Page 6] Internet-Draft Use Cases for the Communication Security November 2016 4. When Communication Security Function detects the flows or packets that meet the Conditions, it performs Actions that Communication Security Controller defines with data model. In case of device spam message prevention, Communication Security Function manages the statistics. When a statistics matches the threshold value, Communication Security Function forwards the packets to Communication Security Controller. Communication Security Controller determines whether they are packets for the spam or not with the statistics. 5. If Communication Security Controller determines that the forwarded packets are for spam, it updates the policy rule or Communication Security Profile to drop the packets and send the update rules to Communication Security Function. 6. Communication Security Function updates the rule of data model and performs the Actions that Communication Security Controller defines. In case of spam prevention, Communication Security Function drops the packets and updates the Signature file adding the new banned terms. 4. Security Considerations TBD 5. IANA Considerations No IANA considerations exist for this document. 6. Conclusions This document provides use cases for the IP-based communications security using Interface to Network Security Functions (I2NSF). The use cases in this document cover the detection and prevention of the illegal authentication, call of VoIP/VoLTE and spam message. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ahn, et al. Expires April 1, 2017 [Page 7] Internet-Draft Use Cases for the Communication Security November 2016 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 7.2. Informative References [I-D. hares-i2nsf-problem-and-use-cases] Hares, S., Zhang, D., Moskowitz, R., and H. Rafiee, " I2NSF Problem Statement and Use cases", draft-ietf- i2nsf-problem-and-use-cases-02 , October 2016. [I-D.jeong-i2nsf-sdn-security-services] Jeong, J., Kim, H., and P. Jung-Soo, "Requirements for Security Services based on Software-Defined Networking", draft-jeong-i2nsf-sdn-security-services-01 (work in progress), March 2015. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Taejin Ahn KT KT Infra R&D Lab Korea Phone: +82 10 6750 6828 Email: taejin.ahn@kt.com Ahn, et al. Expires April 1, 2017 [Page 8] Internet-Draft Use Cases for the Communication Security November 2016 Sehui Lee KT KT Infra R&D Lab Korea Phone: +82 10 5114 7988 Email: sehuilee@kt.com Kyoungyoul Kim KT KT Infra R&D Lab Korea Phone: +82 10 3485 6342 Email: kyoungyoul.kim@kt.com Utae Kim KT KT Infra R&D Lab Korea Phone: +82 10 9893 7474 Email: utae.kim@kt.com Ahn, et al. Expires April 1, 2017 [Page 9]