idnits 2.17.1 draft-ietf-i2nsf-framework-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 : ---------------------------------------------------------------------------- ** 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 498 has weird spacing: '...| Layer heade...' == Line 561 has weird spacing: '...context match...' -- The document date (May 2, 2016) is 2908 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF-Mobile' is mentioned on line 111, but not defined == Missing Reference: 'MPTCP' is mentioned on line 364, but not defined == Missing Reference: 'RFC3286' is mentioned on line 365, but not defined == Missing Reference: 'Remote-Attestation' is mentioned on line 383, 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 == Unused Reference: 'ITU-T-X1036' is defined on line 872, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 11 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: November 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 May 2, 2016 19 Framework for Interface to Network Security Functions 20 draft-ietf-i2nsf-framework-00.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 September 2, 2016. 49 Copyright Notice 51 Copyright (c) 2016 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 the framework for guiding the functionality 67 provided by I2NSF. Network security functions (NSFs) are packet- 68 processing engines that inspect and optionally modify packets 69 traversing networks, either directly or in the context of sessions 70 in which the packet is associated. This document provides an 71 overview of how NSFs are used, and describes how NSF software 72 interfaces are controlled and monitored using rulesets. The design 73 of these software interfaces must prevent the creation of implied 74 constraints on NSF capability and functionality. 76 Table of Contents 78 1. Introduction...................................................3 79 2. Conventions used in this document..............................4 80 3. Interfaces to Flow-based NSFs..................................4 81 4. Reference Models in Managing Flow-based NSFs...................7 82 4.1. NSF Facing (Capability Layer) Interface...................8 83 4.2. Client Facing (Service Layer) Interface...................9 84 4.3. Vendor Facing Interface...................................9 85 4.4. The Network Connecting the Security Controller and NSFs...9 86 4.5. Interface to vNSFs.......................................10 87 5. Flow-based NSF Capability Characterization....................11 88 6. Structure of Rules for governing NSFs.........................15 89 6.1. Capability Layer Rules and Monitoring....................15 90 6.2. Service Layer Policy.....................................16 91 7. Capability Negotiation........................................19 92 8. Types of I2NSF clients........................................19 93 9. Manageability Considerations..................................20 94 10. Security Considerations......................................20 95 11. IANA Considerations..........................................20 96 12. References...................................................21 97 12.1. Normative References....................................21 98 12.2. Informative References..................................21 99 13. Acknowledgments..............................................22 101 1. Introduction 103 This document describes the framework for the Interface to Network 104 Security Functions (I2NSF), and defines a reference model (including 105 major functional components) for I2NSF. It also describes how I2NSF 106 facilitates Software-Defined Networking (SDN) and Network Function 107 Virtualization (NVF) control, while avoiding potential constraints 108 that could limit the internal functionality and capabilities of 109 NSFs. 111 The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile]) 112 call for standard interfaces for clients (e.g., applications, 113 application controllers, or users), to inform the network what they 114 are willing to receive. I2NSF realizes this as a set of security 115 rules for monitoring and controlling the behavior of their specific 116 traffic. It also provides standard interfaces for them to monitor 117 the security functions hosted and managed by service providers. 119 [I2NSF-Problem] describes the motivation and the problem space for 120 Interface to Network Security Functions. 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC-2119 [RFC2119]. 128 In this document, these words will appear with that interpretation 129 only when in ALL CAPS. Lower case uses of these words are not to be 130 interpreted as carrying RFC-2119 significance. 132 BSS: Business Support System 134 Controller: used interchangeably with Service Provider Security 135 Controller or management system throughout this 136 document. 138 FW: Firewall 140 IDS: Intrusion Detection System 142 IPS: Intrusion Protection System 144 NSF: Network Security Functions, defined by [I2NSF-Problem] 146 OSS: Operation Support System 148 vNSF: refers to NSF being instantiated on Virtual Machines. 150 3. Interfaces to Flow-based NSFs 152 The emergence of SDN and NFV have resulted in the need to create 153 application programming interfaces (APIs) in support of dynamic 154 requests from various applications or application controllers. 156 Flow-based NSFs [I2NSF-Problem] inspects packets in the order that 157 they are received. The Interface to Flow-based NSFs can be generally 158 grouped into three types: 160 1) Configuration - deals with the management and configuration of 161 the NSF device itself, such as port address configurations. 162 Configuration deals with attributes that are relatively 163 static. 165 2) Signaling - which represents logging and query functions 166 between the NSF and external systems. Signaling API functions 167 may also be defined by other protocols, such as SYSLOG and 168 DOTS. 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 173 they need to receive, much of the I2NSF efforts towards 174 interface development will be in this area. 176 This draft proposes that a rule provisioning interface to NSFs can 177 be developed on a packet- or flow-based paradigm. A common trait of 178 NSFs is in the processing of packets based on the content 179 (header/payload) and/or context (session state, authentication 180 state, etc) of the received packets. 182 An important concept underlying this framework is the fact that 183 attackers do not have standards as to how to attack networks, so it 184 is equally important not to constrain NSF developers to offering a 185 limited set of security functions. In other words, the introduction 186 of I2NSF standards should not make it easier for attackers to 187 compromise the network. Therefore, in constructing standards for 188 rules provisioning interfaces to NSFs, it is equally important to 189 allow support for vendor-specific functions, as this enables the 190 introduction of NSFs that evolve to meet new threats. Proposed 191 standards for rules provisioning interfaces to NSFs SHOULD NOT: 193 - Narrowly define NSF categories, or their roles when implemented 194 within a network 196 - Attempt to impose functional requirements or constraints, 197 either directly or indirectly, upon NSF developers 199 - Be a limited lowest common denominator approach, where 200 interfaces can only support a limited set of standardized 201 functions, without allowing for vendor-specific functions 203 - Be seen as endorsing a best common practice for the 204 implementation of NSFs 206 By using a packet/flow-based approach to the design of such 207 provisioning interfaces, the goal is to create a workable interface 208 to NSFs that aids in their integration within legacy, SDN, and/or 209 NFV environments, while avoiding potential constraints which could 210 limit 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 standardized by using Event - Condition - Action (ECA) policy 215 rulesets. 217 An Event, when used in the context of policy rules for a flow-based 218 NSF, is used to determine whether the condition clause of the Policy 219 Rule can be evaluated or not. Here are some examples of I2NSF 220 Events: 222 - defining a clause, of the canonical form {variable, operator, 223 value}, to represent an Event (e.g., time == 08:00) 224 - using an Event object as the variable or the value in the above 225 clause (e.g., use one or more attributes from one or more Event 226 objects in the comparison clause) 227 - using a Collection object to collect Events for aggregation, 228 filtering, and/or correlation operations as part of the Event 229 clause processing 230 - encoding the entire Event expression into an attribute 232 A Condition, when used in the context of policy rules for flow-based 233 NSFs, is used to determine whether or not the set of Actions in that 234 Policy Rule can be executed or not. A condition can be based on 235 various combinations of the content (header/payload) and/or the 236 context (session state, authentication state, etc) of the received 237 packets: 239 - Packet content values are based on one or more packet headers, 240 data from the packet payload, bits in the packet, or something 241 derived from the packet; 242 - Context values are based on measured and inferred knowledge that 243 define the state and environment in which a managed entity 244 exists or has existed. In addition to state data, this includes 245 data from sessions, direction of the traffic, time, and geo- 246 location information. State refers to the behavior of a managed 247 entity at a particular point in time. Hence, it may refer to 248 situations in which multiple pieces of information that are not 249 available at the same time must be analyzed. For example, 250 tracking established TCP connections (connections that have gone 251 through the initial three-way handshake). 253 Actions for flow-based NSFs include: 255 - Action ingress processing, such as pass, drop, mirroring, etc; 256 - Action egress processing, such as invoke signaling, tunnel 257 encapsulation, packet forwarding and/or transformation; 258 - Applying a specific Functional Profile or signature - e.g., an 259 IPS Profile, a signature file, an anti-virus file, or a URL 260 filtering file. Many flow-based NSFs utilize profile and/or 261 signature files to achieve more effective threat detection and 262 prevention. It is not uncommon for a NSF to apply different 263 profiles and/or signatures for different flows. Some 264 profiles/signatures do not require any knowledge of past or 265 future activities, while others are stateful, and may need to 266 maintain state for a specific length of time. 268 The functional profile or signature file is one of the key 269 properties that determine the effectiveness of the NSF, and is 270 mostly vendor-specific today. The rulesets and software interfaces 271 of I2NSF aim to standardize the form and function of profile and 272 signature files while supporting vendor-specific functions of each. 274 4. Reference Models in Managing Flow-based NSFs 276 This document only focuses on the framework of rules provisioning 277 for and monitoring of flow-based NSFs. 279 The following figure shows various interfaces for managing the 280 provisioning & monitoring aspects of flow-based NSFs. 282 +-------------------------------------+ 283 | Client or App Controller | 284 | (e.g., Video Conference Ctrl Admin, | 285 | OSS/BSS, or Service Orchestration | 286 +----------+--------------------------+ 287 | 288 | Client Facing (Service Layer) Interface 289 | 290 +-----+---------------+ 291 |Network Operator mgmt| +-------------+ 292 | Security Controller | < --------- > | Vendor | 293 +---------------+-----+ Vendor Facing | System | 294 | Interface +-------------+ 295 | 296 | NSF Facing (capability) Interface 297 | 298 +---------------------------+-----------------------+ 299 | | 300 | | 301 +---+--+ +------+ +------+ +--+---+ 302 + NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . . 303 +------+ +------+ +------+ +------+ 305 Vendor A Vendor B 307 Figure 1: Multiple Interfaces 309 4.1. NSF Facing (Capability Layer) Interface 311 This is the interface between the Service Provider's management 312 system (or Security Controller) and the set of NSFs that are 313 selected to enforce the desired network security. This interface 314 defines the features available for each NSF that the management 315 system can choose to invoke for a particular packet or flow. Note 316 that the management system does not need to use all features for a 317 given NSF, nor does it need to use all available NSFs. Hence, this 318 abstraction enables the same relative features from diverse NSFs 319 from different vendors to be selected. 321 This interface is called the Capability Interface in the I2NSF 322 context. 324 4.2. Client Facing (Service Layer) Interface 326 This interface is for clients or Application Controller to express 327 and monitor security policies for their specific flows. The Client 328 Facing interface is called the Service Layer Interface in the 329 I2NSF context. The I2NSF Service Layer allows the client to define 330 and monitor the client specific policies and their execution 331 status. 333 A single client layer policy may need multiple NSFs (or multiple 334 instantiations of the same NSF) to achieve the desired 335 enforcement. 337 4.3. Vendor Facing Interface 339 NSFs provided by different vendors have different capabilities. In 340 order to automate the process of utilizing multiple types of 341 security functions provided by different vendors, it is necessary 342 to have an interface for vendors to register their NSFs indicating 343 the capabilities of their NSFs. 345 The Registration Interface can be defined statically or 346 instantiated dynamically at runtime. If a new functionality that 347 is exposed to the user is added to an NSF, the vendor MUST notify 348 the network operator's management system or security controller of 349 its updated functionality via the Registration Interface. 351 4.4. The Network Connecting the Security Controller and NSFs 353 Most likely the NSFs are not directly attached to the Security 354 Controller; for example, NSFs can be distributed across the 355 network. The network that connects the Security Controller with 356 the NSFs can be the same network that carries the data traffic, or 357 can be a dedicated network for management purposes only. In either 358 case, packet loss could happen due to failure, congestion, or 359 other reasons. 361 Therefore, the transport mechanism used to carry the control 362 messages and monitoring information should provide reliable 363 message delivery. Transport redundancy mechanisms such as 364 Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission 365 Protocol (SCTP) [RFC3286] will need to be evaluated for 366 applicability. Latency requirements for control message delivery 367 must also be evaluated. 369 The network connection between the Security Controller and NSFs 370 could be: 372 - Closed environments, where there is only one administrative 373 domain. Less restrictive access control and simpler validation 374 can be used inside the domain because of the protected 375 environment. 376 - Open environments, where some NSFs (virtual or physical) can be 377 hosted in external administrative domains or reached via secure 378 external network domains. This requires more restrictive 379 security control to be placed over the I2NSF interface. Not 380 only must the information over the I2NSF interfaces use trusted 381 channels, such as TLS, SASL (RFC4422), or the combination of the 382 two, but also require proper authentication as described in 383 [Remote-Attestation]. 385 Over the Open Environment, I2NSF needs to provide identity 386 information, along with additional data that Authentication, 387 Authorization, and Accounting (AAA) frameworks can use. This 388 enables those frameworks to perform AAA functions on the I2NSF 389 traffic. 391 4.5. Interface to vNSFs 393 Even though there is no difference between virtual network 394 security functions (vNSF) and physical NSFs from the policy 395 provisioning perspective, there are some unique characteristics in 396 interfacing to the vNSFs: 398 - There could be multiple instantiations of one single NSF that 399 has been distributed across a network. When different 400 instantiations are visible to the Security Controller, different 401 policies may be applied to different instantiations of an 402 individual NSF (e.g., to reflect the different roles that each 403 vNSF is designated for). 404 - When multiple instantiations of one single NSF appear as one 405 single entity to the Security Controller, the policy 406 provisioning has to be sent to the NSF's sub-controller, which 407 in turn disseminates the polices to the corresponding 408 instantiations of the NSF, as shown in the Figure 2 below. 409 - Policies to one vNSF may need to be retrieved and moved to 410 another vNSF of the same type when client flows are moved from 411 one vNSF to another. 412 - Multiple vNSFs may share the same physical platform 413 - There may be scenarios where multiple vNSFs collectively perform 414 the security policies needed. 416 +------------------------+ 417 | Security Controller | 418 +------------------------+ 419 ^ ^ 420 | | 421 +-----------+ +------------+ 422 | | 423 v v 424 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 425 | NSF-A +--------------+ | | NSF-B +--------------+ | 426 | |Sub Controller| | | |sub Controller| | 427 | +--------------+ | | +--------------+ | 428 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 429 | |+---------+ +---------+| | | |+---------+ +---------+| | 430 | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | 431 | |+---------+ +---------+| | | |+---------+ +---------+| | 432 | | NSF-A cluster | | | | NSF-B cluster | | 433 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 434 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 436 Figure 2: Cluster of NSF Instantiations Management 438 5. Flow-based NSF Capability Characterization 440 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 441 the commonly deployed flow-based NSFs. However, the differences 442 among them are definitely blurring, due to technological capacity 443 increases, integration of platforms, and new threats. At their core: 444 . Firewall - A device or a function that analyzes packet headers and 445 enforces policy based on protocol type, source address, 446 destination address, source port, destination port, and/or other 447 attributes of the packet header. Packets that do not match policy 448 are rejected. Note that additional functions, such as logging and 449 notification of a system administrator, could optionally be 450 enforced as well. 451 . IDS (Intrusion Detection System) - A device or function that 452 analyzes packets, both header and payload, looking for known 453 events. When a known event is detected, a log message is generated 454 detailing the event. Note that additional functions, such as 455 notification of a system administrator, could optionally be 456 enforced as well. 457 . IPS (Intrusion Prevention System) - A device or function that 458 analyzes packets, both header and payload, looking for known 459 events. When a known event is detected, the packet is rejected. 460 Note that additional functions, such as logging and notification 461 of a system administrator, could optionally be enforced as well. 463 To prevent constraints on NSF vendors' creativity and innovation, 464 this document recommends the Flow-based NSF interfaces to be 465 designed from the paradigm of processing packets in the network. 466 Flow-based NSFs ultimately are packet-processing engines that 467 inspect packets traversing networks, either directly or in the 468 context of sessions in which the packet is associated. 470 Flow-based NSFs differ in the depth of packet header or payload they 471 can inspect, the various session/context states they can maintain, 472 and the specific profiles and the actions they can apply. An example 473 of a session is "allowing outbound connection requests and only 474 allowing return traffic from the external network". 476 Accordingly, the NSF capabilities are characterized by the level of 477 packet processing and context that a NSF supports, the profiles and 478 the actions that the NSF can apply. The term "context" includes 479 anything that can influence the action(s) taken by the NSF, such as 480 time of day, location, session state, and events. 482 Vendors can register their NSFs using Packet Content Match 483 categories. The IDR Flow Specification [RFC5575] has specified 12 484 different packet header matching types. More packet content matching 485 types have been proposed in the IDR WG. I2NSF should re-use the 486 packet matching types being specified as much as possible. More 487 matching types might be added for Flow-based NSFS. Tables 1-4 below 488 list the applicable packet content categories that can be 489 potentially used as packet matching types by Flow-based NSFs: 491 +-----------------------------------------------------------+ 492 | Packet Content Matching Capability Index | 493 +---------------+-------------------------------------------+ 494 | Layer 2 | Layer 2 header fields: | 495 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 496 | | | 497 |---------------+-------------------------------------------+ 498 | Layer 3 | Layer header fields: | 499 | | protocol | 500 | IPv4 Header | dest port | 501 | | src port | 502 | | src address | 503 | | dest address | 504 | | dscp | 505 | | length | 506 | | flags | 507 | | ttl | 508 | | | 509 | IPv6 Header | | 510 | | addr | 511 | | protocol/nh | 512 | | src port | 513 | | dest port | 514 | | src address | 515 | | dest address | 516 | | length | 517 | | traffic class | 518 | | hop limit | 519 | | flow label | 520 | | dscp | 521 | | | 522 | TCP | Port | 523 | SCTP | syn | 524 | DCCP | ack | 525 | | fin | 526 | | rst | 527 | | ? psh | 528 | | ? urg | 529 | | ? window | 530 | | sockstress | 531 | | Note: bitmap could be used to | 532 | | represent all the fields | 533 | | | 534 | UDP | | 535 | | flood abuse | 536 | | fragment abuse | 537 | | Port | 538 | HTTP layer | | 539 | | | hash collision | 540 | | | http - get flood | 541 | | | http - post flood | 542 | | | http - random/invalid url | 543 | | | http - slowloris | 544 | | | http - slow read | 545 | | | http - r-u-dead-yet (rudy) | 546 | | | http - malformed request | 547 | | | http - xss | 548 | | | https - ssl session exhaustion | 549 +---------------+----------+--------------------------------+ 550 | IETF PCP | Configurable | 551 | | Ports | 552 | | | 553 +---------------+-------------------------------------------+ 554 | IETF TRAM | profile | 555 | | | 556 | | | 557 |---------------+-------------------------------------------+ 558 Table 1: Subject Capability Index 560 +-----------------------------------------------------------+ 561 | context matching Capability Index | 562 +---------------+-------------------------------------------+ 563 | Session | Session state, | 564 | | bidirectional state | 565 | | | 566 +---------------+-------------------------------------------+ 567 | Time | time span | 568 | | time occurrence | 569 +---------------+-------------------------------------------+ 570 | Events | Event URL, variables | 571 +---------------+-------------------------------------------+ 572 | Location | Text string, GPS coords, URL | 573 +---------------+-------------------------------------------+ 574 | Connection | Internet (unsecured), Internet | 575 | Type | (secured by VPN, etc.), Intranet, ... | 576 +---------------+-------------------------------------------+ 577 | Direction | Inbound, Outbound | 578 +---------------+-------------------------------------------+ 579 | State | Authentication State | 580 | | Authorization State | 581 | | Accounting State | 582 | | Session State | 583 +---------------+-------------------------------------------+ 585 Table 2: Object Capability Index 587 +-----------------------------------------------------------+ 588 | Action Capability Index | 589 +---------------+-------------------------------------------+ 590 | Ingress port | SFC header termination, | 591 | | VxLAN header termination | 592 +---------------+-------------------------------------------+ 593 | | Pass | 594 | Actions | Deny | 595 | | Mirror | 596 | | Simple Statistics: Count (X min; Day;..)| 597 | | Client specified Functions: URL | 598 +---------------+-------------------------------------------+ 599 | Egress | Encap SFC, VxLAN, or other header | 600 +---------------+-------------------------------------------+ 601 Table 3: Action Capability Index 603 +-----------------------------------------------------------+ 604 | Functional profile Index | 605 +---------------+-------------------------------------------+ 606 | Profile types | Name, type, or | 607 | Signature | Flexible Profile/signature URL | 608 | | Command for Controller to enable/disable | 609 | | | 610 +---------------+-------------------------------------------+ 611 Table 4: Function Capability Index 613 6. Structure of Rules for governing NSFs 615 6.1. Capability Layer Rules and Monitoring 617 The purpose of the Capability Layer is to define explicit rules for 618 individual NSFs to treat packets, as well as methods to monitor the 619 execution status of those functions. 621 [ACL-MODEL] has defined rules for the Access Control List supported 622 by most routers/switches that forward packets based on packets' L2, 623 L3, or sometimes L4 headers. The actions for Access Control Lists 624 include Pass, Drop, or Redirect. 626 The functional profiles (or signatures) for NSFs are not present in 627 [ACL-MODEL] because the functional profiles are unique to specific 628 NSFs. For example, most vendors' IPS/IDS have their proprietary 629 functions/profiles. One of the goals of I2NSF is to define a common 630 envelop format for exchanging or sharing profiles among different 631 organizations to achieve more effective protection against threats. 633 The "packet content matching" of the I2NSF policies should not only 634 include the matching criteria specified by [ACL-MODEL] but also the 635 L4-L7 fields depending on the NSFs selected. 637 Some Flow-based NSFs need matching criteria that include the context 638 associated with the packets. 640 The I2NSF "actions" should extend the actions specified by [ACL- 641 MODEL] to include applying statistics functions, threat profiles, or 642 signature files that clients provide. 644 Policy consistency among multiple security function instances is 645 very critical because security policies are no longer maintained by 646 one central security device, but instead are enforced by multiple 647 security functions instantiated at various locations. 649 6.2. Service Layer Policy 651 This layer is for clients or an Application Controller to express 652 and monitor the needed security policies for their specific flows. 654 Some Customers may not have security skills. As such, they are not 655 able to express requirements or security policies that are precise 656 enough. These customers may instead express expectations or intent 657 of the functionality desired by their security policies. Customers 658 may also express guidelines such as which certain types of 659 destinations are not allowed for certain groups. As a result, there 660 could be different depths or layers of Service Layer policies. Here 661 are some examples of more abstract service layer security Policies: 663 o Pass for Subscriber "xxx" 664 o enable basic parental control 665 o enable "school protection control" 666 o allow Internet traffic from 8:30 to 20:00 667 o scan email for malware detection protect traffic to 668 corporate network with integrity and confidentiality 669 o remove tracking data from Facebook [website = 670 *.facebook.com] 671 o my son is allowed to access facebook from 18:30 to 20:00 673 One Service Layer Security Policy may need multiple security 674 functions at various locations to achieve the enforcement. Service 675 layer Security Policy may need to be updated by clients or 676 Application controllers when clients' service requirements have been 677 changed. Some service layer policies may not be granted because the 678 carrier or Enterprises imposes additional constraints on what a 679 client can have. [I2NSF-Demo] describes an implementation of 680 translating a set of service layer policies to the Capability Layer 681 instructions to NSFs. 683 I2NSF will first focus on simple service layer policies that are 684 modeled as closely as possible on the Capability Layer. The I2NSF 685 simple service layer should have similar structure as the I2NSF 686 capability layer, but with more of a client-oriented expression for 687 the packet content, context, and other parts of an ECA policy rule. 688 This enables the client to construct an ECA policy rule without 689 having to know its detailed structure or syntax. 691 There have been several industry initiatives to address network 692 policies, such as OpenStack's Group-based Policy (GBP), IETF Policy 693 Core Information Model-PCIM [RFC3060, RFC3460], and others. I2NSF 694 will not work on general network service policies, but instead will 695 define a standard interface for clients/applications to inform the 696 Flow-based NSFs on the rules for treating traffic. 698 However, the notion of Groups (or roles), Target, Event, Context (or 699 Conditions), and Action do cover what is needed for 700 clients/applications to express the rules on how their flows can be 701 treated by the Flow-Based NSFs in networks. The goal is to have a 702 policy structure that can be mapped to the Capability layer's Event- 703 Condition-Action paradigm. 705 The I2NSF simple service layer can have the following entities: 707 - I2NSF-Groups: This is a collection of users, applications, 708 virtual networks, or traffic patterns to which a service 709 layer policy can be applied. An I2NSF-Group may be mapped to 710 a client virtual Subnet (i.e. with private address prefix), a 711 subnet with public address families, specific applications, 712 destinations, or any combination of them with logical 713 operators (Logical AND, OR, or NOT). An I2NSF-Group can have 714 one or more Policy Rules applied to it. 715 - Target. This is used by the application client to identify 716 the set of objects to be affected by the policy rules. A 717 Target can be mapped to a physical/logical ingress port, a 718 set of destinations, or a physical/logical egress port. 719 - Policy Rule. A Policy Rule consists of a set of Policy 720 Events, Policy Conditions, and Policy Actions. Policy Rules 721 are triggered by matching Events. If the Event portion of the 722 Policy Rule evaluates to true, then the Condition portion is 723 evaluated (otherwise, the Policy Rule terminates and no 724 action is taken). If the Condition portion of the Policy Rule 725 evaluates to true, then the set of Actions MAY be executed 726 and applied to the traffic (otherwise, the Policy Rule 727 terminates and no action is taken). 728 - Policy Event. This triggers a determination of whether the 729 condition portion of a Policy Rule should be evaluated or 730 not. 731 - Policy Condition. This determines when the Policy Actions 732 contained in a Policy Rule are to be applied. It can be 733 expressed as a direction, a list of L4 ports, time range, or 734 a protocol, etc. 735 - Policy Action: This is the action applied to the traffic that 736 matches the Conditions (and was triggered by the Events). An 737 action may be a simple ACL action (i.e. allow, deny, 738 mirroring), applying a well known statistics functions (e.g. 739 X minutes count, Y hours court), applying client specified 740 functions (with URL provided), or may refer to an ordered 741 sequence of functions. 743 7. Capability Negotiation 745 When an NSF can't perform the desired provisioning (e.g., due to 746 resource constraints), it MUST inform the controller. 748 The protocol needed for this security function/capability 749 negotiation may be somewhat correlated to the dynamic service 750 parameter negotiation procedure [RFC7297]. The Connectivity 751 Provisioning Profile (CPP) template documented in RFC7297, even 752 though currently covering only Connectivity requirements (but 753 includes security clauses such as isolation requirements, non-via 754 nodes, etc.), could be extended as a basis for the negotiation 755 procedure. Likewise, the companion Connectivity Provisioning 756 Negotiation Protocol (CPNP) could be a candidate to proceed with 757 the negotiation procedure. 759 The "security as a service" would be a typical example of the kind 760 of (CPP-based) negotiation procedures that could take place 761 between a corporate customer and a service provider. However, more 762 security specific parameters have to be considered. 764 8. Types of I2NSF clients 766 It is envisioned that I2NSF clients include: 768 - Application Controller: 770 - For example, Video Conference Mgr/Controller needs to 771 dynamically inform network to allow or deny flows (some of 772 which are encrypted) based on specific fields in the packets 773 for a certain time span. Otherwise, some flows can't go 774 through the NSFs (e.g. FW/IPS/IDS) in the network because the 775 payload is encrypted or packets' protocol codes are not 776 recognized by those NSFs. 778 - Security Administrators 780 - Enterprise users and applications 781 - Operator Management System dynamically updates, monitors 782 and verifies the security policies to NSFs (by different 783 vendors) in a network. 784 - Third party system 786 - Security functions send requests for more sophisticated functions 787 upon detecting something suspicious, usually via a security 788 controller. 790 9. Manageability Considerations 792 Management of NSFs usually includes: 794 - life cycle management and resource management of NSFs 796 - configuration of devices, such as address configuration, 797 device internal attributes configuration, etc, 799 - signaling, and 801 - policy rules provisioning. 803 I2NSF will only focus on the policy rule provisioning part, i.e., 804 the last bullet listed above. 806 10. Security Considerations 808 Having a secure access to control and monitor NSFs is crucial for 809 hosted security service. Therefore, proper secure communication 810 channels have to be carefully specified for carrying the 811 controlling and monitoring information between the NSFs and their 812 management entity (or entities). 814 11. IANA Considerations 816 This document requires no IANA actions. RFC Editor: Please remove 817 this section before publication. 819 12. References 821 12.1. Normative References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC3060] Moore, B, et al, "Policy Core Information Model (PCIM)", 827 RFC 3060, Feb 2001. 829 [RFC3460] Moore, B. "Policy Core Information Model (PCIM) 830 Extensions", RFC3460, Jan 2003. 832 [RFC5575] Marques, P, et al, "Dissemination of Flow Specification 833 Rules", RFC 5575, Aug 2009. 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