idnits 2.17.1 draft-merged-i2nsf-framework-04.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 440 has weird spacing: '...| Layer heade...' -- The document date (October 19, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF-Mobile' is mentioned on line 112, but not defined == Missing Reference: 'MPTCP' is mentioned on line 313, but not defined == Missing Reference: 'RFC3286' is mentioned on line 314, but not defined == Unused Reference: 'I2NSF-MOBILE' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'NW-2011' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'SC-MobileNetwork' is defined on line 865, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Lopez 2 Internet Draft Fortinet 3 Intended status: Informational D. Lopez 4 Expires: April 2016 Telefonica 5 L. Dunbar 6 J. Strassner 7 Huawei 8 X. Zhuang 9 China Mobile 10 J. Parrott 11 BT 12 R Krishnan 13 Dell 14 S. Durbha 15 CableLabs 17 October 19, 2015 19 Framework for Interface to Network Security Functions 20 draft-merged-i2nsf-framework-04.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be modified, 29 and derivative works of it may not be created, except to publish it 30 as an RFC and to translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on April 19, 2009. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Abstract 66 This document defines a set of abstractions for guiding the 67 functionality provided by I2NSF. In the design of interfaces to 68 allow for the provisioning of network security functions (NSFs), a 69 critical consideration is to prevent the creation of implied 70 constraints on NSF capability and functionality. 72 This document makes the recommendation that such interfaces be 73 designed from the paradigm of processing packets and flows on the 74 network. NSFs ultimately are packet-processing engines that inspect 75 packets traversing networks, either directly or in the context of 76 sessions in which the packet is associated. 78 Table of Contents 80 1. Introduction...................................................3 81 2. Conventions used in this document..............................4 82 3. Interfaces to Flow-based NSFs..................................4 83 4. Reference Models in Managing NSFs..............................6 84 4.1. NSF Facing (Capability Layer) Interface...................7 85 4.2. Client Facing (Service Layer) Interface...................7 86 4.3. Vendor Facing Interface...................................8 87 4.4. The network connecting the Security Controller and NSFs...8 88 4.5. Interface to vNSFs........................................9 89 5. Flow-based NSF Capability Characterization....................10 90 6. Structure of Rules for governing NSFs.........................14 91 6.1. Capability Layer Rules and Monitoring....................14 92 6.2. Service Layer Policy.....................................16 93 7. Capability Negotiation........................................19 94 8. Types of I2NSF clients........................................19 95 9. Manageability Considerations..................................20 96 10. Security Considerations......................................20 97 11. IANA Considerations..........................................20 98 12. References...................................................21 99 12.1. Normative References....................................21 100 12.2. Informative References..................................21 101 13. Acknowledgments..............................................22 103 1. Introduction 105 This document describes the framework for the Interface to Network 106 Security Functions (I2NSF), and defines a reference model along with 107 functional components for I2NSF. It also describes how I2NSF 108 facilitates Software-defined network (SDN) and Network Function 109 Virtualization (NVF) control, while avoiding potential constraints 110 that could limit NSFs internal functionality and capability. 112 The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile]) 113 call for standard interfaces for clients (e.g., applications, 114 application controllers, or users), to inform the network what they 115 are willing to receive, in other words, the security rules for their 116 specific traffic. It also provides a standard interface for them to 117 monitor the security functions hosted and managed by service 118 providers. 120 [I2NSF-Problem] describes the motivation and the problem space for 121 Interface to Network Security Functions. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC-2119 [RFC2119]. 129 In this document, these words will appear with that interpretation 130 only when in ALL CAPS. Lower case uses of these words are not to be 131 interpreted as carrying RFC-2119 significance. 133 BSS: Business Support System 135 Controller: used interchangeably with Service Provider Security 136 Controller or management system throughout this 137 document. 139 FW: Firewall 141 IDS: Intrusion Detection System 143 IPS: Intrusion Protection System 145 NSF: Network Security Functions, defined by [I2NSF-Problem] 147 OSS: Operation Support System 149 vNSF: refers to NSF being instantiated on Virtual Machines. 151 3. Interfaces to Flow-based NSFs 153 The emergence of SDN and NFV has resulted in the need to create 154 application programming interfaces (APIs) in support of dynamic 155 requests from various applications or application controllers. Flow- 156 based NSFs [I2NSF-Problem] inspects packets in the order that they 157 are received. 159 The Interface to Flow-based NSFs can be generally grouped into three 160 types: 162 1) Configuration - deals with the management and configuration of 163 the NSF device itself, such as port address configurations. 164 Configuration deals with attributes that are relatively static. 166 2) Signaling - which represents logging and query functions between 167 the NSF and external systems. Signaling API functions may also be 168 well defined by other protocols such as SYSLOG, DOTS, etc. 170 3) Rules Provisioning - used to control the rules that govern how 171 packets are treated by the NSFs. Due to the need of 172 applications/controllers to dynamically control what traffic they 173 need to receive, much of the I2NSF efforts towards interface 174 development will be in this area. 176 This draft proposes that a rule provisioning interface to NSFs can 177 be developed on a packet-based paradigm. While there are many 178 classifications of existing and emerging NSFs, a common trait shared 179 by them is in the processing of packets based on the content 180 (header/payload) and context (session state, authentication state, 181 etc) of received packets. 183 An important concept is the fact that attackers do not have 184 standards as to how to attack networks, so it is equally important 185 not to constrain NSF developers to offering a limited set of 186 security functions. In other words, the introduction of I2NSF 187 standards should not make it easier for attackers to compromise the 188 network. Therefore, in constructing standards for rules provisioning 189 interfaces to NSFs, it is equally important to allow support for 190 vendor-specific functions, to allow the introduction of NSFs that 191 evolve to meet new threats. Proposed standards for rules 192 provisioning interfaces to NSFs SHOULD NOT: 194 - Narrowly define NSF categories, or their roles when implemented 195 within a network 197 - Attempt to impose functional requirements or constraints, either 198 directly or indirectly, upon NSF developers 200 - Be a limited lowest-common denominator approach, where interfaces 201 can only support a limited set of standardized functions, without 202 allowing for vendor-specific functions 203 - Be seen as endorsing a best-common-practice for the implementation 204 of NSFs 206 By using a packet-based approach to the design of such provisioning 207 interfaces, the goal is to create a workable interface to NSFs that 208 aids in their integration within legacy, SDN, and/or NFV 209 environments, while avoiding potential constraints which could limit 210 their functional capabilities. 212 Even though security functions come in a variety of form factors and 213 have different features, provisioning to Flow-based NSFs can be 214 categorized by 216 - Subject-Match values, based on packet data, packet header, or 217 packet payload, which can be one or more header fields or bits 218 in the packets, or the various combination of them; 219 - Object-Match values, based on context (e.g., state, direction of 220 the traffic, time, geo-location, etc.); 221 - Action-Egress processing, such as invoke signaling, packet 222 forwarding and/or transformation, SDN/NFV integration; 223 - Functional Profile - a functional profile is a specific 224 organization of characteristics and/or behavior of that define 225 the functionality offered by an entity (e.g., IPS:, 226 signature file, Anti-virus file, URL filtering file, etc.). 227 Integrated and one-pass checks on the content of packets are 228 examples of a functional profile. 230 The functional profile or signature file is one of the key 231 properties that determine the effectiveness of the NSF, and is 232 mostly vendor-specific today. 234 4. Reference Models in Managing NSFs 236 This document only focuses on the framework of rules provisioning 237 and monitoring of flow-based NSFs. 239 The following figure shows various interfaces for managing the 240 provisioning & monitoring aspects of flow-based NSFs. 242 +------------------------------------------+ 243 | Client or App Gateway | 244 | (e.g. Video conference Ctrl | 245 | Admin, OSS/BSS, or Service Orchestration)| 246 +-------+----------------------------------+ 247 | 248 | Client Facing (service layer) Interface 249 +-----+---------------+ 250 |Service Provider mgmt| +-------------+ 251 | Security Controller | < -------- > | Vendor | 252 +---------------------+ Vendor Facing| Sys | 253 | Interface +-------------+ 254 | 255 | NSF Facing (capability) Interface 256 | 257 +------------------------------------------------+ 258 | | 259 | | 260 +------+ +------+ +------+ +------+ 261 + NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . . 262 +------+ +------+ +------+ +------+ 264 Vendor A Vendor B 266 Figure 1: Multiple Interfaces 268 4.1. NSF Facing (Capability Layer) Interface 270 This is the interface between the Service Provider's management 271 system (or Security Controller) and the NSFs that are selected to 272 enforce the desired network security. This interface is called the 273 Capability Interface in the I2NSF context. 275 4.2. Client Facing (Service Layer) Interface 277 This interface is for clients or Application Controller to express 278 and monitor security policies for their specific flows. The Client 279 Facing interface is called the Server Layer Interface in the I2NSF 280 context. The I2NSF Service Layer allows the client to define and 281 monitor the client specific policies and their execution status. 283 A single client layer policy may need multiple NSFs or NSF 284 instantiations that are used collectively to achieve the desired 285 enforcement. 287 4.3. Vendor Facing Interface 289 When service providers have multiple types of security functions 290 provided by different vendors, it is necessary to have an 291 interface for vendors to register their NSFs indicating the 292 capabilities of their NSFs. 294 The Registration Interface can be defined statically or 295 instantiated dynamically at runtime. If new functionality that is 296 exposed to the user is added to an NSF, then the vendor MUST 297 notify the Service Provider management system of its updated 298 interface. 300 4.4. The network connecting the Security Controller and NSFs 302 Most likely, the NSFs are not directly attached to the Security 303 Controller; for example, NSFs can be distributed across the 304 network. The network that connects the Security Controller with 305 the NSFs can be the same network that carries the data traffic, or 306 can be a dedicated network for management purposes only. In either 307 case, packet loss could happen due to failure, congestion, or 308 other reasons. 310 Therefore, the transport mechanism used to carry the control 311 messages and monitoring information should provide reliable 312 message delivery. Transport redundancy mechanisms such as 313 Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission 314 Protocol (SCTP) [RFC3286] will need to be evaluated for 315 applicability. Latency requirements for control message delivery 316 must also be evaluated. 318 The connection between Security Controller and NSFs could be: 320 - Closed environments, where there is only one administrative 321 domain. Less restrictive access control and simpler validation 322 can be used inside the domain because of the protected 323 environment. 325 - Open environments, where some NSFs (virtual or physical) can be 326 hosted in external administrative domains or reached via 327 external network domains. This requires more restrictive 328 security controls to be placed over the I2NSF interface. The 329 information over the I2NSF interfaces must use trusted channels, 330 such as TLS, SASL (RFC4422), or the combination of the two. 332 Over the Open Environment, I2NSF needs to provide identity 333 information, along with additional data that Authentication, 334 Authorization, and Accounting (AAA) frameworks can use. This 335 enables those frameworks to perform AAA functions on the I2NSF 336 traffic. 338 4.5. Interface to vNSFs 340 Even though there is no difference between virtual network 341 security functions (vNSF) and physical NSFs from the policy 342 provisioning perspective, there are some unique characteristics in 343 interfacing to the vNSFs: 345 - There could be multiple instantiations of one single NSF being 346 distributed across a network. When different instantiations are 347 visible to the Security Controller, different policies may be 348 applied to different instantiations of one single NSF (e.g., to 349 reflect the different roles that each vNSF is designated for). 350 - When multiple instantiations of one single NSF appear as one 351 single entity to the Security Controller, the policy 352 provisioning has to be sent to the NSF's sub-controller, which 353 in turn disseminates the polices to the corresponding 354 instantiations of the NSF, as shown in the Figure 2 below. 355 - Policies to one vNSF may need to be retrieved and moved to 356 another vNSF of the same type when client flows are moved from 357 one vNSF to another. 359 - Multiple vNSFs may share the same physical platform 360 - There may be scenarios where multiple vNSFs collectively perform 361 the security policies needed. 363 +------------------------+ 364 | Security Controller | 365 +------------------------+ 366 ^ ^ 367 | | 368 +-----------+ +------------+ 369 | | 370 v v 371 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 372 | NSF-A +--------------+ | | NSF-B +--------------+ | 373 | |Sub Controller| | | |sub Controller| | 374 | +--------------+ | | +--------------+ | 375 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 376 | |+---------+ +---------+| | | |+---------+ +---------+| | 377 | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | 378 | |+---------+ +---------+| | | |+---------+ +---------+| | 379 | | NSF-A cluster | | | | NSF-B cluster | | 380 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 381 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 383 Figure 2: Cluster of NSF Instantiations Management 385 5. Flow-based NSF Capability Characterization 387 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 388 the commonly deployed flow-based NSFs. However, the differences 389 among them are definitely blurring, due to technological capacity 390 increases, integration of platforms, and new threats. At their core: 391 . Firewall - A device or a function that analyzes packet headers and 392 enforces policy based on protocol type, source address, 393 destination address, source port, destination port, and/or other 394 attributes of the packet header). Packets that do not match policy 395 are rejected. Note that additional functions, such as logging and 396 notification of a system administrator, could optionally be 397 enforced as well. 398 . IDS (Intrusion Detection System) - A device or function that 399 analyzes whole packets, both header and payload, looking for known 400 events. When a known event is detected, a log message is generated 401 detailing the event. Note that additional functions, such as 402 notification of a system administrator, could optionally be 403 enforced as well. 404 . IPS (Intrusion Prevention System) - A device or function that 405 analyzes whole packets, both header and payload, looking for known 406 events. When a known event is detected the packet is rejected. 407 Note that additional functions, such as logging and notification 408 of a system administrator, could optionally be enforced as well. 410 To prevent constraints on NSF vendors' creativity and innovation, 411 this document recommends the Flow-based NSF interfaces to be 412 designed from the paradigm of processing packets on the network. 413 Flow-based NSFs ultimately are packet-processing engines that 414 inspect packets traversing networks, either directly or in the 415 context of sessions in which the packet is associated. 417 Flow-based NSFs differ in the depth of packet header or payload they 418 can inspect, the various session/context states they can maintain, 419 and the specific profiles and the actions they can apply. An example 420 of a session is "allowing outbound connection requests and only 421 allowing return traffic from the external network". 423 Accordingly, the NSF capabilities are characterized by the level of 424 packet processing and context that a NSF supports, the profiles and 425 the actions that the NSF can apply. The term "context" includes 426 anything that can influence the action(s) taken by the NSF, such as 427 time of day, location, session state, and events. 429 Vendors can register their NSFs using the Subject-Object-Action- 430 Function categories described in Section 2, with detailed 431 specification of each category as shown in the table below: 433 +-----------------------------------------------------------+ 434 | Subject Capability Index | 435 +---------------+-------------------------------------------+ 436 | Layer 2 | Layer 2 header fields: | 437 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 438 | | | 439 |---------------+-------------------------------------------+ 440 | Layer 3 | Layer header fields: | 441 | | protocol | 442 | IPv4 Header | dest port | 443 | | src port | 444 | | src address | 445 | | dest address | 446 | | dscp | 447 | | length | 448 | | flags | 449 | | ttl | 450 | | | 451 | IPv6 Header | | 452 | | addr | 453 | | protocol/nh | 454 | | src port | 455 | | dest port | 456 | | src address | 457 | | dest address | 458 | | length | 459 | | traffic class | 460 | | hop limit | 461 | | flow label | 462 | | dscp | 463 | | | 464 | TCP | Port | 465 | SCTP | syn | 466 | DCCP | ack | 467 | | fin | 468 | | rst | 469 | | ? psh | 470 | | ? urg | 471 | | ? window | 472 | | sockstress | 473 | | Note: bitmap could be used to | 474 | | represent all the fields | 475 | | | 476 | UDP | | 477 | | flood abuse | 478 | | fragment abuse | 479 | | Port | 480 | HTTP layer | | 481 | | | hash collision | 482 | | | http - get flood | 483 | | | http - post flood | 484 | | | http - random/invalid url | 485 | | | http - slowloris | 486 | | | http - slow read | 487 | | | http - r-u-dead-yet (rudy) | 488 | | | http - malformed request | 489 | | | http - xss | 490 | | | https - ssl session exhaustion | 491 +---------------+----------+--------------------------------+ 492 | IETF PCP | Configurable | 493 | | Ports | 494 | | | 495 +---------------+-------------------------------------------+ 496 | IETF TRAM | profile | 497 | | | 498 | | | 499 |---------------+-------------------------------------------+ 500 Table 1: Subject Capability Index 502 +-----------------------------------------------------------+ 503 | Object (context) matching Capability Index | 504 +---------------+-------------------------------------------+ 505 | Session | Session state, | 506 | | bidirectional state | 507 | | | 508 +---------------+-------------------------------------------+ 509 | Time | time span | 510 | | time occurrence | 511 +---------------+-------------------------------------------+ 512 | Events | Event URL, variables | 513 +---------------+-------------------------------------------+ 514 | Location | Text string, GPS coords, URL | 515 +---------------+-------------------------------------------+ 516 | Connection | Internet (unsecured), Internet | 517 | Type | (secured by VPN, etc.), Intranet, ... | 518 +---------------+-------------------------------------------+ 519 | Direction | Inbound, Outbound | 520 +---------------+-------------------------------------------+ 521 | State | Authentication State | 522 | | Authorization State | 523 | | Accounting State | 524 | | Session State | 525 +---------------+-------------------------------------------+ 527 Table 2: Object Capability Index 529 +-----------------------------------------------------------+ 530 | Action Capability Index | 531 +---------------+-------------------------------------------+ 532 | Ingress port | SFC header termination, | 533 | | VxLAN header termination | 534 +---------------+-------------------------------------------+ 535 | | Pass | 536 | Actions | Deny | 537 | | Mirror | 538 | | Simple Statistics: Count (X min; Day;..)| 539 | | Client specified Functions: URL | 540 +---------------+-------------------------------------------+ 541 | Egress | Encap SFC, VxLAN, or other header | 542 +---------------+-------------------------------------------+ 543 Table 3: Action Capability Index 545 +-----------------------------------------------------------+ 546 | Functional profile Index | 547 +---------------+-------------------------------------------+ 548 | Profile types | Name, type, or | 549 | Signature | Flexible Profile/signature URL | 550 | | Command for Controller to enable/disable | 551 | | | 552 +---------------+-------------------------------------------+ 553 Table 4: Function Capability Index 555 6. Structure of Rules for governing NSFs 557 6.1. Capability Layer Rules and Monitoring 559 The purpose of the Capability Layer is to define explicit rules for 560 individual NSFs to treat packets, as well as methods to monitor the 561 execution status of those functions. 563 [ACL-MODEL] has defined rules for the Access Control List supported 564 by most routers/switches that forward packets based on packets' L2, 565 L3, or sometimes L4 headers. The actions for Access Control Lists 566 include Pass, Drop, or Redirect. 568 The functional profiles (or signatures) for NSFs are not present in 569 [ACL-MODEL] because the functional profiles are unique to specific 570 NSFs. For example, most vendors' IPS/IDS have their proprietary 571 functions/profiles. One of the goals of I2NSF is to define a common 572 envelop format for exchanging or sharing profiles among different 573 organizations to achieve more effective protection against threats. 575 The "subject" of the I2NSF policies should not only include the 576 matching criteria specified by [ACL-MODEL] but also the L4-L7 fields 577 depending on the NSFs selected. 579 The I2NSF Capability Layer has to specify the "Object" (i.e. the 580 context surrounding the packets). 582 The I2NSF "actions" should extend the actions specified by [ACL- 583 MODEL] to include applying statistics functions that clients 584 provide. 586 The rules for Flow-Based NSF can be extended from the Policy Core 587 Information Model [RFC3060] and Policy Core Information Model 588 Extension [RFC3460] which is the base for ITU-T X.1036 [ITU-T- 589 X1036]: 591 +-------------------------+ 592 | Capability-Layer-Rules | 593 +-------------------------+ 594 | | 595 +---------+ +--------+ +---------+ |- Pass 596 |Compound | | | | Simple +-|- Deny 597 |Condition| | action | +--+ Actions| |- Mirror 598 +----+----+ +----+---+ | +---------+ |- Count 599 |<-------+ +---------------+ |- client fun 600 +---+------+ | | 601 ++---+-----+| | | +---------+ 602 | simple || |Compound Operators: +--+ function| 603 |conditions|+ | Logical AND: && | Profile | 604 +--+-----+-+ | Logical OR: || +---------+ 605 | | | Logical NOT: ! 606 | +----+ 607 +-----------+ 608 +------+--+ +--+-----+ +---------+ 609 | Subject | | Object | | Time | 610 | Match | | Match | +--+---------+ 611 +-----+---+ +----+---+ | +---------+ 612 | +-------------------+--+ States | 613 | | +---------+ 614 +--+----------+----------+ | +---------+ 615 +--+----+ +--+---+ +--+---+ +--+ Port | 616 |IPv4 | |IPv6 | | MAC | | +---------+ 617 |Header | |Header| |Header| | * 618 +-------+ +------+ +------+ +--+ * 619 Figure 3: Structure of Capability Layer Rules 621 Policy consistency among multiple security function instances is 622 very critical because security policies are no longer maintained by 623 one central security devices, but instead are enforced by multiple 624 security functions instantiated at various locations. 626 6.2. Service Layer Policy 628 This layer is for clients or Application Controller to express & 629 monitor the needed security policies for their specific flows. 631 Some Customers may not have security skills. As such, they are not 632 able to express requirements or security policies that are precise 633 enough. These customers may express expectations or intent. 634 Customers may also express guidelines such as which certain types of 635 destinations are not allowed for certain groups. As the result, 636 there could be many depths or layers of Service Layer policies. Here 637 are some examples of more abstract service layer security Policies: 639 o Pass for Subscriber "xxx" 640 o enable basic parental control 641 o enable "school protection control" 642 o allow Internet traffic from 8:30 to 20:00 643 o scan email for malware detection protect traffic to 644 corporate network with integrity and confidentiality 645 o remove tracking data from Facebook [website = 646 *.facebook.com] 647 o my son is allowed to access facebook from 18:30 to 20:00 649 One Service Layer Security Policy may need multiple security 650 functions at various locations to achieve the enforcement. Service 651 layer Security Policy may need to be updated by users or Application 652 controller when user's service requirements have been changed. Some 653 service layer policies may not be granted because the carrier or 654 Enterprises imposes additional constraints on what the user can 655 have. [I2NSF-Demo] describes an implementation of translating a set 656 of service layer policies to the Capability Layer instructions to 657 NSFs. 659 I2NSF will first focus on simple service layer policies that are 660 modeled as closely as possible on the Capability Layer. The I2NSF 661 simple service layer should have similar structure as I2NSF 662 capability layer, however with more client oriented expression for 663 the subject, object, action, and function. 665 There have been several industry initiatives to address network 666 policies, such as OpenStack's Group-based Policy (GBP), IETF Policy 667 Core Information Model-PCIM [RFC3060, RFC3460], and others. I2NSF 668 will not work on general network service policies, but instead will 669 define a standard interface for clients/applications to inform the 670 Flow-based NSFs on the rules for treating traffic. 672 However, the notion of Groups (or roles), Target, Context (or 673 conditions), and Action do cover what is needed for 674 clients/applications to express the rules on how their flows can be 675 treated by the Flow-Based NSFs in networks. The goal is to have a 676 policy structure that can be mapped to the Capability layer's 677 Subject-Object-Action-Function" paradigm. 679 Using PCIM (RFC3060, which ITU-T X.1036 was based on) as a basis is 680 possible. However, RFC3060 was created for general network policies. 681 This means that in some areas, it provides more than what I2NSF 682 needs, and in other areas, it needs extension. This is especially 683 pronounced regarding Policy Context and Policy Conditions (e.g., the 684 direction, time, and other contextual events that govern the 685 policies to NSFs). 687 The I2NSF simple service layer can have the following entities: 689 - Composite Groups or Roles (I2NSF-Role): This is a group of 690 users, applications, virtual networks, or traffic patterns to 691 which a service layer policy can be applied. An I2NSF-Role 692 may be mapped to a client virtual Subnet (i.e. with private 693 address prefix), a subnet with public address families, 694 specific applications, destinations, or any combination of 695 them with logical operators (Logical AND, OR, or NOT). An 696 I2NSF-Role can have one or more Policy Rule Sets. 697 - Target. This is used by the application client to establish 698 communications over the network. A Target can be mapped to a 699 physical/logical ingress port, a set of destinations, or a 700 physical/logical egress port. 701 - Policy Rule Set. A Policy Rule Set is used to determine how 702 the traffic between a pair of I2NSF-Role and Target is to be 703 treated. A Policy Rule Set consists of one or more Policy 704 Rules. 705 - Policy Rule. A Policy Rule consists of a Policy Conditions 706 and a set of Actions to be applied to the traffic. 707 - Policy Condition. Describes when a Policy Rule set is to be 708 applied. It can be expressed as a direction, a list of L4 709 ports, time range, or a protocol, etc. 711 - Policy Action: This is the action applied to the traffic that 712 matches the Conditions. An action may be a simple ACL action 713 (i.e. allow, deny, mirroring), applying a well known 714 statistics functions (e.g. X minutes count, Y hours court), 715 applying client specified functions (with URL provided), or 716 may refer to an ordered sequence of functions. 718 +---------+ +--------+ +-------+ |- Logical Port 719 | CTG |---->| Policy |<-----+Target +-|- Ingress Port 720 | | |Role Set| | | |- Egress Port 721 +----+----+ +----+---+ +-------+ |- * 722 |<-------+ +---------------+ 723 +--+------+ | | +--------+Logical 724 +/---+-----+| | | +/-------+ |Combination: 725 | Simple || |Compound Operators: +--+ Policy | | AND/OR/NOT 726 | Group |+ | Logical AND: && | Rule | + 727 +--+-----+-/ | Logical OR: || +-+----+-/ 728 | | | Logical NOT: ! / \ 729 | +----+ +------+ +----------+ 730 | |Action| -| Condition| 731 +----------+---------------+-- +---+--+ +--+-------+ 732 +------+-+ +--+-----+ +---+-----+ | |-Direction 733 | App | |virtual | | Subnet | | |-timer 734 | Group | | Subnet | |host list| | |-L4 port 735 ++-------+--+ +----+---+ +----+----+ | |-Protocol 736 |Client Grp| | | | |- * 737 +----------+ | | | 738 +-------------+--+------+-------+--- | 739 +--+----+ +--+---+ +--+---+ |-Allow 740 |IPv4 | |IPv6 | | MAC | |-Deny 741 |Header | |Header| |Header| |-count 742 +-------+ +------+ +------+ |-apply function list 743 |- * 745 Figure 4: Rule Structure for Simple Service Layer 747 7. Capability Negotiation 749 When an NSF can't perform the desired provisioning (e.g., due to 750 resource constraints), it MUST inform the controller. 752 The protocol needed for this security function/capability 753 negotiation may be somewhat correlated to the dynamic service 754 parameter negotiation procedure [RFC7297]. The Connectivity 755 Provisioning Profile (CPP) template documented in RFC7297, even 756 though currently covering only Connectivity (but includes security 757 clauses such as isolation requirements, non-via nodes, etc.), 758 could be extended as a basis for the negotiation procedure. 759 Likewise, the companion Connectivity Provisioning Negotiation 760 Protocol (CPNP) could be a candidate to proceed with the 761 negotiation procedure. 763 The "security as a service" would be a typical example of the kind 764 of (CPP-based) negotiation procedures that could take place 765 between a corporate customer and a service provider. However, more 766 security specific parameters have to be considered. 768 8. Types of I2NSF clients 770 It is envisioned that I2NSF clients include: 772 - Application Controller: 774 - For example, Video Conference Mgr/Controller needs to 775 dynamically inform network to allow or deny flows (some of 776 which are encrypted) based on specific fields in the packets 777 for a certain time span. Otherwise, some flows can't go 778 through the NSFs (e.g. FW/IPS/IDS) in the network because the 779 payload is encrypted or packets' protocol codes are not 780 recognized by those NSFs. 782 - Security Administrators 784 - Enterprise 785 - Operator Management System dynamically updates, monitors 786 and verifies the security policies to NSFs (by different 787 vendors) in a network. 788 - Third party system 790 - Security functions send requests for more sophisticated functions 791 upon detecting something suspicious, usually via a security 792 controller. 794 9. Manageability Considerations 796 Management of NSFs usually includes 797 - life cycle management and resource management of vNSFs 799 - configuration of devices, such as address configuration, 800 device internal attributes configuration, etc, 802 - signaling, and 804 - policy rules provisioning. 806 I2NSF will only focus on the policy rule provisioning part, i.e., 807 the last bullet listed above. 809 10. Security Considerations 811 Having a secure access to control and monitor NSFs is crucial for 812 hosted security service. Therefore, proper secure communication 813 channels have to be carefully specified for carrying the 814 controlling and monitoring information between the NSFs and their 815 management entity (or entities). 817 11. IANA Considerations 819 This document requires no IANA actions. RFC Editor: Please remove 820 this section before publication. 822 12. References 824 12.1. Normative References 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, March 1997. 829 [RFC3060] Moore, B, et al, "Policy Core Information Model (PCIM)", 830 RFC 3060, Feb 2001. 832 [RFC3460] Moore, B. "Policy Core Information Model (PCIM) 833 Extensions", RFC3460, Jan 2003. 835 [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", 836 RFC7297, April 2014. 838 12.2. Informative References 840 [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM 841 Interface to Virtualized Security Services", , Oct 2014. 844 [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", , Oct 2014. 847 [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access 848 Network Use Case", , Oct 2014 851 [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security 852 Functions Problem Statement", , Jan 2015 855 [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL) 856 YANG Data Model", , Nov 2014. 858 [gs_NFV] ETSI NFV Group Specification, Network Functions 859 Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1, 860 2013. 862 [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall", 863 Network World, 11 November 2011 865 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services 866 in Mobile Network", IETF87 Berlin, July 29, 2013. 868 [I2NSF-Demo] Y. Xie, et al, "Interface to Network Security Functions 869 Demo Outline Design", , April 2015. 872 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 873 storage, distribution and enforcement of policies for 874 network security", Nov 2007. 876 13. Acknowledgments 878 Acknowledgements to xxx for his review and contributions. 880 This document was prepared using 2-Word-v2.0.template.dot. 882 Authors' Addresses 884 Edward Lopez 885 Fortinet 886 899 Kifer Road 887 Sunnyvale, CA 94086 888 Phone: +1 703 220 0988 889 Email: elopez@fortinet.com 891 Diego Lopez 892 Telefonica 893 Email: diego.r.lopez@telefonica.com 895 XiaoJun Zhuang 896 China Mobile 897 Email: zhuangxiaojun@chinamobile.com 899 Linda Dunbar 900 Huawei 901 Email: Linda.Dunbar@huawei.com 903 John Strassner 904 Huawei 905 John.sc.Strassner@huawei.com 907 Joe Parrott 908 BT 909 Email: joe.parrott@bt.com 911 Ramki Krishnan 912 Dell 913 Email: ramki_krishnan@dell.com 915 Seetharama Rao Durbha 916 CableLabs 917 Email: S.Durbha@cablelabs.com