Internet DRAFT - draft-ahn-i2nsf-communications-security-use-case
draft-ahn-i2nsf-communications-security-use-case
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
<Ahn, et al> 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]
