--- 1/draft-ietf-i2nsf-consumer-facing-interface-dm-02.txt 2019-03-11 04:14:09.777828508 -0700 +++ 2/draft-ietf-i2nsf-consumer-facing-interface-dm-03.txt 2019-03-11 04:14:09.865830622 -0700 @@ -1,108 +1,182 @@ I2NSF Working Group J. Jeong Internet-Draft E. Kim Intended status: Standards Track Sungkyunkwan University -Expires: May 8, 2019 T. Ahn +Expires: September 12, 2019 T. Ahn Korea Telecom R. Kumar Juniper Networks S. Hares Huawei - November 4, 2018 + March 11, 2019 I2NSF Consumer-Facing Interface YANG Data Model - draft-ietf-i2nsf-consumer-facing-interface-dm-02 + draft-ietf-i2nsf-consumer-facing-interface-dm-03 Abstract - This document describes a YANG data model for the Consumer-Facing - Interface between an Interface to Network Security Functions (I2NSF) - User and Security Controller in an I2NSF system in a Network - Functions Virtualization (NFV) environment. The data model is - required for enabling different users of a given I2NSF system to - define, manage, and monitor security policies for specific flows - within an administrative domain. + This document describes an information model and a YANG data model + for the Consumer-Facing Interface between an Interface to Network + Security Functions (I2NSF) User and Security Controller in an I2NSF + system in a Network Functions Virtualization (NFV) environment. The + information model defines various managed objects and relationship + among these objects needed to build the interface. The information + model is organized based on the "Event-condition-Event" (ECA) policy + model defined by a capability information model for Interface to + Network Security Functions (I2NSF)[draft-ietf-i2nsf-capability], and + the data model is defined for enabling different users of a given + I2NSF system to define, manage, and monitor security policies for + specific flows within an administrative domain. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on May 8, 2019. + This Internet-Draft will expire on September 12, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Data Modeling for Security Policies for Consumer-Facing - Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1. YANG Data Model for Security Policies for Consumer-Facing - Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Use Case: Policy Instance Example for VoIP/VoLTE Security - Services . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 5.1. Policy Instance YANG Example for VoIP/VoLTE Security - Services . . . . . . . . . . . . . . . . . . . . . . . . 35 - 6. Example XML Output for Various Use Cases . . . . . . . . . . 45 - 6.1. Case 1: VoIP Security Service . . . . . . . . . . . . . . 45 - 6.2. Case 2: DDoS-Attack Mitigation . . . . . . . . . . . . . 47 - 6.3. Case 3: Time-Based Firewall . . . . . . . . . . . . . . . 48 - 6.4. Case 4: Time-Based Web-Filter . . . . . . . . . . . . . . 49 - 6.5. Case 5: Threat-Feed Configuration . . . . . . . . . . . . 50 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 51 - 8.2. Informative References . . . . . . . . . . . . . . . . . 52 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Information Model for Policy . . . . . . . . . . . . . . . . 5 + 4.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 7 + 4.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 9 + 5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 9 + 5.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 10 + 5.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.5. Policy Management Authentication Method . . . . . . . . . 13 + 6. Information Model for Policy Endpoint Groups . . . . . . . . 14 + 6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.2. Device-Group . . . . . . . . . . . . . . . . . . . . . . 16 + 6.3. Location-Group . . . . . . . . . . . . . . . . . . . . . 16 + 7. Information Model for Threat Prevention . . . . . . . . . . . 17 + 7.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.2. Payload-content . . . . . . . . . . . . . . . . . . . . . 19 + 8. Role-Based Acess Control (RBAC) . . . . . . . . . . . . . . . 19 + 9. YANG Data Model for Security Policies for Consumer-Facing + Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Example XML Output for Various Scenarios . . . . . . . . . . 37 + 10.1. DB registration: Information of positions and devices + (Endpoint group) . . . . . . . . . . . . . . . . . . . . 38 + 10.2. Scenario 1: Block SNS access during business hours . . . 38 + 10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to + the company . . . . . . . . . . . . . . . . . . . . . . 40 + 10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a + company web Server . . . . . . . . . . . . . . . . . . . 41 + + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 + 13.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- - interface-dm-01 . . . . . . . . . . . . . . . . . . 53 - Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 53 - Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 53 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 + interface-dm-02 . . . . . . . . . . . . . . . . . . 46 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 46 + Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction - This document provides a YANG [RFC6020] data model that defines the - required data for the Consumer-Facing Interface between an Interface - to Network Security Functions (I2NSF) User and Security Controller in - an I2NSF system [i2nsf-framework] in a Network Functions - Virtualization (NFV) environment. The data model is required for - enabling different users of a given I2NSF system to define, manage - and monitor security policies for specific flows within an - administrative domain. This document defines a YANG data model based - on the information model of I2NSF Consumer-Facing Interface - [client-facing-inf-im]. + In I2NSF framework, each vendor can register their NSFs using the + Vendor Management System (VMS). Assuming that vendors also provide + the front-end web applications registered with the I2NSF provider, + the Consumer-Facing Interface is required because the web + applications developed by each vendor need to have a standard + interface specifying the data types used when I2NSF user and security + controller communicate using this interface. Therefore, this + document specifies the required information, their data types, and + encoding schemes so that any data (security policy) transferred + through the Consumer-Facing Interface can easily be translated by the + security controller into low-level security policies. The translated + policies are delivered to Network Security Functions (NSFs) according + to their respective security capabilities for securiy enforcement. + + The Consumer-Facing Interface would be built using a set of objects, + with each object capturing a unique set of information from Security + Admin (i.e., I2NSF User [RFC8329]) needed to express a Security + Policy. An object may have relationship with various other objects + to express a complete set of requirement. An information model + captures the managed objects and relationship among these objects. + The information model proposed in this document is structured in + accordance with the "Event-Condition-Event" (ECA) policy model. + + An NSF Capability model is proposed in [draft-ietf-i2nsf-capability] + as the basic model for both the NSF-Facing interface and Consumer- + Facing Interface security policy model of this document. + + [RFC3444] explains differences between an information and data model. + This document use the guidelines in [RFC3444] to define both the + information and data model for Consumer-Facing Interface. Figure 1 + shows a high-level abstraction of Consumer-Facing Interface. A data + model, which represents an implementation of the information model in + a specific data representation language, is also defined in the later + sections of this document (see section 10). + + +-----------------+ +-----------------+ + | Consumer-facing | | Consumer-facing | + | Interface +--->+ Interface | + |Information Model| | Data Model | + +--------+--------+ +-----------------+ + ^ + | + +-------------+-------------+------------+ + | | | | + +----+----+ +-----+----+ +-----+----+ +----+----+ + | Multi | | Policy | | Endpoint | | Threat | + | Tenancy | | | | groups | | feed | + +---------+ +-----+----+ +----------+ +---------+ + ^ + | + +------+------+ + | Rule | + +------+------+ + ^ + | + +----------------+----------------+ + | | | + +------+------+ +------+------+ +------+------+ + | Event | | Condition | | Action | + +-------------+ +-------------+ +-------------+ + + Figure 1: Diagram for High-level Abstraction of Consumer-Facing + Interface Data models are defined at a lower level of abstraction and provide many details. They provide details about the implementation of a protocol's specification, e.g., rules that explain how to map managed objects onto lower-level protocol constructs. Since conceptual models can be implemented in different ways, multiple data models can be derived by a single information model. The efficient and flexible provisioning of network functions by NFV leads to a rapid advance in the network industry. As practical @@ -112,2410 +186,1984 @@ functions (VNF) in the NFV system. By the efficient virtual technology, these VNFs might be automatically provisioned and dynamically migrated based on real-time security requirements. This document presents a YANG data model to implement security functions based on NFV. 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 [RFC3444]. + document are to be interpreted as described in RFC 2119 [RFC3444] + RFC8174 [RFC8174]. 3. Terminology This document uses the terminology described in [i2nsf-terminology][client-facing-inf-im][client-facing-inf-req]. -4. Data Modeling for Security Policies for Consumer-Facing Interface + This document follows the guidelines of [RFC6087], uses the common + YANG types defined in [RFC6991], and adopts the Network Management + Datastore Architecture (NMDA). The meaning of the symbols in tree + diagrams is defined in [RFC8340]. + +4. Information Model for Policy + + A Policy object represents a mechanism to express a Security Policy + by Security Admin (i.e., I2NSF User) using Consumer-Facing Interface + toward Security Controller; the policy would be enforced on an NSF. + Figure 2 shows the XML instance of the Policy object. The Policy + object SHALL have following information: + + Name: This field identifies the name of this object. + + Date: Date when this object was created or last modified. + + Rules: This field contains a list of rules. If the rule does not + have a user-defined precedence, then any conflict must be + manually resolved. + + +--rw policy + +--rw policy-name? string + +--rw rule* [rule-name] + +--rw event + +--rw condition + +--rw action + + Figure 2: Policy YANG Data tree + + A policy is a container of Rules. In order to express a Rule, a Rule + must have complete information such as where and when a policy needs + to be applied. This is done by defining a set of managed objects and + relationship among them. A Policy Rule may be related segmentation, + threat mitigation or telemetry data collection from an NSF in the + network, which will be specified as the sub-model of the policy model + in the subsequent sections. Figure 3 shows the XML instance of the + Rule object. The rule object SHALL have the following information: + + Name: This field identifies the name of this object. + + Date: This field indicates the date when this object was created + or last modified. + + Event: This field includes the information to determine whether + the Rule Condition can be evaluated or not. See details in + Section 3.1. + + Condition: This field contains all the checking conditions to + apply to the objective traffic. See details in + Section 4.2. + + Action: This field identifies the action taken when a rule is + matched. There is always an implicit action to drop + traffic if no rule is matched for a traffic type. See + details in Section 4.3. + + Owner: This field contains the onwer of the rule. For example, + the person who created it, and eligible for modifying it. + + +--rw rule* [rule-name] + +--rw rule-name string + +--rw date? yang:date-and-time + +--rw event* [name] + +--rw condition + +--rw action + +--rw owner? string + + Figure 3: YANG Data tree for Rule + +4.1. Event Sub-Model + + The Event Object contains information related to scheduling a Rule. + The Rule could be activated based on a time calendar or security + event including threat level changes. Figure 4 shows the XML + instance of the Event object. Event object SHALL have following + information: + + Name: This field identifies the name of this object. + + Date: This field indicates the date when this object was created + or last modified. + + Event-Type: This field identifies whether the event of triggering + policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or + "EVENT-ENFORCED". + + Time-Information: This field contains a time calendar such as + "BEGIN-TIME" and "END-TIME" for one time enforcement or + recurring time calendar for periodic enforcement. + + +--rw event + +--rw name? string + +--rw date? yang:date-and-time + +--rw event-type enumeration + +--rw time-information + +--rw time + | +--rw begin-time begin-time-type + | +--rw end-time end-time-type + +--rw recursive + +--rw recur boolean + +--rw recursive-type? enumeration + + Figure 4: Event sub-model YANG data tree + +4.2. Condition Sub-Model + + This object represents Conditions that Security Admin wants to apply + the checking on the traffic in order to determine whether the set of + actions in the Rule can be executed or not. The condition sub-model + consists of 3 different types of three containers each representing + different cases, such as general firewall and ddos-mitigation cases, + and a case when the condition is based on the payload strings of + packets. Each containers have source-target and destination-target + to represent the source and destination for each case. Figure 5 + shows the XML instance of the Condition object.The Condition submodel + SHALL have following information: + + Firewall-condition: This field represents the general firewall + case, where a security admin can set up firewall conditions + using the information present in this field. The source + and destination is represented as source-target and + destination-target, each referring to the IP-address-based + groups defined in the endpoint-group. + + DDoS-condition: This field represents the condition for DDoS + mitigation, where a security admin can set up DDoS + mitigation conditions using the information present in this + field. The source and destination is represented as + source-target and destination-target, each referring to the + device-groups defined and registered in the endpoint-group. + + Custom-condition: This field contains the payload string + information. This information is useful when security rule + condition is based on the string contents of incoming or + outgoing packets. The source and destination is + represented as source-target and destination-target, each + referring to the payload-groups defined and registered in + the endpoint-group. + + +--rw condition + +--rw firewall-condition + | +--rw source-target + | | +--rw src-target? -> /policy + | | /endpoint-group + | | /user-group + | | /name + | +--rw destination-target + | | +--rw dest-target* -> /policy + | | /endpoint-group + | | /user-group + | | /name + +--rw ddos-condition + | +--rw source-target + | | +--rw src-target* -> /policy + | | /endpoint-group + | | /device-group + | | /name + | +--rw destination-target + | | +--rw dest-target* -> /policy + | | /endpoint-group + | | /device-group + | | /name + | +--rw rate-limit + | +--rw packet-per-second? uint8 + +--rw custom-condition + | +--rw source-target + | | +--rw src-target* -> /policy + | | /threat-prevention + | | /payload-content + | | /name + | +--rw destination-target + | | +--rw dest-target? -> /policy + | | /threat-prevention + | | /payload-content + | | /name + +--rw threat-feed-condition + +--rw source-target + | +--rw src-target* -> /policy + | /threat-prevention + | /threat-feed-list + | /name + +--rw destination-target + +--rw dest-target? -> /policy + /threat-prevention + /threat-feed-list + /name + + Figure 5: Condition sub-model YANG data tree + +4.3. Action Sub-Model + + This object represents actions that Security Admin wants to perform + based on certain traffic class. Figure 6 shows the XML instance of + the Action object. The Action object SHALL have following + information: + + Name: This field identifies the name of this object. + + Date: This field indicates the date when this object was created + or last modified. + + Action: This field identifies the action when a rule is matched + by an NSF. The action could be one of "PASS", "DROP", + "ALERT", "MIRROR", and "LOG". + + +--rw action + +--rw name string + +--rw date yang:date-and-time + +--rw action string + + Figure 6: Action sub-model YANG data tree + +5. Information Model for Multi-Tenancy + + Multi-tenancy is an important aspect of any application that enables + multiple administrative domains in order to manage application + resources. An Enterprise organization may have multiple tenants or + departments such as Human Resources (HR), Finance, and Legal, with + each tenant having a need to manage their own Security Policies. In + a Service Provider, a tenant could represent a Customer that wants to + manage its own Security Policies. There are multiple managed objects + that constitute multi-tenancy aspects as shown in Figure 7. This + section lists these objects and any relationship among these objects. + Below diagram shows an example of multi-tenancy in an Enterprise + domain. + + +-------------------+ + (Multi-Tenancy) | Domain | + |(e.g., Enterprise) | + +---------+---------+ + ^ + | + +--------------------+--------------------+ + | | | + +--------+-------+ +---------+--------+ +--------+--------+ + | Department 1 | | Department 2 | | Department n | + +--------+-------+ +---------+--------+ +--------+--------+ + ^ ^ ^ + | | | + +--------+--------+ +-----------------+ +--------+--------+ + | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | + +--------+--------+ +--------+--------+ +--------+--------+ + ^ ^ ^ + | | | + +--------+--------+ +--------+--------+ +--------+--------+ + | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | + +-----------------+ +-----------------+ +-----------------+ + + Figure 7: Multi-tenancy Diagram + +5.1. Policy-Domain + + This object defines a boundary for the purpose of policy management + within a Security Controller. This may vary based on how the + Security Controller is deployed and hosted. For example, if an + Enterprise hosts a Security Controller in their network; the domain + in this case could just be the one that represents that Enterprise. + But if a Cloud Service Provider hosts managed services, then a domain + could represent a single customer of that Provider. Figure 8 shows + the XML instance of the Policy-domain object. Multi-tenancy model + should be able to work in all such environments. The Policy-Domain + object SHALL have following information: + + Name: Name of the organization or customer representing this + domain. + + Address: Address of the organization or customer. + + Contact: Contact information of the organization or customer. + + Date: Date when this account was created or last modified. + + Authentication-Method: Authentication method to be used for this + domain. It should be a reference to a "Policy-Management- + Authentication-Method" object. + + +--rw policy-domain* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw address? string + +--rw contact? string + +--rw policy-tenant* [name] + +--rw authentication-method? -> /policy + /multi-tenancy + /policy-mgnt-auth-method + /name + ... + ... + + Figure 8: Policy domain YANG data tree + +5.2. Policy-Tenant + + This object defines an entity within an organization. The entity + could be a department or business unit within an Enterprise + organization that would like to manage its own Policies due to + regulatory compliance or business reasons. Figure 9 shows the XML + instance of the Policy-tenant object. The Policy-Tenant object SHALL + have following information: + + Name: Name of the Department or Division within an organization. + + Date: Date when this account was created or last modified. + + Domain: This field identifies the domain to which this tenant + belongs. This should be a reference to a Policy-Domain + object. + + +--rw policy-tenant* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw domain? -> /policy + /multi-tenancy + /policy-domain + /name + + Figure 9: Policy tenant YANG data tree + +5.3. Policy-Role + + This object defines a set of permissions assigned to a user in an + organization that wants to manage its own Security Policies. It + provides a convenient way to assign policy users to a job function or + a set of permissions within the organization. Figure 10 shows the + XML instance of the Policy-role object. The Policy-Role object SHALL + have the following information: + + Name: This field identifies the name of the role. + + Date: Date when this role was created or last modified. + + Access-Profile: This field identifies the access profile for the + role. The profile grants or denies the permissions to + access Endpoint Groups for the purpose of policy management + or may restrict certain operations related to policy + managements. There are two permission types, read-only and + read-and-write, to choose from for each access-profile. + + +--rw policy-role + | +--rw name? string + | +--rw date? yang:date-and-time + | +--rw access-profile* [name] + | +--rw name string + | +--rw date? yang:date-and-time + | +--rw permission-type? identityref + + Figure 10: Policy role YANG data tree + +5.4. Policy-User + + This object represents a unique identity of a user within an + organization. The identity authenticates with Security Controller + using credentials such as a password or token in order to perform + policy management. A user may be an individual, system, or + application requiring access to Security Controller. Figure 11 shows + the XML instance of the Policy-user object. The Policy-User object + SHALL have the following information: + + Name: Name of a user. + + Date: Date when this user was created or last modified. + + Password: User password for basic authentication. + + Email: E-mail address of the user. + + Scope-Type: This field identifies whether the user has domain- + wide or tenant-wide privileges. + + Role: This field should be a reference to a Policy-Role object + that defines the specific permissions. + + +--rw policy-user* [name] + | +--rw name string + | +--rw date? yang:date-and-time + | +--rw password? string + | +--rw email? string + | +--rw scope-type? identityref + | +--rw role? -> /policy + /multi-tenancy + /policy-role + /access-profile + /name + + Figure 11: Policy user YANG data tree + +5.5. Policy Management Authentication Method + + This object represents authentication schemes supported by Security + Controller. Figure 12 shows the XML instance of the Policy + Management Authentication Method onject. This Policy-Management- + Authentication-Method object SHALL have the following information: + + Name: This field identifies name of this object. + + Date: Date when this object was created or last modified. + + Authentication-Method: This field identifies the authentication + methods. It could be a password-based, token-based, + certificate-based or single sign-on authentication. + + Mutual-Authentication: This field indicates whether mutual + authentication is mandatory or not. + + Token-Server: This field stores the information about server that + validates the token submitted as credentials. + + Certificate-Server: This field stores the information about + server that validates certificates submitted as + credentials. + + Single Sign-on-Server: This field stores the information about + server that validates user credentials. + + +--rw policy-mgnt-auth-method* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw mutual-authentication? boolean + +--rw password + | +--rw password? password-type + +--rw token + | +--rw token? string + | +--rw token-server? inet:ipv4-address + +--rw certificate + | +--rw certificate? certificate-type + | +--rw certificate-server? inet:ipv4-address + +--rw single-sign-on + +--rw credential? certificate-type + +--rw certificate-server? inet:ipv4-address + + Figure 12: Policy management authentication method YANG data tree + +6. Information Model for Policy Endpoint Groups + + The Policy Endpoint Group is a very important part of building User- + construct based policies. Security Admin would create and use these + objects to represent a logical entity in their business environment, + where a Security Policy is to be applied. There are multiple managed + objects that constitute a Policy Endpoint Group as shown in + Figure 13. Figure 14 shows the XML instance of the endpoint-group + object. shows the XML instance of the User-group object.. This + section lists these objects and relationship among them. + + +-------------------+ + | Endpoint Group | + +---------+---------+ + ^ + | + +--------------+----------------+ + 1..n | 1..n | 1..n | + +-----+----+ +------+-----+ +-------+------+ + |User-group| |Device-group| |Location-group| + +----------+ +------------+ +--------------+ + + Figure 13: Endpoint Group Diagram + + +--rw endpoint-group + +--rw user-group* [name] + | ... + +--rw device-group* [name] + | ... + +--rw location-group* [name] + ... + + Figure 14: Endpoint Group YANG data tree + +6.1. User Group + + This object represents a User-group. Figure 15 shows the XML + instance of the User-group object.The User-Group object SHALL have + the following information: + + Name: This field identifies the name of this object. + + Date: Date when this object was created or last modified. + + IP-Address: This field identifies the IP address of a user. + + Range-IP-Address: This field is a range of IP addresses of users. + + +--rw user-group* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw (match-type)? + +--:(exact-match) + | +--rw ip-address* inet:ipv4-address + +--:(range-match) + +--rw range-ip-address* [start-ip-address end-ip-address] + +--rw start-ip-address inet:ipv4-address + +--rw end-ip-address inet:ip-address + + Figure 15: User group YANG data tree + +6.2. Device-Group + + This object represents a Device-group. Figure 16 shows the XML + instance of the Device-group object.The Device-Group object SHALL + have the following information: + + Name: This field identifies the name of this object. + + Date: Date when this object was created or last modified. + + IP-Address: This field identifies the IP address of a device. + + Range-IP-Address: This field is a range of IP addresses of + devices. + + +--rw device-group* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw (match-type)? + +--:(exact-match) + | +--rw ip-address* inet:ipv4-address + +--:(range-match) + +--rw range-ip-address* [start-ip-address end-ip-address] + +--rw start-ip-address inet:ipv4-address + +--rw end-ip-address inet:ip-address + + Figure 16: Device group YANG data tree + +6.3. Location-Group + + This object represents a location group based on either tag or other + information. Figure 17 shows the XML instance of the Location-group + object. The Location-group object SHALL have the following + information: + + Name: This field identifies the name of this object. + + Date: Date when this object was created or last modified. + + continent: to identify which continent the location group member + is based at. + + +--rw location-group* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw continent? identityref + + Figure 17: Location group YANG data tree + +7. Information Model for Threat Prevention + + The threat prevention plays an important part in the overall security + posture by reducing the attack surfaces. This information could come + from various threat feeds (i.e., sources for obtaining the threat + information), such as EmergingThreats.com or AlienVault.com. There + are multiple managed objects that constitute this category. This + section lists these objects and relationship among them. Figure 19 + shows the XML instance of a Threat-prevention object. + + +-------------------+ + | Threat Prevention | + +---------+---------+ + ^ + | + +---------+---------+ + 1..n | 1..n | + +------+------+ +--------+--------+ + | Threat-feed | | payload-content | + +-------------+ +-----------------+ + + Figure 18: Threat Prevention Diagram + + +--rw threat-prevention + | +--rw threat-feed-list* [name] + | ... + | +--rw payload-content* [name] + | ... + + Figure 19: Threat Prevention YANG data tree + +7.1. Threat-Feed + + This object represents a threat feed which provides signatures of + malicious activities. Figure 20 shows the XML instance of a Threat- + feed-list. The Threat-Feed object SHALL have the following + information: + + Name: This field identifies the name of this object. + + Date: Date when this object was created or last modified. + + Threat-feed-Server: This field identifies the information about + the feed provider, it may be an external service or local + server. + + Threat-file-types: This field identifies the information about + the file types identified and reported by the threat-feed. + + signatures: This field contains the signatures of malicious + programs or activities provided by the threat-feed. + + +--rw threat-feed-list* [name] + +--rw name string + +--rw date? yang:date-and-time + +--rw threat-feed-server + | +--rw (match-type)? + | | +--:(exact-match) + | | | +--rw ip-address* inet:ipv4-address + | | +--:(range-match) + | | +--rw range-ip-address* [start-ip-address end-ip-address] + | | +--rw start-ip-address inet:ipv4-address + | | +--rw end-ip-address inet:ip-address + | +--rw threat-feed-description? string + +--rw threat-file-types* identityref + +--rw signatures* string + + Figure 20: Threat feed YANG data tree + +7.2. Payload-content + + This object represents a custom list created for the purpose of + defining exception to threat feeds. Figure 21 shows the XML instance + of a Payload-content list. The Payload-content object SHALL have the + following information: + + Name: This field identifies the name of this object. + + Date: Date when this object was created or last modified. + + List-Content: This field contains contents such as IP addresses + or URL names. + + +--rw payload-content* [name] + | +--rw name string + | +--rw date? yang:date-and-time + | +--rw content* string + + Figure 21: Payload-content in YANG data tree + +8. Role-Based Acess Control (RBAC) + + Role-Based Access Control (RBAC) provides a powerful and centralized + control within a network. It is a policy neutral access control + mechanism defined around roles and privileges. The components of + RBAC, such as role-permissions, user-role and role-role + relationships, make it simple to perform user assignments. + + +--------------+ + | | + | User 1 + (has many) + | |\ + +--------------+ \ +---------------+ +-------------+ + . \ | | (has many) | | + . --->+ List of roles +----------->+ Permissions | + +--------------+ / | | | | + | | / +---------------+ +-------------+ + | User n +/ + | | (has many) + +--------------+ + + Figure 22: RBAC Diagram + + As shown in Figure 22, a role represents a collection of permissions + (e.g., accessing a file server or other particular resources). A + role may be assigned to one or multiple users. Both roles and + permissions can be organized in a hirarchy. A role may consists of + other roles and permissions. + + Following are the steps required to build RBAC: + + 1. Defining roles and permissions. + + 2. Establishing relations among roles and permissions. + + 3. Defining users. + + 4. Associating rules with roles and permissions. + + 5. assigning roles to users. + +9. YANG Data Model for Security Policies for Consumer-Facing Interface The main objective of this data model is to fully transform the information model [client-facing-inf-im] into a YANG data model that can be used for delivering control and management messages via the Consumer-Facing Interface between an I2NSF User and Security Controller for the I2NSF User's high-level security policies. The semantics of the data model must be aligned with the information model of the Consumer-Facing Interface. The transformation of the information model was performed so that this YANG data model can facilitate the efficient delivery of the control or management messages. This data model is designed to support the I2NSF framework that can be extended according to the security needs. In other words, the model design is independent of the content and meaning of specific policies as well as the implementation approach. This document suggests a VoIP/VoLTE security service as a use case for policy rule generation. - Multi-tenancy in this document enables multiple administrative - domains in order to manage application resources. An Enterprise - organization may have multiple tenants or departments such as human - resources (HR), finance, and legal departments. Thus, we need an - object which defines a set of permissions assigned to a user in an - organization that wants to manage its own Security Policies. You can - think of it as a way to assign policy users to a job function or a - set of permissions within the organization. The policy-role object - SHALL have Name, Date and access-profile to grant or deny permissions - for the perpose of security policy management. - -module: policy-general - +--rw policy - | +--rw rule* [rule-id] - | +--rw rule-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw case? string - | +--rw event* [event-id] - | | +--rw event-id string - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw event-type? string - | | +--rw time-information? string - | | +--rw event-map-group? -> /threat-feed/event-map-group - | | /event-map-group-id - | | +--rw enable? boolean - | +--rw condition* [condition-id] - | | +--rw condition-id string - | | +--rw source? string - | | +--rw destination? string - | | +--rw match? boolean - | | +--rw match-direction? string - | | +--rw exception? string - | +--rw policy-action* [policy-action-id] - | +--rw policy-action-id string - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw primary-action? string - | +--rw secondary-action? string - | +--rw owner? string - +--rw multi-tenancy - | +--rw policy-domain* [policy-domain-id] - | | +--rw policy-domain-id uint16 - | | +--rw name string - | | +--rw address? string - | | +--rw contact string - | | +--rw date yang:date-and-time - | | +--rw policy-tenant* [policy-tenant-id] - | | | +--rw policy-tenant-id uint16 - | | | +--rw name string - | | | +--rw date yang:date-and-time - | | | +--rw domain? -> /multi-tenancy - | | | /policy-domain - | | | /policy-domain-id - | | +--rw authentication-method? -> /multi-tenancy - | | /policy-mgnt-auth-method - | | /policy-mgnt-auth-method-id - | +--rw policy-role* [policy-role-id] - | | +--rw policy-role-id uint16 - | | +--rw name string - | | +--rw date yang:date-and-time - | | +--rw access-profile string - | +--rw policy-user* [policy-user-id] - | | +--rw policy-user-id uint16 - | | +--rw name string - | | +--rw date yang:date-and-time - | | +--rw password string - | | +--rw email string - | | +--rw scope-type? string - | | +--rw scope-reference? string - | | +--rw role string - | +--rw policy-mgnt-auth-method* [policy-mgnt-auth-method-id] - | +--rw policy-mgnt-auth-method-id uint16 - | +--rw name string - | +--rw date yang:date-and-time - | +--rw authentication-method enumeration - | +--rw mutual-authentication boolean - | +--rw token-server inet:ipv4-address - | +--rw certificate-server inet:ipv4-address - | +--rw single-sing-on-server inet:ipv4-address - +--rw endpoint-group - | +--rw meta-data-source* [meta-data-source-id] - | | +--rw meta-data-source-id uint16 - | | +--rw name string - | | +--rw date yang:date-and-time - | | +--rw tag-type? boolean - | | +--rw tag-server-information? inet:ipv4-address - | | +--rw tag-application-protocol? string - | | +--rw tag-server-credential? string - | +--rw user-group* [user-group-id] - | | +--rw user-group-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw group-type? enumeration - | | +--rw meta-data-server? inet:ipv4-address - | | +--rw group-member? string - | | +--rw risk-level? uint16 - | +--rw device-group* [device-group-id] - | | +--rw device-group-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw group-type? enumeration - | | +--rw meta-data-server? inet:ipv4-address - | | +--rw group-member? string - | | +--rw risk-level? uint16 - | +--rw application-group* [application-group-id] - | | +--rw application-group-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw group-type? enumeration - | | +--rw meta-data-server? inet:ipv4-address - | | +--rw group-member? string - | | +--rw risk-level? uint16 - | +--rw location-group* [location-group-id] - | +--rw location-group-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw group-type? enumeration - | +--rw meta-data-server? inet:ipv4-address - | +--rw group-member? string - | +--rw risk-level? uint16 - +--rw threat-feed - | +--rw threat-feed* [threat-feed-id] - | | +--rw threat-feed-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw feed-type enumeration - | | +--rw feed-server? inet:ipv4-address - | | +--rw feed-priority? uint16 - | +--rw custom-list* [custom-list-id] - | | +--rw custom-list-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw list-type enumeration - | | +--rw list-property enumeration - | | +--rw list-content? string - | +--rw malware-scan-group* [malware-scan-group-id] - | | +--rw malware-scan-group-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw signature-server? inet:ipv4-address - | | +--rw file-types? string - | | +--rw malware-signatures? string - | +--rw event-map-group* [event-map-group-id] - | +--rw event-map-group-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw security-events? string - | +--rw threat-map? string - +--rw telemetry-data - +--rw telemetry-data* [telemetry-data-id] - | +--rw telemetry-data-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw logs? boolean - | +--rw syslogs? boolean - | +--rw snmp? boolean - | +--rw sflow? boolean - | +--rw netflow? boolean - | +--rw interface-stats? boolean - +--rw telemetry-source* [telemetry-source-id] - | +--rw telemetry-source-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw source-type? enumeration - | +--rw nsf-source? inet:ipv4-address - | +--rw nsf-credentials? string - | +--rw collection-interval? uint16 - | +--rw collection-method? enumeration - | +--rw heartbeat-interval? uint16 - | +--rw qos-marking? uint16 - +--rw telemetry-destination* [telemetry-destination-id] - +--rw telemetry-destination-id uint16 - +--rw name? string - +--rw date? yang:date-and-time - +--rw collector-source? inet:ipv4-address - +--rw collector-credentials? string - +--rw data-encoding? string - +--rw data-transport? enumeration - - Figure 1: Generic Data Model for Security Policies for cf Interface - -4.1. YANG Data Model for Security Policies for Consumer-Facing - Interface - This section describes a YANG data model for Consumer-Facing Interface, based on the information model of Consumer-Facing Interface to security controller [client-facing-inf-im]. - file "policy-general.yang" -module ietf-policy-general { + file "ietf-cfi-policy.yang" +module ietf-i2nsf-cfi-policy { + yang-version 1.1; namespace - "urn:ietf:params:xml:ns:yang:ietf-policy-general"; + "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; prefix - cf-interface; + cfi-policy; import ietf-yang-types{ prefix yang; + reference + "Section 3 of RFC 6991"; } import ietf-inet-types{ prefix inet; + reference + "Section 4 of RFC 6991"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: WG Chair: Adrian Farrel WG Chair: Linda Dunbar Editor: Jaehoon Paul Jeong "; description - "This module defines a YANG data module for consumer-facing - interface to security controller."; + "This module is a YANG module for Consumer-Facing Interface. + Copyright (c) 2018 IETF Trust and the persons identified as + authors of the code. All rights reserved. + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Simplified BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (http://trustee.ietf.org/license-info). + This version of this YANG module is part of RFC XXXX; see + the RFC itself for full legal notices."; - revision "2018-11-04"{ - description "fourth revision"; + revision "2019-03-11"{ + description "latest revision"; reference - "draft-kumar-i2nsf-client-facing-interface-im-04"; - } - //Groupings - container policy { - description - "This object is a policy instance to have - complete information such as where and when - a policy need to be applied."; - - list rule { - key "rule-id"; - leaf rule-id { - type uint16; - description - "This is ID for rules."; - } - description - "This is a container for rules."; - leaf name { - type string; - description - "This field idenfifies the name of this object."; - } - leaf date { - type yang:date-and-time; - description - "Date this object was created or last - modified"; + "draft-ietf-consumer-facing-interface-dm-02"; } - leaf case { - type string; + identity permission-type { description - "to identify whether the rule belongs to - web filter or enterprise mode."; + "Base identity for the permission types."; } - list event { - key "event-id"; - description - "This represents the security event of a - policy-rule."; - leaf event-id { - type string; - mandatory true; - description - "This represents the event-id."; - } - leaf name { - type string; - description - "This field idenfifies the name of this object."; - } - leaf date { - type yang:date-and-time; + identity read-only { + base permission-type; description - "Date this object was created or last - modified"; + "Identity for read-only permission."; } - leaf event-type { - type string; + identity read-and-write { + base permission-type; description - "This field identifies the event of - policy enforcement trigger type."; + "Identity for read permission."; } - leaf time-information { - type string; + + identity scope-type { description - "This field contains time calendar such as - BEGIN-TIME and END-TIME for one time - enforcement or recurring time calendar for - periodic enforcement."; - } - leaf event-map-group { - type leafref { - path "/threat-feed/event-map-group/event-map-group-id"; + "Base Identity for scope-type."; } + identity tenant-wide { + base scope-type; description - "This field contains security events or threat - map in order to determine when a policy need - to be activated. This is a reference to - Evnet-Map-Group."; + "Base Identity for tenant-wide scope type."; } - leaf enable { - type boolean; + identity domain-wide { + base scope-type; description - "This determines whether the condition - matches the security event or not."; - } + "Base Identity for domain-wide scope type."; } - list condition { - key "condition-id"; - description - "This represents the condition of a - policy-rule."; - leaf condition-id { - type string; + identity malware-file-type { description - "This represents the condition-id."; + "Base identity for malware file types."; } - leaf source { - type string; + identity executable-file { + base malware-file-type; description - "This field identifies the source of - the traffic. This could be reference to - either 'Policy Endpoint Group' or - 'Threat-Feed' or 'Custom-List' if Security - Admin wants to specify the source; otherwise, - the default is to match all traffic."; + "Identity for executable file types."; } - leaf destination { - type string; + identity doc-file { + base malware-file-type; description - "This field identifies the source of - the traffic. This could be reference to - either 'Policy Endpoint Group' or - 'Threat-Feed' or 'Custom-List' if Security - Admin wants to specify the source; otherwise, - the default is to match all traffic."; + "Identity for Microsoft document file types."; } - leaf match { - type boolean; + identity html-app-file { + base malware-file-type; description - "This field identifies the match criteria used to - evaluate whether the specified action need to be - taken or not. This could be either a Policy- - Endpoint-Group identifying a Application set or a - set of traffic rules."; + "Identity for html application file types."; } - leaf match-direction { - type string; + identity javascript-file { + base malware-file-type; description - "This field identifies if the match criteria is - to evaluated for both direction of the traffic or - only in one direction with default of allowing in - the other direction for stateful match conditions. - This is optional and by default rule should apply - in both directions."; + "Identity for Javascript file types."; } - leaf exception { - type string; + identity pdf-file { + base malware-file-type; description - "This field identifies the exception - consideration when a rule is evaluated for a - given communication. This could be reference to - Policy-Endpoint-Group object or set of traffic - matching criteria."; - } + "Identity for pdf file types."; } - list policy-action { - key "policy-action-id"; - leaf policy-action-id { - type string; - mandatory true; + identity dll-file { + base malware-file-type; description - "this represents the policy-action-id."; + "Identity for dll file types."; } + identity msi-file { + base malware-file-type; description - "This object represents actions that a - Security Admin wants to perform based on - a certain traffic class."; + "Identity for Microsoft installer file types."; + } - leaf name { - type string; + identity security-event-type { description - "The name of the policy-action object."; + "Base identity for security event types."; } - leaf date { - type yang:date-and-time; + identity ddos { + base malware-file-type; description - "When the object was created or last - modified."; + "Identity for DDoS event types."; } - leaf primary-action { - type string; + identity spyware { + base malware-file-type; description - "This field identifies the action when a rule - is matched by NSF. The action could be one of - 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', - 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; + "Identity for spyware event types."; } - leaf secondary-action { - type string; + identity trojan { + base malware-file-type; description - "This field identifies additional actions if - a rule is matched. This could be one of 'LOG', - 'SYSLOG', 'SESSION-LOG', etc."; + "Identity for Trojan infection event types."; } - leaf owner { - type string; + identity ransomeware { + base malware-file-type; description - "This field defines the owner of this - policy. Only the owner is authorized to - modify the contents of the policy."; - - } - } - } + "Identity for ransomeware infection event types."; } - container multi-tenancy { + identity continent { description - "The descriptions of multi-tenancy."; - - list policy-domain { - key "policy-domain-id"; + "Base Identity for continent types."; + } - leaf policy-domain-id { - type uint16; + identity africa { + base continent; description - "This represents the list of domains."; + "Identity for africa."; } + identity asia { + base continent; description - "this represent the list of policy domains"; - leaf name { - type string; - mandatory true; - description - "Name of the organization or customer representing - this domain."; + "Identity for asia."; } - leaf address { - type string; + identity europe { + base continent; description - "address of an organization or customer."; + "Identity for europe."; } - leaf contact { - type string; - mandatory true; + identity north-america { + base continent; description - "contact information of the organization - or customer."; + "Identity for north-america."; } - leaf date { - type yang:date-and-time; - mandatory true; + identity south-america { + base continent; description - "The date when this account was created - or last modified."; + "Identity for south-america."; } - list policy-tenant { - key "policy-tenant-id"; - leaf policy-tenant-id { - type uint16; + identity oceania { + base continent; description - "The policy tenant id."; + "Identity for Oceania"; } - description - "This represents the list of tenants"; + typedef certificate-type { - leaf name { - type string; - mandatory true; + type enumeration { + enum cer { description - "Name of the Department or Division within - an organization."; + "The extension type is '.cer'."; } - leaf date { - type yang:date-and-time; - mandatory true; + enum crt { description - "Date this account was created or last modified."; - } - leaf domain { - type leafref { - path "/multi-tenancy/policy-domain/policy-domain-id"; + "The extension type is '.crt'."; } + enum key { description - "This field identifies the domain to which this - tenant belongs. This should be reference to a - 'Policy-Domain' object."; - } + "The extension type is '.key'."; } - leaf authentication-method { - type leafref { - path "/multi-tenancy/policy-mgnt-auth-method/policy-mgnt-auth-method-id"; } description - "Authentication method to be used for this domain. - It should be a reference to a 'policy-mgmt-auth-method' - object."; - } + "CRT certificate extension, which is used for certificates. + The certificates may be encoded as binary DER or as ASCII PEM. + The CER and CRT extensions are nearly synonymous. Most common + among *nix systems. CER certificate extension, which is an + alternate form of .crt (Microsoft Convention) You can use MS to + convert .crt to .cer (.both DER encoded .cer, or base64[PEM] + encoded .cer). The KEY extension is used both for public and + private PKCS#8 keys. The keys may be encoded as binary DER or + as ASCII PEM."; } - list policy-role { - key "policy-role-id"; - leaf policy-role-id { - type uint16; - mandatory true; - description - "This defines a set of permissions assigned - to a user in an organization that want to manage - its own Security Policies."; - } +grouping meta { description - "This represents the list of policy roles."; - + "The purpose of this grouping is to avoid repetition of same fields, such as 'name' and 'date'."; leaf name { type string; - mandatory true; - description - "This field identifies name of the role."; + description "This is the name for an entity."; } leaf date { type yang:date-and-time; - mandatory true; - description - "Date this role was created or last modified."; - } - leaf access-profile { - type string; - mandatory true; - description - "This field identifies the access profile for the - role. The profile grants or denies access to policy - objects. Multiple access profiles can be - concatenated together."; + description "This is the date when the entity is created or modified."; } } - list policy-user { - key "policy-user-id"; - leaf policy-user-id { - type uint16; +grouping ip-address { description - "This represents the policy-user-id."; - } + "There are two types to configure a security policy + for IPv4 address, such as exact match and range match."; + choice match-type { description - "This represents the list of policy users."; - leaf name { - type string; - mandatory true; + "User can choose between 'exact match' and 'range match'."; + case exact-match { + leaf-list ip-address { + type inet:ipv4-address; description - "The name of a user."; + "Exactly matches the IP address specified."; } - leaf date { - type yang:date-and-time; - mandatory true; - description - "Date this user was created or last modified"; - } - leaf password { - type string; - mandatory true; + case range-match { + list range-ip-address { + key "start-ip-address end-ip-address"; + leaf start-ip-address { + type inet:ipv4-address; description - "User password for basic authentication"; + "Start IP address for a range match."; } - leaf email { - type string; - mandatory true; + leaf end-ip-address { + type inet:ip-address; description - "The email account of a user"; + "End IP address for a range match."; } - leaf scope-type { - type string; description - "identifies whether a user has domain-wide - or tenant-wide privileges"; + "Range match for an IP-address."; } - leaf scope-reference { - type string; - description - "This references policy-domain or policy-tenant - to identify the scope."; } - leaf role { - type string; - mandatory true; - description - "This references policy-role to define specific - permissions"; } } - list policy-mgnt-auth-method { - key "policy-mgnt-auth-method-id"; - leaf policy-mgnt-auth-method-id { - type uint16; +grouping user-group { description - "This represents the authentication method id."; + "This grouping is to remove repetition of + 'name' and 'ip-address' fields."; + uses meta; + uses ip-address; } + +grouping device-group { description - "The descriptions of policy management - authentication methods."; - leaf name { + "This grouping is to remove repetition of + 'name', 'ip-address', and 'protocol' fields."; + uses meta; + uses ip-address; + leaf-list protocol { type string; - mandatory true; description - "name of the authentication method"; - } - leaf date { - type yang:date-and-time; - mandatory true; - description - "date when the authentication method - was created"; - } - leaf authentication-method { - type enumeration{ - enum password{ - description - "password-based authentication."; - } - enum token{ - description - "token-based authentication."; - } - enum certificate{ - description - "certificate-based authentication."; - } - } - mandatory true; - description - "The description of authentication method; - token-based, password, certificate, - single-sign-on"; + "This represents the port numbers of devices."; } - leaf mutual-authentication { - type boolean; - mandatory true; - description - "To identify whether the authentication - is mutual"; } - leaf token-server { - type inet:ipv4-address; - mandatory true; - description - "The token-server information if the - authentication method is token-based"; - } - leaf certificate-server { - type inet:ipv4-address; - mandatory true; + +grouping location-group { description - "The certificate-server information if - the authentication method is certificate-based"; + "This grouping is to remove repetition of + 'name' and 'continent' fields."; + uses meta; + leaf continent { + type identityref { + base continent; } - leaf single-sing-on-server { - type inet:ipv4-address; - mandatory true; description - "The single-sign-on-server information - if the authentication method is - single-sign-on-based"; - } - } + "location-group-based on geo-ip of + respective continent."; } -container endpoint-group { - description - "A logical entity in their business - environment, where a security policy - is to be applied."; - list meta-data-source { - key "meta-data-source-id"; - leaf meta-data-source-id { - type uint16; - mandatory true; - description - "This represents the meta-data source id."; } - description - "This represents the meta-data source."; - leaf name { - type string; - mandatory true; - description - "This identifies the name of the - meta-datas-ource."; - } - leaf date { - type yang:date-and-time; - mandatory true; - description - "This identifies the date this object was - created or last modified."; - } - leaf tag-type { - type boolean; - description - "This identifies the group type; user group, - app group or device group."; - } - leaf tag-server-information { - type inet:ipv4-address; - description - "The description of suthentication method; - token-based, password, certificate, - single-sign-on"; - } - leaf tag-application-protocol { - type string; +grouping payload-string { description - "This filed identifies the protocol e.g. LDAP, - Active Directory, or CMDB"; - } - leaf tag-server-credential { + "This grouping is to remove repetition of + 'name' and 'content' fields."; + uses meta; + leaf-list content { type string; description - "This field identifies the credential - information needed to access the tag server"; + "This represents the payload string content."; } } - list user-group{ - key "user-group-id"; - leaf user-group-id { - type uint16; - mandatory true; - description - "This represents the the user group id."; - } - description - "This represents the user group."; - - leaf name { +container policy { + leaf policy-name { type string; description - "This field identifies the name of user-group."; - } - leaf date { - type yang:date-and-time; - description - "when this user-group was created or last modified."; - } - leaf group-type { - type enumeration{ - enum user-tag{ - description - "The user group is based on user-tag."; - } - enum user-name{ - description - "The user group is based on user-name."; - } - enum ip-address{ - description - "The user group is based on ip-address."; - } - } - description - "This describes the group type; User-tag, - User-name or IP-address."; + "The name which identifies the policy."; } - leaf meta-data-server { - type inet:ipv4-address; description - "This references metadata source"; - } + "There can be a multiple number of security rules in + a policy object. This object is a policy instance to + have complete information such as where and when a + policy need to be applied."; - leaf group-member { + list rule { + leaf rule-name { type string; + mandatory true; description - "This describes the user-tag information"; - } - - leaf risk-level { - type uint16; - description - "This represents the threat level; valid range - may be 0 to 9."; - } - } - list device-group { - key "device-group-id"; - leaf device-group-id { - type uint16; - description - "This represents a device group id."; + "This represents the name for rules."; } + key "rule-name"; description - "This represents a device group."; - leaf name { - type string; - description - "This field identifies the name of - a device-group."; + "There can be a single or multiple number of rules."; - } leaf date { type yang:date-and-time; description - "The date when this group was create or - last modified."; - } - leaf group-type { - type enumeration{ - enum device-tag{ - description - "The device group is based on device-tag."; - } - enum device-name{ - description - "The device group is based on device-name."; - } - enum ip-address{ - description - "The device group is based on ip-address."; - } - } - description - "This describes the group type; device-tag, - device-name or IP-address."; - } - leaf meta-data-server { - type inet:ipv4-address; - description - "This references meta-data-source - object."; - } - leaf group-member { - type string; - description - "This describes the device-tag, device-name or - IP-address information"; - } - leaf risk-level { - type uint16; - description - "This represents the threat level; valid range - may be 0 to 9."; - } + "Date this object was created or last + modified"; } - list application-group{ - key "application-group-id"; - leaf application-group-id { - type uint16; + list event { + uses meta; + key "name"; description - "This represents an application group id."; + "This represents the event map group name."; + + leaf security-event { + type identityref { + base security-event-type; } description - "This represents an application group."; - leaf name { - type string; - description - "This field identifies the name of - an application group"; - } - leaf date { - type yang:date-and-time; - description - "The date when this group was created or - last modified."; + "This contains the description of security events."; } - leaf group-type { + leaf enforce-type { type enumeration{ - enum application-tag{ + enum admin-enforced { description - "The application group is based on application-tag."; + "The enforcement type is admin-enforced."; } - enum device-name{ + enum time-enforced { description - "The application group is based on application-name."; + "The enforcement type is time-enforced."; } - enum ip-address{ + enum event-enforced { description - "The application group is based on ip-address."; + "The enforcement type is event-enforced."; } } description - "This identifies the group type; - application-tag, application-name or - IP-address."; + "This field identifies the event of + policy enforcement trigger type."; } - leaf meta-data-server { - type inet:ipv4-address; + container time-information { description - "This references meta-data-source - object."; - } - leaf group-member { + "The container for time-information."; + leaf begin-time { type string; description - "This describes the application-tag, - application-name or IP-address information"; + "This is start time for time zone"; } - leaf risk-level { - type uint16; + leaf end-time { + type string; description - "This represents the threat level; valid range - may be 0 to 9."; + "This is end time for time zone"; } } - list location-group{ - key "location-group-id"; - leaf location-group-id { - type uint16; + container recursive { description - "This represents a location group id."; - } + "The container to represent the recursiveness + of the rule."; + leaf recur { + type boolean; description - "This represents a location group."; + "recursive enforcement"; - leaf name { - type string; - description - "This field identifies the name of - a location group"; - } - leaf date { - type yang:date-and-time; - description - "The date when this group was created or - last modified."; } - leaf group-type { + leaf recursive-type{ type enumeration{ - enum location-tag{ - description - "The location group is based on location-tag."; - } - enum location-name{ - description - "The location group is based on location-name."; - } - enum ip-address{ + enum daily { description - "The location group is based on ip-address."; - } + "The recursive type is daily."; } + enum weekly { description - "This identifies the group type; - location-tag, location-name or - IP-address."; + "The recursive type is weekly."; } - leaf meta-data-server { - type inet:ipv4-address; + enum monthly { description - "This references meta-data-source - object."; + "The recursive type is monthly."; } - leaf group-member { - type string; - description - "This describes the location-tag, - location-name or IP-address information"; } - leaf risk-level { - type uint16; description - "This represents the threat level; valid range - may be 0 to 9."; + "This leaf identifies the recursive type."; } } } - container threat-feed { - description - "this describes the list of threat-feed."; - - list threat-feed { - key "threat-feed-id"; - leaf threat-feed-id { - type uint16; - mandatory true; + container condition { description - "This represents the threat-feed-id."; - } + "The conditions for general security policies."; + container firewall-condition { description - "This represents the threat feed within the - threat-prevention-list."; - leaf name { - type string; + "The general firewall condition."; + container source-target { description - "Name of the theat feed."; + "This represents the source."; + leaf src-target { + type leafref { + path "/policy/endpoint-group/user-group/name"; } - leaf date { - type yang:date-and-time; description - "when the threat-feed was created."; + "This describes the paths to + the source reference."; } - leaf feed-type { - type enumeration { - enum unknown { - description - "feed-type is unknown."; } - enum ip-address { + container destination-target { description - "feed-type is IP address."; + "This represents the destination."; + leaf-list dest-target { + type leafref { + path "/policy/endpoint-group/user-group/name"; } - enum url { description - "feed-type is URL."; - } + "This describes the paths to the + destination target reference."; } - mandatory true; - description - "This determined whether the feed-type is IP address - based or URL based."; } - leaf feed-server { - type inet:ipv4-address; - description - "this contains threat feed server information."; } - leaf feed-priority { - type uint16; + container ddos-condition { description - "this describes the priority of the threat from - 0 to 5, where 0 means the threat is minimum and - 5 meaning the maximum."; - } - } - list custom-list { - key "custom-list-id"; - leaf custom-list-id { - type uint16; + "The condition for DDoS mitigation."; + container source-target { description - "this describes the custom-list-id."; + "This represents the source."; + leaf-list src-target { + type leafref { + path "/policy/endpoint-group/device-group/name"; } description - "this describes the threat-prevention custom list."; - leaf name { - type string; - description - "Name of the custom-list."; + "This describes the path to the + source target references."; } - leaf date { - type yang:date-and-time; - description - "when the custom list was created."; } - leaf list-type { - type enumeration { - enum unknown { + container destination-target { description - "list-type is unknown."; + "This represents the target."; + leaf-list dest-target { + type leafref { + path "/policy/endpoint-group/device-group/name"; } - enum ip-address { description - "list-type is IP address."; + "This describes the path to the + destination target references."; } - enum mac-address { - description - "list-type is MAC address."; } - enum url { + container rate-limit { + description "This describes the rate-limit."; + leaf packet-per-second { + type uint8; description - "list-type is URL."; + "The rate-limit limits the amount of incoming packets."; } } - mandatory true; - description - "This determined whether the feed-type is IP address - based or URL based."; } - leaf list-property { - type enumeration { - enum unknown { + container custom-condition { description - "list-property is unknown."; - } - enum blacklist { + "The condition based on packet contents."; + container source-target { description - "list-property is blacklist."; + "This represents the source."; + leaf-list src-target { + type leafref { + path "/policy/threat-prevention/payload-content/name"; } - enum whitelist { description - "list-property is whitelist."; + "Describes the payload string + content condition source."; } } - mandatory true; + container destination-target { description - "This determined whether the list-type is blacklist - or whitelist."; + "This represents the destination."; + leaf dest-target { + type leafref { + path "/policy/threat-prevention/payload-content/name"; } - leaf list-content { - type string; description - "This describes the contents of the custom-list."; + "Describes the payload string + content condition destination."; } } - list malware-scan-group { - key "malware-scan-group-id"; - leaf malware-scan-group-id { - type uint16; - mandatory true; - description - "This is the malware-scan-group-id."; } + container threat-feed-condition { description - "This represents the malware-scan-group."; - leaf name { - type string; + "The condition based on the threat-feed information."; + container source-target { description - "Name of the malware-scan-group."; + "This represents the source."; + leaf-list src-target { + type leafref { + path "/policy/threat-prevention/threat-feed-list/name"; } - leaf date { - type yang:date-and-time; - description - "when the malware-scan-group was created."; + description "Describes the threat-feed + condition source."; } - leaf signature-server { - type inet:ipv4-address; - description - "This describes the signature server of the - malware-scan-group."; } - leaf file-types { - type string; + container destination-target { description - "This contains a list of file types needed to - be scanned for the virus."; + "This represents the destination."; + leaf dest-target { + type leafref { + path "/policy/threat-prevention/threat-feed-list/name"; } - leaf malware-signatures { - type string; - description - "This contains a list of malware signatures or hash."; + description "Describes the threat-feed + condition destination."; } } - list event-map-group { - key "event-map-group-id"; - leaf event-map-group-id { - type uint16; - mandatory true; - description - "This is the event-map-group-id."; } - description - "This represents the event map group."; - - leaf name { - type string; - description - "Name of the event-map."; } - leaf date { - type yang:date-and-time; - description - "when the event-map was created."; - } - leaf security-events { - type string; + container action { description - "This contains a list of security events."; - } - leaf threat-map { + "This is the action container."; + leaf primary-action { type string; - description - "This contains a list of threat levels."; - } - } - } - container telemetry-data { - description - "Telemetry provides visibility into the network - activities which can be tapped for further - security analytics, e.g., detecting potential - vulnerabilities, malicious activities, etc."; - - list telemetry-data { - key "telemetry-data-id"; - - leaf telemetry-data-id { - type uint16; mandatory true; description - "This is ID for telemetry-data-id."; + "This field identifies the action when a rule + is matched by NSF. The action could be one of + 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', + 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; } - description - "This is ID for telemetry-data."; - leaf name { + leaf secondary-action { type string; description - "Name of the telemetry-data object."; - } - leaf date { - type yang:date-and-time; - description - "This field states when the telemery-data - object was created."; - } - leaf logs { - type boolean; - description - "This field identifies whether logs - need to be collected."; - } - leaf syslogs { - type boolean; - description - "This field identifies whether System logs - need to be collected."; - } - leaf snmp { - type boolean; - description - "This field identifies whether 'SNMP traps' and - 'SNMP alarms' need to be collected."; - } - leaf sflow { - type boolean; - description - "This field identifies whether 'sFlow' data - need to be collected."; - } - leaf netflow { - type boolean; - description - "This field identifies whether 'NetFlow' data - need to be collected."; - } - leaf interface-stats { - type boolean; - description - "This field identifies whether 'Interface' data - such as packet bytes and counts need to be - collected."; - } + "This field identifies additional actions if + a rule is matched. This could be one of 'LOG', + 'SYSLOG', 'SESSION-LOG', etc."; } - list telemetry-source { - key "telemetry-source-id"; - leaf telemetry-source-id { - type uint16; - mandatory true; - description - "This is ID for telemetry-source-id."; } - description - "This is ID for telemetry-source."; - leaf name { + leaf owner { type string; description - "This identifies the name of this object."; - } - leaf date { - type yang:date-and-time; - description - "Date this object was created or last modified"; + "This field defines the owner of this + policy. Only the owner is authorized to + modify the contents of the policy."; } - leaf source-type { - type enumeration { - enum network-nsf { - description - "NSF telemetry source type is network-nsf."; } - enum firewall-nsf { - description - "NSF telemetry source type is firewall-nsf."; - } - enum ids-nsf { - description - "NSF telemetry source type is ids-nsf."; - } - enum ips-nsf { - description - "NSF telemetry source type is ips-nsf."; - } - enum proxy-nsf { - description - "NSF telemetry source type is proxy-nsf."; - } - enum other-nsf { - description - "NSF telemetry source type is other-nsf."; - } - } - description - "This should have one of the following type of - the NSF telemetry source: NETWORK-NSF, - FIREWALL-NSF, IDS-NSF, IPS-NSF, - PROXY-NSF, VPN-NSF, DNS, ACTIVE-DIRECTORY, - IP Reputation Authority, Web Reputation - Authority, Anti-Malware Sandbox, Honey Pot, - DHCP, Other Third Party, ENDPOINT"; - } - leaf nsf-source { - type inet:ipv4-address; - description - "This field contains information such as - IP address and protocol (UDP or TCP) port - number of the NSF providing telemetry data."; - } - leaf nsf-credentials { - type string; - description - "This field contains username and password - to authenticate with the NSF."; - } - leaf collection-interval { - type uint16; - units seconds; - default 5000; - description - "This field contains time in milliseconds - between each data collection. For example, - a value of 5000 means data is streamed to - collector every 5 seconds. Value of 0 means - data streaming is event-based"; - } - leaf collection-method { - type enumeration { - enum unknown { - description - "collection-method is unknown."; - } - enum push-based { - description - "collection-method is PUSH-based."; - } - enum pull-based { - description - "collection-method is PULL-based."; - } - } - description - "This field contains a method of collection, - i.e., whether it is PUSH-based or PULL-based."; - } - leaf heartbeat-interval { - type uint16; - units seconds; - description - "time in seconds the source sends telemetry - heartbeat."; - } - leaf qos-marking { - type uint16; +container multi-tenancy { description - "DSCP value must be contained in this field."; - } - } - list telemetry-destination { - key "telemetry-destination-id"; + "The multi-tenant environment information + in which the policy is applied. The Rules + in the Policy can refer to sub-objects + (e.g., domain, tenant, role, and user) of it."; - leaf telemetry-destination-id { - type uint16; - description - "this represents the telemetry-destination-id"; - } - description - "This object contains information related to - telemetry destination. The destination is - usually a collector which is either a part of - Security Controller or external system - such as Security Information and Event - Management (SIEM)."; - leaf name { + list policy-domain { + uses meta; + key "name"; + leaf address { type string; description - "This identifies the name of this object."; - } - leaf date { - type yang:date-and-time; - description - "Date this object was created or last - modified"; - } - leaf collector-source { - type inet:ipv4-address; - description - "This field contains information such as - IP address and protocol (UDP or TCP) port - number for the collector's destination."; + "The address details of the organization + or customer."; } - leaf collector-credentials { + leaf contact { type string; description - "This field contains the username and - password for the collector."; + "contact information of the organization + or customer."; } - leaf data-encoding { - type string; + list policy-tenant { + uses meta; + key "name"; description - "This field contains the telemetry data encoding - in the form of schema."; + "This represents the list of tenants"; + leaf domain { + type leafref { + path "/policy/multi-tenancy/policy-domain/name"; } - leaf data-transport { - type enumeration{ - enum grpc { description - "telemetry data protocol is grpc."; + "This field identifies the domain to which this + tenant belongs. This should be reference to a + 'Policy-Domain' object."; } - enum buffer-over-udp{ - description - "telemetry data protocol is buffer over UDP."; } + leaf authentication-method { + type leafref { + path "/policy/multi-tenancy/policy-mgnt-auth-method/name"; } description - "This field contains streaming telemetry data - protocols. This could be gRPC, protocol - buffer over UDP, etc."; - } - } - } - } - - - Figure 2: YANG for policy-general - -5. Use Case: Policy Instance Example for VoIP/VoLTE Security Services - - A common scenario for VoIP/VoLTE policy enforcement could be that a - malicious call is made to a benign user of any telecommunication - company. For example, imagine a case wherea company "A" employs a - hacker with a malicious attempt to hack a user's phone with malware. - The company "A" is located in a country, such as Africa, and uses the - user's hacked phone to call the company. The hacked user is unaware - of the company "A" so complains about the international call that was - made to the company "B", which is the user's telecommunications - company. The company "A" charges the company "B" for the - international call. The company "B" cannot charge the user for the - call, and has no choice but to pay the company "A". The following - shows the example data tree model for the VoIP/VoLTE services. - Multi-tenancy, endpoint groups, threat prevention, and telemetry data - components are general part of the tree model, so we can just modify - the policy instance in order to generate and enforce high-level - policies. The policy-calendar can act as a scheduler to set the star - and end time to block calls which uses suspicious ids, or calls from - other countries. - - module: policy-voip - +--rw policy-voip - | +--rw rule-voip* [rule-voip-id] - | | +--rw rule-voip-id uint16 - | | +--rw name? string - | | +--rw date? yang:date-and-time - | | +--rw event* [event-id] - | | | +--rw event-id string - | | | +--rw name? string - | | | +--rw date? yang:date-and-time - | | | +--rw event-type? string - | | | +--rw Time-Information? string - | | | +--rw event-map-group? -> /threat-feed/event-map-group - | | | /event-map-group-id - | | | +--rw enable? boolean - | | +--rw condition* [condition-id] - | | | +--rw condition-id string - | | | +--rw source-caller? -> /threat-feed/threat-feed - | | | /threat-feed-id - | | | +--rw destination-callee? -> /threat-feed/custom-list - | | | /custom-list-id - | | | +--rw match? boolean - | | | +--rw match-direction? string - | | | +--rw exception? string - | | +--rw action* [action-id] - | | | +--rw action-id string - | | | +--rw name? string - | | | +--rw date? yang:date-and-time - | | | +--rw primary-action? string - | | | +--rw secondary-action? string - | | +--rw precedence? uint16 - | +--rw owner* [owner-id] - | +--rw owner-id string - | +--rw name? string - | +--rw date? yang:date-and-time - +--rw threat-feed - +--rw threat-feed* [threat-feed-id] - | +--rw threat-feed-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw feed-type enumeration - | +--rw feed-server? inet:ipv4-address - | +--rw feed-priority? uint16 - +--rw custom-list* [custom-list-id] - | +--rw custom-list-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw list-type enumeration - | +--rw list-property enumeration - | +--rw list-content? string - +--rw malware-scan-group* [malware-scan-group-id] - | +--rw malware-scan-group-id uint16 - | +--rw name? string - | +--rw date? yang:date-and-time - | +--rw signature-server? inet:ipv4-address - | +--rw file-types? string - | +--rw malware-signatures? string - +--rw event-map-group* [event-map-group-id] - +--rw event-map-group-id uint16 - +--rw name? string - +--rw date? yang:date-and-time - +--rw security-events? string - +--rw threat-map? string - - Figure 3: Policy Instance Example for VoIP/VoLTE Security Services - -5.1. Policy Instance YANG Example for VoIP/VoLTE Security Services - - The following YANG data model is a policy instance for VoIP/VoLTE - security services. The policy-calendar can act as a scheduler to set - the start time and end time to block malicious calls which use - suspicious IDs, or calls from other countries. - - file "ietf-i2nsf-cf-interface-voip.yang" - - module ietf-policy-voip { - namespace - "urn:ietf:params:xml:ns:yang:ietf-policy-voip"; - prefix - "cf-interface"; - - import ietf-yang-types{ - prefix yang; - } - import ietf-inet-types{ - prefix inet; + "Authentication method to be used for this domain. + It should be a reference to a 'policy-mgmt-auth-method' + object."; } - organization - "IETF I2NSF (Interface to Network Security Functions) - Working Group"; - - contact - "WG Web: - WG List: - - WG Chair: Adrian Farrel - - - WG Chair: Linda Dunbar - - - Editor: Jaehoon Paul Jeong - "; - description - "This module defines a YANG data module for consumer-facing - interface to security controller."; - - revision "2018-11-04"{ - description "sixth revision"; - reference - "draft-kumar-i2nsf-client-facing-interface-im-07"; + "This represents the list of policy domains."; } - container policy-voip { + container policy-role { + uses meta; description - "This object is a policy instance to have - complete information such as where and when - a policy need to be applied."; - list rule-voip { - key "rule-voip-id"; - leaf rule-voip-id { - type uint16; - mandatory true; + "This represents the list of policy roles."; + list access-profile { + uses meta; + key "name"; description - "This is ID for rules."; + "This field identifies the access profile for the + role. The profile grants or denies access to policy + objects."; + leaf permission-type { + type identityref { + base permission-type; } + default read-only; description - "This is a container for rules."; - leaf name { - type string; - description - "This field idenfifies the name of this object."; + "Permission type for access-profile: read-only + or read-and-write."; } - leaf date { - type yang:date-and-time; - description - "Date this object was created or last - modified"; - } - list event { - key "event-id"; - description - "This represents the security event of a - policy-rule."; - leaf event-id { - type string; - mandatory true; - description - "This represents the event-id."; } - leaf name { - type string; - description - "This field idenfifies the name of this object."; } - leaf date { - type yang:date-and-time; + list policy-user { + uses meta; + key "name"; description - "Date this object was created or last - modified"; - } - leaf event-type { + "This represents the policy users."; + leaf password { type string; description - "This field identifies the event event type - ."; + "User password for basic authentication"; } - leaf Time-Information { + leaf email { type string; description - "This field contains time calendar such as - BEGIN-TIME and END-TIME for one time - enforcement or recurring time calendar for - periodic enforcement."; - } - leaf event-map-group { - type leafref{ - path "/threat-feed/event-map-group/event-map-group-id"; - } - description - "This field contains security events or threat - map in order to determine when a policy need - to be activated. This is a reference to - Evnet-Map-Group."; - } - leaf enable { - type boolean; - description - "This determines whether the condition - matches the security event or not."; + "The email account of a user"; } + leaf scope-type { + type identityref { + base scope-type; } - list condition { - key "condition-id"; - description - "This represents the condition of a - policy-rule."; - leaf condition-id { - type string; + default tenant-wide; description - "This represents the condition-id."; + "identifies whether a user has domain-wide + or tenant-wide privileges"; } - leaf source-caller { + leaf role { type leafref { - path "/threat-feed/threat-feed/threat-feed-id"; + path "/policy/multi-tenancy/policy-role/access-profile/name"; } description - "This field identifies the source of - the traffic. This could be reference to - either 'Policy Endpoint Group' or - 'Threat-Feed' or 'Custom-List' if Security - Admin wants to specify the source; otherwise, - the default is to match all traffic."; - } - leaf destination-callee { - type leafref { - path "/threat-feed/custom-list/custom-list-id"; + "This represents the reference to the + access-profiles."; } - description - "This field identifies the source of - the traffic. This could be reference to - either 'Policy Endpoint Group' or - 'Threat-Feed' or 'Custom-List' if Security - Admin wants to specify the source; otherwise, - the default is to match all traffic."; } - leaf match { + list policy-mgnt-auth-method { + uses meta; + key "name"; + leaf mutual-authentication { type boolean; description - "This field identifies the match criteria used to - evaluate whether the specified action need to be - taken or not. This could be either a Policy- - Endpoint-Group identifying a Application set or a - set of traffic rules."; - } - leaf match-direction { - type string; - description - "This field identifies if the match criteria is - to evaluated for both direction of the traffic or - only in one direction with default of allowing in - the other direction for stateful match conditions. - This is optional and by default rule should apply - in both directions."; - } - leaf exception { - type string; - description - "This field identifies the exception - consideration when a rule is evaluated for a - given communication. This could be reference to - Policy-Endpoint-Group object or set of traffic - matching criteria."; - } - } - list action { - key "action-id"; - leaf action-id { - type string; - mandatory true; - description - "this represents the policy-action-id."; - } - description - "This object represents actions that a - Security Admin wants to perform based on - a certain traffic class."; - leaf name { - type string; - description - "The name of the policy-action object."; - } - - leaf date { - type yang:date-and-time; - description - "When the object was created or last - modified."; - } - leaf primary-action { - type string; - description - "This field identifies the action when a rule - is matched by NSF. The action could be one of - 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', - 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; - } - leaf secondary-action { - type string; - description - "This field identifies additional actions if - a rule is matched. This could be one of 'LOG', - 'SYSLOG', 'SESSION-LOG', etc."; - } - } - leaf precedence { - type uint16; - description - "This field identifies the precedence - assigned to this rule by Security Admin. - This is helpful in conflict resolution - when two or more rules match a given - traffic class."; - } - } - list owner { - key "owner-id"; - leaf owner-id { - type string; - mandatory true; - description - "this represents the owner-id."; + "To identify whether the authentication + is mutual."; } - description - "This field defines the owner of this policy. - Only the owner is authorized to modify the - contents of the policy."; - leaf name { + container password { + leaf password { type string; description - "The name of the owner."; - } - leaf date { - type yang:date-and-time; - description - "When the object was created or last - modified."; - } - } + "This should be defined using the + regular expression."; } - container threat-feed { - description - "this describes the list of threat-feed."; - - list threat-feed { - key "threat-feed-id"; - leaf threat-feed-id { - type uint16; - mandatory true; description - "This represents the threat-feed-id."; + "This represents the password method."; } - description - "This represents the threat feed within the - threat-prevention-list."; - leaf name { + container token { + leaf token { type string; description - "Name of the theat feed."; + "This should be defined according to + the token scheme."; } - - leaf date { - type yang:date-and-time; description - "when the threat-feed was created."; - } - - leaf feed-type { - type enumeration { - enum unknown { + "This represents the token method."; + leaf token-server { + type inet:ipv4-address; description - "feed-type is unknown."; + "The token-server information if the + authentication method is token-based"; } - enum ip-address { - description - "feed-type is IP address."; } - enum url { + container certificate { description - "feed-type is URL."; - } - } - mandatory true; + "This represents the certificate method."; + leaf certificate { + type certificate-type; description - "This determined whether the feed-type is IP address - based or URL based."; + "This represents the certificate-type."; } - - leaf feed-server { + leaf certificate-server { type inet:ipv4-address; description - "this contains threat feed server information."; - } - - leaf feed-priority { - type uint16; - description - "this describes the priority of the threat from - 0 to 5, where 0 means the threat is minimum and - 5 meaning the maximum."; - } + "The certificate-server information if + the authentication method is + certificate-based"; } - list custom-list { - key "custom-list-id"; - leaf custom-list-id { - type uint16; - description - "this describes the custom-list-id."; } + container single-sign-on { description - "this describes the threat-prevention custom list."; - leaf name { - type string; - description - "Name of the custom-list."; - } - - leaf date { - type yang:date-and-time; + "This represents the authentication method + for single-sing-on."; + leaf credential { + type certificate-type; description - "when the custom list was created."; - } + "This represents the authentication + using user credentials."; - leaf list-type { - type enumeration { - enum unknown { - description - "list-type is unknown."; } - enum ip-address { + leaf certificate-server { + type inet:ipv4-address; description - "list-type is IP address."; + "The certificate-server information if + the authentication method is + certificate-based"; } - enum mac-address { - description - "list-type is MAC address."; } - enum url { description - "list-type is URL."; - } + "This represents the policy managegement method."; } - mandatory true; - description - "This determined whether the feed-type is IP address - based or URL based."; } - leaf list-property { - type enumeration { - enum unknown { +container endpoint-group { description - "list-property is unknown."; - } - enum blacklist { + "A logical entity in their business + environment, where a security policy + is to be applied."; + list user-group { + uses user-group; + key "name"; description - "list-property is blacklist."; + "This represents the user group."; } - enum whitelist { + list device-group { + uses device-group; + key "name"; description - "list-property is whitelist."; - } + "This represents the device group."; } - mandatory true; + list location-group{ + uses location-group; + key "name"; description - "This determined whether the list-type is blacklist - or whitelist."; + "This represents the location group."; } - leaf list-content { - type string; - description - "This describes the contents of the custom-list."; - } } - list malware-scan-group { - key "malware-scan-group-id"; - leaf malware-scan-group-id { - type uint16; - mandatory true; +container threat-prevention { description - "This is the malware-scan-group-id."; - } + "this describes the list of threat-prevention."; + list threat-feed-list { + uses meta; + key "name"; description - "This represents the malware-scan-group."; - leaf name { + "This represents the threat feed list."; + container threat-feed-server { + uses ip-address; + description + "This describes the threat-feed server."; + leaf threat-feed-description { type string; description - "Name of the malware-scan-group."; + "This object containes threat-feed + description."; } - - leaf date { - type yang:date-and-time; - description - "when the malware-scan-group was created."; } - - leaf signature-server { - type inet:ipv4-address; - description - "This describes the signature server of the - malware-scan-group."; + leaf-list threat-file-types { + type identityref { + base malware-file-type; } - - leaf file-types { - type string; + default executable-file; description "This contains a list of file types needed to be scanned for the virus."; } - - leaf malware-signatures { - type string; - description - "This contains a list of malware signatures or hash."; - } - } - list event-map-group { - key "event-map-group-id"; - leaf event-map-group-id { - type uint16; - mandatory true; - description - "This is the event-map-group-id."; - } - description - "This represents the event map group."; - leaf name { + leaf-list signatures { type string; description - "Name of the event-map."; - } - - leaf date { - type yang:date-and-time; - description - "when the event-map was created."; + "This contains a list of signatures or hash + of the threats."; } - - leaf security-events { - type string; - description - "This contains a list of security events."; } - - leaf threat-map { - type string; + list payload-content { + uses payload-string; + key "name"; description - "This contains a list of threat levels."; + "This represents the payload-string group."; } } } } - Figure 4: Policy Instance YANG Example for VoIP Security Services + Figure 23: YANG for policy-general -6. Example XML Output for Various Use Cases +10. Example XML Output for Various Scenarios - In this section, we present an XML example for various use cases. - Here, we show the policy examples that can be delivered through - consumer-facing interface. For now, the considered use cases are: - VoIP security service, DDoS-attack mitigation, time-based firewall, - and web-filter. + This section describes the XML instances for different policies + examples that are delivered through Consumer-Facing Interface. The + considered use cases are: VoIP/VoLTE security service, DDoS-attack + mitigation, time-based firewall as a web-filter. -6.1. Case 1: VoIP Security Service +10.1. DB registration: Information of positions and devices (Endpoint + group) - The first example is a VoIP policy. Here, we are going to drop calls - commin from a country with an Ip from South Africa that is classified - as malicious. The below figure shows the XML document generated by - using the YANG data tree as shown in the previous section. + In order to create a rule of a security policy, it is essential to + first register data (those which are used to form such rule) to the + database. For example, The endpoint group consists of three + different groups: user-group, device-group, and payload-group. Each + of these groups have separate group members with information other + than meta ("name" or "date"), such as ip-addresses or protocols used + by devices. Figure 24 shows an example XML representation of the + registered information for the user-group and device-group. - - - - - - - - - - - 01 - voip-policy-example - 2017.10.25/20:30:32 - - 01 - voip_call - 2017.10.25/20:30:32 - malicious - 19 - True - - - 01 - 105.176.0.0 - 192.168.171.35 - - 22:00 - 08:00 - - default - 00 - - - 01 - action-voip - 2017.10.25/20:30:32 - DENY - LOG - - none - - 01 - i2nsf-admin - - - - - - - - Figure 5: An XML Example for VoIP Security Service + + + + employees + + 221.159.112.1 + 221.159.112.90 + + + + webservers + + 221.159.112.91 + 221.159.112.97 + + http + https + + -6.2. Case 2: DDoS-Attack Mitigation + Figure 24: Registering user-group and device-group information - The second example is a DDoS-attack mitigation policy. Here, the - time information is not set because the service provided by the - network should be maintained at all times. If the packets sent by - any sources are more than the set threshold, then the admin can set - the percentage of the packets to be dropped to safely maintain the - service. +10.2. Scenario 1: Block SNS access during business hours - - - - - - - - - - - 03 - ddos-policy-example - 2018.10.25/11:25:32 + The first example scenario is to "block SNS access during business + hours" using a time-based firewall policy. In this scenario, all + users registered as "employee" in the user-group list are unable to + access Social Networking Services (SNS) during the office hours. The + XML instance is described below: + + + + security_policy_for_blocking_sns + + block_access_to_sns_during_office_hours - 03 - ddos - 2018.10.25/11:25:32 - ddos - 03 - True - - - 03 - Any - 192.168.173.37 - 30 - --:-- - --:-- + 09:00 + 18:00 - default - 00 + + + + + employees + + + + + sns-websites + + - 03 - action-ddos - 2018.10.25/11:25:32 - REJECT - LOG + drop - none - - 03 - i2nsf-admin - - - - - - - + + - Figure 6: An XML Example for DDoS-attack Mitigation + Figure 25: An XML Example for Time-based Firewall -6.3. Case 3: Time-Based Firewall + Time-based-condition Firewall - The third example is a time-based firewall policy. Consider a Smart - Factory which operates from 9 am to 7 pm during the working days. - During these hours, only the admin responsible for operating the - factory is allow to access a control system. The below figure show - that any access during outside the operating hours is rejected. + 1. The policy name is "security_policy_for_blocking_sns". - - - - - - - - - - - 01 - fw-policy-example - 2018.10.25/11:19:05 - - 01 - invalid_access - 2018.10.25/11:19:05 - invalid - 02 - True - + 2. The rule name is "block_access_to_sns_during_office_hours". + + 3. The Source-target is "employees". + + 4. The destination target is "sns-websites". "sns-websites" is the + key which represents the list containing the information, such as + URL, about sns-websites. + + 5. The action required is to "drop" any attempt to connect to + websites related to Social networking. + +10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to the + company + + The second example scenario is to "block malicious VoIP/VoLTE packets + coming to the company" using a VoIP policy. In this scenario, the + calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that + are classified as malicious are dropped. The IP addresses of the + employees and malicious VOIP IDs should be blocked are stored in the + database or datastore of the enterprise. Here and the rest of the + cases assume that the security administrators or someone responsible + for the existing and newly generated policies, are not aware of which + and/or how many NSFs are needed to meet the security requirements. + Figure 26 represents the XML document generated from YANG discussed + in previous sections. Once a high-level seucurity policy is created + by a security admin, it is delivered by the Consumer-Facing + Interface, through RESTCONF server, to the security controller. The + XML instance is described below: + + + + security_policy_for_blocking_malicious_voip_packets + + Block_malicious_voip_and_volte_packets - 02 - 115.176.0.1 - 192.168.173.41 - - 09:00 - 17:00 - - default - 00 + + + malicious-id + + + + + employees + + - 02 - action-fw - 2018.10.25/11:19:05 - PASS - LOG + drop - none - - 02 - i2nsf-admin - - - - - - - + + - Figure 7: An XML Example for Time-based Firewall + Figure 26: An XML Example for VoIP Security Service -6.4. Case 4: Time-Based Web-Filter + Custom-condition Firewall - The last example is a time-based web-filter policy. Let us suppose - that a owner of an enterprise wants to forbid access to a specific - set of websites, such as Facebook, Youtube, Instagram, etc. The - below figure shows an example policy an admin of a sector or - department can deploy. + 1. The policy name is + "security_policy_for_blocking_malicious_voip_packets". - - - - - - - - - - - 03 - wf-policy-example - 2018.10.26/14:03:17 - - 04 - wf - 2018.10.26/14:03:17 - wf - 04 - True - + 2. The rule name is "Block_malicious_voip_and_volte_packets". + + 3. The Source-target is "malicious-id". This can be a single ID or + a list of IDs, depending on how the ID are stored in the + database. The "malicious-id" is the key so that the security + admin can read every stored malicious VOIP IDs that are named as + "malicious-id". + + 4. The destination target is "employees". "employees" is the key + which represents the list containing information about employees, + such as IP addresses. + + 5. The action required is "drop" when any incoming packets are from + "malicious-id". + +10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a company + web Server + + The third example scenario is to "Mitigate HTTP and HTTPS flood + attacks on a company web Server" using a DDoS-attack mitigation + policy. Here, the time information is not set because the service + provided by the network should be maintained at all times. If the + packets sent by any sources are more than the set threshold, then the + admin can set the percentage of the packets to be dropped to safely + maintain the service. In this scenario, the source is set as "any" + to block any sources which send abnormal amount of packets. The + destination is set as "web_server01". Once the rule is set and + delivered and enforced to the nsfs by the securiy controller, the + NSFs will monitor the incoming packet amounts and the destination to + act according to the rule set. The XML instance is described below: + + + + security_policy_for_ddos_attacks + + 100_packets_per_second - 04 - 192.168.1.3 - www.facebook.com - - 09:00 - 18:00 - - default - 00 + + + webservers + + + 100 + + - 04 - action-wf - 2018.10.26/14:03:17 - REJECT - LOG + drop - none - - 03 - i2nsf-admin - - - - - - - + + - Figure 8: An XML Example for Time-based Web-filter + Figure 27: An XML Example for DDoS-attack Mitigation -6.5. Case 5: Threat-Feed Configuration + DDoS-condition Firewall - The threat-feed container described above can convey various sources - containing information concerning security threats. One good example - can be STIX. STIX (Structured Threat Information Expression) is a - language and serialization format used to exchange cyber threat - intelligence (CTI). It is a lanauge to describe threat information - in a standardized format to enable exchanging and sharing them. The - blow figure show the necessary configuration, which can be generated - and delivered by consumer-facing interface. + 1. The policy name is "security_policy_for_ddos_attacks". - ... - ... - - - 02 - stix - 2018.10.25/11:25:32 - ip-address - 105.134.171.24 - ip-address - - - ... - ... + 2. The rule name is "100_packets_per_second". - Figure 9: An XML Example for Threat-feed Configuration + 3. The destination target is "webservers". "webservers" is the key + which represents the list containing information, such as IP + addresses and ports, about web-servers. - Usually, STIX can be obtained from a TAXII server which contains a - collection of cyber threat information formatted in STIX. Here, the - "feed-server" leaf contains the ip-address of the TAXII server, so - that recent threat related information can be collected when the - configuration is set. + 4. The rate limit exists to limit the incoming amount of packets per + second. In this case the rate limit is "100" packets per second. + This amount depends on the packet receiving capacity of the + server devices. -7. Security Considerations + 5. The Source-target is all sources which send abnormal amount of + packets. + + 6. The action required is to "drop" packet reception is more than + 100 packets per second. + +11. Security Considerations The data model for the I2NSF Consumer-Facing Interface is derived from the I2NSF Consumer-Facing Interface Information Model [client-facing-inf-im], so the same security considerations with the information model should be included in this document. The data model needs to support a mechanism to protect Consumer-Facing Interface to Security Controller. -8. References +12. IANA Considerations -8.1. Normative References + This document requests IANA to register the following URI in the + "IETF XML Registry" [RFC3688]: + + URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy + Registrant Contact: The I2NSF. + XML: N/A; the requested URI is an XML namespace. + + This document requests IANA to register the following YANG module in + the "YANG Module Names" registry [RFC7950]. + + name: ietf-i2nsf-cfi-policy + namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy + prefix: cfi-policy + reference: RFC 7950 + +13. References + +13.1. Normative References [RFC3444] Pras, A., "On the Difference between Information Models and Data Models", RFC 3444, January 2003. -8.2. Informative References +13.2. Informative References [client-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, S., and L. Xia, "Information model for Client-Facing Interface to Security Controller", draft-kumar-i2nsf- client-facing-interface-im-07 (work in progress), July 2018. [client-facing-inf-req] Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, S., and L. Xia, "Requirements for Client-Facing Interface to Security Controller", draft-ietf-i2nsf-client-facing- interface-req-05 (work in progress), May 2018. - [i2nsf-framework] - Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. - Kumar, "Framework for Interface to Network Security - Functions", RFC 8329, February 2018. + [draft-ietf-i2nsf-capability] + Xia, L., Strassner, J., Huawei, Basile, C., PoliTo, Lopez, + D., and TID, "Information Model of NSFs Capabilities", + draft-ietf-i2nsf-capability-04 (work in progress), October + 2018. [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L. Xia, "Information model for Client-Facing Interface to - Security Controller", draft-ietf-i2nsf-terminology-06 - (work in progress), July 2018. + Security Controller", draft-ietf-i2nsf-terminology-07 + (work in progress), January 2019. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. + [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG + Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, + January 2011, . + + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., + and J. Jeong, "Interface to Network Security Functions + (I2NSF): Problem Statement and Use Cases", RFC 8192, + DOI 10.17487/RFC8192, July 2017, + . + + [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. + Kumar, "Framework for Interface to Network Security + Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, + . + + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- - dm-01 + dm-02 The following changes have been made from draft-ietf-i2nsf-consumer- - facing-interface-dm-01: + facing-interface-dm-02: - o In Section 6, four additional XML output examples (VoIP, DDoS- - attack, Time-based Firewall and Web-filter) for security policies - are added. Also, an example XML output for Threat-feed - configuration is added using STIX and TAXII as a threat-feed - example. + o In this version of the WG draft, we merged the + [client-facing-inf-im] and draft-ietf-i2nsf-consumer-facing- + interface-dm-02 drafts. In sections 4 to 9, we describe the + information model for the security policies delivered through the + Consumer-Facing Interface. In sections 10 to 12, we provide and + discuss the YANG data model and example XML outputs of security + policies for various use cases. - o The overall organization of the YANG data model and its data types - have also been reviewed and corrected, and produced the - corresponding data tree as shown in the Sections 4 and 5. + o In Section 10, the following changes have been made: For "time- + information" container in event sub-module list, the enforcement + type is defined into three different types (admin-enforced, time- + enforced, and event-enforced). Also, begin-time and end-time type + has been defined seperately. The security policies can now be set + recursively (daily, weekly, and monthly). - o Overall editorial errors have been corrected. + o "policy-role" now has the access-profile container, and previlege + can be set separately per profile. + + o "policy-user" information, such as email and password is newly + defined by regular expressions. + + o "authentication-method" in "policy-mgnt-auth-method" has been + modified. More specifically, the authentication-method type has + been changed from string to choice so that one can choose between + password, token, and certificate. If not selected, password is + used as a default. + + o "Certificate-type" has been re-defined to include common + certificate extensions, such as ".CRT", "CER", and "KEY". + + o Used groupings to represent the groups in the Endpoint groups. + + o Added examples for registering information (i.e., endpoint-groups, + threat-prevention, and multi-tenancy.) Appendix B. Acknowledgments 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). Appendix C. Contributors This document is made by the group effort of I2NSF working group. Many people actively contributed to this document, such as Mahdi F. - Dachmehchi and Daeyoung Hyun. The following are considered co- - authors: + Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their + contributions. - o Hyoungshick Kim (Sungkyunkwan University) + The following are co-authors of this document: - o Seungjin Lee (Sungkyunkwan University) + Hyoungshick Kim + Department of Software + 2066 Seo-ro Jangan-gu + Suwon, Gyeonggi-do 16419 + Republic of Korea - o Jinyong Tim Kim (Sungkyunkwan University) + EMail: hyoung@skku.edu + + Seungjin Lee + Department of Electrical and Computer Engineering + 2066 Seo-ro Jangan-gu + Suwon, Gyeonggi-do 16419 + Republic of Korea + + EMail: jine33@skku.edu + + Jinyong Tim Kim + Department of Electrical and Computer Engineering + 2066 Seo-ro Jangan-gu + Suwon, Gyeonggi-do 16419 + Republic of Korea + + EMail: timkim@skku.edu + + Anil Lohiya + Juniper Networks + 1133 Innovation Way + Sunnyvale, CA 94089 + US + + EMail: alohiya@juniper.net + + Dave Qi + Bloomberg + 731 Lexington Avenue + New York, NY 10022 + US + + EMail: DQI@bloomberg.net + + Nabil Bitar + Nokia + 755 Ravendale Drive + Mountain View, CA 94043 + US + + EMail: nabil.bitar@nokia.com + + Senad Palislamovic + Nokia + 755 Ravendale Drive + Mountain View, CA 94043 + US + + EMail: senad.palislamovic@nokia.com + + Liang Xia + Huawei + 101 Software Avenue + Nanjing, Jiangsu 210012 + China + + EMail: Frank.Xialiang@huawei.com Authors' Addresses + 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