--- 1/draft-ietf-i2nsf-capability-data-model-00.txt 2018-07-02 07:18:07.309167700 -0700 +++ 2/draft-ietf-i2nsf-capability-data-model-01.txt 2018-07-02 07:18:07.441170862 -0700 @@ -1,24 +1,24 @@ Network Working Group S. Hares Internet-Draft Huawei Intended status: Standards Track J. Jeong -Expires: October 25, 2018 J. Kim +Expires: January 3, 2019 J. Kim Sungkyunkwan University R. Moskowitz HTT Consulting Q. Lin Huawei - April 23, 2018 + July 02, 2018 I2NSF Capability YANG Data Model - draft-ietf-i2nsf-capability-data-model-00 + draft-ietf-i2nsf-capability-data-model-01 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). Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -27,21 +27,21 @@ 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 October 25, 2018. + This Internet-Draft will expire on January 3, 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 @@ -65,40 +65,43 @@ 5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7 5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7 5.6. Default Action Capabilities . . . . . . . . . . . . . . . 7 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.3. Action Capabilities . . . . . . . . . . . . . . . . . 14 - 6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 16 - 6.2.5. Default Action Capabilities . . . . . . . . . . . . . 17 - 6.2.6. RPC for Acquiring Appropriate Network Security + 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 . . . . . . . . . . . . . . . . . . . . . 53 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 - 12.2. Informative References . . . . . . . . . . . . . . . . . 55 + 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 Appendix A. Example: Extended VoIP-VoLTE Security Function - Capabilities Module . . . . . . . . . . . . . . . . 56 - Appendix B. Example: Configuration XML of Capability Module . . 57 + Capabilities Module . . . . . . . . . . . . . . . . 55 + Appendix B. Example: Configuration XML of Capability Module . . 56 B.1. Example: Configuration XML of Generic Network Security - Function Capabilities . . . . . . . . . . . . . . . . . . 57 + Function Capabilities . . . . . . . . . . . . . . . . . . 56 B.2. Example: Configuration XML of Extended VoIP/VoLTE - Security Function Capabilities Module . . . . . . . . . . 59 + Security Function Capabilities Module . . . . . . . . . . 58 + Appendix C. Changes from draft-ietf-i2nsf-capability-data- + model-01 . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 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). @@ -403,60 +406,53 @@ uses i2nsf-net-sec-caps Figure 3: Data Model Structure for Capabilities of Network Security Function 6.2.1. Event Capabilities The data model for event capabilities has the following structure: +--rw i2nsf-net-sec-caps - +--rw net-sec-capabilities* [nsc-capabilities-name] - +--rw nsc-capabilities-name string - +--rw rule-description? boolean - +--rw rule-rev? boolean - +--rw rule-priority? boolean + +--rw net-sec-capabilities +--rw time | +--rw time-zone - | | +--rw time-zone-offset boolean - | +--rw time-interval - | +--rw absolute-time-interval + | | +--rw time-zone-offset? boolean + | +--rw time-inteval + | +--rw absolute-time-inteval | | +--rw start-time? boolean | | +--rw end-time? boolean - | +--rw periodic-time-interval + | +--rw periodic-time-inteval | +--rw day? boolean | +--rw month? boolean +--rw event - | +--rw (event-type)? - | +--:(usr-event) - | | +--rw usr-manual? string + | +--rw usr-event | | +--rw usr-sec-event-content? boolean | | +--rw usr-sec-event-format | | | +--rw unknown? boolean | | | +--rw guid? boolean | | | +--rw uuid? boolean | | | +--rw uri? boolean | | | +--rw fqdn? boolean | | | +--rw fqpn? boolean | | +--rw usr-sec-event-type | | +--rw unknown? boolean | | +--rw user-created? boolean | | +--rw user-grp-created? boolean | | +--rw user-deleted? boolean | | +--rw user-grp-deleted? boolean | | +--rw user-logon? boolean | | +--rw user-logoff? boolean | | +--rw user-access-request? boolean | | +--rw user-access-granted? boolean | | +--rw user-access-violation? boolean - | +--:(dev-event) - | | +--rw dev-manual? string + | +--rw dev-event | | +--rw dev-sec-event-content boolean | | +--rw dev-sec-event-format | | | +--rw unknown? boolean | | | +--rw guid? boolean | | | +--rw uuid? boolean | | | +--rw uri? boolean | | | +--rw fqdn? boolean | | | +--rw fqpn? boolean | | +--rw dev-sec-event-type | | | +--rw unknown? boolean @@ -466,87 +462,78 @@ | | | +--rw equipment-err-alarm? boolean | | | +--rw environmental-err-alarm? boolean | | +--rw dev-sec-event-type-severity | | +--rw unknown? boolean | | +--rw cleared? boolean | | +--rw indeterminate? boolean | | +--rw critical? boolean | | +--rw major? boolean | | +--rw minor? boolean | | +--rw warning? boolean - | +--:(sys-event) - | | +--rw sys-manual? string + | +--rw sys-event | | +--rw sys-sec-event-content? boolean | | +--rw sys-sec-event-format | | | +--rw unknown? boolean | | | +--rw guid? boolean | | | +--rw uuid? boolean | | | +--rw uri? boolean | | | +--rw fqdn? boolean | | | +--rw fqpn? boolean | | +--rw sys-sec-event-type | | +--rw unknown? boolean | | +--rw audit-log-written-to? boolean | | +--rw audit-log-cleared? boolean | | +--rw policy-created? boolean | | +--rw policy-edited? boolean | | +--rw policy-deleted? boolean | | +--rw policy-executed? boolean - | +--:(time-event) - | +--rw time-manual? string + | +--rw time-event | +--rw time-sec-event-begin? boolean | +--rw time-sec-event-end? boolean | +--rw time-sec-event-time-zone? boolean +--rw condition | ... +--rw action | ... +--rw resolution-strategy - | ... - +--rw default-action ... Figure 4: Data Model Structure for Event Capabilities of Network Security Function These objects are defined as capabilities of user security event, device security event, system security event, and time security event. These objects can be extended according to specific vendor event features. We will add additional event objects for more generic network security functions. 6.2.2. Condition Capabilities The data model for condition capabilities has the following structure: +--rw i2nsf-net-sec-caps - +--rw net-sec-capabilities* [nsc-capabilities-name] - +--rw nsc-capabilities-name string - +--rw rule-description? boolean - +--rw rule-rev? boolean + +--rw net-sec-capabilities +--rw time | +--rw time-zone - | | +--rw time-zone-offset boolean - | +--rw time-interval - | +--rw absolute-time-interval + | | +--rw time-zone-offset? boolean + | +--rw time-inteval + | +--rw absolute-time-inteval | | +--rw start-time? boolean | | +--rw end-time? boolean - | +--rw periodic-time-interval + | +--rw periodic-time-inteval | +--rw day? boolean | +--rw month? boolean +--rw event | ... +--rw condition - | +--rw (condition-type)? - | +--:(packet-security-condition) - | | +--rw packet-manual? string + | +--rw packet-security-condition | | +--rw packet-security-mac-condition | | | +--rw pkt-sec-cond-mac-dest? boolean | | | +--rw pkt-sec-cond-mac-src? boolean | | | +--rw pkt-sec-cond-mac-8021q? boolean | | | +--rw pkt-sec-cond-mac-ether-type? boolean | | | +--rw pkt-sec-cond-mac-tci? string | | +--rw packet-security-ipv4-condition | | | +--rw pkt-sec-cond-ipv4-header-length? boolean | | | +--rw pkt-sec-cond-ipv4-tos? boolean | | | +--rw pkt-sec-cond-ipv4-total-length? boolean @@ -578,202 +565,229 @@ | | | +--rw pkt-sec-cond-tcp-window-size? boolean | | | +--rw pkt-sec-cond-tcp-flags? boolean | | +--rw packet-security-udp-condition | | | +--rw pkt-sec-cond-udp-src-port? boolean | | | +--rw pkt-sec-cond-udp-dest-port? boolean | | | +--rw pkt-sec-cond-udp-length? boolean | | +--rw packet-security-icmp-condition | | +--rw pkt-sec-cond-icmp-type? boolean | | +--rw pkt-sec-cond-icmp-code? boolean | | +--rw pkt-sec-cond-icmp-seg-num? boolean - | +--:(packet-payload-condition) - | | +--rw packet-payload-manual? string + | +--rw packet-payload-condition | | +--rw pkt-payload-content? boolean - | +--:(target-condition) - | | +--rw target-manual? string + | +--rw acl-number? boolean + | +--rw application-condition + | | +--rw application-object? boolean + | | +--rw application-group? boolean + | | +--rw application-label? boolean + | | +--rw category + | | +--rw application-category? boolean + | +--rw target-condition | | +--rw device-sec-context-cond? boolean - | +--:(users-condition) - | | +--rw users-manual? string + | +--rw users-condition | | +--rw user | | | +--rw (user-name)? | | | +--:(tenant) | | | | +--rw tenant? boolean | | | +--:(vn-id) | | | +--rw vn-id? boolean | | +--rw group | | +--rw (group-name)? - | | +--:(tenant) - | | | +--rw tenant? boolean - | | +--:(vn-id) - | | +--rw vn-id? boolean - | +--:(context-condition) - | | +--rw context-manual? string - | +--:(gen-context-condition) - | +--rw gen-context-manual? string + | | | +--:(tenant) + | | | | +--rw tenant? boolean + | | | +--:(vn-id) + | | | +--rw vn-id? boolean + | | +--rw security-grup boolean + | +--rw url-category-condition + | | +--rw pre-defined-category? boolean + | | +--rw user-defined-category? boolean + | +--rw context-condition + | | +--rw temp? string + | +--rw gen-context-condition | +--rw geographic-location | +--rw src-geographic-location? boolean | +--rw dest-geographic-location? boolean +--rw action | ... +--rw resolution-strategy - | ... - +--rw default-action ... Figure 5: Data Model Structure for Condition Capabilities of Network Security Function These objects are defined as capabilities of packet security condition, packet payload security condition, target security condition, user security condition, context condition, and generic context condition. These objects can be extended according to specific vendor condition features. We will add additional condition objects for more generic network security functions. 6.2.3. Action Capabilities The data model for action capabilities has the following structure: +--rw i2nsf-net-sec-caps - +--rw net-sec-capabilities* [nsc-capabilities-name] - +--rw nsc-capabilities-name string - +--rw rule-description? boolean - +--rw rule-rev? boolean - +--rw rule-priority? boolean + +--rw net-sec-capabilities +--rw time | +--rw time-zone - | | +--rw time-zone-offset boolean - | +--rw time-interval - | +--rw absolute-time-interval + | | +--rw time-zone-offset? boolean + | +--rw time-inteval + | +--rw absolute-time-inteval | | +--rw start-time? boolean | | +--rw end-time? boolean - | +--rw periodic-time-interval + | +--rw periodic-time-inteval | +--rw day? boolean | +--rw month? boolean +--rw event | ... +--rw condition | ... +--rw action - | +--rw (action-type)? - | +--:(ingress-action) - | | +--rw ingress-manual? string + | +--rw rule-log? boolean + | +--rw session-log? boolean + | +--rw ingress-action | | +--rw ingress-action-type | | +--rw pass? boolean | | +--rw drop? boolean | | +--rw reject? boolean | | +--rw alert? boolean | | +--rw mirror? boolean - | +--:(egress-action) - | +--rw egress-manual? string + | +--rw egress-action | +--rw egress-action-type | +--rw invoke-signaling? boolean | +--rw tunnel-encapsulation? boolean | +--rw forwarding? boolean | +--rw redirection? boolean +--rw resolution-strategy - | ... - +--rw default-action ... Figure 6: Data Model Structure for Action Capabilities of Network Security Function These objects are defined capabilities as ingress action, egress action, and apply profile action. These objects can be extended according to specific vendor action feature. We will add additional action objects for more generic network security functions. 6.2.4. Resolution Strategy Capabilities The data model for resolution strategy capabilities has the following structure: +--rw i2nsf-net-sec-caps - +--rw net-sec-capabilities* [nsc-capabilities-name] - +--rw nsc-capabilities-name string - +--rw rule-description? boolean - +--rw rule-rev? boolean - +--rw rule-priority? boolean + +--rw net-sec-capabilities +--rw time | +--rw time-zone - | | +--rw time-zone-offset boolean - | +--rw time-interval - | +--rw absolute-time-interval + | | +--rw time-zone-offset? boolean + | +--rw time-inteval + | +--rw absolute-time-inteval | | +--rw start-time? boolean | | +--rw end-time? boolean - | +--rw periodic-time-interval + | +--rw periodic-time-inteval | +--rw day? boolean | +--rw month? boolean +--rw event | ... +--rw condition | ... +--rw action | ... +--rw resolution-strategy - | +--rw first-matching-rule? boolean - | +--rw last-matching-rule? boolean - +--rw default-action - ... + +--rw first-matching-rule? boolean + +--rw last-matching-rule? boolean 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. Default Action Capabilities +6.2.5. Content Security Capabilities - The data model for default action capabilities has the following + The data model for content security capabilities has the following structure: - +--rw i2nsf-net-sec-caps - +--rw net-sec-capabilities* [nsc-capabilities-name] - +--rw nsc-capabilities-name string - +--rw rule-description? boolean - +--rw rule-rev? boolean - +--rw rule-priority? boolean - +--rw time - | +--rw time-zone - | | +--rw time-zone-offset boolean - | +--rw time-interval - | +--rw absolute-time-interval - | | +--rw start-time? boolean - | | +--rw end-time? boolean - | +--rw periodic-time-interval - | +--rw day? boolean - | +--rw month? boolean - +--rw event - | ... - +--rw condition - | ... - +--rw action - | ... - +--rw resolution-strategy - | ... - +--rw default-action - +--rw default-action-type - +--rw ingress-action-type - +--rw pass? boolean - +--rw drop? boolean - +--rw reject? boolean - +--rw alert? boolean - +--rw mirror? boolean + +--rw complete-nsf-capabilities + +--rw con-sec-control-capabilities + | +--rw anti-virus? boolean + | +--rw ips? boolean + | +--rw ids? boolean + | +--rw url-filter? boolean + | +--rw data-filter? boolean + | +--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 Default Action Capabilities of + Figure 8: Data Model Structure for Content Security Capabilities of Network Security Function -6.2.6. RPC for Acquiring Appropriate 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 + + 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)? + | +--:(network-layer-ddos-attack) + | | +--rw network-layer-ddos-attack-types + | | +--rw syn-flood-attack? boolean + | | +--rw udp-flood-attack? boolean + | | +--rw icmp-flood-attack? boolean + | | +--rw ip-fragment-flood-attack? boolean + | | +--rw ipv6-related-attack? boolean + | +--:(app-layer-ddos-attack) + | +--rw app-layer-ddos-attack-types + | +--rw http-flood-attack? boolean + | +--rw https-flood-attack? boolean + | +--rw dns-flood-attack? boolean + | +--rw dns-amp-flood-attack? boolean + | +--rw ssl-flood-attack? boolean + +--:(single-packet-attack) + +--rw (single-packet-attack-type)? + +--:(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 + 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 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 @@ -783,38 +797,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 9: RPC for Acquiring Appropriate Network Security Function + Figure 10: 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-03-23.yang" + file "ietf-i2nsf-capability@2018-07-02.yang" module ietf-i2nsf-capability { namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; prefix i2nsf-capability; import ietf-inet-types{ prefix inet; } @@ -838,21 +852,21 @@ Editor: Jaehoon Paul Jeong Editor: Jinyong Tim Kim "; description "This module describes a capability model for I2NSF devices."; - revision "2018-03-23"{ + revision "2018-07-02"{ description "The fifth revision"; reference "draft-ietf-i2nsf-capability-00"; } grouping i2nsf-nsf-location { description "This provides a location for capabilities."; container nsf-address { description @@ -976,46 +990,23 @@ description "This is type of NSF."; } uses i2nsf-nsf-location; uses i2nsf-it-resources; } grouping i2nsf-net-sec-caps { description "i2nsf-net-sec-caps"; - list net-sec-capabilities { - key "nsc-capabilities-name"; + container net-sec-capabilities { description "net-sec-capabilities"; - leaf nsc-capabilities-name { - type string; - mandatory true; - description - "nsc-capabilities-name"; - } - - leaf rule-description { - type boolean; - description - "This is rule-description."; - } - leaf rule-rev { - type boolean; - description - "This is rule-revision"; - } - leaf rule-priority { - type boolean; - description - "This is rule-priority"; - } container time { description "This is capabilities for time"; container time-zone { description "This can be used to apply rules according to time zone"; leaf time-zone-offset { @@ -1068,33 +1059,22 @@ " This is abstract. An event is defined as any important occurrence in time of a change in the system being managed, and/or in the environment of the system being managed. When used in the context of policy rules for a flow-based NSF, it is used to determine whether the Condition clause of the Policy Rule can be evaluated or not. Examples of an I2NSF event include time and user actions (e.g., logon, logoff, and actions that violate any ACL.)."; - choice event-type { - description - "Vendors can use YANG data model to configure rules - by concreting this event type"; - case usr-event { - leaf usr-manual { - type string; - description - "This is manual for user event. - Vendors can write instructions for user event - that vendor made"; - } - + container usr-event { + description "TBD"; leaf usr-sec-event-content { type boolean; description "This is a mandatory string that contains the content of the UserSecurityEvent. The format of the content is specified in the usrSecEventFormat class attribute, and the type of event is defined in the usrSecEventType class attribute. An example of the usrSecEventContent attribute is a string hrAdmin, with the usrSecEventFormat set to 1 (GUID) and the @@ -1214,28 +1196,22 @@ this user. The content and format are specified in the usrSecEventContent and usrSecEventFormat class attributes, respectively. An example of the usrSecEventContent attribute is string hrAdmin, with the usrSecEventFormat attribute set to 1 (GUID) and the usrSecEventType attribute set to 5 (new logon)."; } } - case dev-event { - leaf dev-manual { - type string; - description - "This is manual for device event. - Vendors can write instructions for device event - that vendor made"; - } + container dev-event { + description "TBD"; leaf dev-sec-event-content { type boolean; mandatory true; description "This is a mandatory string that contains the content of the DeviceSecurityEvent. The format of the content is specified in the devSecEventFormat class attribute, and the type of event is defined in the devSecEventType class attribute. An example of the @@ -1368,29 +1344,22 @@ description "If devSecEventTypeSeverity is minor"; } leaf warning { type boolean; description "If devSecEventTypeSeverity is warning"; } } } - case sys-event { - leaf sys-manual { - type string; - description - "This is manual for system event. - Vendors can write instructions for system event - that vendor made"; - } - + container sys-event { + description "TBD"; leaf sys-sec-event-content { type boolean; description "This is a mandatory string that contains a content of the SystemSecurityEvent. The format of a content is specified in a sysSecEventFormat class attribute, and the type of event is defined in the sysSecEventType class attribute. An example of the sysSecEventContent attribute is string sysadmin3, with the sysSecEventFormat attribute set to 1(GUID), @@ -1483,28 +1453,23 @@ is that policy is deleted"; } leaf policy-executed{ type boolean; description "If sysSecEventTypeSeverity is that policy is executed"; } } } - case time-event { - leaf time-manual { - type string; - description - "This is manual for time event. - Vendors can write instructions for time event - that vendor made"; - } + container time-event { + description "TBD"; + leaf time-sec-event-begin { type boolean; description "This is a mandatory DateTime attribute, and represents the beginning of a time period. It has a value that has a date and/or a time component (as in the Java or Python libraries)."; } leaf time-sec-event-end { @@ -1520,47 +1485,36 @@ } leaf time-sec-event-time-zone { type boolean; description "This is a mandatory string attribute, and defines a time zone that this event occurred in using the format specified in ISO8601."; } } - } + } container condition { description " This is abstract. A condition is defined as a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether or not the set of Actions in that (imperative) I2NSF Policy Rule can be executed or not. Examples of I2NSF Conditions include matching attributes of a packet or flow, and comparing the internal state of an NSF to a desired state."; - choice condition-type { - description - "Vendors can use YANG data model to configure rules - by concreting this condition type"; - - case packet-security-condition { - leaf packet-manual { - type string; - description - "This is manual for packet condition. - Vendors can write instructions for packet condition - that vendor made"; - } + container packet-security-condition { + description "TBD"; container packet-security-mac-condition { description "The purpose of this Class is to represent packet MAC packet header information that can be used as part of a test to determine if the set of Policy Actions in this ECA Policy Rule should be execute or not."; leaf pkt-sec-cond-mac-dest { type boolean; @@ -1838,28 +1795,28 @@ } } container packet-security-udp-condition { description "The purpose of this Class is to represent packet UDP packet header information that can be used as part of a test to determine if the set of Policy Actions in this ECA Policy Rule should be executed or not."; - leaf-list pkt-sec-cond-udp-src-port { + leaf pkt-sec-cond-udp-src-port { type boolean; description "This is a mandatory string attribute, and defines the UDP Source Port number (16 bits)."; } - leaf-list pkt-sec-cond-udp-dest-port { + leaf pkt-sec-cond-udp-dest-port { type boolean; description "This is a mandatory string attribute, and defines the UDP Destination Port number (16 bits)."; } leaf pkt-sec-cond-udp-length { type boolean; description "This is a mandatory string attribute, and defines @@ -1884,64 +1842,83 @@ } leaf pkt-sec-cond-icmp-seg-num { type boolean; description "The icmp Sequence Number."; } } } - case packet-payload-condition { - leaf packet-payload-manual { - type string; - description - "This is manual for payload condition. - Vendors can write instructions for payload condition - that vendor made"; - } + container packet-payload-condition { + description "TBD"; leaf pkt-payload-content { type boolean; description "The content keyword is very important in signatures. Between the quotation marks you can write on what you would like the signature to match."; } } - case target-condition { - leaf target-manual { - type string; + leaf acl-number { + type boolean; description - "This is manual for target condition. - Vendors can write instructions for target condition - that vendor made"; + "This is acl-number."; + } + + container application-condition { + description + "TBD"; + + leaf application-object { + type boolean; + description + "This is application object."; + } + leaf application-group { + type boolean; + description + "This is application group."; + + } + leaf application-label { + type boolean; + description + "This is application label."; + } + container category { + description + "TBD"; + leaf application-category { + type boolean; + description + "TBD"; } + } + } + + container target-condition { + description "TBD"; leaf device-sec-context-cond { type boolean; description "The device attribute that can identify a device, including the device type (i.e., router, switch, pc, ios, or android) and the device's owner as well."; } } - case users-condition { - leaf users-manual { - type string; - description - "This is manual for user condition. - Vendors can write instructions for user condition - that vendor made"; - } + container users-condition { + description "TBD"; container user{ description "The user (or user group) information with which network flow is associated: The user has many attributes such as name, id, password, type, authentication mode and so on. Name/id is often used in the security policy to identify the user. Besides, NSF is aware of the IP address of the user provided by a unified user management system @@ -2009,40 +1987,55 @@ description "VN-ID information."; leaf vn-id { type boolean; description "User's VN-ID information."; } } } + leaf security-grup { + type boolean; + mandatory true; + description + "security-grup."; + } + } } + container url-category-condition { + description + "TBD"; + leaf pre-defined-category { + type boolean; + description + "This is pre-defined-category."; } - case context-condition { - leaf context-manual { - type string; + leaf user-defined-category { + type boolean; description - "This is manual for context condition. - Vendors can write instructions for context condition - that vendor made"; + "This user-defined-category."; } } - case gen-context-condition { - leaf gen-context-manual { + + container context-condition { + description "TBD"; + leaf temp { type string; description - "This is manual for generic context condition. - Vendors can write instructions for generic context - condition that vendor made"; + "This is temp for context condition."; + + } } + container gen-context-condition { + description "TBD"; container geographic-location { description "The location where network traffic is associated with. The region can be the geographic location such as country, province, and city, as well as the logical network location such as IP address, network section, and network domain."; leaf src-geographic-location { @@ -2053,46 +2046,46 @@ database."; } leaf dest-geographic-location { type boolean; description "This is mapped to ip address. We can acquire destination region through ip address stored the database."; } } - - } } } container action { description "An action is used to control and monitor aspects of flow-based NSFs when the event and condition clauses are satisfied. NSFs provide security functions by executing various Actions. Examples of I2NSF Actions include providing intrusion detection and/or protection, web and flow filtering, and deep packet inspection for packets and flows."; - choice action-type { + leaf rule-log { + type boolean; description - "Vendors can use YANG data model to configure rules - by concreting this action type"; - case ingress-action { - leaf ingress-manual { - type string; + "rule-log"; + } + leaf session-log { + type boolean; description - "This is manual for ingress action. - Vendors can write instructions for ingress action - that vendor made"; + "session-log"; } + + container ingress-action { + description "TBD"; + container ingress-action-type { description "Ingress action type: permit, deny, and mirror."; leaf pass { type boolean; description "If ingress action is pass"; } leaf drop { type boolean; @@ -2101,37 +2094,31 @@ } leaf reject { type boolean; description "If ingress action is reject"; } leaf alert { type boolean; description "If ingress action is alert"; - } leaf mirror { type boolean; description "If ingress action is mirror"; } } } - case egress-action { - leaf egress-manual { - type string; - description - "This is manual for egress action. - Vendors can write instructions for egress action - that vendor made"; - } + container egress-action { + description "TBD"; + container egress-action-type { description "Egress-action-type: invoke-signaling, tunnel-encapsulation, and forwarding."; leaf invoke-signaling { type boolean; description "If egress action is invoke signaling"; } leaf tunnel-encapsulation { @@ -2144,84 +2131,41 @@ description "If egress action is forwarding"; } leaf redirection { type boolean; description "If egress action is redirection"; } } } - } + } container resolution-strategy { description "The resolution strategies can be used to specify how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF"; leaf first-matching-rule { type boolean; description "If the resolution strategy is first matching rule"; } leaf last-matching-rule { type boolean; description "If the resolution strategy is last matching rule"; } } - container default-action { - description - "This default action can be used to specify a predefined - action when no other alternative action was matched - by the currently executing I2NSF Policy Rule. An analogy - is the use of a default statement in a C switch statement."; - - container default-action-type { - description - "Ingress action type: permit, deny, and mirror."; - - container ingress-action-type { - description - "Ingress action type: permit, deny, and mirror."; - leaf pass { - type boolean; - description - "If ingress action is pass"; - } - leaf drop { - type boolean; - description - "If ingress action is drop"; - } - leaf reject { - type boolean; - description - "If ingress action is reject"; - } - leaf alert { - type boolean; - description - "If ingress action is alert"; - - } - leaf mirror { - type boolean; - description - "If ingress action is mirror"; - } - } - } - } } } grouping i2nsf-con-sec-control-caps { description "i2nsf-con-sec-control-caps"; container con-sec-control-capabilities { description "content-security-control-capabilities"; @@ -2435,26 +2378,36 @@ list nsf { key "nsf-name"; description "nsf-name"; leaf nsf-name { type string; mandatory true; description "nsf-name"; } + uses capabilities-information; + container generic-nsf-capabilities { description "generic-nsf-capabilities"; uses i2nsf-net-sec-caps; } + + container complete-nsf-capabilities { + description + "generic-nsf-capabilities"; + uses i2nsf-con-sec-control-caps; + uses i2nsf-attack-mitigation-control-caps; + } + } rpc call-appropriate-nsf { description "We can acquire appropriate NSF that we want If we give type of NSF that we want to use, we acquire the location information of NSF"; input { leaf nsf-type { @@ -2467,21 +2420,21 @@ uses i2nsf-it-resources; } output { uses i2nsf-nsf-location; } } } - Figure 10: YANG Data Module of I2NSF Capability + Figure 11: 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]. @@ -2625,21 +2578,21 @@ leaf sip-header-user-agent { type boolean; description "SIP header user agent."; } } } } - Figure 11: Example: Extended VoIP-VoLTE Security Function + Figure 12: 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 @@ -2702,28 +2655,28 @@ true - Figure 12: Example: Configuration XML for Generic Network Security + Figure 13: 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 11) configuration according to a + function capabilities (See Figure 12) 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. @@ -2761,23 +2714,45 @@ true - Figure 13: Example: Configuration XML for Extended VoIP/VoLTE + Figure 14: 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: + + 1. We have clarified and simplified capabilities. + + 2. We added additional condition capabilities for application and + url. + + 3. We replaced unnecessary leaf-list component to leaf component. + + 4. We replaced the list component to the container component for + net-sec-capabilities. + + 5. We modified the choice-case structure into a container structure + to allow for the selection of multiple catalogues for condition + and action clauses. + + 6. We added complete-nsf-capabilities such as content capabilities + and attack mitigation capabilities. + Authors' Addresses Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Phone: +1-734-604-0332 EMail: shares@ndzh.com