draft-ietf-i2nsf-consumer-facing-interface-dm-11.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-12.txt 
I2NSF Working Group J. Jeong, Ed. I2NSF Working Group J. Jeong, Ed.
Internet-Draft C. Chung Internet-Draft C. Chung
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: March 10, 2021 T. Ahn Expires: March 12, 2021 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
September 6, 2020 September 8, 2020
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-11 draft-ietf-i2nsf-consumer-facing-interface-dm-12
Abstract Abstract
This document describes an information model and a YANG data model This document describes an information model and a YANG data model
for the Consumer-Facing Interface between an Interface to Network for the Consumer-Facing Interface between an Interface to Network
Security Functions (I2NSF) User and Security Controller in an I2NSF Security Functions (I2NSF) User and Security Controller in an I2NSF
system in a Network Functions Virtualization (NFV) environment. The system in a Network Functions Virtualization (NFV) environment. The
information model defines various types of managed objects and the information model defines various types of managed objects and the
relationship among them needed to build the interface. The relationship among them needed to build the interface. The
information model is based on the "Event-Condition-Action" (ECA) information model is based on the "Event-Condition-Action" (ECA)
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 10, 2021. This Internet-Draft will expire on March 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13
5. Information Model for Threat Prevention . . . . . . . . . . . 14 5. Information Model for Threat Prevention . . . . . . . . . . . 14
5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15 5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15
6. Network Configuration Access Control Model (NACM) for I2NSF 6. Network Configuration Access Control Model (NACM) for I2NSF
Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16
7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18 7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18
7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18 7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18
8. XML Configuration Examples of High-Level Security Policy 8. XML Configuration Examples of High-Level Security Policy
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Database Registration: Information of Positions and 8.1. Database Registration: Information of Positions and
Devices (Endpoint Group) . . . . . . . . . . . . . . . . 42 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41
8.2. Scenario 1: Block SNS Access during Business Hours . . . 44 8.2. Scenario 1: Block SNS Access during Business Hours . . . 43
8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
a Company . . . . . . . . . . . . . . . . . . . . . . . . 46 a Company . . . . . . . . . . . . . . . . . . . . . . . . 45
8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
Company Web Server . . . . . . . . . . . . . . . . . . . 48 Company Web Server . . . . . . . . . . . . . . . . . . . 47
9. XML Configuration Example of a User Group's Access Control 9. XML Configuration Example of a User Group's Access Control
for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 49 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . 54 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . 56 14.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
In a framework of Interface to Network Security Functions (I2NSF) In a framework of Interface to Network Security Functions (I2NSF)
[RFC8329], each vendor can register their NSFs using a Developer's [RFC8329], each vendor can register their NSFs using a Developer's
Management System (DMS). Assuming that vendors also provide the Management System (DMS). Assuming that vendors also provide the
front-end web applications registered with an I2NSF User, the front-end web applications registered with an I2NSF User, the
Consumer-Facing Interface is required because the web applications Consumer-Facing Interface is required because the web applications
developed by each vendor need to have a standard interface specifying developed by each vendor need to have a standard interface specifying
the data types used when the I2NSF User and Security Controller the data types used when the I2NSF User and Security Controller
skipping to change at page 5, line 10 skipping to change at page 5, line 10
in the NFV system. By the efficient virtualization technology, these in the NFV system. By the efficient virtualization technology, these
VNFs might be automatically provisioned and dynamically migrated VNFs might be automatically provisioned and dynamically migrated
based on real-time security requirements. This document presents a based on real-time security requirements. This document presents a
YANG data model to implement security functions based on NFV. YANG data model to implement security functions based on NFV.
2. Terminology 2. Terminology
This document uses the terminology described in [RFC8329]. This document uses the terminology described in [RFC8329].
This document follows the guidelines of [RFC8407], uses the common This document follows the guidelines of [RFC8407], uses the common
YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the YANG types defined in [RFC6991], and adopts the Network Management
Network Management Datastore Architecture (NMDA). The meaning of the Datastore Architecture (NMDA). The meaning of the symbols in tree
symbols in tree diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
3. Information Model for Policy 3. Information Model for Policy
A Policy object represents a mechanism to express a Security Policy A Policy object represents a mechanism to express a Security Policy
by Security Administrator (i.e., I2NSF User) using Consumer-Facing by Security Administrator (i.e., I2NSF User) using Consumer-Facing
Interface toward Security Controller; the policy would be enforced on Interface toward Security Controller; the policy would be enforced on
an NSF. Figure 2 shows the YANG tree of the Policy object. The an NSF. Figure 2 shows the YANG tree of the Policy object. The
Policy object SHALL have the following information: Policy object SHALL have the following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
skipping to change at page 18, line 32 skipping to change at page 18, line 32
policies as well as the implementation approach. policies as well as the implementation approach.
With the YANG data model of I2NSF Consumer-Facing Interface, this With the YANG data model of I2NSF Consumer-Facing Interface, this
document suggests use cases for security policy rules such as time- document suggests use cases for security policy rules such as time-
based firewall, VoIP/VoLTE security service, and DDoS-attack based firewall, VoIP/VoLTE security service, and DDoS-attack
mitigation in Section 8. mitigation in Section 8.
7.1. YANG Module of Consumer-Facing Interface 7.1. YANG Module of Consumer-Facing Interface
This section describes a YANG module of Consumer-Facing Interface. This section describes a YANG module of Consumer-Facing Interface.
This YANG module imports from [I-D.ietf-netmod-rfc6991-bis]. It This YANG module imports from [RFC6991]. It makes references to [RFC
makes references to [RFC0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC 0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][
2616][RFC2818][RFC4250][RFC5321]. RFC5321].
<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-09-06.yang" <CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-09-08.yang"
module ietf-i2nsf-cfi-policy { module ietf-i2nsf-cfi-policy {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy";
prefix nsfcfi; prefix nsfcfi;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
} }
skipping to change at page 19, line 40 skipping to change at page 19, line 40
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
http://trustee.ietf.org/license-info). http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with an actual RFC number and remove // RFC Ed.: replace XXXX with an actual RFC number and remove
// this note. // this note.
revision "2020-09-06"{ revision "2020-09-08"{
description "Initial revision."; description "Initial revision.";
reference reference
"RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model";
// RFC Ed.: replace XXXX with an actual RFC number and remove // RFC Ed.: replace XXXX with an actual RFC number and remove
// this note. // this note.
} }
identity malware-file-type { identity malware-file-type {
description description
skipping to change at page 27, line 39 skipping to change at page 27, line 39
* Typedefs * Typedefs
*/ */
typedef time { typedef time {
type string { type string {
pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'
+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
} }
description description
"The time type represents an instance of time of zero-duration "The time type represents an instance of time of zero-duration
that recurs every day."; that recurs every day.";
reference
"RFC 6991-bis: Common YANG Data Types - typedef time is used.";
// RFC Ed.: When RFC 6991-bis becomes an RFC, remove 'typedef time'
// this note.
} }
/* /*
* Groupings * Groupings
*/ */
grouping ipv4-list { grouping ipv4-list {
description description
"Grouping for an IPv4 address list."; "Grouping for an IPv4 address list.";
leaf-list ipv4 { leaf-list ipv4 {
skipping to change at page 34, line 47 skipping to change at page 34, line 42
} }
container period{ container period{
when when
"../../frequency!='only-once'"; "../../frequency!='only-once'";
description description
"This represents the repetition time. In the case where "This represents the repetition time. In the case where
the frequency is weekly, the days can be set."; the frequency is weekly, the days can be set.";
leaf start-time { leaf start-time {
type time; type time;
// RFC Ed.: When RFC 6991-bis becomes an RFC, time must
// be replaced with yang:time.
// this note.
description description
"This is a period's start time for an event."; "This is a period's start time for an event.";
reference
"RFC 6991-bis: Common YANG Data Types - The time type
represents an instance of time of zero-duration that
recurs every day.";
// RFC Ed.: Replace 6991-bis with an actual RFC number
// and remove this note.
} }
leaf end-time { leaf end-time {
type time; type time;
// RFC Ed.: When RFC 6991-bis becomes an RFC, time must
// be replaced with yang:time.
// this note.
description description
"This is a period's end time for an event."; "This is a period's end time for an event.";
reference
"RFC 6991-bis: Common YANG Data Types - The time type
represents an instance of time of zero-duration that
recurs every day.";
// RFC Ed.: Replace 6991-bis with an actual RFC number
// and remove this note.
} }
leaf-list day { leaf-list day {
when when
"../../../frequency='weekly'"; "../../../frequency='weekly'";
type identityref{ type identityref{
base day; base day;
} }
min-elements 1; min-elements 1;
description description
"This represents the repeated day of every week (e.g., "This represents the repeated day of every week (e.g.,
skipping to change at page 54, line 14 skipping to change at page 53, line 14
101 Software Avenue 101 Software Avenue
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
EMail: Frank.Xialiang@huawei.com EMail: Frank.Xialiang@huawei.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-netmod-rfc6991-bis]
Schoenwaelder, J., "Common YANG Data Types", draft-ietf-
netmod-rfc6991-bis-04 (work in progress), July 2020.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
1983, <https://www.rfc-editor.org/info/rfc854>. 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913, [RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913,
DOI 10.17487/RFC0913, September 1984, DOI 10.17487/RFC0913, September 1984,
<https://www.rfc-editor.org/info/rfc913>. <https://www.rfc-editor.org/info/rfc913>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
skipping to change at page 55, line 47 skipping to change at page 54, line 43
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
 End of changes. 20 change blocks. 
58 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/