idnits 2.17.1 draft-ietf-i2nsf-framework-03.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 16 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 726 has weird spacing: '...| Layer heade...' == Line 789 has weird spacing: '...context match...' -- The document date (August 17, 2016) is 2781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF-Mobile' is mentioned on line 118, but not defined == Missing Reference: 'Remote-Attestation' is mentioned on line 408, but not defined == Missing Reference: 'MPTCP' is mentioned on line 426, but not defined == Missing Reference: 'RFC3286' is mentioned on line 427, but not defined == Unused Reference: 'RFC3060' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC3460' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'I2NSF-MOBILE' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'NW-2011' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'SC-MobileNetwork' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 923, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 13 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: January 2017 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 16 R. Kumar 17 A. Lohiya 18 Juniper Networks 20 August 17, 2016 22 Framework for Interface to Network Security Functions 23 draft-ietf-i2nsf-framework-03.txt 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. This document may not be modified, 32 and derivative works of it may not be created, except to publish it 33 as an RFC and to translate it into languages other than English. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on February 17, 2009. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Abstract 70 This document describes the framework for the Interface to Network 71 Security Functions (I2NSF), and defines a reference model (including 72 major functional components) for I2NSF. Network security functions 73 (NSFs) are packet-processing engines that inspect and optionally 74 modify packets traversing networks, either directly or in the 75 context of sessions in which the packet is associated. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Conventions used in this document..............................4 81 3. I2NSF Reference Model..........................................4 82 3.1. Client Facing Interface...................................6 83 3.2. NSFs Facing Interface.....................................7 84 3.3. Registration Interface....................................8 85 4. Threats Associated with Externally Provided NSFs...............8 86 5. Avoiding NSF Ossification......................................9 87 6. The Network Connecting I2NSF Components.......................10 88 6.1. Network connecting I2NSF Clients and I2NSF Controller....10 89 6.2. Network Connecting the Security Controller and NSFs......11 90 6.3. Interface to vNSFs.......................................12 91 7. I2NSF Flow Security Policy Structure..........................13 92 7.1. Client Facing Flow Security Policy structure.............14 93 7.2. NSF Facing Flow Security Policy structure................15 94 7.3. Difference from ACL data model...........................16 95 8. Capability Negotiation........................................17 96 9. Registration consideration....................................17 97 9.1. Flow-based NSF Capability Characterization...............17 98 9.2. Registration Categories..................................18 99 10. Manageability Considerations.................................21 100 11. Security Considerations......................................22 101 12. IANA Considerations..........................................22 102 13. References...................................................22 103 13.1. Normative References....................................22 104 13.2. Informative References..................................23 105 14. Acknowledgments..............................................24 107 1. Introduction 109 This document describes the framework for the Interface to Network 110 Security Functions (I2NSF), and defines a reference model (including 111 major functional components) for I2NSF, including an analysis of the 112 threats implied by the deployment of NSFs that are externally 113 provided. It also describes how I2NSF facilitates Software-Defined 114 Networking (SDN) and Network Function Virtualization (NFV) control, 115 while avoiding potential constraints that could limit the internal 116 functionality and capabilities of NSFs. 118 The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile]) 119 call for standard interfaces for clients (e.g., applications, 120 overlay or cloud network management system, or enterprise network 121 administrator or management system), to inform the network what they 122 are willing to receive. I2NSF realizes this as a set of security 123 rules for monitoring and controlling the behavior of their specific 124 flows. It also provides standard interfaces for them to monitor the 125 flow based security functions hosted and managed by different 126 administrative domains. 128 [I2NSF-Problem] describes the motivation and the problem space for 129 Interface to Network Security Functions. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC-2119 [RFC2119]. 137 In this document, these words will appear with that interpretation 138 only when in ALL CAPS. Lower case uses of these words are not to be 139 interpreted as carrying RFC-2119 significance. 141 BSS: Business Support System 143 Controller: used interchangeably with Service Provider Security 144 Controller or management system throughout this 145 document. 147 FW: Firewall 149 IDS: Intrusion Detection System 151 IPS: Intrusion Protection System 153 NSF: Network Security Functions, defined by [I2NSF-Problem] 155 OSS: Operation Support System 157 3. I2NSF Reference Model 159 The following figure shows a reference model (including major 160 functional components) for I2NSF and the interfaces among those 161 components. 163 +-----------------------------------------------------+ 164 | I2NSF Client | 165 | E.g. Overlay Network Mgnt, Enterprise network Mgnt | 166 | another network domain's mgnt, etc. | 167 +----------+------------------------------------------+ 168 | 169 | Client Facing Interface 170 | 171 +-----+---------------+ 172 |Network Operator mgmt| +-------------+ 173 | Security Controller | < --------- > | Developer's | 174 +---------------+-----+ Registration | Mgnt System | 175 | Interface +-------------+ 176 | 177 | NSF Facing Interface 178 | 179 +---------------------------+-----------------------+ 180 | | 181 | | 182 +---+--+ +------+ +------+ +--+---+ 183 + NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . . 184 +------+ +------+ +------+ +------+ 186 Developer A Developer B 188 Figure 1: I2NSF Reference Model 189 Note that security controller focuses on the management of NSFs, and 190 it does not participate in the NSF data plane activity. The diagram 191 has to be interpreted from the point of view of the security 192 controller and does not assume any particular management 193 architecture for the NSFs or on the developer's side. 195 When defining controller interfaces, this framework adheres to the 196 following principles: 198 - Agnostic of network topology and NSF location in the network 199 - Agnostic of provider, implementation and form-factor (physical, 200 virtual) 201 - Agnostic to how NSF is implemented and its hosting environment 202 - Agnostic to how NSF becomes operational 203 - Agnostic to NSF control plane implementation (if there is one) 204 - Agnostic to NSF data plane implementation such as encapsulation 205 capabilities. 207 3.1. Client Facing Interface 209 The Client Facing Interface, which is often loosely called the north 210 bound interface to the controller, is for clients to express and 211 monitor security policies for clients' specific flows through an 212 administrative domain. 214 In today's world, where everything is connected, preventing unwanted 215 traffic has become a key challenge. More and more networks, 216 including various types of Internet of Things (IoT) networks, 217 information-centric networks (ICN), content delivery networks (CDN), 218 and cloud networks, are some form of overlay networks with their 219 paths (or links) among nodes being provided by other networks 220 (a.k.a. underlay networks). The overlay networks' own security 221 solutions cannot prevent various attacks from saturating the access 222 links to the overlay network nodes, which may cause overlay nodes' 223 CPU/links too overloaded to handle their own legitimate traffic. 225 Very much like traditional networks placing firewall or intrusion 226 prevention system (IPS) on the wire to enforce traffic rules, 227 Interface to Network Security Functions (I2NSF) can be used by 228 overlay networks to request certain flow-based security rules to be 229 enforced by underlay networks. With this mechanism, unwanted 230 traffic, including DDoS attacks, can be eliminated from occupying 231 the physical links and ports to the overlay network nodes, thereby 232 avoiding excessive or problematic overlay node CPU/storage/port 233 utilization. The same approach can be used by enterprise networks to 234 request their specific flow security policies to be enforced by the 235 provider network that interconnect their users. Clients may not care 236 where a specific security policy is implemented. 238 Here are some examples of I2NSF clients: 240 - A videoconference network manager that needs to dynamically inform 241 the underlay network to allow, rate-limit or deny flows (some of 242 which are encrypted) based on specific fields in the packets for a 243 certain time span. 244 - Enterprise network administrators and management systems that need 245 to request their provider network to enforce some rules to their 246 specific flows. 248 - An IoT management system sending requests to the underlay network 249 to block flows that match their specific conditions. 251 3.2. NSFs Facing Interface 253 The NSFs Facing Interface, which is often loosely called the south 254 bound interface to the controller, specifies and monitors a number 255 of flow based security policies to individual NSFs. Note that the 256 controller does not need to use all features for a given NSF, nor 257 does it need to use all available NSFs. Hence, this abstraction 258 enables the same relative features from diverse NSFs from different 259 developers to be selected. 261 Flow-based NSFs [I2NSF-Problem] inspects packets in the order that 262 they are received. The Interface to Flow-based NSFs can be generally 263 grouped into three types: 265 1) Registration Interface - Interface to discover NSF/vNSF capability 266 so that controller can determine whether a NSF is capable of 267 enforcing a given policy. This could be either a query interface 268 (controller queries from a NSF for a specific functionality) or a 269 report interface where each NSF sends its supported capabilities 270 such as feature, scale, performance. The operational state of the 271 NSF is not changed by this interface. 272 2) Capability Interface - Interface used by controller to program a 273 specific NSF to enforce a security policy. This changes the 274 operational state of the NSF if successful. Due to the need of 275 applications/controllers to dynamically control what traffic they 276 need to receive, much of the I2NSF efforts would be focused 277 towards this interface. 278 3) Monitoring Interface - Interface to get monitoring information 279 from a NSF. This could be a query or report interface. This 280 includes logging and query functions between the NSF and external 281 systems. The functions for this interface may also be defined by 282 other protocols, such as SYSLOG and DOTS. 283 4) Notification Interface - Interface used for notification 284 (event/alarm) from a NSF to the controller (if registered). The 285 controller may take an action based on the event. This is a report 286 and registry interface. This does not change the operational state 287 of the NSF. 289 This draft proposes that a capability interface to NSFs can be 290 developed on a flow-based paradigm. A common trait of flow based 291 NSFs is in the processing of packets based on the content 292 (header/payload) and/or context (session state, authentication 293 state, etc) of the received packets. 295 3.3. Registration Interface 297 NSFs provided by different developers may have different 298 capabilities. In order to automate the process of utilizing multiple 299 types of security functions provided by different developers, it is 300 necessary to have an interface for developers to register their NSFs 301 indicating the capabilities of their NSFs. 303 NSF's capabilities can be either pre-configured or retrieved 304 dynamically on a need basis through the registration interface. If a 305 new functionality that is exposed to the user is added to an NSF, 306 then those capabilities must be notified to security controller via 307 the Registration Interface. 309 4. Threats Associated with Externally Provided NSFs 310 While associated with a much higher flexibility, and in many cases a 311 necessary approach given the deployment conditions, the usage of 312 externally provided NSFs implies several additional concerns in 313 security. The most relevant threats associated with a security 314 platform of this nature are: 315 o An unknown/unauthorized client can try to impersonate another 316 client that can legitimately access external NSF services. This 317 attack may lead to accessing the policies and applications of the 318 attacked client or to generate network traffic outside the 319 security functions with a falsified identity. 320 o An authorized client may misuse assigned privileges to alter the 321 network traffic processing of other clients in the NSF underlay or 322 platform. This can become especially serious when such a client 323 has higher (or even administration) privileges granted by the 324 provider (the direct NSF provider, the ISP or the underlay network 325 operator). 327 o A client may try to install malformed elements (policy or 328 configuration), trying to directly take the control of a NSF or 329 the whole provider platform, for example by exploiting a 330 vulnerability on one of the functions, or may try to intercept or 331 modify the traffic of other clients in the same provider platform. 332 o A malicious provider can modify the software providing the 333 functions (the operating system or the specific NSF 334 implementations) to alter the behavior of the latter. This event 335 has a high impact on all clients accessing NSFs as the provider 336 has the highest level of privilege on the software in execution. 337 o A client that has physical access to the provider platform can 338 modify the behavior of the hardware/software components, or the 339 components themselves. Furthermore, it can access a serial console 340 (most devices offer this interface for maintenance reasons) to 341 access the NSF software with the same level of privilege of the 342 provider. 343 The authentication between the client and the NSF environment and, 344 what is more important, the attestation of the elements in the NSF 345 environment by clients could address these threats to an acceptable 346 level of risk. Periodical attestation enables clients to detect 347 alterations in the NSFs and their supporting infrastructure able, 348 and raises the degree of physical control necessary to perform an 349 untraceable malicious modification of the environment. 351 5. Avoiding NSF Ossification 353 An important concept underlying this framework is the fact that 354 attackers do not have standards as to how to attack networks, so it 355 is equally important not to constrain NSF developers to offering a 356 limited set of security functions. In other words, the introduction 357 of I2NSF standards should not make it easier for attackers to 358 compromise the network. Therefore, in constructing standards for 359 rules provisioning interfaces to NSFs, it is equally important to 360 allow support for specific functions, as this enables the 361 introduction of NSFs that evolve to meet new threats. Proposed 362 standards for rules provisioning interfaces to NSFs SHOULD NOT: 364 - Narrowly define NSF categories, or their roles when implemented 365 within a network 367 - Attempt to impose functional requirements or constraints, 368 either directly or indirectly, upon NSF developers 370 - Be a limited lowest common denominator approach, where 371 interfaces can only support a limited set of standardized 372 functions, without allowing for developer-specific functions 374 - Be seen as endorsing a best common practice for the 375 implementation of NSFs 377 To prevent constraints on NSF developers' creativity and innovation, 378 this document recommends the Flow-based NSF interfaces to be 379 designed from the paradigm of processing packets in the network. 380 Flow-based NSFs ultimately are packet-processing engines that 381 inspect packets traversing networks, either directly or in the 382 context of sessions in which the packet is associated. The goal is 383 to create a workable interface to NSFs that aids in their 384 integration within legacy, SDN, and/or NFV environments, while 385 avoiding potential constraints which could limit their functional 386 capabilities. 388 6. The Network Connecting I2NSF Components 390 6.1. Network connecting I2NSF Clients and I2NSF Controller 392 Editor's note: should we add the Remote Attestation to this 393 section? 395 As a general principle, in the I2NSF environment clients directly 396 interact with the controller. Given the role of the Security 397 Controller, a mutual authentication of clients and the Security 398 Controller maybe required. I2NSF does not mandate a specific 399 authentication scheme; it is up to the users to choose available 400 authentication scheme based on their needs. 402 Upon successful authentication, a trusted connection between the 403 client and the Security Controller (or an endpoint designated by 404 it) SHALL be established. All traffic to and from the NSF 405 environment will flow through this connection. The connection is 406 intended not only to be secure, but trusted in the sense that it 407 SHOULD be bound to the mutual authentication between client and 408 Security Controller, as described in [Remote-Attestation], with 409 the only possible exception of the application of the lowest 410 levels of assurance, in which case the client MUST be made aware 411 of this circumstance. 413 6.2. Network Connecting the Security Controller and NSFs 415 Most likely the NSFs are not directly attached to the I2NSF 416 Controller; for example, NSFs can be distributed across the 417 network. The network that connects the I2NSF Controller with the 418 NSFs can be the same network that carries the data traffic, or can 419 be a dedicated network for management purposes only. In either 420 case, packet loss could happen due to failure, congestion, or 421 other reasons. 423 Therefore, the transport mechanism used to carry the control 424 messages and monitoring information should provide reliable 425 message delivery. Transport redundancy mechanisms such as 426 Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission 427 Protocol (SCTP) [RFC3286] will need to be evaluated for 428 applicability. Latency requirements for control message delivery 429 must also be evaluated. 431 The network connection between the Security Controller and NSFs 432 can rely either on: 434 - Closed environments, where there is only one administrative 435 domain. Less restrictive access control and simpler validation 436 can be used inside the domain because of the protected 437 environment. 438 - Open environments, where some NSFs can be hosted in external 439 administrative domains or reached via secure external network 440 domains. This requires more restrictive security control to be 441 placed over the I2NSF interface. The information over the I2NSF 442 interfaces SHALL be exchanged used trusted channels as described 443 in the previous section. 445 When running in an open environment, I2NSF needs to rely on 446 interfaces to properly verify peer identities e.g. through an 447 AAA framework. The implementation of identity management 448 functions is out of scope for I2NSF. 450 6.3. Interface to vNSFs 452 Even though there is no difference between virtual network 453 security functions (vNSF) and physical NSFs from the policy 454 provisioning perspective, there are some unique characteristics in 455 interfacing to the vNSFs: 457 - There could be multiple instantiations of one single NSF that 458 has been distributed across a network. When different 459 instantiations are visible to the Security Controller, different 460 policies may be applied to different instantiations of an 461 individual NSF (e.g., to reflect the different roles that each 462 vNSF is designated for). 463 - When multiple instantiations of one single NSF appear as one 464 single entity to the Security Controller, the policy 465 provisioning has to be sent to the NSF Manager, which in turn 466 disseminates the polices to the corresponding instantiations of 467 the NSF, as shown in the Figure 2 below. 468 - Policies to one vNSF may need to be retrieved and moved to 469 another vNSF of the same type when client flows are moved from 470 one vNSF to another. 471 - Multiple vNSFs may share the same physical platform 472 - There may be scenarios where multiple vNSFs collectively perform 473 the security policies needed. 475 +------------------------+ 476 | Security Controller | 477 +------------------------+ 478 ^ ^ 479 | | 480 +-----------+ +------------+ 481 | | 482 v v 483 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 484 | NSF-A +--------------+ | | NSF-B +--------------+ | 485 | |NSF Manager | | | |NSF Manager | | 486 | +--------------+ | | +--------------+ | 487 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 488 | |+---------+ +---------+| | | |+---------+ +---------+| | 489 | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | 490 | |+---------+ +---------+| | | |+---------+ +---------+| | 491 | | NSF-A cluster | | | | NSF-B cluster | | 492 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 493 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 495 Figure 2: Cluster of NSF Instantiations Management 497 7. I2NSF Flow Security Policy Structure 499 Even though security functions come in a variety of form factors and 500 have different features, provisioning to flow-based NSFs can be 501 standardized by using Event - Condition - Action (ECA) policy 502 rulesets. 504 Event is used to determine whether the condition clause of the 505 Policy Rule can be evaluated or not. 507 A Condition, when used in the context of policy rules for flow-based 508 NSFs, is used to determine whether or not the set of Actions in that 509 Policy Rule can be executed or not. A condition can be based on 510 various combinations of the content (header/payload) and/or the 511 context (session state, authentication state, etc) of the received 512 packets. 514 Action can be simple permit/deny/rate-limiting, applying specify 515 profile, or establishing specific secure tunnels, etc. 517 7.1. Client Facing Flow Security Policy structure 519 This layer is for client's network management system to express and 520 monitor the needed flow security policies for their specific flows. 522 Some customers may not have security skills. As such, they are not 523 able to express requirements or security policies that are precise 524 enough. These customers may instead express expectations or intent 525 of the functionality desired by their security policies. Customers 526 may also express guidelines such as which certain types of 527 destinations are not allowed for certain groups. As a result, there 528 could be different depths or layers of Service Layer policies. Here 529 are some examples of more abstract security Policies that can be 530 developed based on the I2NSF defined client interfaces: 532 o Pass for Subscriber "xxx" 533 o Enable basic parental control 534 o Enable "school protection control" 535 o Allow Internet traffic from 8:30 to 20:00 536 o Scan email for malware detection protect traffic to 537 corporate network with integrity and confidentiality 538 o Remove tracking data from Facebook [website = 539 *.facebook.com] 540 o My son is allowed to access Facebook from 18:30 to 20:00 542 One flow policy over Client Facing Interface may need multiple 543 network functions at various locations to achieve the enforcement. 544 Some flow Security policies from clients may not be granted because 545 of resource constraints. [I2NSF-Demo] describes an implementation of 546 translating a set of client policies to the flow policies to 547 individual NSFs. 549 I2NSF will first focus on simple client policies that can be modeled 550 as closely as possible to the flow security policies to individual 551 NSFs. The I2NSF simple client flow policies should have similar 552 structure as the policies to NSFs, but with more of a client- 553 oriented expression for the packet content, context, and other parts 554 of an ECA policy rule. This enables the client to construct an ECA 555 policy rule without having to know actual tags or addresses in the 556 packets. 558 For example, when used in the context of policy rules over the 559 Client Facing Interface: 561 - An Event can be "the client has passed AAA process"; 562 - A Condition can be matching client Identifier, or from specific 563 ingress or egress points; and 564 - An action can be establishing a IPSec tunnel. 566 7.2. NSF Facing Flow Security Policy structure 568 The NSF Facing Interface is to pass explicit rules to individual 569 NSFs to treat packets, as well as methods to monitor the execution 570 status of those functions. 572 Here are some examples of Events over the NSF facing interface: 574 - time == 08:00, 575 - a NSF state change from standby to active 577 Here are some examples of Conditions over the NSF facing interface 579 - Packet content values are based on one or more packet headers, 580 data from the packet payload, bits in the packet, or something 581 derived from the packet; 582 - Context values are based on measured and inferred knowledge that 583 define the state and environment in which a managed entity 584 exists or has existed. In addition to state data, this includes 585 data from sessions, direction of the traffic, time, and geo- 586 location information. State refers to the behavior of a managed 587 entity at a particular point in time. Hence, it may refer to 588 situations in which multiple pieces of information that are not 589 available at the same time must be analyzed. For example, 590 tracking established TCP connections (connections that have gone 591 through the initial three-way handshake). 593 Actions to individual flow-based NSFs include: 595 - Action ingress processing, such as pass, drop, rate limiting, 596 mirroring, etc. 597 - Action egress processing, such as invoke signaling, tunnel 598 encapsulation, packet forwarding and/or transformation. 599 - Applying a specific Functional Profile or signature - e.g., an 600 IPS Profile, a signature file, an anti-virus file, or a URL 601 filtering file. Many flow-based NSFs utilize profile and/or 602 signature files to achieve more effective threat detection and 603 prevention. It is not uncommon for a NSF to apply different 604 profiles and/or signatures for different flows. Some 605 profiles/signatures do not require any knowledge of past or 606 future activities, while others are stateful, and may need to 607 maintain state for a specific length of time. 609 The functional profile or signature file is one of the key 610 properties that determine the effectiveness of the NSF, and is 611 mostly NSF-specific today. The rulesets and software interfaces of 612 I2NSF aim to specify the format to pass profile and signature files 613 while supporting specific functionalities of each. 615 Policy consistency among multiple security function instances is 616 very critical because security policies are no longer maintained by 617 one central security device, but instead are enforced by multiple 618 security functions instantiated at various locations. 620 7.3. Difference from ACL data model 622 [ACL-MODEL] has defined rules for the Access Control List supported 623 by most routers/switches that forward packets based on packets' L2, 624 L3, or sometimes L4 headers. The actions for Access Control Lists 625 include Pass, Drop, or Redirect. 627 The functional profiles (or signatures) for NSFs are not present in 628 [ACL-MODEL] because the functional profiles are unique to specific 629 NSFs. For example, most IPS/IDS implementations have their 630 proprietary functions/profiles. One of the goals of I2NSF is to 631 define a common envelop format for exchanging or sharing profiles 632 among different organizations to achieve more effective protection 633 against threats. 635 The "packet content matching" of the I2NSF policies should not only 636 include the matching criteria specified by [ACL-MODEL] but also the 637 L4-L7 fields depending on the NSFs selected. 639 Some Flow-based NSFs need matching criteria that include the context 640 associated with the packets. 642 The I2NSF "actions" should extend the actions specified by [ACL- 643 MODEL] to include applying statistics functions, threat profiles, or 644 signature files that clients provide. 646 8. Capability Negotiation 648 It is very possible that the underlay network (or provider network) 649 does not have the capability or resource to enforce the flow 650 security policies requested by the overlay network (or enterprise 651 network). Therefore, it is very important to have capability 652 discovery or inquiry mechanism over the I2NSF Client Facing 653 Interface for the clients to discover if the needed flow polices can 654 be supported or not. 656 When an NSF cannot perform the desired provisioning (e.g., due to 657 resource constraints), it MUST inform the controller. 659 The protocol needed for this security function/capability 660 negotiation may be somewhat correlated to the dynamic service 661 parameter negotiation procedure [RFC7297]. The Connectivity 662 Provisioning Profile (CPP) template documented in RFC7297, even 663 though currently covering only Connectivity requirements (but 664 includes security clauses such as isolation requirements, non-via 665 nodes, etc.), could be extended as a basis for the negotiation 666 procedure. Likewise, the companion Connectivity Provisioning 667 Negotiation Protocol (CPNP) could be a candidate to proceed with the 668 negotiation procedure. 670 The "security as a service" would be a typical example of the kind 671 of (CPP-based) negotiation procedures that could take place between 672 a corporate customer and a service provider. However, more security 673 specific parameters have to be considered. 675 9. Registration consideration 677 9.1. Flow-based NSF Capability Characterization 679 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 680 the commonly deployed flow-based NSFs. However, the differences 681 among them are definitely blurring, due to technological capacity 682 increases, integration of platforms, and new threats. At their core: 683 . Firewall - A device or a function that analyzes packet headers and 684 enforces policy based on protocol type, source address, 685 destination address, source port, destination port, and/or other 686 attributes of the packet header. Packets that do not match policy 687 are rejected. Note that additional functions, such as logging and 688 notification of a system administrator, could optionally be 689 enforced as well. 690 . IDS (Intrusion Detection System) - A device or function that 691 analyzes packets, both header and payload, looking for known 692 events. When a known event is detected, a log message is generated 693 detailing the event. Note that additional functions, such as 694 notification of a system administrator, could optionally be 695 enforced as well. 696 . IPS (Intrusion Prevention System) - A device or function that 697 analyzes packets, both header and payload, looking for known 698 events. When a known event is detected, the packet is rejected. 699 Note that additional functions, such as logging and notification 700 of a system administrator, could optionally be enforced as well. 702 Flow-based NSFs differ in the depth of packet header or payload they 703 can inspect, the various session/context states they can maintain, 704 and the specific profiles and the actions they can apply. An example 705 of a session is "allowing outbound connection requests and only 706 allowing return traffic from the external network". 708 9.2. Registration Categories 710 Developers can register their NSFs using Packet Content Match 711 categories. The IDR Flow Specification [RFC5575] has specified 12 712 different packet header matching types. More packet content matching 713 types have been proposed in the IDR WG. I2NSF should re-use the 714 packet matching types being specified as much as possible. More 715 matching types might be added for Flow-based NSFS. Tables 1-4 below 716 list the applicable packet content categories that can be 717 potentially used as packet matching types by Flow-based NSFs: 719 +-----------------------------------------------------------+ 720 | Packet Content Matching Capability Index | 721 +---------------+-------------------------------------------+ 722 | Layer 2 | Layer 2 header fields: | 723 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 724 | | | 725 |---------------+-------------------------------------------+ 726 | Layer 3 | Layer header fields: | 727 | | protocol | 728 | IPv4 Header | dest port | 729 | | src port | 730 | | src address | 731 | | dest address | 732 | | dscp | 733 | | length | 734 | | flags | 735 | | ttl | 736 | | | 737 | IPv6 Header | | 738 | | addr | 739 | | protocol/nh | 740 | | src port | 741 | | dest port | 742 | | src address | 743 | | dest address | 744 | | length | 745 | | traffic class | 746 | | hop limit | 747 | | flow label | 748 | | dscp | 749 | | | 750 | TCP | Port | 751 | SCTP | syn | 752 | DCCP | ack | 753 | | fin | 754 | | rst | 755 | | ? psh | 756 | | ? urg | 757 | | ? window | 758 | | sockstress | 759 | | Note: bitmap could be used to | 760 | | represent all the fields | 761 | | | 762 | UDP | | 763 | | flood abuse | 764 | | fragment abuse | 765 | | Port | 766 | HTTP layer | | 767 | | | hash collision | 768 | | | http - get flood | 769 | | | http - post flood | 770 | | | http - random/invalid url | 771 | | | http - slowloris | 772 | | | http - slow read | 773 | | | http - r-u-dead-yet (rudy) | 774 | | | http - malformed request | 775 | | | http - xss | 776 | | | https - ssl session exhaustion | 777 +---------------+----------+--------------------------------+ 778 | IETF PCP | Configurable | 779 | | Ports | 780 | | | 781 +---------------+-------------------------------------------+ 782 | IETF TRAM | profile | 783 | | | 784 | | | 785 |---------------+-------------------------------------------+ 786 Table 1: Subject Capability Index 788 +-----------------------------------------------------------+ 789 | context matching Capability Index | 790 +---------------+-------------------------------------------+ 791 | Session | Session state, | 792 | | bidirectional state | 793 | | | 794 +---------------+-------------------------------------------+ 795 | Time | time span | 796 | | time occurrence | 797 +---------------+-------------------------------------------+ 798 | Events | Event URL, variables | 799 +---------------+-------------------------------------------+ 800 | Location | Text string, GPS coords, URL | 801 +---------------+-------------------------------------------+ 802 | Connection | Internet (unsecured), Internet | 803 | Type | (secured by VPN, etc.), Intranet, ... | 804 +---------------+-------------------------------------------+ 805 | Direction | Inbound, Outbound | 806 +---------------+-------------------------------------------+ 807 | State | Authentication State | 808 | | Authorization State | 809 | | Accounting State | 810 | | Session State | 811 +---------------+-------------------------------------------+ 813 Table 2: Object Capability Index 815 +-----------------------------------------------------------+ 816 | Action Capability Index | 817 +---------------+-------------------------------------------+ 818 | Ingress port | SFC header termination, | 819 | | VxLAN header termination | 820 +---------------+-------------------------------------------+ 821 | | Pass | 822 | Actions | Deny | 823 | | Mirror | 824 | | Simple Statistics: Count (X min; Day;..)| 825 | | Client specified Functions: URL | 826 +---------------+-------------------------------------------+ 827 | Egress | Encap SFC, VxLAN, or other header | 828 +---------------+-------------------------------------------+ 829 Table 3: Action Capability Index 831 +-----------------------------------------------------------+ 832 | Functional profile Index | 833 +---------------+-------------------------------------------+ 834 | Profile types | Name, type, or | 835 | Signature | Flexible Profile/signature URL | 836 | | Command for Controller to enable/disable | 837 | | | 838 +---------------+-------------------------------------------+ 839 Table 4: Function Capability Index 841 10. Manageability Considerations 843 Management of NSFs usually includes: 845 - life cycle management and resource management of NSFs 847 - configuration of devices, such as address configuration, 848 device internal attributes configuration, etc, 850 - signaling, and 852 - policy rules provisioning. 854 I2NSF will only focus on the policy rule provisioning part, i.e., 855 the last bullet listed above. 857 11. Security Considerations 859 Having a secure access to control and monitor NSFs is crucial for 860 hosted security service. Therefore, proper secure communication 861 channels have to be carefully specified for carrying the 862 controlling and monitoring information between the NSFs and their 863 management entity (or entities). 865 12. IANA Considerations 867 This document requires no IANA actions. RFC Editor: Please remove 868 this section before publication. 870 13. References 872 13.1. Normative References 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, March 1997. 877 [RFC3060] Moore, B, et al, "Policy Core Information Model (PCIM)", 878 RFC 3060, Feb 2001. 880 [RFC3460] Moore, B. "Policy Core Information Model (PCIM) 881 Extensions", RFC3460, Jan 2003. 883 [RFC5575] Marques, P, et al, "Dissemination of Flow Specification 884 Rules", RFC 5575, Aug 2009. 886 [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", 887 RFC7297, April 2014. 889 13.2. Informative References 891 [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM 892 Interface to Virtualized Security Services", , Oct 2014. 895 [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", , Oct 2014. 898 [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access 899 Network Use Case", , Oct 2014 902 [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security 903 Functions Problem Statement", , Jan 2015 906 [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL) 907 YANG Data Model", , Nov 2014. 909 [gs_NFV] ETSI NFV Group Specification, Network Functions 910 Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1, 911 2013. 913 [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall", 914 Network World, 11 November 2011 916 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services 917 in Mobile Network", IETF87 Berlin, July 29, 2013. 919 [I2NSF-Demo] Y. Xie, et al, "Interface to Network Security Functions 920 Demo Outline Design", , April 2015. 923 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 924 storage, distribution and enforcement of policies for 925 network security", Nov 2007. 927 14. Acknowledgments 929 Acknowledgements to xxx for his review and contributions. 931 This document was prepared using 2-Word-v2.0.template.dot. 933 Authors' Addresses 935 Edward Lopez 936 Fortinet 937 899 Kifer Road 938 Sunnyvale, CA 94086 939 Phone: +1 703 220 0988 940 Email: elopez@fortinet.com 942 Diego Lopez 943 Telefonica 944 Email: diego.r.lopez@telefonica.com 946 XiaoJun Zhuang 947 China Mobile 948 Email: zhuangxiaojun@chinamobile.com 950 Linda Dunbar 951 Huawei 952 Email: Linda.Dunbar@huawei.com 954 John Strassner 955 Huawei 956 John.sc.Strassner@huawei.com 958 Joe Parrott 959 BT 960 Email: joe.parrott@bt.com 962 Ramki Krishnan 963 Dell 964 Email: ramki_krishnan@dell.com 966 Seetharama Rao Durbha 967 CableLabs 968 Email: S.Durbha@cablelabs.com 970 Rakesh Kumar 971 Juniper Networks 972 Email: rkkumar@juniper.net 973 Anil Lohiya 974 Juniper Networks 975 Email: alohiya@juniper.net