draft-ietf-i2nsf-consumer-facing-interface-dm-04.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-05.txt 
I2NSF Working Group J. Jeong I2NSF Working Group J. Jeong
Internet-Draft E. Kim Internet-Draft E. Kim
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: October 6, 2019 T. Ahn Expires: December 14, 2019 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
April 4, 2019 June 12, 2019
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-04 draft-ietf-i2nsf-consumer-facing-interface-dm-05
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 managed objects and relationship information model defines various types of managed objects and the
among these objects needed to build the interface. The information relationship among them needed to build the interface. The
model is organized based on the "Event-condition-Event" (ECA) policy information model is organized based on the "Event-Condition-Action"
model defined by a capability information model for Interface to (ECA) policy model defined by a capability information model for
Network Security Functions (I2NSF)[i2nsf-capability-im], and the data I2NSF [i2nsf-capability-im], and the data model is defined for
model is defined for enabling different users of a given I2NSF system enabling different users of a given I2NSF system to define, manage,
to define, manage, and monitor security policies for specific flows and monitor security policies for specific flows within an
within an administrative domain. administrative domain.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 6, 2019. This Internet-Draft will expire on December 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 35 skipping to change at page 2, line 35
4. Information Model for Policy . . . . . . . . . . . . . . . . 5 4. Information Model for Policy . . . . . . . . . . . . . . . . 5
4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7 4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7
4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 7 4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 7
4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9 4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9
5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 10 5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 10
5.1. Policy Domain . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Policy Domain . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Policy Tenant . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Policy Tenant . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Policy Role . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Policy Role . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Policy User . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Policy User . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Policy Management Authentication Method . . . . . . . . . 13 5.5. Policy Management Authentication Method . . . . . . . . . 13
6. Information Model for Policy Endpoint Groups . . . . . . . . 14 6. Information Model for Policy Endpoint Groups . . . . . . . . 15
6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Location Group . . . . . . . . . . . . . . . . . . . . . 16 6.3. Location Group . . . . . . . . . . . . . . . . . . . . . 17
7. Information Model for Threat Prevention . . . . . . . . . . . 17 7. Information Model for Threat Prevention . . . . . . . . . . . 17
7.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 19 7.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 19
8. Role-based Acess Control (RBAC) . . . . . . . . . . . . . . . 19 8. Role-based Acess Control (RBAC) . . . . . . . . . . . . . . . 19
9. YANG Data Model for Security Policies for Consumer-Facing 9. YANG Data Model for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Example XML Output for Various Scenarios . . . . . . . . . . 38 10. Example XML Output for Various Scenarios . . . . . . . . . . 38
10.1. DB Registration: Information of Positions and Devices 10.1. DB Registration: Information of Positions and Devices
(Endpoint Group) . . . . . . . . . . . . . . . . . . . . 39 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 39
10.2. Scenario 1: Block SNS Access during Business Hours . . . 39 10.2. Scenario 1: Block SNS Access during Business Hours . . . 39
skipping to change at page 3, line 11 skipping to change at page 3, line 11
a Company . . . . . . . . . . . . . . . . . . . . . . . 41 a Company . . . . . . . . . . . . . . . . . . . . . . . 41
10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
Company Web Server . . . . . . . . . . . . . . . . . . . 42 Company Web Server . . . . . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-03 . . . . . . . . . . . . . . . . . . 47 interface-dm-04 . . . . . . . . . . . . . . . . . . 47
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 47 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 47
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
In an I2NSF framework, each vendor can register their NSFs using a In an I2NSF framework, each vendor can register their NSFs using a
Developer's Management System (DMS). Assuming that vendors also Developer's Management System (DMS). Assuming that vendors also
provide the front-end web applications registered with an I2NSF User, provide the front-end web applications registered with an I2NSF User,
the Consumer-Facing Interface is required because the web the Consumer-Facing Interface is required because the web
skipping to change at page 3, line 39 skipping to change at page 3, line 39
These policies can easily be translated by the Security Controller These policies can easily be translated by the Security Controller
into low-level security policies. The Security Controller delivers into low-level security policies. The Security Controller delivers
the translated policies to Network Security Functions (NSFs) the translated policies to Network Security Functions (NSFs)
according to their respective security capabilities for the required according to their respective security capabilities for the required
securiy enforcement. securiy enforcement.
The Consumer-Facing Interface would be built using a set of objects, The Consumer-Facing Interface would be built using a set of objects,
with each object capturing a unique set of information from Security with each object capturing a unique set of information from Security
Administrator (i.e., I2NSF User [RFC8329]) needed to express a Administrator (i.e., I2NSF User [RFC8329]) needed to express a
Security Policy. An object may have relationship with various other Security Policy. An object may have relationship with various other
objects to express a complete set of requirement. An information objects to express a complete set of requirements. An information
model captures the managed objects and relationship among these model captures the managed objects and relationship among these
objects. The information model proposed in this document is objects. The information model proposed in this document is
structured in accordance with the "Event-Condition-Event" (ECA) structured in accordance with the "Event-Condition-Action" (ECA)
policy model. policy model.
An NSF Capability model is proposed in [i2nsf-capability-im] as the An NSF Capability model is proposed in [i2nsf-capability-im] as the
basic model for both the NSF-Facing interface and Consumer-Facing basic model for both the NSF-Facing interface and Consumer-Facing
Interface security policy model of this document. Interface security policy model of this document.
[RFC3444] explains differences between an information and data model. [RFC3444] explains differences between an information and data model.
This document use the guidelines in [RFC3444] to define both the This document uses the guidelines in [RFC3444] to define both the
information and data model for Consumer-Facing Interface. Figure 1 information and data model for Consumer-Facing Interface. Figure 1
shows a high-level abstraction of Consumer-Facing Interface. A data shows a high-level abstraction of Consumer-Facing Interface. A data
model, which represents an implementation of the information model in model, which represents an implementation of the information model in
a specific data representation language, is also defined in this a specific data representation language, is also defined in this
document. document.
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Consumer-Facing | | Consumer-Facing | | Consumer-Facing | | Consumer-Facing |
| Interface +--->+ Interface | | Interface +--->+ Interface |
|Information Model| | Data Model | |Information Model| | Data Model |
skipping to change at page 4, line 42 skipping to change at page 4, line 42
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
Figure 1: Diagram for High-level Abstraction of Consumer-Facing Figure 1: Diagram for High-level Abstraction of Consumer-Facing
Interface Interface
Data models are defined at a lower level of abstraction and provide Data models are defined at a lower level of abstraction and provide
many details. They provide details about the implementation of a many details. They provide details about the implementation of a
protocol's specification, e.g., rules that explain how to map managed protocol's specification, e.g., rules that explain how to map managed
objects onto lower-level protocol constructs. Since conceptual objects onto lower-level protocol constructs. Since conceptual
models can be implemented in different ways, multiple data models can models can be implemented in different ways, multiple data models can
be derived by a single information model. be derived from a single information model.
The efficient and flexible provisioning of network functions by a The efficient and flexible provisioning of network functions by a
Network Functions Virtualization (NFV) system leads to a rapid Network Functions Virtualization (NFV) system leads to a rapid
advance in the network industry. As practical applications, Network advance in the network industry. As practical applications, Network
Security Functions (NSFs), such as firewall, Intrusion Detection Security Functions (NSFs), such as firewall, Intrusion Detection
System (IDS)/Intrusion Prevention System (IPS), and attack System (IDS)/Intrusion Prevention System (IPS), and attack
mitigation, can also be provided as Virtual Network Functions (VNF) mitigation, can also be provided as Virtual Network Functions (VNF)
in the NFV system. By the efficient virtual technology, these VNFs in the NFV system. By the efficient virtualization technology, these
might be automatically provisioned and dynamically migrated based on VNFs might be automatically provisioned and dynamically migrated
real-time security requirements. This document presents a YANG data based on real-time security requirements. This document presents a
model to implement security functions based on NFV. YANG data model to implement security functions based on NFV.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "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]. RFC8174 [RFC8174].
3. Terminology 3. Terminology
skipping to change at page 5, line 31 skipping to change at page 5, line 31
YANG types defined in [RFC6991], and adopts the Network Management YANG types defined in [RFC6991], and adopts the Network Management
Datastore Architecture (NMDA). The meaning of the symbols in tree Datastore Architecture (NMDA). The meaning of the symbols in tree
diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
4. Information Model for Policy 4. 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 XML instance of the Policy object. The an NSF. Figure 2 shows the XML instance of the Policy object. The
Policy object SHALL have 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.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
Rules: This field contains a list of rules. If the rule does not Rules: This field contains a list of rules. If the rule does not
have a user-defined precedence, then any conflict must be have a user-defined precedence, then any conflict must be
manually resolved. manually resolved.
+--rw policy +--rw policy
skipping to change at page 6, line 32 skipping to change at page 6, line 32
Condition: This field contains all the checking conditions to Condition: This field contains all the checking conditions to
apply to the objective traffic. See details in apply to the objective traffic. See details in
Section 4.2. Section 4.2.
Action: This field identifies the action taken when a rule is Action: This field identifies the action taken when a rule is
matched. There is always an implicit action to drop matched. There is always an implicit action to drop
traffic if no rule is matched for a traffic type. See traffic if no rule is matched for a traffic type. See
details in Section 4.3. details in Section 4.3.
IPsec: This field contains the information about IPsec type. IPsec-Method: This field contains the information about IPsec
There are two types such as IPsec-IKE and IPsec-IKEless method type. There are two types such as IPsec-IKE and
[i2nsf-ipsec]. IPsec-IKEless. [i2nsf-ipsec].
Owner: This field contains the onwer of the rule. For example, Owner: This field contains the onwer of the rule. For example,
the person who created it, and eligible for modifying it. the person who created it, and eligible for modifying it.
+--rw rule* [rule-name] +--rw rule* [rule-name]
+--rw rule-name string +--rw rule-name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw event* [name] +--rw event* [name]
+--rw condition +--rw condition
+--rw action +--rw action
+--rw ipsec +--rw ipsec-method
+--rw owner? string +--rw owner? string
Figure 3: YANG Data Tree for Rule Figure 3: YANG Data Tree for Rule
4.1. Event Sub-model 4.1. Event Sub-model
The Event Object contains information related to scheduling a Rule. The Event Object contains information related to scheduling a Rule.
The Rule could be activated based on a time calendar or security The Rule could be activated based on a time calendar or security
event including threat level changes. Figure 4 shows the XML event including threat level changes. Figure 4 shows the XML
instance of the Event object. Event object SHALL have following instance of the Event object. Event object SHALL have following
skipping to change at page 7, line 45 skipping to change at page 7, line 45
+--rw recur boolean +--rw recur boolean
+--rw recursive-type? enumeration +--rw recursive-type? enumeration
Figure 4: Event Sub-model YANG Data Tree Figure 4: Event Sub-model YANG Data Tree
4.2. Condition Sub-model 4.2. Condition Sub-model
This object represents Conditions that Security Administrator wants This object represents Conditions that Security Administrator wants
to apply the checking on the traffic in order to determine whether 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 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 Sub-model consists of three different types of containers each
representing different cases, such as general firewall and DDoS- representing different cases, such as general firewall and DDoS-
mitigation cases, and a case when the condition is based on the mitigation cases, and a case when the condition is based on the
payload strings of packets. Each containers have source-target and payload strings of packets. Each containers have source-target and
destination-target to represent the source and destination for each destination-target to represent the source and destination for each
case. Figure 5 shows the XML instance of the Condition object. The case. Figure 5 shows the XML instance of the Condition object. The
Condition Sub-model SHALL have following information: Condition Sub-model SHALL have following information:
Firewall-condition: This field represents the general firewall Firewall-condition: This field represents the general firewall
case, where a security admin can set up firewall conditions case, where a security admin can set up firewall conditions
using the information present in this field. The source using the information present in this field. The source
skipping to change at page 14, line 21 skipping to change at page 14, line 21
Mutual-Authentication: This field indicates whether mutual Mutual-Authentication: This field indicates whether mutual
authentication is mandatory or not. authentication is mandatory or not.
Token-Server: This field stores the information about server that Token-Server: This field stores the information about server that
validates the token submitted as credentials. validates the token submitted as credentials.
Certificate-Server: This field stores the information about Certificate-Server: This field stores the information about
server that validates certificates submitted as server that validates certificates submitted as
credentials. credentials.
IPsec: This field contains the information about IPsec type. IPsec-Method: This list has IPsec method types based on the
There are two types; 1) IPsec-IKE and IPsec-IKEless. identities defined. There are two types such as IPsec-IKE
and IPsec-IKEless.
Single Sign-on-Server: This field stores the information about Single Sign-on-Server: This field stores the information about
server that validates user credentials. server that validates user credentials.
+--rw policy-mgnt-auth-method* [name] +--rw policy-mgnt-auth-method* [name]
+--rw name string +--rw name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw mutual-authentication? boolean +--rw mutual-authentication? boolean
+--rw password +--rw password
| +--rw password? password-type | +--rw password? password-type
+--rw token +--rw token
| +--rw token? string | +--rw token? string
| +--rw token-server? inet:ipv4-address | +--rw token-server? inet:ipv4-address
+--rw certificate +--rw certificate
| +--rw certificate? certificate-type | +--rw certificate? certificate-type
| +--rw certificate-server? inet:ipv4-address | +--rw certificate-server? inet:ipv4-address
+--rw ipsec* [ipsec-method] +--rw ipsec-method* [method]
| +--rw ipsec-method identityref | +--rw method identityref
+--rw single-sign-on +--rw single-sign-on
+--rw credential? certificate-type +--rw credential? certificate-type
+--rw certificate-server? inet:ipv4-address +--rw certificate-server? inet:ipv4-address
Figure 12: Policy Management Authentication Method YANG Data Tree Figure 12: Policy Management Authentication Method YANG Data Tree
6. Information Model for Policy Endpoint Groups 6. Information Model for Policy Endpoint Groups
The Policy Endpoint Group is a very important part of building User- The Policy Endpoint Group is a very important part of building User-
Construct based policies. A Security Administrator would create and Construct based policies. A Security Administrator would create and
skipping to change at page 21, line 47 skipping to change at page 21, line 47
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
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.";
revision "2019-04-04"{ revision "2019-06-12"{
description "latest revision"; description "latest revision";
reference reference
"draft-ietf-consumer-facing-interface-dm-03"; "draft-ietf-consumer-facing-interface-dm-03";
} }
identity permission-type { identity permission-type {
description description
"Base identity for the permission types."; "Base identity for the permission types.";
} }
identity read-only { identity read-only {
skipping to change at page 24, line 4 skipping to change at page 24, line 4
identity trojan { identity trojan {
base malware-file-type; base malware-file-type;
description description
"Identity for Trojan infection event types."; "Identity for Trojan infection event types.";
} }
identity ransomeware { identity ransomeware {
base malware-file-type; base malware-file-type;
description description
"Identity for ransomeware infection event types."; "Identity for ransomeware infection event types.";
} }
identity ipsec-type { identity i2nsf-ipsec {
description description
"Base identity for the IPsec types."; "Base identity for IPsec method types.";
} }
identity ike { identity ipsec-ike {
base ipsec-type; base i2nsf-ipsec;
description description
"Identity for ipsec-ike"; "Identity for ipsec-ike.";
} }
identity ikeless { identity ipsec-ikeless {
base ipsec-type; base i2nsf-ipsec;
description description
"Identity for ipsec-ikeless"; "Identity for ipsec-ikeless.";
} }
identity continent { identity continent {
description description
"Base Identity for continent types."; "Base Identity for continent types.";
} }
identity africa { identity africa {
base continent; base continent;
description description
skipping to change at page 30, line 7 skipping to change at page 30, line 7
description description
"The general firewall condition."; "The general firewall condition.";
container source-target { container source-target {
description description
"This represents the source."; "This represents the source.";
leaf src-target { leaf src-target {
type leafref { type leafref {
path "/policy/endpoint-group/user-group/name"; path "/policy/endpoint-group/user-group/name";
} }
description description
"This describes the paths to "This describes the paths to
the source reference."; the source reference.";
} }
} }
container destination-target { container destination-target {
description description
"This represents the destination."; "This represents the destination.";
leaf-list dest-target { leaf-list dest-target {
type leafref { type leafref {
path "/policy/endpoint-group/user-group/name"; path "/policy/endpoint-group/user-group/name";
} }
description description
skipping to change at page 31, line 23 skipping to change at page 31, line 23
description description
"The condition based on packet contents."; "The condition based on packet contents.";
container source-target { container source-target {
description description
"This represents the source."; "This represents the source.";
leaf-list src-target { leaf-list src-target {
type leafref { type leafref {
path "/policy/threat-prevention/payload-content/name"; path "/policy/threat-prevention/payload-content/name";
} }
description description
"Describes the payload string "Describes the payload string
content condition source."; content condition source.";
} }
} }
container destination-target { container destination-target {
description description
"This represents the destination."; "This represents the destination.";
leaf dest-target { leaf dest-target {
type leafref { type leafref {
path "/policy/threat-prevention/payload-content/name"; path "/policy/threat-prevention/payload-content/name";
} }
description description
"Describes the payload string "Describes the payload string
content condition destination."; content condition destination.";
} }
} }
} }
container threat-feed-condition { container threat-feed-condition {
description description
"The condition based on the threat-feed information."; "The condition based on the threat-feed information.";
container source-target { container source-target {
description description
"This represents the source."; "This represents the source.";
skipping to change at page 32, line 39 skipping to change at page 32, line 39
'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc.";
} }
leaf secondary-action { leaf secondary-action {
type string; type string;
description description
"This field identifies additional actions if "This field identifies additional actions if
a rule is matched. This could be one of 'LOG', a rule is matched. This could be one of 'LOG',
'SYSLOG', 'SESSION-LOG', etc."; 'SYSLOG', 'SESSION-LOG', etc.";
} }
} }
container ipsec { container ipsec-method {
description description
"This container represents the IPsec-IKE/IKEless cases."; "This container represents the IPsec IKE and IKEless cases.";
leaf ipsec-method { leaf method {
type leafref { type leafref {
path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec/ipsec-method"; path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec-method/method";
} }
description description
"This represents the IPsec-method, which "This references the IPsec method types,
is defined by policy-mgny-auth-method."; which includes IPsec IKE and IPsec IKEless cases.";
} }
} }
leaf owner { leaf owner {
type string; type string;
description description
"This field defines the owner of this "This field defines the owner of this
policy. Only the owner is authorized to policy. Only the owner is authorized to
modify the contents of the policy."; modify the contents of the policy.";
} }
} }
skipping to change at page 33, line 50 skipping to change at page 33, line 50
path "/policy/multi-tenancy/policy-domain/name"; path "/policy/multi-tenancy/policy-domain/name";
} }
description description
"This field identifies the domain to which this "This field identifies the domain to which this
tenant belongs. This should be reference to a tenant belongs. This should be reference to a
'Policy-Domain' object."; 'Policy-Domain' object.";
} }
} }
leaf authentication-method { leaf authentication-method {
type leafref { type leafref {
path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec/ipsec-method"; path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec-method/method";
} }
description description
"Authentication method to be used for this domain. "Authentication method to be used for this domain.
It should be a reference to a 'policy-mgmt-auth-method' It should be a reference to a 'policy-mgmt-auth-method'
object."; object.";
} }
description description
"This represents the list of policy domains."; "This represents the list of policy domains.";
} }
container policy-role { container policy-role {
skipping to change at page 35, line 35 skipping to change at page 35, line 35
description description
"This represents the authentication method name."; "This represents the authentication method name.";
} }
leaf mutual-authentication { leaf mutual-authentication {
type boolean; type boolean;
description description
"To identify whether the authentication "To identify whether the authentication
is mutual."; is mutual.";
} }
list password-based { list password-based {
key "password"; key "password";
leaf password { leaf password {
type string; type string;
description description
"This should be defined using the "This should be defined using the
regular expression."; regular expression.";
} }
description description
"This represents the password-based method."; "This represents the password-based method.";
} }
list token-based { list token-based {
key "token"; key "token";
leaf token { leaf token {
type string; type string;
description description
"This should be defined according to "This should be defined according to
the token scheme."; the token scheme.";
} }
leaf token-server { leaf token-server {
type inet:ipv4-address; type inet:ipv4-address;
description description
"This represents the token-server "This represents the token-server
information if the authentication method information if the authentication method
is token-based."; is token-based.";
} }
description description
"This represents the token-based method."; "This represents the token-based method.";
} }
list certificate-based { list certificate-based {
key "certificate"; key "certificate";
leaf certificate { leaf certificate {
type certificate-type; type certificate-type;
skipping to change at page 36, line 31 skipping to change at page 36, line 31
leaf certificate-server { leaf certificate-server {
type inet:ipv4-address; type inet:ipv4-address;
description description
"The certificate-server information if "The certificate-server information if
the authentication method is the authentication method is
certificate-based"; certificate-based";
} }
description description
"This describes the certificate-based authentication list."; "This describes the certificate-based authentication list.";
} }
list ipsec { list ipsec-method {
key "ipsec-method"; key "method";
leaf ipsec-method { leaf method {
type identityref { type identityref {
base ipsec-type; base i2nsf-ipsec;
} }
description description
"This represents the IPsec-IKE or IPsec-IKEless cases."; "This represents IPsec IKE and IPsec IKEless cases.";
} }
description description
"This represents the list of IPsec-method."; "This represents the list of IPsec method types.";
} }
list single-sign-on { list single-sign-on {
key "credential"; key "credential";
leaf credential { leaf credential {
type certificate-type; type certificate-type;
description description
"This represents the authentication "This represents the authentication
using user credentials."; using user credentials.";
} }
leaf certificate-server { leaf certificate-server {
skipping to change at page 40, line 31 skipping to change at page 40, line 31
</firewall-condition> </firewall-condition>
<custom-condition> <custom-condition>
<destination-target> <destination-target>
<dest-target>sns-websites</dest-target> <dest-target>sns-websites</dest-target>
</destination-target> </destination-target>
</custom-condition> </custom-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec> <ipsec-method>
<ipsec-method>ikeless</ipsec-method> <method>ipsec-ike</method>
</ipsec> </ipsec-method>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </ietf-i2nsf-cfi-policy:policy>
Figure 25: An XML Example for Time-based Firewall Figure 25: An XML Example for Time-based Firewall
Time-based-condition Firewall Time-based-condition Firewall
1. The policy name is "security_policy_for_blocking_sns". 1. The policy name is "security_policy_for_blocking_sns".
2. The rule name is "block_access_to_sns_during_office_hours". 2. The rule name is "block_access_to_sns_during_office_hours".
3. The Source-target is "employees". 3. The Source-target is "employees".
4. The destination target is "sns-websites". "sns-websites" is the 4. The destination target is "sns-websites". "sns-websites" is the
key which represents the list containing the information, such as key which represents the list containing the information, such as
URL, about sns-websites. URL, about sns-websites.
5. The action required is to "drop" any attempt to connect to 5. The action required is to "drop" any attempt to connect to
websites related to Social networking. websites related to Social networking.
6. The IPsec-method is set to "ikeless". 6. The IPsec method type used for nsf traffic steering is set to
"ipsec-ike".
10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a
Company Company
The second example scenario is to "block malicious VoIP/VoLTE packets The second example scenario is to "block malicious VoIP/VoLTE packets
coming to a company" using a VoIP policy. In this scenario, the coming to a company" using a VoIP policy. In this scenario, the
calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that
are classified as malicious are dropped. The IP addresses of the are classified as malicious are dropped. The IP addresses of the
employees and malicious VOIP IDs should be blocked are stored in 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 database or datastore of the enterprise. Here and the rest of the
skipping to change at page 41, line 45 skipping to change at page 41, line 46
</custom-condition> </custom-condition>
<firewall-condition> <firewall-condition>
<destination-target> <destination-target>
<dest-target>employees</dest-target> <dest-target>employees</dest-target>
</destination-target> </destination-target>
</firewall-condition> </firewall-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec> <ipsec-method>
<ipsec-method>ikeless</ipsec-method> <method>ipsec-ikeless</method>
</ipsec> </ipsec-method>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </ietf-i2nsf-cfi-policy:policy>
Figure 26: An XML Example for VoIP Security Service Figure 26: An XML Example for VoIP Security Service
Custom-condition Firewall Custom-condition Firewall
1. The policy name is 1. The policy name is
"security_policy_for_blocking_malicious_voip_packets". "security_policy_for_blocking_malicious_voip_packets".
skipping to change at page 42, line 25 skipping to change at page 42, line 25
admin can read every stored malicious VOIP IDs that are named as admin can read every stored malicious VOIP IDs that are named as
"malicious-id". "malicious-id".
4. The destination target is "employees". "employees" is the key 4. The destination target is "employees". "employees" is the key
which represents the list containing information about employees, which represents the list containing information about employees,
such as IP addresses. such as IP addresses.
5. The action required is "drop" when any incoming packets are from 5. The action required is "drop" when any incoming packets are from
"malicious-id". "malicious-id".
6. The IPsec-method is set to "ikeless". 6. The IPsec method used for nsf traffic steering is set to "ipsec-
ikeless".
10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company 10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company
Web Server Web Server
The third example scenario is to "Mitigate HTTP and HTTPS flood The third example scenario is to "Mitigate HTTP and HTTPS flood
attacks on a company web server" using a DDoS-attack mitigation attacks on a company web server" using a DDoS-attack mitigation
policy. Here, the time information is not set because the service policy. Here, the time information is not set because the service
provided by the network should be maintained at all times. If the 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 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 admin can set the percentage of the packets to be dropped to safely
skipping to change at page 43, line 23 skipping to change at page 43, line 23
<dest-target>webservers</dest-target> <dest-target>webservers</dest-target>
</destination-target> </destination-target>
<rate-limit> <rate-limit>
<packet-per-second>100</packet-per-second> <packet-per-second>100</packet-per-second>
</rate-limit> </rate-limit>
</ddos-condition> </ddos-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec> <encrypt>
<ipsec-method>ikeless</ipsec-method> <ipsec-method>ipsec-ike</ipsec-method>
</ipsec> </encrypt>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </ietf-i2nsf-cfi-policy:policy>
Figure 27: An XML Example for DDoS-attack Mitigation Figure 27: An XML Example for DDoS-attack Mitigation
DDoS-condition Firewall DDoS-condition Firewall
1. The policy name is "security_policy_for_ddos_attacks". 1. The policy name is "security_policy_for_ddos_attacks".
2. The rule name is "100_packets_per_second". 2. The rule name is "100_packets_per_second".
skipping to change at page 43, line 52 skipping to change at page 44, line 5
second. In this case the rate limit is "100" packets per second. second. In this case the rate limit is "100" packets per second.
This amount depends on the packet receiving capacity of the This amount depends on the packet receiving capacity of the
server devices. server devices.
5. The Source-target is all sources which send abnormal amount of 5. The Source-target is all sources which send abnormal amount of
packets. packets.
6. The action required is to "drop" packet reception is more than 6. The action required is to "drop" packet reception is more than
100 packets per second. 100 packets per second.
7. The IPsec-method is set to "ikeless". 7. The IPsec method used for nsf traffic steering is set to "ipsec-
ike".
11. Security Considerations 11. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is based on The data model for the I2NSF Consumer-Facing Interface is based on
the I2NSF framework [RFC8329], so the same security considerations the I2NSF framework [RFC8329], so the same security considerations
with the I2NSF framework should be included in this document. The with the I2NSF framework should be included in this document. The
data model needs a secure communication channel to protect the data model needs a secure communication channel to protect the
Consumer-Facing Interface between the I2NSF User and Security Consumer-Facing Interface between the I2NSF User and Security
Controller. Controller.
skipping to change at page 45, line 47 skipping to change at page 45, line 47
[client-facing-inf-req] [client-facing-inf-req]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Requirements for Client-Facing Interface S., and L. Xia, "Requirements for Client-Facing Interface
to Security Controller", draft-ietf-i2nsf-client-facing- to Security Controller", draft-ietf-i2nsf-client-facing-
interface-req-05 (work in progress), May 2018. interface-req-05 (work in progress), May 2018.
[i2nsf-capability-im] [i2nsf-capability-im]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-04 (work in progress), October 2018. i2nsf-capability-05 (work in progress), April 2019.
[i2nsf-ipsec] [i2nsf-ipsec]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "Software-Defined Networking (SDN)-based IPsec Garcia, "Software-Defined Networking (SDN)-based IPsec
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-04 (work in progress), March 2019. protection-04 (work in progress), March 2019.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-07 (work in Terminology", draft-ietf-i2nsf-terminology-07 (work in
progress), January 2019. progress), January 2019.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-03 dm-04
The following changes have been made from draft-ietf-i2nsf-consumer- The following changes have been made from draft-ietf-i2nsf-consumer-
facing-interface-dm-03: facing-interface-dm-04:
o This version added an I2NSF IPsec field for configuration and o In Section 4 and Section 5.5, a field named "ipsec-method" is
state data for IPsec management (i.e., IPsec method such as IKE added to support IPsec method types (i.e., IPsec IKE and IPsec
and IKEless [i2nsf-ipsec]) in the I2NSF framework. IKEless) for the configuration and state data of IPsec management
in the I2NSF framework, which is specified in [i2nsf-ipsec].
Appendix B. Acknowledgments Appendix B. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute for Information & communications
Technology Promotion(IITP) grant funded by the Korea government(MSIP) Technology Promotion (IITP) grant funded by the Korea government
(No.R-20160222-002755, Cloud based Security Intelligence Technology (MSIP)(No. R-20160222-002755, Cloud based Security Intelligence
Development for the Customized Security Service Provisioning). Technology Development for the Customized Security Service
Provisioning).
Appendix C. Contributors Appendix C. Contributors
This document is made by the group effort of I2NSF working group. This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document, such as Mahdi F. Many people actively contributed to this document, such as Mahdi F.
Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their
contributions. contributions.
The following are co-authors of this document: The following are co-authors of this document:
Hyoungshick Kim Hyoungshick Kim
Department of Software Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu 2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419 Suwon, Gyeonggi-do 16419
Republic of Korea Republic of Korea
EMail: hyoung@skku.edu EMail: hyoung@skku.edu
Seungjin Lee Seungjin Lee
Department of Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu 2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419 Suwon, Gyeonggi-do 16419
Republic of Korea Republic of Korea
EMail: jine33@skku.edu EMail: jine33@skku.edu
Jinyong Tim Kim Jinyong Tim Kim
Department of Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu 2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419 Suwon, Gyeonggi-do 16419
Republic of Korea Republic of Korea
EMail: timkim@skku.edu EMail: timkim@skku.edu
Anil Lohiya Anil Lohiya
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
skipping to change at page 49, line 8 skipping to change at page 49, line 13
Huawei Huawei
101 Software Avenue 101 Software Avenue
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
EMail: Frank.Xialiang@huawei.com EMail: Frank.Xialiang@huawei.com
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Eunsoo Kim Eunsoo Kim
Department of Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4104 Phone: +82 31 299 4104
EMail: eskim86@skku.edu EMail: eskim86@skku.edu
URI: http://seclab.skku.edu/people/eunsoo-kim/ URI: http://seclab.skku.edu/people/eunsoo-kim/
Tae-Jin Ahn Tae-Jin Ahn
 End of changes. 52 change blocks. 
98 lines changed or deleted 106 lines changed or added

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