--- 1/draft-ietf-i2nsf-capability-data-model-01.txt 2018-11-04 03:13:38.580646964 -0800 +++ 2/draft-ietf-i2nsf-capability-data-model-02.txt 2018-11-04 03:13:38.696649735 -0800 @@ -1,47 +1,47 @@ -Network Working Group S. Hares +I2NSF Working Group S. Hares Internet-Draft Huawei Intended status: Standards Track J. Jeong -Expires: January 3, 2019 J. Kim +Expires: May 8, 2019 J. Kim Sungkyunkwan University R. Moskowitz HTT Consulting Q. Lin Huawei - July 02, 2018 + November 4, 2018 I2NSF Capability YANG Data Model - draft-ietf-i2nsf-capability-data-model-01 + draft-ietf-i2nsf-capability-data-model-02 Abstract This document defines a YANG data model for capabilities that enable - an I2NSF user to control various Network Security Functions (NSFs) in - the framework for Interface to Network Security Functions (I2NSF). + a user to control various Network Security Functions (NSFs) in the + framework for Interface to Network Security Functions (I2NSF). 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 January 3, 2019. + This Internet-Draft will expire on May 8, 2019. Copyright Notice Copyright (c) 2018 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 @@ -50,59 +50,61 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. The Structure and Objective of NSF Capabilities . . . . . . . 6 5.1. Generic Network Security Function Identification . . . . 6 5.2. Event Capabilities . . . . . . . . . . . . . . . . . . . 6 5.3. Condition Capabilities . . . . . . . . . . . . . . . . . 7 5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7 5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7 - 5.6. Default Action Capabilities . . . . . . . . . . . . . . . 7 + 5.6. Default Action Capabilities . . . . . . . . . . . . . . . 8 5.7. RPC for Acquiring Appropriate Network Security Function . 8 6. Data Model Structure . . . . . . . . . . . . . . . . . . . . 8 6.1. Network Security Function Identification . . . . . . . . 8 6.2. Capabilities of Generic Network Security Function . . . . 9 - 6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 9 - 6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 11 + 6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 10 + 6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 12 6.2.3. Action Capabilities . . . . . . . . . . . . . . . . . 14 - 6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 15 - 6.2.5. Content Security Capabilities . . . . . . . . . . . . 15 - 6.2.6. Attack Mitigation Capabilities . . . . . . . . . . . 16 - 6.2.7. RPC for Acquiring Appropriate Network Security - Function . . . . . . . . . . . . . . . . . . . . . . 17 - 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 18 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 - 12.2. Informative References . . . . . . . . . . . . . . . . . 53 + 6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 16 + 6.2.5. Capabilities of Advanced Network Security Function . 16 + 6.2.6. Content Security Capabilities . . . . . . . . . . . . 17 + 6.2.7. Attack Mitigation Capabilities . . . . . . . . . . . 18 + 6.2.8. RPC for Acquiring Appropriate Network Security + Function . . . . . . . . . . . . . . . . . . . . . . 19 + 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 20 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 57 + 10.2. Informative References . . . . . . . . . . . . . . . . . 57 Appendix A. Example: Extended VoIP-VoLTE Security Function - Capabilities Module . . . . . . . . . . . . . . . . 55 - Appendix B. Example: Configuration XML of Capability Module . . 56 + Capabilities Module . . . . . . . . . . . . . . . . 59 + Appendix B. Example: Configuration XML of Capability Module . . 60 B.1. Example: Configuration XML of Generic Network Security - Function Capabilities . . . . . . . . . . . . . . . . . . 56 + Function Capabilities . . . . . . . . . . . . . . . . . . 60 B.2. Example: Configuration XML of Extended VoIP/VoLTE - Security Function Capabilities Module . . . . . . . . . . 58 + Security Function Capabilities Module . . . . . . . . . . 62 Appendix C. Changes from draft-ietf-i2nsf-capability-data- - model-01 . . . . . . . . . . . . . . . . . . . . . . 59 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 + model-01 . . . . . . . . . . . . . . . . . . . . . . 63 + + Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 64 + Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 64 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 1. Introduction As the industry becomes more sophisticated and network devices (e.g., Internet of Things, Self-driving vehicles, and VoIP/VoLTE smartphones), service providers have a lot of problems mentioned in [RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies the information model of the capabilities of Network Security Functions (NSFs). @@ -146,38 +148,38 @@ 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 [RFC2119]. 3. Terminology This document uses the terminology described in [i2nsf-terminology][i2nsf-nsf-cap-im] - [i2rs-rib-data-model][supa-policy-info-model]. Especially, the - following terms are from [supa-policy-info-model]: + [RFC8431][supa-policy-info-model]. Especially, the following terms + are from [supa-policy-info-model]: o Data Model: A data model is a representation of concepts of interest to an environment in a form that is dependent on data repository, data definition language, query language, implementation language, and protocol. o Information Model: An information model is a representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, and protocol. 3.1. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams - [i2rs-rib-data-model] is as follows: + [RFC8431] is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "list" and "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also @@ -368,32 +370,34 @@ +--rw target-device | +--rw pc? boolean | +--rw mobile-phone? boolean | +--rw voip-volte-phone? boolean | +--rw tablet? boolean | +--rw iot? boolean | +--rw vehicle? boolean +--rw generic-nsf-capabilities | +--rw net-sec-capabilities | uses net-sec-caps + +--rw advanced-nsf-capabilities + | +--rw advaneced-sec-capabilities + | uses advaneced-sec-caps +--rw complete-nsf-capabilities +--rw con-sec-control-capabilities | uses i2nsf-con-sec-control-caps +--rw attack-mitigation-capabilities uses i2nsf-attack-mitigation-control-caps Figure 2: Data Model Structure for NSF-Identification - This draft also utilizes the concepts originated in Basile, Lioy, - Pitscheider, and Zhao[2015] concerning conflict resolution, use of - external data, and target device. The authors are grateful to - Cataldo for pointing out this excellent work. + This document also utilizes a formal model for policy reconciliation + proposed by Basile et al. [Policy-Reconciliation], which handles + conflict resolution, the use of external data, and target device. The nsf-type object can be used for configuration about type of a NSF. The types of NSF consists of Network Firewall, Web Application Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address object can be used for configuration about location of a NSF. The target-device object can be used for configuration about target devices. We will add additional type of a NSF for more generic network security functions. 6.2. Capabilities of Generic Network Security Function @@ -697,21 +701,57 @@ Figure 7: Data Model Structure for Resolution Strategy Capabilities of Network Security Function These objects are defined capabilities as first-matching-rule and last-matching-rule. These objects can be extended according to specific vendor resolution strategy features. We will add additional resolution strategy objects for more generic network security functions. -6.2.5. Content Security Capabilities +6.2.5. Capabilities of Advanced Network Security Function + + The data model for advanced NSF capabilities has the following + structure: + + +--rw advanced-nsf-capabilities + | +--rw advanced-sec-capabilities + | +--rw antivirus + | | +--rw detect? boolean + | | +--rw exception-application? boolean + | | +--rw exception-signature? boolean + | | +--rw whitelists? boolean + | +--rw antiddos + | | +--rw syn-flood-action? boolean + | | +--rw udp-flood-action? boolean + | | +--rw http-flood-action? boolean + | | +--rw https-flood-action? boolean + | | +--rw dns-request-flood-action? boolean + | | +--rw dns-reply-flood-action? boolean + | | +--rw icmp-flood-action? boolean + | | +--rw sip-flood-action? boolean + | | +--rw detect-mode? boolean + | | +--rw baseline-learn? boolean + | +--rw ips + | +--rw signature-set? boolean + | +--rw exception-signature? boolean + ... + + Figure 8: Data Model Structure for Capabilities of Advanced Network + Security Function + + These objects are defined capabilities of advanced network security + functions such as antivirus, antiddos, and ips. A detailed data + model for the configuration of the advanced network security + functions is described in [i2nsf-advanced-nsf-dm]. + +6.2.6. Content Security Capabilities The data model for content security capabilities has the following structure: +--rw complete-nsf-capabilities +--rw con-sec-control-capabilities | +--rw anti-virus? boolean | +--rw ips? boolean | +--rw ids? boolean | +--rw url-filter? boolean @@ -719,30 +759,30 @@ | +--rw mail-filter? boolean | +--rw sql-filter? boolean | +--rw file-blocking? boolean | +--rw file-isolate? boolean | +--rw pkt-capture? boolean | +--rw application-behavior? boolean | +--rw voip-volte? boolean +--rw attack-mitigation-capabilities ... - Figure 8: Data Model Structure for Content Security Capabilities of + Figure 9: Data Model Structure for Content Security Capabilities of Network Security Function Content security is composed of a number of distinct security Capabilities; each such Capability protects against a specific type of threat in the application layer. Content security is a type of Generic Network Security Function (GNSF), which summarizes a well- defined set of security Capabilities. -6.2.6. Attack Mitigation Capabilities +6.2.7. Attack Mitigation Capabilities The data model for attack mitigation capabilities has the following structure: +--rw complete-nsf-capabilities ... +--rw attack-mitigation-capabilities +--rw (attack-mitigation-control-type)? +--:(ddos-attack) | +--rw (ddos-attack-type)? @@ -765,29 +805,29 @@ +--:(scan-and-sniff-attack) | +--rw ip-sweep-attack? boolean | +--rw port-scanning-attack? boolean +--:(malformed-packet-attack) | +--rw ping-of-death-attack? boolean | +--rw teardrop-attack? boolean +--:(special-packet-attack) +--rw oversized-icmp-attack? boolean +--rw tracert-attack? boolean - Figure 9: Data Model Structure for Attack Mitigation Capabilities of + Figure 10: Data Model Structure for Attack Mitigation Capabilities of Network Security Function Attack mitigation is composed of a number of GNSFs; each one protects against a specific type of network attack. Attack Mitigation security is a type of GNSF, which summarizes a well-defined set of security Capabilities. -6.2.7. RPC for Acquiring Appropriate Network Security Function +6.2.8. RPC for Acquiring Appropriate Network Security Function The data model for RPC for Acquiring Appropriate Network Security Function has the following structure: rpcs: +---x call-appropriate-nsf +---w input | +---w nsf-type nsf-type | +---w target-device | +---w pc? boolean @@ -797,38 +837,38 @@ | +---w iot? boolean | +---w vehicle? boolean +--ro output +--ro nsf-address +--ro (nsf-address-type)? +--:(ipv4-address) | +--ro ipv4-address inet:ipv4-address +--:(ipv6-address) +--ro ipv6-address inet:ipv6-address - Figure 10: RPC for Acquiring Appropriate Network Security Function + Figure 11: RPC for Acquiring Appropriate Network Security Function This shows a RPC for acquiring an appropriate network security function according to type of NSF and/or target devices. If the SFF [i2nsf-sfc]does not have the location information of network security functions that it should send in own cache table, this can be used to acquire the information. These objects are defined as input data (i.e., NSF type and target devices) and output data (i.e., location information of NSF). 7. YANG Modules 7.1. I2NSF Capability YANG Data Module This section introduces a YANG module for the information model of network security functions, as defined in the [i2nsf-nsf-cap-im]. - file "ietf-i2nsf-capability@2018-07-02.yang" + file "ietf-i2nsf-capability@2018-11-04.yang" module ietf-i2nsf-capability { namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; prefix i2nsf-capability; import ietf-inet-types{ prefix inet; } @@ -852,24 +892,24 @@ Editor: Jaehoon Paul Jeong Editor: Jinyong Tim Kim "; description "This module describes a capability model for I2NSF devices."; - revision "2018-07-02"{ + revision "2018-11-04"{ description "The fifth revision"; reference - "draft-ietf-i2nsf-capability-00"; + "draft-ietf-i2nsf-capability-04"; } grouping i2nsf-nsf-location { description "This provides a location for capabilities."; container nsf-address { description "This is location information for capabilities."; choice nsf-address-type { description @@ -2155,20 +2195,128 @@ leaf last-matching-rule { type boolean; description "If the resolution strategy is last matching rule"; } } } } + grouping i2nsf-advanced-sec-caps { + description + "i2nsf-advanced-sec-caps"; + container advanced-sec-capabilities { + description + "net-sec-capabilities"; + + container antivirus { + description + "antivirus"; + + leaf detect { + type boolean; + description + "detect capability"; + } + leaf exception-application { + type boolean; + description + "exception-application capability"; + } + leaf exception-signature { + type boolean; + description + "exception-signature capability"; + } + leaf whitelists { + type boolean; + description + "exception-signature capability"; + } + } + + container antiddos { + description + "antiddos"; + + leaf syn-flood-action { + type boolean; + description + "syn-flood-action capability"; + } + leaf udp-flood-action { + type boolean; + description + "udp-flood-action capability"; + } + leaf http-flood-action { + type boolean; + description + "http-flood-action capability"; + } + leaf https-flood-action { + type boolean; + description + "https-flood-action capability"; + } + leaf dns-request-flood-action { + type boolean; + description + "dns-request-flood-action capability"; + } + leaf dns-reply-flood-action { + type boolean; + description + "dns-reply-flood-action capability"; + } + leaf icmp-flood-action { + type boolean; + description + "icmp-flood-action capability"; + } + leaf sip-flood-action { + type boolean; + description + "sip-flood-action capability"; + } + leaf detect-mode { + type boolean; + description + "detect mode capability"; + } + leaf baseline-learn { + type boolean; + description + "baseline-learn capability"; + } + } + + container ips { + description + "ips"; + + leaf signature-set { + type boolean; + description + "signature-set capability"; + } + leaf exception-signature { + type boolean; + description + "exception-signature capability"; + + } + } + } + } + grouping i2nsf-con-sec-control-caps { description "i2nsf-con-sec-control-caps"; container con-sec-control-capabilities { description "content-security-control-capabilities"; leaf anti-virus { type boolean; @@ -2386,20 +2534,25 @@ "nsf-name"; } uses capabilities-information; container generic-nsf-capabilities { description "generic-nsf-capabilities"; uses i2nsf-net-sec-caps; } + container advanced-nsf-capabilities { + description + "advanced-nsf-capabilities"; + uses i2nsf-advanced-sec-caps; + } container complete-nsf-capabilities { description "generic-nsf-capabilities"; uses i2nsf-con-sec-control-caps; uses i2nsf-attack-mitigation-control-caps; } } @@ -2420,112 +2573,95 @@ uses i2nsf-it-resources; } output { uses i2nsf-nsf-location; } } } - Figure 11: YANG Data Module of I2NSF Capability + Figure 12: YANG Data Module of I2NSF Capability 8. IANA Considerations No IANA considerations exist for this document at this time. URL will be added. 9. Security Considerations This document introduces no additional security threats and SHOULD follow the security requirements as stated in [RFC8329]. -10. 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). - -11. Contributors - - I2NSF is a group effort. I2NSF has had a number of contributing - authors. The following are considered co-authors: - - o Hyoungshick Kim (Sungkyunkwan University) - - o Daeyoung Hyun (Sungkyunkwan University) - - o Dongjin Hong (Sungkyunkwan University) - - o Liang Xia (Huawei) - - o Jung-Soo Park (ETRI) - - o Tae-Jin Ahn (Korea Telecom) - - o Se-Hui Lee (Korea Telecom) - -12. References +10. References -12.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [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, July 2017. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, February 2018. -12.2. Informative References + [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, + S., and N. Bahadur, "A YANG Data Model for Routing + Information Base (RIB)", RFC RFC8431, September 2018. + +10.2. Informative References + + [i2nsf-advanced-nsf-dm] + Pan, W. and L. Xia, "Configuration of Advanced Security + Functions with I2NSF Security Controller", draft-dong- + i2nsf-asf-config-01 (work in progress), October 2018. [i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. Lopez, "Information Model of NSFs Capabilities", draft-ietf- - i2nsf-capability-01 (work in progress), April 2018. + i2nsf-capability-04 (work in progress), October 2018. [i2nsf-nsf-yang] Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG - Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-00 - (work in progress), March 2018. + Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01 + (work in progress), July 2018. [i2nsf-sfc] Hyun, S., Jeong, J., Park, J., and S. Hares, "Service Function Chaining-Enabled I2NSF Architecture", draft-hyun- - i2nsf-nsf-triggered-steering-05 (work in progress), March + i2nsf-nsf-triggered-steering-06 (work in progress), July 2018. [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) - Terminology", draft-ietf-i2nsf-terminology-05 (work in - progress), January 2018. + Terminology", draft-ietf-i2nsf-terminology-06 (work in + progress), July 2018. - [i2rs-rib-data-model] - Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, - S., and N. Bahadur, "A YANG Data Model for Routing - Information Base (RIB)", draft-ietf-i2rs-rib-data-model-12 - (work in progress), April 2018. + [Policy-Reconciliation] + Basile, C., Lioy, A., Pitscheider, C., and S. Zhao, "A + Formal Model of Policy Reconciliation", + Euromicro Euromicro International Conference on Parallel, + Distributed and Network-Based Processing (PDP), March + 2015. [supa-policy-info-model] Strassner, J., Halpern, J., and S. Meer, "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- model-03 (work in progress), May 2017. Appendix A. Example: Extended VoIP-VoLTE Security Function Capabilities Module @@ -2578,21 +2714,21 @@ leaf sip-header-user-agent { type boolean; description "SIP header user agent."; } } } } - Figure 12: Example: Extended VoIP-VoLTE Security Function + Figure 13: Example: Extended VoIP-VoLTE Security Function Capabilities Module Appendix B. Example: Configuration XML of Capability Module This section gives a xml examples for a configuration of Capability module according to a requirement. B.1. Example: Configuration XML of Generic Network Security Function Capabilities @@ -2655,28 +2791,28 @@ true - Figure 13: Example: Configuration XML for Generic Network Security + Figure 14: Example: Configuration XML for Generic Network Security Function Capability B.2. Example: Configuration XML of Extended VoIP/VoLTE Security Function Capabilities Module This section gives a xml example for extended VoIP-VoLTE security - function capabilities (See Figure 12) configuration according to a + function capabilities (See Figure 13) configuration according to a requirement. Requirement: Register VoIP/VoLTe security function according to requirements. 1. The location of the NSF is 221.159.112.151. 2. The NSF can obtain the best effect if the packet was generated by VoIP-VoLTE phone. @@ -2714,44 +2850,58 @@ true - Figure 14: Example: Configuration XML for Extended VoIP/VoLTE + Figure 15: Example: Configuration XML for Extended VoIP/VoLTE Security Function Capabilities Appendix C. Changes from draft-ietf-i2nsf-capability-data-model-01 The following changes are made from draft-ietf-i2nsf-capability-data- - model-00: + model-01: - 1. We have clarified and simplified capabilities. + o We added capabilities of advanced network security functions such + as anti-virus, anti-ddos, and IPS. - 2. We added additional condition capabilities for application and - url. +Appendix D. Acknowledgments - 3. We replaced unnecessary leaf-list component to leaf component. + 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). - 4. We replaced the list component to the container component for - net-sec-capabilities. +Appendix E. Contributors - 5. We modified the choice-case structure into a container structure - to allow for the selection of multiple catalogues for condition - and action clauses. + This document is made by the group effort of I2NSF working group. + Many people actively contributed to this document. The following are + considered co-authors: - 6. We added complete-nsf-capabilities such as content capabilities - and attack mitigation capabilities. + o Hyoungshick Kim (Sungkyunkwan University) + + o Daeyoung Hyun (Sungkyunkwan University) + + o Dongjin Hong (Sungkyunkwan University) + + o Liang Xia (Huawei) + + o Jung-Soo Park (ETRI) + + o Tae-Jin Ahn (Korea Telecom) + + o Se-Hui Lee (Korea Telecom) Authors' Addresses Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Phone: +1-734-604-0332