[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                             H. Kim
Internet-Draft                                                     H. Ko
Intended status: Standards Track                                   S. Oh
Expires: May 4, 2017                                            J. Jeong
                                                 Sungkyunkwan University
                                                                  S. Lee
                                                           Korea Telecom
                                                        October 31, 2016


       An Architecture for Security Management in I2NSF Framework
          draft-kim-i2nsf-security-management-architecture-03

Abstract

   This document describes an architecture for security management in
   Interface to Network Security Functions (I2NSF) framework.  This
   security management architecture consists of I2NSF User, Security
   Management System (i.e., Security Controller and Developer's
   Management System), and Network Security Functions (NSFs) in the
   I2NSF framework.  I2NSF User consists of Application Logic, Policy
   Updater, and Event Collector.  Security Controller consists of
   Security Policy Manager and NSF Capability Manager.  This document
   explains their missions and the processing of security management in
   a high level.  It also describes representative use cases, such as
   security management for the list of malware domains, security
   management for VoIP-VoLTE and time-dependent access control.

Status of This Memo

   This Internet-Draft is submitted to IETF 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.



Kim, et al.                Expires May 4, 2017                  [Page 1]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   This Internet-Draft will expire on May 4, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Objectives . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Architecture of Security Management  . . . . . . . . . . . . .  4
     5.1.  Security Policy Manager  . . . . . . . . . . . . . . . . .  5
     5.2.  NSF Capability Manager . . . . . . . . . . . . . . . . . .  6
     5.3.  Developer's Management System  . . . . . . . . . . . . . .  6
     5.4.  Application Logic  . . . . . . . . . . . . . . . . . . . .  6
     5.5.  Policy Updater . . . . . . . . . . . . . . . . . . . . . .  6
     5.6.  Event Collector  . . . . . . . . . . . . . . . . . . . . .  6
   6.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Security Management for the List of Malware Domains  . . .  7
     6.2.  Security Management for VoIP-VoLTE . . . . . . . . . . . .  8
     6.3.  Security Management for Time-Dependent Access Control  . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Changes from
                draft-kim-i2nsf-security-management-architecture-02 . 10










Kim, et al.                Expires May 4, 2017                  [Page 2]


Internet-Draft   I2NSF Security Management Architecture     October 2016


1.  Introduction

   To enforce a user's high-level security policy into the I2NSF
   framework [i2nsf-framework], I2NSF User delivers such a policy to
   Security Controller via Consumer-Facing Interface.  In this document,
   an architecture for security management is proposed for a given high-
   level policy in the I2NSF framework.  This architecture contains
   I2NSF User, Security Management System (i.e., Security Controller and
   Developer's Management System), and NSFs in the I2NSF framework.
   I2NSF User includes Application Logic, Policy Updater, and Event
   Collector.  Security Controller contains Security Policy Manager and
   NSF Capability Manager.

   Security Policy Manager and NSF Capability Manager in Security
   Controller are responsible for controlling the updated security
   policy which will be given by Policy Updater in I2NSF User via
   Consumer-Facing Interface.  If a new policy were created or existing
   policies needed to be updated, Policy Updater delivers them to
   Security Controller.  On the other hand, when an event occurs for NSF
   to change a low-level policy, NSF sends the event to Security
   Controller.  Security Controller then forwards it to Event Collector.
   Next, Event Collector sends it to Application Logic.  Application
   Logic then updates the current policies in accordance with the event.

   In this document, we propose a security management architecture that
   integrates additional components for security management into the
   I2NSF framework.  Our architecture is designed to support flexible
   and effective security policies.  Application Logic generates a high-
   level policy and Policy Updater sends it to Security Policy Manager
   via Consumer-Facing Interface.  Security Policy Manager maps the
   high-level policy into several low-level policies in Security
   Controller.  After mapping, the low-level policies are distributed to
   NSF(s) so that they can be enforced in them.

2.  Requirements Language

   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 RFC 2119 [RFC2119].

3.  Terminology

   This document uses the terminology described in [i2nsf-framework].
   In addition, the following terms are defined below:

   o  Application Logic: It is a component in the security management
      architecture which generates high-level security policies to block
      or mitigate security attacks.



Kim, et al.                Expires May 4, 2017                  [Page 3]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   o  Policy Updater: It is a component which forwards a high-level
      security policy to Security Controller.  The high-level policy is
      received from Application Logic.

   o  Security Policy Manager: It maps a high-level security policy
      received from Policy Updater into low-level security policies, and
      vice versa.

   o  NSF Capability Manager: It is a component which stores the NSF
      capability registered by Developer's Management System via
      Registration Interface and shares it with Security Policy Manger
      to generate the corresponding low-level security policies.

   o  Event Collector: It is a component which receives an event which
      should be reflected on updating (or generating) a high-level
      policy in Application Logic, from Security Controller.

4.  Objectives

   The two main objectives for security management architecture in this
   document are as follows.

   o  High-level security management: To propose the design of a generic
      security management architecture to support the enforcement of
      flexible and effective security policies in NSFs.

   o  Automatic update of security policies: To provide the reflection
      of an event which occurs for NSFs to change a low-level policy for
      new security attacks on the corresponding high-level security
      policies.

5.  Architecture of Security Management

   This section describes a security management architecture in I2NSF
   and focuses on Security Management System containing Security
   Controller and Developer's Management System.  It also explains some
   basic operations of Security Controller and describes the details of
   each component consisting the architecture.

   Figure 1 shows a security management architecture in the I2NSF
   framework.  The architecture is designed to support the enforcement
   of flexible and effective security policies.  Application Logic in
   I2NSF User generates a high-level policy in accordance with new
   security attacks, and Policy Updater in I2NSF User then sends the
   policy to Security Policy Manager in Security Controller.  Security
   Policy Manager maps the high-level policy into several low-level
   policies which are relevant to NSF capability registered into NSF
   Capability Manager.  After mapping, the low-level policies are



Kim, et al.                Expires May 4, 2017                  [Page 4]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   distributed to NSF(s) by Security Policy Manager through NSF-Facing
   Interface.  In the following sections, we explain the details of each
   component.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | I2NSF User                                                        |
   |                        +-+-+-+-+-+-+-+-+-+-+-+                    |
   |                     ---|  Application Logic  |<--                 |
   |                     |  +-+-+-+-+-+-+-+-+-+-+-+  |                 |
   |                     |                           |                 |
   |                     |                           |                 |
   |              +-+-+-+v+-+-+-+-+-+         +-+-+-+v+-+-+-+          |
   |              | Policy Updater  |         |  Event      |          |
   |              +-+-+-+-+-+-+-+-+-+         |  Collector  |          |
   |                          |               +-+-+-+^+-+-+-+          |
   |                          |                      |                 |
   |                          |                      |                 |
   |                          |    -------------------                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              |    | Consumer-Facing Interface
   +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Security Management System|    |                                   |
   |       +-+-+-+-+-+-+-+-+-+v+-+-+-+-+                               |
   |       |Security Controller        |                               |
   |       | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration                  |
   |       | |Security | |NSF        | |  Interface  +-+-+-+-+-+-+-+   |
   |       | |Policy   | |Capability | |<----------->| Developer's |   |
   |       | |Manager  | |Manager    | |             | Mgnt System |   |
   |       | +-+-+-+-+-+ +-+-+-+-+-+-+ |             +-+-+-+-+-+-+-+   |
   |       +-+-+-+-+-+-^-+-+-+-+-+-+-+-+                               |
   +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       | NSF-Facing Interface
                  +-+-+v+-+-+
                  |   NSF   |
                  +-+-+-+-+-+

            Figure 1: Security Management Architecture in I2NSF

5.1.  Security Policy Manager

   Security Policy Manager is a component which receives a high-level
   policy from Policy Updater via Consumer-Facing Interface, and maps
   the high-level policy into several low-level policies which are
   relevant to a given NSF capability from NSF Capability Manager.
   Additionally, Security Policy Manager delivers those policies to
   NSF(s) via NSF-Facing Interface.

   On the other hand, when an event that requires the low-level policies



Kim, et al.                Expires May 4, 2017                  [Page 5]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   to be changed happens in NSF, NSF sends the event to Security Policy
   Manager via NSF-Facing Interface.  Security Policy Manager then sends
   it to Event collector via Consumer-Facing Interface.

5.2.  NSF Capability Manager

   NSF Capability Manager is a component integrated into Security
   Controller.  It stores the NSF capability registered by Developer's
   Management System via Registration Interface and shares it with
   Security Policy Manager so that Security Policy Manager can generate
   low-level policies relevant to a given NSF capability.  Moreover,
   whenever a new NSF is registered, NSF Capability Manager requests
   Developer's Management System to register the NSF capability into the
   management table of NSF Capability Manager via Registration
   Interface.  On the other hand, when the existing NSF is deleted, NSF
   Capability Manager eliminates the NSF capability from its management
   table.

5.3.  Developer's Management System

   Developer's Management System is a component which registers a new
   NSF's capability to NSF Capability Manager via Registration
   Interface.  Moreover, in case there are some updates in the
   registered NSF, such updates will be delivered from Developer's
   Management System to NSF Capability Manager.

5.4.  Application Logic

   Application Logic is a component which generates a high-level
   security policy to block or mitigate security attacks, and sends the
   generated policies to Policy Updater.  However, this component is out
   of our standardization scope.  We explain its detailed operations in
   two use cases in Section 6.

5.5.  Policy Updater

   Policy Updater is a component which receives a high-level security
   policy generated by Application Logic and delivers it to Security
   Policy Manager via Consumer-Facing Interface.

5.6.  Event Collector

   Event Collector receives an event, which should be reflected on
   updating (or generating) a high-level policy in Application Logic,
   from Security Controller.  The procedure of receiving an event in NSF
   is necessary because a low-level security policy can be updated
   according to a specific event that occurred in an NSF.  After
   receiving the event, Event Collector forwards it to Application Logic



Kim, et al.                Expires May 4, 2017                  [Page 6]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   so that Application Logic can update (or generate) a high-level
   security policy based on the event received from Security Controller.

6.  Use Cases

   A generic architecture is designed to react to security attacks that
   can occur in a real world environment.  This section shows the
   procedure of the defense for security attacks in the I2NSF framework
   [i2nsf-framework] for a given list of security attacks in malware
   domains, VoIP/VoLTE security attacks, and time-dependent access
   control.

6.1.  Security Management for the List of Malware Domains

   Malware domain blacklisting maintains and publishes the blacklists of
   IP addresses of possible attacking hosts, servers, and networks that
   are suspicious of malicious activities.  Figure 2 shows a security
   management architecture for Malware Domain Blacklisting.

   Based on the malware domain blacklisting, the list of malware domains
   can be updated either manually or automatically by Malware Domain
   Manager in I2NSF User.  Malware Domain Manager also periodically
   generates a new high-level security policy to prevent the delivery of
   packets from/to those newly added malware domains and enforce the
   low-level security policies in NSF.  Additionally, Malware Domain
   Manager sends the new high-level security policy to Policy Updater,
   which forwards it to Security Controller.

   When NSF detects a new dangerous domain, the corresponding IP
   addresses are sent by an NSF to Security controller via NSF-Facing
   Interface.  Security Controller delivers the IP addresses to Event
   Collector, which in turn forwards the IP addresses to Dangerous
   Domain Manager.  Finally, Dangerous Domain Manager updates the
   Dangerous domain database.

















Kim, et al.                Expires May 4, 2017                  [Page 7]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | I2NSF User                                                        |
   |                        +-+-+-+-+-+-+-+-+-+-+-+-+                  |
   |                     ---|Malware Domain Manager |<--               |
   |                     |  +-+-+-+-+-+-+-+-+-+-+-+-+  |               |
   |                     |                             |               |
   |                     |                             |               |
   |              +-+-+-+v+-+-+-+-+-+         +-+-+-+-+v+-+-+          |
   |              | Policy Updater  |         |  Event      |          |
   |              +-+-+-+-+-+-+-+-+-+         |  Collector  |          |
   |                          |               +-+-+-+^+-+-+-+          |
   |                          |                      |                 |
   |                          |                      |                 |
   |                          |    -------------------                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              |    |Consumer-Facing Interface
   +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Security Management System|    |                                   |
   |       +-+-+-+-+-+-+-+-+-+v+-+-+-+-+                               |
   |       |Security Controller        |                               |
   |       | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration                  |
   |       | |Security | |NSF        | |  Interface  +-+-+-+-+-+-+-+   |
   |       | |Policy   | |Capability | |<----------->| Developer's |   |
   |       | |Manager  | |Manager    | |             | Mgnt System |   |
   |       | +-+-+-+-+-+ +-+-+-+-+-+-+ |             +-+-+-+-+-+-+-+   |
   |       +-+-+-+-+-+-^-+-+-+-+-+-+-+-+                               |
   +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |NSF-Facing Interface
                  +-+-+v+-+-+
                  |   NSF   |
                  +-+-+-+-+-+

                   Figure 2: Malware Domain Blacklisting

6.2.  Security Management for VoIP-VoLTE

   VoIP-VoLTE security management maintains and publishes the blacklists
   of IP addresses, source ports, expire time, user-agents, and Session
   Initiation Protocol (SIP) URIs of SIP device that are suspicious of
   illegal call and authentication.  In our generic security management
   architecture, VoIP-VoLTE Security Manager is plays the role of
   Application Logic for VoIP-VoLTE security services in Figure 1.

   Based on VoIP-VoLTE security management, the list of illegal devices
   information can be updated either manually or automatically by VoIP-
   VoLTE Security Manager as Application Logic.  Also, VoIP-VoLTE
   Security Manager periodically generates a new high-level security
   policy to prevent the delivery of packets from/to those newly added



Kim, et al.                Expires May 4, 2017                  [Page 8]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   VoIP-VoLTE attackers and enforce the low-level security policies in
   NSF.  It sends the new high-level security policy to Policy Updater,
   which forwards it to Security Controller.

   When the NSF detects an anomalous message or call delivered from a
   domain, the domain information such as an IP address, user-agents and
   expire time values is sent by an NSF to Security Controller via NSF-
   Facing Interface.  Security Controller delivers it to Event
   Collector.  Event Collector forwards the detected domain information
   to VoIP-VoLTE Security Manager, and then VoIP-VoLTE Security Manager
   updates the VoIP-VoLTE database.

6.3.  Security Management for Time-Dependent Access Control

   Time-dependent access control policies manage a user's access to
   particular websites during a certain period of time.  For example, in
   a company, a manager blocks employees' access to Youtube, which is a
   big distraction during working hours.

   Based on time-dependent access control, I2NSF User registers the list
   of blocked websites and blocking time at Application logic.
   Application logic stores the list into database and generates a high-
   level security policy (e.g., blocking the access to websites by
   checking the blocked websites and blocking time in the list).
   Application logic delivers it to Policy updater, and then Policy
   updater forwards it to Security controller.  In Security controller,
   Security policy manager maps the high-level policy to low-level
   policies, and then it sends the corresponding NSFs to enforce the
   low-level policies.

7.  Security Considerations

   The security management architecture is derived from the I2NSF
   framework [i2nsf-framework], so the security considerations of the
   I2NSF framework should be included in this document.  Especially,
   proper secure communication channels should be used for the delivery
   of control or management messages amongst the components in the
   proposed architecture.

8.  Acknowledgements

   This work was supported by Institute for Information & communications
   Technology Promotion(IITP) grant funded by the Korea government(MSIP)
   (No.R-20160222-002755, Cloud based Security Intelligence Technology
   Development for the Customized Security Service Provisioning).  This
   document has greatly benefited from inputs by Mahdi Daghmehchi-
   Firoozjaei, Eunsoo Kim, Soyoung Kim, and Tae-Jin Ahn.




Kim, et al.                Expires May 4, 2017                  [Page 9]


Internet-Draft   I2NSF Security Management Architecture     October 2016


9.  References

9.1.  Normative References

   [RFC2119]          Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

9.2.  Informative References

   [i2nsf-framework]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J.,
                      and R. Kumar, "Framework for Interface to Network
                      Security Functions", draft-ietf-i2nsf-framework-04
                      (work in progress), October 2016.

Appendix A.  Changes from
             draft-kim-i2nsf-security-management-architecture-02

   The following changes were made from
   draft-kim-i2nsf-security-management-architecture-02:

   o  This version reflects the framework for I2NSF in
      draft-ietf-i2nsf-framework-04 with the updated terminology.

Authors' Addresses

   Hyoungshick Kim
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4324
   Fax:   +82 31 290 7996
   EMail: hyoung@skku.edu
   URI:   http://seclab.skku.edu/people/hyoungshick-kim/














Kim, et al.                Expires May 4, 2017                 [Page 10]


Internet-Draft   I2NSF Security Management Architecture     October 2016


   Hoon Ko
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82-31-299-4104
   EMail: skoh21@skku.edu


   Sanghak Oh
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82-31-299-4104
   EMail: osh09@skku.edu


   Jaehoon Paul Jeong
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


   Se-Hui Lee
   Korea Telecom
   70 Yuseong-Ro, Yuseong-Gu
   Daejeon  305-811
   Republic of Korea

   Phone: +82 42 870 8162
   EMail: sehuilee@kt.com








Kim, et al.                Expires May 4, 2017                 [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/