idnits 2.17.1 draft-you-i2nsf-user-group-policy-capability-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2016) is 2839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7674 (Obsoleted by RFC 8955) == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-01 == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-01 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 Working Group J. You 3 Internet-Draft J. Strassner 4 Intended status: Standards Track Huawei 5 Expires: January 19, 2017 M. Zarny 6 Independent 7 C. Jacquenet 8 France Telecom 9 S. Majee 10 F5 Networks 11 July 18, 2016 13 User-Group-based Security Policy for Capability Layer 14 draft-you-i2nsf-user-group-policy-capability-00 16 Abstract 18 This draft defines the I2NSF Capability APIs for implementing User- 19 Group-based Security Policies using the Event-Condition-Action 20 Policy Rule paradigm. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 19, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Abbreviations and Acronyms . . . . . . . . . . . . . . . 3 65 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Alternative 1: Using Packet User-Group Labels . . . . . . 4 68 3.2. Alternative 2: Using User-group IDs Directly . . . . . . 5 69 4. ECA for User-group-based Security Policy . . . . . . . . . . 5 70 4.1. Information Model Design . . . . . . . . . . . . . . . . 6 71 4.2. FlowSpecECAPolicyRule Class Definition . . . . . . . . . 6 72 4.3 Event . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.4. Condition . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.5. Action . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.5.1. Traffic-rate Action . . . . . . . . . . . . . . . . . 8 76 4.5.2. Traffic-detail Action . . . . . . . . . . . . . . . . 9 77 4.5.3. Redirect Action . . . . . . . . . . . . . . . . . . . 9 78 4.5.4. Traffic-marking Action. . . . . . . . . . . . . . . . 9 79 4.6. Capability Layer Rules . . . . . . . . . . . . . . . . . 9 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 8.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 In traditional networks, network access is typically controlled 91 through a combination of mechanisms. These include maintaining 92 separate static VLAN/IP subnet assignments per organization, 93 applying Control Lists (ACLs) on VLANs and/or IP subnets, and 94 leveraging Network Access Control(NAC). However, traditional access 95 control mechanisms ([I-D.ietf-i2nsf-problem-and-use-cases]) do not 96 work well with newer network paradigms and architectures. Most 97 network administrators have to manually plan and implement necessary 98 changes because little, if any, automation exists across diverse 99 sets of network security platforms. 101 [I-D.you-i2nsf-user-group-based-policy] discusses User-Group aware 102 Policy Control (UAPC). This facilitates consistent enforcement of 103 policies based on User-Group identity, since the User-Group IDs are 104 generated by a set of ECA Policy Rules. It also discusses how this 105 can be used in the I2NSF Service Layer [I-D.ietf-i2nsf-framework]. 106 The UAPC mechanism calls for: (1) a User-Group identifier (e.g., 107 source and destination IP address, time-of-day, device certificate, 108 or a combination of these and other similar attributes); (2) a 109 policy server service that maintains policies for defining and 110 managing user-groups as well as permissions associated with 111 user-groups; and (3) a logical security controller that is 112 responsible for managing Network Security Functions (NSFs), and 113 installing necessary policies on them. 115 This document proposes I2NSF capability layer APIs for implementing 116 User-Group-based security policies by using the Event-Condition- 117 Action (ECA) Policy Rule paradigm. 119 2. Terminology 121 This section contains terminology and definitions that are important 122 for understanding the technical content of this document. 124 2.1. Abbreviations and Acronyms 126 AAA: Authentication, Authorization, and Accounting 127 ECA: Event-Condition-Action 128 NSF: Network Security Function 129 UAPC: User-Group Aware Policy Control 130 VRF: Virtual Routing and Forwarding instance 132 2.2. Definitions 134 Event: An event is defined as any important occurrence in time of 135 a change in the system being managed, and/or in the environment of 136 the system being managed. An Event, when used in the context of a 137 Policy Rule, is used to determine whether the Condition clause of 138 an imperative Policy Rule can be evaluated or not. For an ECA 139 Policy Rule, if the Event clause is TRUE, then the Condition 140 Clause MUST be evaluated. 142 Condition: A set of attributes, features, and/or values that are 143 to be compared with a set of known attributes, features, and/or 144 values in order to make a decision. A Condition, when used in the 145 context of a Policy Rule, is used to determine whether or not the 146 set of Actions in that Policy Rule can be executed or not. For an 147 ECA Policy Rule, if the Condition clause is TRUE, then at least 148 one Action contained in this ECA Policy Rule MUST be evaluated. 150 Action: An Action is a set of purposeful activity that has 151 associated behavior. An Action, when used in the context of a 152 Policy Rule, may be executed when both the Event and the Condition 153 clauses of its owning Policy Rule evaluate to true. The execution 154 of this Action MAY be influenced by applicable metadata. 156 3. Overall Architecture 158 The Security Controller coordinates various network security-related 159 tasks on a set of NSFs under its administration, and invokes the set 160 of NSFs that are required to implement security for particular 161 packets. 163 The NSF may match on User-Group IDs in the packets, or it may match 164 on common packet header fields such as an n-tuple, and then map the 165 n-tuple to the appropriate User-Group ID supplied out-of-band by the 166 Security Controller. If the packet matches a specified User-Group 167 ID, the NSF enforces the corresponding policies. 169 The interface between the Security Controller and the NSF is called 170 the capability interface in the I2NSF context. This document 171 describes the I2NSF capability layer API for implementing User-Group- 172 based security policies by using policy rules that are defined in an 173 Event-Condition-Action (ECA) structure. 175 +--------+ +-----------+ 176 | Policy +--------+ Security | 177 | Server | | Controller| 178 +----+---+ +-----+-----+ 179 | | 180 +----+---+ | 181 | AAA | | NSF- Facing 182 | Server | | Interface 183 +--------+ | 184 | 185 +------------+-----------+-------+--------+-----------+ 186 | | | | | 187 | | | | | 188 +----+----+ +----+---+ +----+---+ +----+---+ +----+---+ 189 | Ingress | | NSF #1 | | NSF #2 | ... | NSF #n | | Egress | 190 +---------+ +--------+ +--------+ +--------+ +--------+ 192 Figure 1. Functional Architecture 194 3.1. Option 1: Using Packet User-Group Labels 196 This option empoloys the User-Group Label (UGL), a packet header 197 field, to carry the User-Group ID. UGLs are disseminated using 198 the Registration Interface (see [I-D.ietf-i2nsf-terminology] and 199 [I-D.ietf-i2nsf-framework]). 201 UGLs work in a 'UGL-capable' domain. This is a domain in which all 202 NSFs residing in that domain support both the UGL field as well as 203 mapping the UGL field (and hence, the User-Group ID that the UGL 204 field represents) to a set of ECA Policy Rules. 206 In this alternative, the ingress NSF matches on common packet header 207 fields, such as an n-tuple, and then maps the n-tuple to the 208 appropriate User-Group ID supplied out-of-band by the Security 209 Controller. Then, the ingress NSF inserts the corresponding UGL 210 into the packet. The UGL is used by NSFs to make forwarding 211 decisions in the UGL-supported domain. 213 The UGL field can be inserted into the packet using, for example, 214 SFC encapsulation [I-D.ietf-sfc-nsh]. One benefit of option 1 is 215 that only edge NSFs need to do UGL insertion or removal; other NSFs 216 can easily enforce User-Group based policies based on the UGL 217 carried in the packet. If the UGL field does not match any policy, 218 a UGL-compliant NSF may apply a default policy, such as dropping or 219 forwarding, to the packet. For example, if no policy is matched, 220 firewalls typically will drop the packet, since Firewalls define a 221 deny action as the default action to use. 223 3.2. Option 2: Using User-0Group IDs Directly 225 This alternative option relies on all NSFs being able to identify 226 appropriate fields in a packet, map them to an appropriate User- 227 Group, and then use that User-Group to control actions on the packet. 228 In this option, User-Groups are disseminated using the Registration 229 Interface. 231 The Ingress NSF matches on common packet header fields, such as an 232 n-tuple, and then maps the n-tuple to the appropriate User-Group ID 233 (which is supplied out-of-band by the Security Controller). Then, 234 the ingress NSF enforces User-Group Policy Rules based on the 235 identified User-Group ID, without inserting any field into the 236 packet. Hence, option 2 requires all NSFs on the forwarding path to 237 support User-Group mapping. If the NSF fails to associate the packet 238 with a User-Group, it may use a default Policy Rule that is 239 associated with, for example, a default unknown User-Group. The 240 Policy associated with the default unknown User-Group should then be 241 enforced. For example, an unknown User-Group could be mapped to a 242 null VLAN, and a message sent to the appropriate Controller to 243 perform basic security checking on it and then assign a real 244 User-Group to the packet or flow (and a corresponding VLAN). 246 4. ECA for User-group-based Security Policy 248 This document uses Policy Rules, in the form of an Event-Condition- 249 Action (ECA) structure, to describe User-Group-based security 250 policies. 252 The fundamental constructs of ECA languages are reactive rules of the 253 form: 255 IF the event clause evaluates to TRUE 256 IF the condition clause evaluates to TRUE 257 THEN execute actions in the action clause 258 ENDIF 259 ENDIF 261 The Event clause, Condition clause, and Action clause collectively 262 form a three-tuple. The Event and Condition clauses are made up of 263 one or more Boolean statements. If the Event clause evaluates to 264 FALSE, execution stops. If the Event clause evaluates to TRUE, then 265 the Condition clause is evaluated. Once again, if the Condition 266 clause evaluates to FALSE, execution stops; otherwise, Actions in 267 the Policy Rule may be executed. 269 4.1. Information Model Design 271 The information model design for User-Group-based Security Policies 272 is based on the information model design of the capability interface 273 [I-D.draft-xia-i2nsf-capability-interface-im]. 275 It is assumed that an external model, or set of models, is used to 276 define the concept of an ECA Policy Rule and its components (e.g., 277 Event, Condition, and Action objects). A functional block diagram of 278 the ECA Model is shown in Figure 2 below: 280 +-------------------------+ 0..n 0..n +-----------------+ 281 | |/ \ \| External Common | 282 | External ECA Info Model + A ---------------+ Superclass for | 283 | |\ / Aggregates /| ECA Objects | 284 +----------+--------------+ ECAObjects +--------+--------+ 285 / \ / \ 286 | | 287 | | 288 +-----------+-----------+ +-------------+------+-----+ 289 | SecurityECAPolicyRule | | | | 290 +-----------+-----------+ | | | 291 | +-----+----+ +------+----+ +-----+----+ 292 | | External | | External | | External | 293 | | Event | | Condition | | Action | 294 | +-----+----+ +-----+-----+ +-----+----+ 295 +------+---------+ | | | 296 | | | | | 297 +------+--------+ / \ / \ / \ / \ 298 | FlowSpec | Other Security Security Other 299 | ECAPolicyRule | SecurityECA Events Conditions Actions 300 +---------------+ PolicyRules 302 Figure 2. High-Level Information Model Design 304 The SecurityECAPolicyRule is the top of the User-Group ECA Policy 305 Rule hierarchy. It inherits from the (external) generic ECA Policy 306 Rule to define Security ECA Policy Rules that are specific to 307 managing User-Groups. The SecurityECAPolicyRule contains all of the 308 attributes, methods, and relationships defined in its (generic) 309 superclass, and adds additional concepts that are required for 310 Network Security (these will be defined in the next version of this 311 draft). 313 The AggregatesECAObjects relationship defines the set of Events, 314 Conditions, and Actions that are aggregated by a specific 315 ECAPolicyRule. This aggregation is inherited by all subclasses of 316 SecurityECAPolicyRule. 318 This draft defines a single subclass of SecurityECAPolicyRule, called 319 FlowSpecECAPolicyRule. Additional ECA Policy Rules will be defined in 320 future versions of this draft. 322 This draft defines four subclasses of the (external) generic Action 323 class. Additional Event, Condition, and Action subclasses will be 324 defined in future versions of this draft. Note that any of the 325 Events, Conditions, and Actions defined in [I-D.draft-xia-i2nsf- 326 capability-interface-im] can also be used; this is because the 327 FlowSpecECAPolicyRule is really a container, which is meant to 328 aggregate Events, Conditions, and Actions. The Flow Spec Rule is 329 is thus generic; application-specific needs are provided by 330 choosing a suitable set of Events, Conditions, and Actions. 332 It is assumed that the (external) generic ECAPolicyRule class 333 defines basic information in the form of attributes, such as an 334 unique object ID, as well as a description and other basic, but 335 necessary, information. It is also assumed that the (external) 336 generic ECA Policy Rule is abstract; the SecurityECAPolicyRule is 337 also abstract. This enables data model optimizations to be made 338 while making this information model detailed but flexible and 339 extensible. 341 The SecurityECAPolicyRule defines network security policy as a 342 container that aggregates Event, Condition, and Action objects, 343 which are described in Sections 4.3, 4.4, and 4.5, respectively. 344 Events, Conditions, and Actions can be generic or security-specific. 346 Brief class descriptions of these classes are provided in the 347 following sub-sections. In addition, none of the ECAPolicyRule 348 subclasses will define attributes. This enables them to be viewed 349 as simple object containers, and hence, applicable to a wide 350 variety of content. It also means that the content of the function 351 is defined solely by the set of Events, Conditions, and Actions 352 that are contained by the particular subclass. This enables the 353 Policy Rule, with its aggregated set of Events, Conditions, and 354 Actions, to be treated as a reusable object. 356 4.2. FlowSpecECAPolicyRule Class Definition 358 The purpose of a FlowSpecECAPolicyRule is to define an ECA Policy 359 Rule that can invoke FlowSpecs as Actions. The set of invoked 360 Actions are triggered by a set of Events and Conditions. This ECA 361 Policy Rule serves as a reusable container, and hence, the set of 362 Events, Conditions, and Actions that it aggregates are also reused. 364 4.3. Event 366 Events are external stimuli, such as alarms, user actions (e.g., 367 logon and logoff, or access requests), and packet arrival or 368 departure occurrences. A set of exemplary Events are defined in 369 [I-D.draft-xia-i2nsf-capability-interface-im]. 371 4.4. Condition 373 Conditions are typically attributes or values that affect the state 374 of a managed entity. These include: 376 - n-tuple of the incoming packet 377 - cross checking with other data, such as correlation with 378 packets received from different ports or past time, or 379 - the current state of a flow 381 A set of exemplary Conditions are defined in 382 [I-D.draft-xia-i2nsf-capability-interface-im]. 384 4.5. Action 386 This document defines a minimum set of Actions. The first set of 387 Actions are, based on [RFC5575] and [RFC7674]. This is not meant 388 to be an inclusive list of all possible Actions, but only a subset 389 that pertain specifically to flows, which can be interpreted 390 consistently across the network. Other Actions will be defined in 391 future versions of this document. An exemplary set of additional 392 Actions is defined in [I-D.draft-xia-i2nsf-capability-interface-im]. 394 Note that [RFC5575] and [RFC7674] define a general procedure to 395 encode flow specification rules for aggregated traffic flows, so 396 that they can be distributed as BGP [RFC4271] network layer 397 reachability information. 399 4.5.1. Traffic-rate Action 401 The traffic-rate instructs a system to shape a certain stream to a 402 set of predefined bandwidth characteristics. This is implemented 403 using BGP extended community values attributes [RFC4360]. A 404 traffic-rate of 0 should result in all traffic for this particular 405 flow to be discarded. 407 4.5.2. Traffic-deetail Action 409 The traffic-detail enables traffic sampling and logging for a 410 particular flow. This is implemented using BGP extended community 411 values attributes [RFC4360]. 413 4.5.3. Redirect Action 415 The Redirect allows the traffic to be redirected to a specified VRF 416 routing instance that lists the specified route-target in its import 417 policy. This is implemented using BGP extended community values 418 attributes [RFC4360]. 420 4.5.4. Traffic-marking Action 422 The Traffic-marking instructs a system to modify the DSCP bits of a 423 transiting IP packet to the corresponding value. This is implemented 424 using BGP extended community values attributes [RFC4360]. 426 4.6. Capability Layer Rules 428 This will be completed in the next version of this document. 430 5. Security Considerations 432 This document provides an Event-Condition-Action model for describing 433 user-group-based security policies. It is not intended to represent 434 any particular system design or implementation, nor does it define a 435 protocol, and as such it does not have any specific security 436 requirements. 438 6. IANA Considerations 440 This document has no actions for IANA. 442 7. Acknowledgements 444 TBD. 446 8. References 448 8.1. Normative References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 456 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 457 DOI 10.17487/RFC4271, January 2006, 458 . 460 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 461 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 462 February 2006, . 464 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 465 and D. McPherson, "Dissemination of Flow Specification 466 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 467 . 469 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 470 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 471 October 2015, . 473 8.2. Informative References 475 [I-D.ietf-i2nsf-problem-and-use-cases] 476 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 477 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 478 ietf-i2nsf-problem-and-use-cases-01 (work in progress), 479 July 2016. 481 [I-D.ietf-i2nsf-framework] 482 Lopez, E., Lopez, D., Dunbar, L., Strassner, J., Zhuang, 483 J., Parrott, J., Krishnan, R., Durbha, S., "Framework for 484 Interface to Network Security Functions", 485 draft-ietf-i2nsf-framework-02 (work in progress), 486 July 2016 488 [I-D.ietf-sfc-nsh] 489 Quinn, P. and Elzur, U., "Network Service Header", 490 draft-ietf-sfc-nsh-05 (work in progress), May 2016. 492 [I-D.you-i2nsf-user-group-based-policy] 493 You, J., Zarny, M., Jacquenet, C., Boucadair, M., Yizhou, 494 L., Strassner, J., and S. Majee, "User-group-based 495 Security Policy for Service Layer", draft-you-i2nsf-user- 496 group-based-policy-02 (work in progress), July 2016. 498 [I-D.draft-xia-i2nsf-capability-interface-im] 499 Xia, L. Strassner, J., Li, K., Zhang, D., Lopez, E., 500 Bouthors, N., Fang, L., "Information Model of Interface 501 to Network Security Functions Capability interface", 502 draft-xia-i2nsf-capability-interface-im-06 (work in 503 progress), July 2016 505 [I-D.ietf-i2nsf-terminology] 506 Hares, S., Strassner, J., Lopez, D., Xia, L., "Interface 507 to Network Security Functions (I2NSF) Terminology", 508 draft-ietf-i2nsf-terminology-01, July 2016 510 Authors' Addresses 512 Jianjie You 513 Huawei 514 101 Software Avenue, Yuhuatai District 515 Nanjing, 210012 516 China 517 Email: youjianjie@huawei.com 519 John Strassner 520 Huawei 521 2330 Central Expressway 522 San Jose, CA 523 USA 524 Email: john.sc.strassner@huawei.com 526 Myo Zarny 527 Independent 528 Email: myo.zarny@gmail.com 530 Christian Jacquenet 531 France Telecom 532 Rennes 35000 533 France 534 Email: christian.jacquenet@orange.com 536 Sumandra Majee 537 F5 Networks 538 3545 N 1st St 539 San Jose, CA 95134 540 Email: S.Majee@f5.com