idnits 2.17.1 draft-baspez-i2nsf-capabilities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 434, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF C. Basile 3 Internet-Draft PoliTo 4 Intended status: Experimental D. Lopez 5 Expires: January 9, 2017 TID 6 July 8, 2016 8 A Model of Security Capabilities for Network Security Functions 9 draft-baspez-i2nsf-capabilities-00 11 Abstract 13 This document presents a model of Security Capabilities. Security 14 Capabilities are intended to describe the potentiality that Network 15 Security Functions (NSFs) have for security policy enforcement 16 purposes. Therefore, Security Capabilities are represented as 17 abstract functionalities that a NSF owns in terms of enforcement 18 actions, conditions that can apply in order to determine to which 19 packet or traffic enforce the actions, and other mechanisms that NSF 20 use to determine the actions to enforce. The proposed capability 21 model defines without ambiguities the operations a function can do in 22 term of security policy enforcement. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Policy model . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Geometric model of policies . . . . . . . . . . . . . . . 4 62 3.2. Condition types . . . . . . . . . . . . . . . . . . . . . 7 63 4. Capability Model . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Algebra of capabilities . . . . . . . . . . . . . . . . . 9 65 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 Security Capabilities are intended to describe the potentiality that 73 Network Security Functions (NSFs) have for security policy 74 enforcement purposes. Security Capabilities are abstract concepts 75 that are independent of the actual security control that will 76 implement them. However, every NSF will be associated to the 77 capabilities it owns. Security Capabilities are required to allow 78 interoperability among network functions. It would be a market 79 enabler having a way to substitute a NSF with an equivalent one 80 (i.e., having the same functionality). Moreover, Security 81 Capabilities are very useful to reason about generic functions, which 82 may be needed at design time. That is, it is not needed to refer to 83 a specific product when designing the network, rather the functions 84 characterized by their capabilities are considered. 86 Therefore, we have developed another model where Security 87 Capabilities determine what a security control can do in terms of 88 conditions, actions, resolution strategies, external data, if it 89 supports default action, etc. That is, the Security Capabilities 90 model defines without any ambiguity the things a function can do in 91 term of security policy enforcement. The Security Capability model 92 is built on a predefined general policy model. The type of policies 93 that a NSF can enforce are obtained by customizing the general policy 94 model with the Security Capability information. 96 The Capability Model has been designed to support at least capability 97 matching, i.e., to identify the NSFs in a catalog that can perform 98 the operations required to enforce a high-level policy. 100 Moreover, the Capability Model has been preliminarily validated by 101 verifying that is allows the correct description of several existing 102 security controls. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 In this document, these words will appear with that interpretation 111 only when in ALL CAPS. Lower case uses of these words are not to be 112 interpreted as carrying RFC-2119 significance. 114 3. Policy model 116 The starting point of the design of our capability model is a simple 117 observation. As human beings, we all understand immediately each 118 other when we refer to security controls by just naming their 119 category. For instance, experts agree on what is a NAT, a filtering 120 control, or a VPN concentrator. Network security experts 121 unequivocally refer to ``packet filters'' as stateless devices able 122 to allow or deny packets forwarding based on conditions on source and 123 destination IP addresses, source and destination ports, and IP 124 protocol type fields [Alshaer]. Moreover, it is known that packet 125 filter rules are prioritized and it is possible to specify a default 126 action. More precisely, packet filters implement the First Matching 127 Rule (FMR) or Last Matching Rule (LMR) resolution strategies. 129 However, we feel the need for more information in case of other 130 devices, like stateful firewalls or application layer filters. These 131 devices filter packets or communications, but there are differences 132 among products in the packets and communications that they can 133 categorize and the states they maintain. Analogous considerations 134 can be applied for channel protection protocols, where we all 135 understand that they will protect packets by means of symmetric 136 algorithms whose keys could have been negotiated with asymmetric 137 cryptography, but they may work at different layers and support 138 different algorithms and protocols. To ensure protection, these 139 protocols apply integrity, optionally confidentiality, apply anti- 140 reply protections, and authenticate peers. 142 3.1. Geometric model of policies 144 We refer in this paper to the policy model defined in [Bas12] as 145 geometric model, which is summarized here. Policies are specified by 146 means of a set of rules in the ``if condition then action'' format 147 [RFC3198]. Rules are formed by a condition clause and an action 148 clause. All the actions available to the security function are well 149 known and organized in an action set A. 151 For filtering controls, the enforceable actions are Allow and Deny, 152 thus A={Allow,Deny}. For channel protection controls, they may be 153 informally written as ``enforce confidentiality'', ``enforce data 154 authentication and integrity'', and ``enforce confidentiality and 155 data authentication and integrity''. However, these actions need to 156 be instantiated to the technology used, for instance AH-transport 157 mode and ESP-transport mode (and combinations thereof) are a more 158 precise and univocal definition of channel protection actions. 160 Conditions are typed predicates concerning a given selector. A 161 selector describes the values that a protocol field may take, e.g., 162 the IP source selector is the set of all possible IP addresses, and 163 it may also refer to the part of the packet where the values come 164 from, e.g., the IP source selector refers to the IP source field in 165 the IP header. Geometrically, a condition is the subset of its 166 selector for which it evaluates to true. A condition on a given 167 selector matches a packet if the value of the field referred to by 168 the selector belongs to the condition. For instance, in Figure 169 Figure 1 the conditions are s1 [ S1 (read as s1 subset of S1) and s2 170 [ S2 (s1 subset of S2), both s1 and s2 match the packet x1, while 171 only s2 matches x2. 173 S2 ^ Destination port 174 | 175 | 176 | x2 177 +........o 178 | . 179 | . 180 --+..................+------------------------------------+ 181 | | . | | 182 s | . | | 183 e | . | (rectangle) | 184 g | . | condition clause (c) | 185 m | . | here the action a is applied | 186 e | . | | 187 n | . | x1=point=packet | 188 t +..................|.............o | 189 | | . | . | 190 --+..................+------------------------------------+ 191 | . . . . 192 | . . . . 193 | . . . . 194 | . . . . 195 | . . . . 196 | . . . . 197 +--------------+---------+-------------+----------------------+------> 198 | |---- segment = condition in S1 -----| S1 199 + IP source 201 Figure 1: Geometric representation of a rule r=(c,a) that matches x1 202 but does not match x2. 204 To consider conditions in different selectors, the decision space is 205 extended using the Cartesian product because distinct selectors refer 206 to different fields, possibly from different protocol headers. 207 Hence, given a policy-enabled element that allows the definition of 208 conditions on the selectors S1, S2,..., Sm (where m is the number of 209 selectors available at the security control we want to model), its 210 selection space is: 212 S=S1 X S2 X ... X Sm 214 To consider conditions in different selectors, the decision space is 215 extended using the Cartesian product because distinct selectors refer 216 to different fields, possibly from different protocol headers. 218 Accordingly, the condition clause c is a subset of S: 220 c = s1 X s2 X ... X sm [ S1 \times S1 X S2 X ... X Sm = S 222 S represents the totality of the packets that are individually 223 selectable by the security control to model when we use it to enforce 224 a policy. Unfortunately, not all its subsets are valid condition 225 clauses: only hyper-rectangles or union of hyper-rectangles (as they 226 are Cartesian product of conditions) are valid. This is an intrinsic 227 constraint of the policy languages as they specify rules by defining 228 a condition for each selector. Languages that allow specification of 229 conditions as relations over more fields are modelled by the 230 geometric model as more complex geometric shapes determined by the 231 equations. However, the algorithms to compute intersections are much 232 more sophisticated than intersection hyper-rectangles. Figure 233 Figure 1 graphically represents a condition clause c in a two- 234 dimensional selection space. 236 In the geometric model, a rule is expressed as r=(c,a), where c [ S 237 (the condition clause is a subset of the selection space), and the 238 action a belongs to A. A condition clause of a rule matches a packet, 239 or briefly a rule matches a packet, if all the conditions forming the 240 clause match the packet: in Figure Figure 1, the rule with condition 241 clause c matches the packet x1 but not x2. 243 The rule set R is composed of n rules ri=(ci,ai). 245 The decision criteria for the action to apply when a packet matches 246 two or more rules is abstracted by means of the resolution strategy 247 RS: Pow(R) -> A, where Pow(R) is the power set of rules in R. 249 Formally, given a set of rules, the resolution strategy maps all the 250 possible subsets of rules to an action a in A. When no rule matches a 251 packet, the security controls may select the default action d in A, 252 if they support one. 254 Resolution strategies may use, besides intrinsic rule data (i.e., 255 condition clause and action clause), also ``external data'' 256 associated to each rule, such as priority, identity of the creator, 257 and creation time. Formally, every rule ri is associated by means of 258 the function e(.) to: 260 e(ri) = (ri,f1(ri),f2(ri),...) 262 where $E={fj:R -> Xj}j$ is the set that includes all the functions 263 that map rules to external attributes in Xj. However, E, e, and all 264 the Xj are determined by the resolution strategy used. 266 A policy is thus a function p: S -> A that connects each point of the 267 selection space to an action taken from the action set A according to 268 the rules in R. By also assuming RS(0)=d (where 0 is the empty-set) 269 and RS(ri)=ai, the policy p can be described with this formula 270 p(x)=RS(match{R(x)}). 272 Therefore, in the geometric model, a policy is completely defined by 273 the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS, 274 the set E of mappings to the external attributes, and the default 275 action d. 277 Note that, the geometric model also supports ECA paradigms by simply 278 modelling events like an additional selector. 280 3.2. Condition types 282 After having analysed the literature and the existing security 283 controls, we have categorized the types of selectors in exact match, 284 range-based, regex-based, and custom-match [Bas15][Lunt]. 286 Exact match selectors are (unstructured) sets: elements can only be 287 checked for equality, as no order is defined on them. As an example, 288 the protocol type field of the IP header is a unordered set of 289 integer values associated to protocols. 291 Range-based selectors are ordered sets where it is possible to 292 naturally specify ranges as they can be easily mapped to integers. 293 As an example, the ports in the TCP protocol are well represented 294 using a range-based selector (e.g., 1024-65535). We include in the 295 range-based selectors all the category of selectors that have been 296 defined by Al-Shaer et al. as prefix match [Alshaer]. These 297 selectors allow the specification of ranges of values by means of 298 simple regular expressions. The typical case is the IP address 299 selector (e.g., 10.10.1.*). There is no need to distinguish between 300 prefix match and range-based selectors as 10.10.1.* easily maps to 301 [10.10.1.0, 10.10.1.255]. 303 Another category of selector types includes the regex-based 304 selectors, where the matching is performed by using regular 305 expressions. This selector type is frequent at the application 306 layer, where data are often represented as strings of text. The 307 regex-based selector type also includes as sub-case the string-based 308 selectors, where matching is evaluated using string matching 309 algorithms (SMA) [Cormen] Indeed, for our purposes, string matching 310 can be mapped to regular expressions, even if in practice SMA are 311 much faster. For instance, Squid (http://www.squid-cache.org/), a 312 popular Web caching proxy that offers various access control 313 capabilities, allows the definition of conditions on URLs that can be 314 evaluated with SMA (e.g., dstdomain) or regex matching (e.g., 315 dstdom_regex). 317 Finally, we introduce the idea of custom check selectors. For 318 instance the malware analysis looks for specific patterns and returns 319 a Boolean value is an example of custom check selector, if the logic 320 of checking is not seen (nor really interesting) from the outside. 321 In order to be properly used by high-level policy based processed 322 (like reasoning systems, refinement systems) these custom check 323 selector need at least to be described as black-boxes, that is, the 324 list of fields that they process (inputs) in order to return the 325 Boolean verdict (output). 327 4. Capability Model 329 Our model of capabilities is based on actions and traffic 330 classification features. Indeed, the need for enforcing one of the 331 actions that a security control can apply to packets/flows is the 332 main reason to use a security control. Moreover, security controls 333 have classification features that permit the identification of the 334 target packets/flows of the actions enforced, i.e., the selectors 335 presented in Section 3.1. A security manager decides for a specific 336 security control depending on the actions and classification 337 features. If the security control can enforce the needed actions and 338 has the classification features needed to identify the packets flows 339 required by a policy, then the security control is capable of 340 enforcing the policy. Our refinement model needs to know NSFs 341 capabilities to perform its operations. 343 However, security controls may have specific characteristics that 344 automatic processes or administrators need to know when they have to 345 generate configurations, like the available resolution strategies and 346 the possibility to set default actions. We have ignored, to simplify 347 this presentation, options to generate configurations that may have 348 better performance, like the use of chains or ad hoc structures 349 [Taylor]. Adding support to these forms of optimization is certainly 350 feasible with a limited effort but it was outside the scope of this 351 paper, that is, to show that adding security awareness to NFV 352 management and orchestration features is possible. It is one of the 353 task for future work. 355 Capabilities can be used for two purposes: describing generic 356 security functions, and describing specific products. With the term 357 generic security function (GNSF) we denote known classes of security 358 functions. The idea is to have generic components whose behaviour is 359 as well understood as for the network components (i.e., a switch is a 360 switch and we know to use it even if it may have some vendor-specific 361 functions). These generic functions can be substituted by any 362 product that owns the required capability at instantiation time. 364 We have analysed several classes of NSFs to prove the validity of our 365 approach. We found the common features and defined a set of generic 366 NSFs, including packet filter, URL filter, HTTP filter, VPN gateway, 367 anti-virus, anti-malware, content filter, monitoring, anonymity proxy 368 that will be described in a data model TBD. 370 Moreover, we have also categorized common extensions of the generic 371 NSFs, packet filters that may decide based on time information. 372 Moreover, some other packet filters add stateful features at ISO/OSI 373 layer 4. 375 The next section will introduce our algebra to compose capabilities, 376 defined to associate NSFs to capabilities and to check whether a NSF 377 has the capabilities needed to enforce policies. 379 4.1. Algebra of capabilities 381 Our capabilities are defined by a 4-tuple: 383 (Ac; Cc; RSc; Dc) [ (AC; CC; RSC; DC)= K 385 where AC is the set of all the supported actions, CC is set of all 386 the supported conditions types, RSC is the set of all the supported 387 resolutions strategies, and Dc [ DC={F} U A, where F indicates that 388 the default action is supported and can be freely selected by the 389 policy editor, and explicitly indicates the default action if this 390 cannot be explicitly configured. 392 We defined a syntax to specify: 394 o subsets of actions: Ac={a:action1,a:action2,...} [ AC 396 o subset of conditions: Cc={c:cond1,c:cond2,} [ CC 398 o subset of resolution strategies RSc={rs:res1,rs:res2,...} [ RSC 399 Given cap1=(Ac1,Cc1,RSc1,def1) and cap2=(Ac2,Cc2,RSc2,def2), we 400 define 402 o capability addition: cap1+cap2 = (Ac1 U Ac2, Cc1 U Cc2, RSc1, 403 def1) 405 o capability subtraction: cap_1-cap_2 = ({Ac1 \ Ac2,Cc1 \ 406 Cc2,RSc1,def1) 408 Note that addition and subtraction do not alter the resolution 409 strategy and the default action method, as our main intent was to 410 model addition of modules 412 As an example, a generic packet filter that supports the first 413 matching rule resolution strategies, allows the explicit 414 specification of default actions and also supports time-based 415 conditions. The description of its capabilities is the following: 417 o Apf = {a:Allow, a:Deny} 419 o Cpf= {c:IPsrc,c:IPdst,c:Psrc,c:Pdst,c:protType} 421 o Ctime = {c:timestart,c:days,c:datestart,c:datestop} 423 o cap_pf=(Apf; Cpf; {FMR}; F) 425 o cap_pf+time=cap_pf + Ctime 427 By abuse of notation, we wrote cap_pf+time=cap_pf + Ctime to shorten 428 the more correct expression cap_pf+time=cap_pf +(;Ctime;;)$. 430 5. References 432 5.1. Normative References 434 [I-D.ietf-i2nsf-framework] 435 elopez@fortinet.com, e., Lopez, D., Dunbar, L., Strassner, 436 J., Zhuang, X., Parrott, J., Krishnan, R., and S. Durbha, 437 "Framework for Interface to Network Security Functions", 438 draft-ietf-i2nsf-framework-02 (work in progress), 439 July 2016. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 443 RFC2119, March 1997, 444 . 446 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 447 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 448 J., and S. Waldbusser, "Terminology for Policy-Based 449 Management", RFC 3198, DOI 10.17487/RFC3198, 450 November 2001, . 452 5.2. Informative References 454 [Alshaer] Al Shaer, E. and H. Hamed, "Modeling and management of 455 firewall policies", 2004. 457 [Bas12] Basile, C., Cappadonia, A., and A. Lioy, "Network-Level 458 Access Control Policy Analysis and Transformation", 2012. 460 [Bas15] Basile, C. and A. Lioy, "Analysis of application-layer 461 filtering policies with application to HTTP", 2015. 463 [Cormen] Cormen, T., "Introduction to Algorithms", 2009. 465 [Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable 466 packet classification", 2003. 468 [Taylor] Taylor, D. and J. Turner, "Scalable packet classification 469 using distributed crossproducting of field labels", 2004. 471 Authors' Addresses 473 Cataldo Basile 474 Politecnico di Torino 475 Corso Duca degli Abruzzi, 34 476 Torino, 10129 477 Italy 479 Phone: +39 011 090 7173 480 Email: cataldo.basile@polito.it 482 Diego R. Lopez 483 Telefonica I+D 484 Zurbaran, 12 485 Madrid, 28010 486 Spain 488 Phone: +34 913 129 041 489 Email: diego.r.lopez@telefonica.com