--- 1/draft-ietf-i2nsf-capability-02.txt 2018-10-22 08:14:06.272364814 -0700 +++ 2/draft-ietf-i2nsf-capability-03.txt 2018-10-22 08:14:06.328366154 -0700 @@ -1,21 +1,21 @@ I2NSF L. Xia Internet Draft J. Strassner Intended status: Standard Track Huawei -Expires: January 02, 2019 C. Basile +Expires: April 22, 2019 C. Basile PoliTO D. Lopez TID - July 02, 2018 + October 22, 2018 Information Model of NSFs Capabilities - draft-ietf-i2nsf-capability-02.txt + draft-ietf-i2nsf-capability-03.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -24,21 +24,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on January 02, 2019. + This Internet-Draft will expire on April 22, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,37 +53,43 @@ This draft defines the concept of an NSF (Network Security Function) capability, as well as its information model. Capabilities are a set of features that are available from a managed entity, and are represented as data that unambiguously characterizes an NSF. Capabilities enable management entities to determine the set of features from available NSFs that will be used, and simplify the management of NSFs. Table of Contents - 1. Introduction ................................................. 2 - 2. Conventions used in this document ............................ 3 - 2.1. Acronyms ................................................ 3 - 3. Capability Information Model Design .......................... 4 - 3.1. Design Principles and ECA Policy Model Overview ......... 5 - 3.2. Relation with the External Information Model ............ 8 - 3.3. I2NSF Capability Information Model Theory of Operation .. 9 - 3.3.1. I2NSF Capability Information Model ................ 11 - 3.3.2. The SecurityCapability class ...................... 13 - 3.3.3. I2NSF Condition Clause Operator Types ............. 14 - 3.3.4. Capability Selection and Usage .................... 16 - 3.3.5. Capability Algebra ............................... 17 - 4. IANA Considerations ......................................... 19 - 5. References .................................................. 19 - 5.1. Normative References ................................... 19 - 5.2. Informative References ................................. 20 - 6. Acknowledgments ............................................. 22 + 1. Introduction ................................................ 3 + 2. Conventions used in this document ........................... 3 + 2.1. Acronyms ............................................... 4 + 3. Capability Information Model Design ......................... 4 + 3.1. Design Principles and ECA Policy Model Overview ........ 5 + 3.2. Relation with the External Information Model ........... 8 + 3.3. I2NSF Capability Information Model Theory of Operation . 9 + 3.3.1. I2NSF Capability Information Model ............... 11 + 3.3.2. The SecurityCapability class ..................... 14 + 3.4. Modelling NSF Features as Security Capabilities ....... 15 + 3.4.1. Matched Policy Rule .............................. 15 + 3.4.2. Conflict, Resolution Strategy and Default Action . 16 + 3.4.3. I2NSF Condition Clause Operator Types ............ 17 + 3.4.4. Uses of the capability information model ......... 19 + 3.4.5. A Syntax to Describe the Capability of an NSF .... 19 + 3.4.6. Capability Algebra ............................... 20 + 4. Considerations on the Practical Use of the CapIM ........... 21 + 5. Security Considerations .................................... 22 + 6. Contributors ............................................... 22 + 7. Acknowledgements ........................................... 23 + 8. References ................................................. 23 + 8.1. Normative References .................................. 23 + 8.2. Informative References ................................ 24 1. Introduction The rapid development of virtualized systems requires advanced security protection in various scenarios. Examples include network devices in an enterprise network, User Equipment in a mobile network, devices in the Internet of Things, or residential access users [RFC8192]. NSFs produced by multiple security vendors provide various security @@ -109,22 +115,24 @@ This document is organized as follows. Section 2 defines conventions and acronyms used. Section 3 discusses the design principles for I2NSF capability information model, the related ECA model, and provides detailed information model design of I2NSF network security capability. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC-2119 [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. This document uses terminology defined in [I-D.draft-ietf-i2nsf- terminology] for security related and I2NSF scoped terminology. 2.1. Acronyms I2NSF - Interface to Network Security Functions NSF - Network Security Function @@ -341,41 +349,41 @@ NSFs to be used; 4) The security controller takes the above information and creates or uses one or more data models from the CapIM to manage the NSFs; 5) Control and monitoring can then begin. This assumes that an external information model is used to define the concept of an ECA Policy Rule and its components (e.g., Event, Condition, and Action objects). This enables I2NSF Policy Rules [I- - D.draft-ietf-i2nsf-terminology] to be subclassed from an external + D.draft-ietf-i2nsf-terminology] to be sub-classed from an external information model. The external ECA Information Model supplies at least a set of objects that represent a generic ECA Policy Rule, and a set of objects that represent Events, Conditions, and Actions that can be aggregated by the generic ECA Policy Rule. This enables appropriate I2NSF Components to reuse this generic model for different purposes, as well as specialize it (i.e., create new model objects) to represent concepts that are specific to I2NSF and/or an application that is using I2NSF. It is assumed that the external ECA Information Model also has the ability to aggregate metadata. This enables metadata to be used to prescribe and/or describe characteristics and behavior of the ECA - Policy Rule. Specifically, Capabilities are subclassed from this + Policy Rule. Specifically, Capabilities are sub-classed from this external metadata model. If the desired Capabilities are already defined in the CapIM, then no further action is necessary. Otherwise, new Capabilities SHOULD be defined either by defining new classes that can wrap existing classes using the decorator pattern - [Gamma] or by another mechanism (e.g., through subclassing); the + [Gamma] or by another mechanism (e.g., through sub-classing); the parent class of the new Capability SHOULD be either an existing CapIM metadata class or a class defined in the external metadata information model. In either case, the ECA objects can use the existing aggregation between them and the Metadata class to add metadata to appropriate ECA objects. Detailed descriptions of each portion of the information model are given in the following sections. 3.3. I2NSF Capability Information Model Theory of Operation @@ -413,28 +421,27 @@ logically ANDed together, where each sub-clause contains only terms that use OR and/or NOT operators). Similarly, disjunctive normal form is a set of sub-clauses that are logically ORed together, where each sub-clause contains only terms that use AND and/or NOT operators. This document defines additional important extensions to both the external ECA Policy Rule model and the external Metadata model that are used by the I2NSF CapIM; examples include resolution strategy, external data, and default actions. All these extensions come from - the geometric model defined in [Bas12]. A more detailed description - is provided in Appendix E; a summary of the important points of this - geometric model follows. + the geometric model defined in [Bas12]. A summary of the important + points of this geometric model follows. Formally, given a set of actions in an I2NSF Policy Rule, the resolution strategy maps all the possible subsets of actions to an outcome. In other words, the resolution strategy is included in an - I2NSF Policy to decide how to evaluate all the actions from the + I2NSF Policy Rule to decide how to evaluate all the actions from the matching I2NSF Policy Rule. Some concrete examples of resolution strategy are: o First Matching Rule (FMR) o Last Matching Rule (LMR) o Prioritized Matching Rule (PMR) with Errors (PMRE) @@ -456,23 +462,23 @@ execution of all actions. Invoke the error handler of the failed action, but regardless of the result, execution of the ECA Policy Rule MUST be terminated. Regardless of the resolution strategy, when no rule matches a packet, a default action MAY be executed. Resolution strategies may use, besides intrinsic rule data (i.e., event, condition, and action clauses), "external data" associated to each rule, such as priority, identity of the creator, and creation - time. Two examples of this are attaching metadata to the policy - action and/or policy rule, and associating the policy rule with - another class to convey such information. + time. Two examples of this are attaching metadata to the policy rule + and/or its action, and associating the policy rule with another + class to convey such information. 3.3.1. I2NSF Capability Information Model Figure 1 below shows one example of an external model. This is a simplified version of the MEF Policy model [PDO]. For our purposes: o MCMPolicyObject is an abstract class, and is derived from MCMManagedEntity [MCM] o MCMPolicyStructure is an abstract superclass for building @@ -565,42 +571,143 @@ This enables the HasSecurityCapabilityDetail association class to be the target of a Policy Rule. That is, the HasSecurityCapabilityDetail class has attributes and methods that define which I2NSFSecurityCapabilities of this NSF are visible and can be used [MCM]. 3.3.2. The SecurityCapability class The SecurityCapability class defines the concept of metadata that define security-related capabilities. It is subclassed from an - appropriate class of an external metadata information - model.Subclasses of the SecurityCapability class can be used to - answer the following questions: + appropriate class of an external metadata information model. + Subclasses of the SecurityCapability class can be used to answer the + following questions: o What are the events that are caught by the NSF to trigger the condition clause evaluation (Event subclass)? o What kind of condition clauses can be specified on the NSF to define valid rules? This question splits into two questions: (1) what are the conditions that can be specified (Condition subclass), and (2) how to build a valid condition clause from a set of individual conditions (ClauseEvaluation class). o What are the actions that the NSF can enforce (Action class)? o How to define a correct policy on the NSF? - 3.3.3. I2NSF Condition Clause Operator Types + 3.4. Modelling NSF Features as Security Capabilities + + The capability model proposed in this document is intended to + provide a formal framework to describe and process the features of + NSFs, and to evaluate their fitness to a particular purpose, + expressed in terms of a (possibly complex) policy statement. Using + the capability model, NSF providers and users can declare and + manipulate the features of a function or a combination of them. + + Specifically, if the NSF has the classification features needed to + identify the packets/flows required by a policy, and can enforce the + needed actions, then that particular NSF is capable of enforcing the + policy. Therefore, capability selection and usage are based on the + set of security traffic classification and action features that an + NSF provides. + + NSFs may also have specific characteristics that automatic processes + or administrators need to know when they have to generate + configurations, like the available resolution strategies and the + possibility to set default actions, which are described in Sections + 3.4.3. + + 3.4.1. Matched Policy Rule + + The concept of a "matched" policy rule is defined as one in which + its event and condition clauses both evaluate to true. To precisely + describe what an NSF can do in terms of security, the things need to + describe are the events it can catch, the conditions it can + evaluate, and the actions it can enforce. + + Therefore, the properties that to characterize the capabilities of a + NSF are as below: + + o Ac is the set of Actions currently available from the NSF; + + o Ec is the set of Events that an NSF can catch. Note that for NSF + (e.g., a packet filter) that are not able to react to events, + this set will be empty; + + o Cc is the set of Conditions currently available from the NSF; + + o EVc defines the set of Condition Clause Evaluation Rules that can + be used at the NSF to decide when the Condition Clause is true + given the result of the evaluation of the individual Conditions. + + 3.4.2. Conflict, Resolution Strategy and Default Action + + Formally, two I2NSF Policy Rules conflict with each other if: + + o the Event Clauses of each evaluate to TRUE; + + o the Condition Clauses of each evaluate to TRUE; + + o the Action Clauses affect the same object in different ways. + + For example, if we have two Policy Rules in the same Policy: + + R1: During 8am-6pm, if traffic is external, then run through FW + R2: During 7am-8pm, conduct anti-malware investigation + + There is no conflict between R1 and R2, since the actions are + different. However, consider these two rules: + + R3: During 8am-6pm, John gets GoldService + R4: During 10am-4pm, FTP from all users gets BronzeService + + R3 and R4 are now in conflict, between the hours of 10am and 4pm, + because the actions of R3 and R4 are different and apply to the same + user (i.e., John). + + Conflicts theoretically compromise the correct functioning of + devices (as happened for routers several year ago). However, NSFs + have been designed to cope with these issues. Since conflicts are + originated by simultaneously matching rules, an additional process + decides the action to be applied, e.g., among the ones the matching + rule would have enforced. This process is described by means of a + resolution strategy + + On the other hand, it may happen that, if an event is caught, none + of the policy rules matches. As a simple case, no rules may match a + packet arriving at border firewall. In this case, the packet is + usually dropped, that is, the firewall has a default behavior to + manage cases that are not covered by specific rules. + + Therefore, we introduce another security capability that serves to + characterize valid policies for an NSF that solve conflicts with + resolution strategies and enforce default actions if no rules match: + + o RSc is the set of Resolution Strategy that 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; + + o Dc defines the notion of a Default action. This action can be + either an explicit action that has been chosen {a}, or a set of + actions {F}, where F is a dummy symbol (i.e., a placeholder + value) that can be used to indicate that the default action can + be freely selected by the policy editor. This is denoted as {F} U + {a}. + + 3.4.3. I2NSF Condition Clause Operator Types After having analyzed the literature and some existing NSFs, the - types of selectors are categorized as exact-match, range-based, - regex-based, and custom-match [Bas15][Lunt]. + types of Condition clause operators/selectors are categorized as + exact-match, range-based, regex-based, and custom-match + [Bas15][Lunt]. Exact-match selectors are (unstructured) sets: elements can only be checked for equality, as no order is defined on them. As an example, the protocol type field of the IP header is an unordered set of integer values associated to protocols. The assigned protocol numbers are maintained by the IANA (http://www.iana.org/assignments/protocol-numbers/protocol- numbers.xhtml). In this selector, it is only meaningful to specify condition clauses @@ -665,115 +772,66 @@ Finally, the idea of a custom check selector is introduced. For instance, malware analysis can look for specific patterns, and returns a Boolean value if the pattern is found or not. In order to be properly used by high-level policy-based processing systems (such as reasoning systems and policy translation systems), these custom check selectors can be modeled as black-boxes (i.e., a function that has a defined set of inputs and outputs for a particular state), which provide an associated Boolean output. - More examples of custom check selectors will be presented in the - next versions of the draft. Some examples are already present in - Section 6. - - 3.3.4. Capability Selection and Usage - - Capability selection and usage are based on the set of security - traffic classification and action features that an NSF provides; - these are defined by the capability model. If the NSF has the - classification features needed to identify the packets/flows - required by a policy, and can enforce the needed actions, then that - particular NSF is capable of enforcing the policy. - - NSFs may also have specific characteristics that automatic processes - or administrators need to know when they have to generate - configurations, like the available resolution strategies and the - possibility to set default actions. + 3.4.4. Uses of the capability information model The capability information model can be used for two purposes: describing the features provided by generic security functions, and describing the features provided by specific products. The term - Generic Network Security Function (GNSF) refers to the classes of - security functions that are known by a particular system. The idea - is to have generic components whose behavior is well understood, so - that the generic component can be used even if it has some vendor- - specific functions. These generic functions represent a point of - interoperability, and can be provided by any product that offers the - required capabilities. GNSF examples include packet filter, URL - filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content - filter, monitoring, and anonymity proxy; these will be described - later in a revision of this draft as well as in an upcoming data - model contribution. - - The next section will introduce the algebra to compose the - information model of capability registration, defined to associate - NSFs to capabilities and to check whether a NSF has the capabilities - needed to enforce policies. - -3.3.5. Capability Algebra - - We introduce a Capability Algebra to ensure that the actions of - different policy rules do not conflict with each. - - Formally, two I2NSF Policy Rules conflict with each other if: - - o the event clauses of each evaluate to TRUE - - o the condition clauses of each evaluate to TRUE - - o the action clauses affect the same object in different ways - - For example, if we have two Policy Rules in the same Policy: - - R1: During 8am-6pm, if traffic is external, then run through FW - R2: During 7am-8pm, conduct anti-malware investigation + Generic Network Security Function (GNSF) has been used to define + generalized categories of NSFs. The idea is to have generic + components whose behavior is well understood, so that the generic + component can be used even if it has some vendor-specific functions. - There is no conflict between R1 and R2, since the actions are - different. However, consider these two rules: + These generic functions represent a point of interoperability, and + can be provided by any product that offers the required + capabilities. GNSF examples include packet filter, URL filter, HTTP + filter, VPN gateway, anti-virus, anti-malware, content filter, + monitoring, and anonymity proxy; these will be described later in a + revision of this draft. - R3: During 8am-6pm, John gets GoldService - R4: During 10am-4pm, FTP from all users gets BronzeService + 3.4.5. A Syntax to Describe the Capability of an NSF - R3 and R4 are now in conflict, between the hours of 10am and 4pm, - because the actions of R3 and R4 are different and apply to the same - user (i.e., John). + To characterize the behavior of the Policy Rule as specified by the + CapIM, a NSF can be associated to its security capabilities by means + of a 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where Ac, Cc, Ec, RSc, Dc, + and EVc have been described in the previous sections. - Let us define the concept of a "matched" policy rule as one in which - its event and condition clauses both evaluate to true. Then, the - behavior of the Policy Rule, as specified by the CapIM, is defined - by a 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where: + As an example, assume that a packet filter capability, Cap_pf, is + defined, its, capabilities can be defined as - o Ac is the set of Actions currently available from the NSF; + Cap_pf = (Apf, Cpf, Epf, RSpf, Dpf, EVpf) - o Cc is the set of Capabilities currently available from the NSF; + where: - o Ec is the set of Events that an NSF can catch. Note that for NSF - (e.g., a packet filter) that are not able to react to events, - this set will be empty; + Apf = {Allow, Deny} + Cpf = {IPsrc,IPdst,Psrc,Pdst,protType} + Epf = {} + RSpf = {FMR} + Dpf = {A1} + EVpf = {DNF} - o RSc is the set of Resolution Strategies that 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; + 3.4.6. Capability Algebra - o Dc defines the notion of a Default action. This action can be - either an explicit action that has been chosen {a}, or a set of - actions {F}, where F is a dummy symbol (i.e., a placeholder - value) that can be used to indicate that the default action can - be freely selected by the policy editor. This is denoted as {F} U - {a}. + Assigning capabilities to a large number of NSFs can be a complex + (and boring) operation, therefore, this document presents a formal + way (Capability Algebra) to define templates and manipulate them for + NSF. - EVc defines the set of Condition Clause Evaluation Rules that can be - used at the NSF to decide when the condition clause is true given - the result of the evaluation of the individual conditions. Before - introducing the rest of the capability model, we will introduce the + Before introducing the capability algebra, we will introduce the symbols that we will use to represent set operations: o "U" is the union operation, A U B returns a new set that includes all the elements in A and all the elements in B o "\" is the set minus operation, A \ B returns all the elements that are in A but not in B. Given two sets of capabilities, denoted as cap1=(Ac1,Cc1, Ec1,RSc1,Dc1,EVc1) and cap2=(Ac2,Cc2,Ec2,RSc2,Dc2,EVc2) @@ -786,67 +844,126 @@ \ Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2} In the above formulae, "U" is the set union operator and "\" is the set difference operator. The addition and subtraction of capabilities are defined as the addition (set union) and subtraction (set difference) of both the capabilities and their associated actions. Note that the Resolution Strategies and Default Actions are added in both cases. - As an example, assume that a packet filter capability, Cpf, is - defined. Further, assume that a second capability, called Ctime, - exists, and that it defines time-based conditions. Suppose we need - to construct a new generic packet filter, Cpfgen, that adds time- - based conditions to Cpf. Conceptually, this is simply the addition - of the Cpf and Ctime capabilities, as follows: + As an example, assume that a packet filter capability, Cap_pf, is + defined as in a previous section. Further, assume that a second + capability, called Cap_time, exists, and that it defines time-based + conditions. Suppose we need to construct a new generic packet + filter, Cap_pfgen, that adds time-based conditions to Cap_pf. + + Conceptually, this is simply the addition of the Cap_pf and Cap_time + capabilities, as follows: Apf = {Allow, Deny} Cpf = {IPsrc,IPdst,Psrc,Pdst,protType} Epf = {} RSpf = {FMR} Dpf = {A1} EVpf = {DNF} Atime = {Allow, Deny, Log} Ctime = {timestart, timeend, datestart, datestop} Etime = {} RStime = {LMR} Dtime = {A2} EVtime = {} - Then, Cpfgen is defined as: + Then, Cap_pfgen is defined as: Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf U RStime, Dpf U Time, EVpf U EVtime} - = {Allow, Deny, Log}, - {{IPsrc,IPdst,Psrc,Pdst,protType} U {timestart, timeend, - datestart, datestop}} - {} - {FMR, LMR} - {A1, A2} - {DNF} + = { {Allow, Deny, Log}, + {IPsrc,IPdst,Psrc,Pdst,protType} U {timestart, + timeend, datestart, datestop}, + {}, + {FMR, LMR}, + {A1, A2}, + {DNF} } - In other words, Cpfgen provides three actions (Allow, Deny, Log), + In other words, Cap_pfgen provides three actions (Allow, Deny, Log), filters traffic based on a 5-tuple that is logically ANDed with a time period, can use either FMR or LMR (but obviously not both), and can provide either A1 or A2 (but again, not both) as a default action. In any case, multiple conditions will be processed with DNF when evaluating the condition clause. - 4. IANA Considerations + 4. Considerations on the Practical Use of the CapIM - TBD + CapIM is a solid basis for the data models that may serve in I2NSF. + Nevertheless, a partial re-organization of the data models already + produced by the WG is expected. - 5. References + Currently (A survey on the existing data models in the I2NSF world + with a couple of lines about it and a list of things that can be + inherited). - 5.1. Normative References + The CapIM can benefit from the definition of lists of elements to + help to easily build the description of the capabilities which + mainly consists in listing the things it can do: + + o the actions that NSFs can enforce; + + o the conditions that can be specified by at least one NSF. + + Knowing all actions and conditions would be desirable, but covering + all of them is actually unreasonable. For instance, one-of-the-YANG- + models lists a high number of protocols that can be a solid basis to + build this list. + + On the other hand, resolution strategies, and condition clause + evaluation methods are limited and listing all of them seems + feasible. + + Finally, Events are too bounded to the systems/domain/architectures, + therefore, compiling a list is simply impossible. + + 5. Security Considerations + + This document defines an object-oriented information model for + describing policy information that is independent of any specific + repository, language, or protocol. This document does not define any + particular system implementation, including a protocol. Hence, it + does not have any specific security requirements. + + 6. Contributors + + The following people contributed to creating this document, and are + listed below in alphabetical order: + + Antonio Lioy (Politecnico di Torino) + + Dacheng Zhang (Huawei) + + Edward Lopez (Fortinet) + + Fulvio Valenza (Politecnico di Torino) + + Kepeng Li (Alibaba) + Luyuan Fang (Microsoft) + + Nicolas Bouthors (QoSmos) + + 7. Acknowledgements + + Thanks to Linda Dunbar, Susan Hares and Jaehoon Paul Jeong for the + discussion and comments. + + 8. References + + 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, @@ -865,21 +982,24 @@ [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, DOI 10.17487/RFC8192, July 2017, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J. and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, February 2018. - 5.2. Informative References + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", RFC8174, May 2017. + + 8.2. Informative References [INCITS359 RBAC] NIST/INCITS, "American National Standard for Information Technology - Role Based Access Control", INCITS 359, April, 2003 [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to Network Security Functions (I2NSF) Terminology", Work in Progress, January, 2018 [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J., @@ -931,24 +1051,20 @@ [OODSRP] http://www.oodesign.com/single-responsibility- principle.html [PDO] MEF, "Policy Driven Orchestration", Technical Specification MEF Y, January 2018 [Taylor] Taylor, D. and J. Turner, "Scalable packet classification using distributed crossproducting of field labels", 2004. - 6. Acknowledgments - - This document was prepared using 2-Word-v2.0.template.dot. - Authors' Addresses Cataldo Basile Politecnico di Torino Corso Duca degli Abruzzi, 34 Torino, 10129 Italy Email: cataldo.basile@polito.it Liang Xia (Frank)