idnits 2.17.1 draft-ietf-i2nsf-framework-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 781 has weird spacing: '...| Layer heade...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 10, 2017) is 2383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-13 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-04 == Outdated reference: A later version (-07) exists of draft-pastor-i2nsf-nsf-remote-attestation-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF D. Lopez 2 Internet-Draft Telefonica I+D 3 Intended status: Informational E. Lopez 4 Expires: April 25, 2018 Curveball Networks 5 L. Dunbar 6 J. Strassner 7 Huawei 8 R. Kumar 9 Juniper Networks 10 October 10, 2017 12 Framework for Interface to Network Security Functions 13 draft-ietf-i2nsf-framework-08 15 Abstract 17 This document describes the framework for the Interface to Network 18 Security Functions (I2NSF), and defines a reference model (including 19 major functional components) for I2NSF. Network security functions 20 (NSFs) are packet-processing engines that inspect and optionally 21 modify packets traversing networks, either directly or in the context 22 of sessions to which the packet is associated. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 25, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. I2NSF Reference Model . . . . . . . . . . . . . . . . . . . . 4 63 3.1. I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 6 64 3.2. I2NSF NSF-Facing Interface . . . . . . . . . . . . . . . . 6 65 3.3. I2NSF Registration Interface . . . . . . . . . . . . . . . 7 66 4. Threats Associated with Externally Provided NSFs . . . . . . . 7 67 5. Avoiding NSF Ossification . . . . . . . . . . . . . . . . . . 8 68 6. The Network Connecting I2NSF Components . . . . . . . . . . . 9 69 6.1. Network Connecting I2NSF Users and I2NSF Controller . . . 9 70 6.2. Network Connecting the Controller and NSFs . . . . . . . 9 71 6.3. Interface to vNSFs . . . . . . . . . . . . . . . . . . . . 10 72 7. I2NSF Flow Security Policy Structure . . . . . . . . . . . . . 12 73 7.1. Customer-Facing Flow Security Policy Structure . . . . . . 12 74 7.2. NSF-Facing Flow Security Policy Structure . . . . . . . . 13 75 7.3. Differences from ACL Data Models . . . . . . . . . . . . . 14 76 8. Capability Negotiation . . . . . . . . . . . . . . . . . . . . 15 77 9. Registration Considerations . . . . . . . . . . . . . . . . . 16 78 9.1. Flow-Based NSF Capability Characterization . . . . . . . . 16 79 9.2. Registration Categories . . . . . . . . . . . . . . . . . 17 80 10. Manageability Considerations . . . . . . . . . . . . . . . . . 19 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 86 14.2. Informative References . . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 This document describes the framework for the Interface to Network 92 Security Functions (I2NSF), and defines a reference model (including 93 major functional components) for I2NSF. This includes an analysis of 94 the threats implied by the deployment of Network Security Functions 95 (NSFs) that are externally provided. It also describes how I2NSF 96 facilitates implementing security functions in a technology- and 97 vendor-independent manner in Software-Defined Networking (SDN) and 98 Network Function Virtualization (NFV) environments, while avoiding 99 potential constraints that could limit the capabilities of NSFs. 101 The I2NSF use cases [RFC8192] call for standard interfaces for users 102 of an I2NSF system (e.g., applications, overlay or cloud network 103 management system, or enterprise network administrator or management 104 system), to inform the I2NSF system which I2NSF functions should be 105 applied to which traffic (or traffic patterns). The I2NSF system 106 realizes this as a set of security rules for monitoring and 107 controlling the behavior of different traffic. It also provides 108 standard interfaces for users to monitor flow-based security 109 functions hosted and managed by different administrative domains. 111 [RFC8192] also describes the motivation and the problem space for 112 an Interface to Network Security Functions system. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 In this document, these words will appear with that interpretation 121 only when in ALL CAPS. Lower case uses of these words are not to be 122 interpreted as carrying RFC-2119 significance. 124 Note: as this is an informational document, no RFC-2119 key words 125 are used. 127 2.1. Acronyms 129 The following acronyms are used in this document: 131 DOTS Distributed Denial-of-Service Open Threat Signaling 132 IDS Intrusion Detection System 133 IoT Internet of Things 134 IPS Intrusion Protection System 135 NSF Network Security Function 137 2.2. Definitions 139 The following terms, which are used in this document, are defined in 140 the I2NSF terminology document [I-D.ietf-i2nsf-terminology]: 142 Capability 144 Controller 146 Firewall 148 I2NSF Consumer 150 I2NSF NSF-Facing Interface 152 I2NSF Policy Rule 154 I2NSF Producer 156 I2NSF Registration Interface 158 I2NSF Registry 160 Interface 162 Interface Group 164 Intrusion Detection System 166 Intrusion Protection System 168 Network Security Function 170 Role 172 3. I2NSF Reference Model 174 Figure 1 shows a reference model (including major functional 175 components and interfaces) for an I2NSF system. This figure is drawn 176 from the point-of-view of the Network Operator Management System; 177 hence, this view does not assume any particular management 178 architecture for either the NSFs or for how NSFs are managed (on the 179 developer's side). In particular, the Network Operator Management 180 System does not participate in NSF data plane activities. 182 Note that the term "Controller" is defined in 183 [I-D.ietf-i2nsf-terminology]. 185 +-------------------------------------------------------+ 186 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 187 | Network Mgmt, another network domain's mgmt, etc.) | 188 +--------------------+----------------------------------+ 189 | 190 | I2NSF Consumer-Facing Interface 191 | 192 | I2NSF 193 +------------+---------+ Registration +-------------+ 194 | Network Operator Mgmt| Interface | Developer's | 195 | System | < --------- > | Mgmt System | 196 +----------------+-----+ +-------------+ 197 | 198 | I2NSF NSF-Facing Interface 199 | 200 +---------------+----+------------+---------------+ 201 | | | | 202 +---+---+ +---+---+ +---+---+ +---+---+ 203 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-m | ... 204 +-------+ +-------+ +-------+ +-------+ 206 Developer Mgmt System A Developer Mgmt System B 208 Figure 1: I2NSF Reference Model 210 When defining I2NSF interfaces, this framework adheres to the 211 following principles: 213 o Agnostic of network topology and NSF location in the network 215 o Agnostic of provider of the NSF (i.e., independent of the way that 216 the provider makes an NSF available, as well as how the provider 217 allows the NSF to be managed) 219 o Agnostic of any vendor-specific operational, administrative, and 220 management implementation, hosting environment, and form-factor 221 (physical or virtual) 223 o Agnostic to NSF control plane implementation (e.g., signaling 224 capabilities) 226 o Agnostic to NSF data plane implementation (e.g., encapsulation 227 capabilities) 229 3.1. I2NSF Consumer-Facing Interface 231 The I2NSF Consumer-Facing Interface is used to enable different users 232 of a given I2NSF system to define, manage, and monitor security 233 policies for specific flows within an administrative domain. The 234 location and implementation of I2NSF policies are irrelevant to the 235 consumer of I2NSF policies. 237 Some examples of I2NSF Consumers include: 239 o A videoconference network manager that needs to dynamically inform 240 the underlay network to allow, rate-limit, or deny flows (some of 241 which are encrypted) based on specific fields in the packets for a 242 certain time span. 244 o Enterprise network administrators and management systems that need 245 to request their provider network to enforce specific I2NSF 246 policies for particular flows. 248 o An IoT management system sending requests to the underlay network 249 to block flows that match a set of specific conditions. 251 3.2. I2NSF NSF-Facing Interface 253 The I2NSF NSF-Facing Interface (NSF-Facing Interface for short) is 254 used to specify and monitor flow-based security policies enforced by 255 one or more NSFs. Note that the I2NSF Management System does not 256 need to use all features of a given NSF, nor does it need to use all 257 available NSFs. Hence, this abstraction enables NSF features to be 258 treated as building blocks by an NSF system; thus, developers are 259 free to use the security functions defined by NSFs independent of 260 vendor and technology. 262 Flow-based NSFs [RFC8192] inspect packets in the order that they 263 are received. Note that all Interface Groups require the NSF to be 264 registered using the Registration Interface. The Interface to 265 flow-based NSFs can be categorized as follows: 267 1. NSF Operational and Administrative Interface: an Interface Group 268 used by the I2NSF Management System to program the operational 269 state of the NSF; this also includes administrative control 270 functions. I2NSF Policy Rules represent one way to change this 271 Interface Group in a consistent manner. Since applications and 272 I2NSF Components need to dynamically control the behavior of 273 traffic that they send and receive, much of the I2NSF effort is 274 focused on this Interface Group. 276 2. Monitoring Interface: an Interface Group used by the the I2NSF 277 Management System to obtain monitoring information from one or 278 more selected NSFs. Each interface in this Interface Group could 279 be a query- or a report-based interface. The difference is that 280 a query-based interface is used by the the I2NSF Management 281 System to obatin information, whereas a report-based interface 282 is used by the NSF to provide information. The functionality of 283 this Interface Group may also be defined by other protocols, 284 such as SYSLOG and DOTS (Distributed Denial-of-Service Open 285 Threat Signaling). The I2NSF Management System may take one or 286 more actions based on the receipt of information; this should be 287 specified by an I2NSF Policy Rule. This Interface Group does 288 NOT change the operational state of the NSF. 290 This document uses the flow-based paradigm to develop the NSF-Facing 291 Interface. A common trait of flow-based NSFs is in the processing 292 of packets based on the content (e.g., header/payload) and/or 293 context (e.g., session state, authentication state) of the 294 received packets. This feature is one of the requirements for 295 defining the behavior of I2NSF. 297 3.3. I2NSF Registration Interface 299 NSFs provided by different vendors may have different capabilities. 300 In order to automate the process of utilizing multiple types of 301 security functions provided by different vendors, it is necessary to 302 have a dedicated interface for vendors to define the capabilities of 303 (i.e., register) their NSFs. This Interface is called the 304 I2NSF Registration Interface. 306 An NSF's capabilities can either be pre-configured or retrieved 307 dynamically through the I2NSF Registration Interface. If a new 308 function that is exposed to the consumer is added to an NSF, then 309 the capabilities of that new function should be registered in the 310 I2NSF Registry via the I2NSF Registration Interface, so that 311 interested management and control entities may be made aware of them. 313 4. Threats Associated with Externally Provided NSFs 315 While associated with a much higher flexibility, and in many cases a 316 necessary approach given the deployment conditions, the usage of 317 externally provided NSFs implies several additional concerns in 318 security. The most relevant threats associated with a security 319 platform of this nature are: 321 o An unknown/unauthorized user can try to impersonate another user 322 that can legitimately access external NSF services. This attack 323 may lead to accessing the I2NSF Policy Rules and applications of 324 the attacked user, and/or to generate network traffic outside the 325 security functions with a falsified identity. 327 o An authorized user may misuse assigned privileges to alter the 328 network traffic processing of other users in the NSF underlay or 329 platform. 331 o A user may try to install malformed elements (e.g., I2NSF Policy 332 Rules, or configuration files), trying to directly take the 333 control of a NSF or the whole provider platform. For example, 334 a user may exploit a vulnerability on one of the functions, or 335 may try to intercept or modify the traffic of other users in the 336 same provider platform. 338 o A malicious provider can modify the software (e.g., the operating 339 system or the specific NSF implementation) to alter the behavior 340 of one or more NSFs. This event has a high impact on all users 341 accessing NSFs, since the provider has the highest level of 342 privileges controlling the operation of the software. 344 o A user that has physical access to the provider platform can 345 modify the behavior of the hardware/software components, or the 346 components themselves. For example, the user can access a serial 347 console (most devices offer this interface for maintenance 348 reasons) to access the NSF software with the same level of 349 privilege of the provider. 351 The above threats may be mitigated by requiring the use of an AAA 352 framework for all users to access the I2NSF environment. This could 353 be further enhanced by requiring attestation to be used to detect 354 changes to the I2NSF environment by authorized parties. 356 5. Avoiding NSF Ossification 358 A basic tenet in the introduction of I2NSF standards is that the 359 standards should not make it easier for attackers to compromise the 360 network. Therefore, in constructing standards for I2NSF Interfaces 361 as well as I2NSF Policy Rules, it is equally important to allow 362 support for specific functions, as this enables the introduction of 363 NSFs that evolve to meet new threats. Proposed standards for I2NSF 364 Interfaces to communicate with NSFs, as well as I2NSF Policy Rules 365 to control NSF functionality, should not: 367 o Narrowly define NSF categories, or their roles, when implemented 368 within a network 370 o Attempt to impose functional requirements or constraints, either 371 directly or indirectly, upon NSF developers 373 o Be a limited lowest common denominator approach, where interfaces 374 can only support a limited set of standardized functions, without 375 allowing for developer-specific functions 377 o Be seen as endorsing a best common practice for the implementation 378 of NSFs; rather, this document describes the conceptual structure 379 and reference model of I2NSF 381 To prevent constraints on NSF developers' creativity and innovation, 382 this document recommends the Flow-based NSF interfaces to be designed 383 from the paradigm of processing packets in the network. Flow-based 384 NSFs ultimately are packet-processing engines that inspect packets 385 traversing networks, either directly or in the context of sessions in 386 which the packet is associated. The goal is to create a workable 387 interface to NSFs that aids in their integration within legacy, SDN, 388 and/or NFV environments, while avoiding potential constraints which 389 could limit their functional capabilities. 391 6. The Network Connecting I2NSF Components 393 6.1. Network Connecting I2NSF Users and the I2NSF Controller 395 As a general principle, in the I2NSF environment, users directly 396 interact with the I2NSF Controller. Given the role of the I2NSF 397 Controller, a mutual authentication of users and the I2NSF 398 Controller may be required. I2NSF does not mandate a specific 399 authentication scheme; it is up to the users to choose available 400 authentication schemes based on their needs. 402 Upon successful authentication, a trusted connection between the 403 user and the I2NSF Controller (or an endpoint designated by it) will 404 be established. All traffic to and from the NSF environment will 405 flow through this connection. The connection is intended not only to 406 be secure, but trusted in the sense that it should be bound to the 407 mutual authentication between the user and the I2NSF Controller, as 408 described in [I-D.pastor-i2nsf-remote-attestation]. The only 409 possible exception is when the required level of assurance is lower, 410 (see Section 4.1 of [I-D.pastor-i2nsf-remote-attestation]), in which 411 case the user must be made aware of this circumstance. 413 6.2. Network Connecting the I2NSF 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 network. 417 The network that connects the I2NSF Controller with the NSFs can be 418 the same network that carries the data traffic, or can be a dedicated 419 network for management purposes only. In either case, packet loss 420 could happen due to failure, congestion, or other reasons. 422 Therefore, the transport mechanism used to carry the control messages 423 and monitoring information should provide reliable message delivery. 424 Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the 425 Stream Control Transmission Protocol (SCTP) will need to be evaluated 426 for applicability. Latency requirements for control message delivery 427 must also be evaluated. 429 The network connection between the I2NSF Controller and NSFs can 430 rely either on: 432 o Closed environments, where there is only one administrative 433 domain. Less restrictive access control and simpler validation 434 can be used inside the domain because of the protected nature of 435 a closed environment. 437 o Open environments, where one or more NSFs can be hosted in one or 438 more external administrative domains that are reached via secure 439 external network connections. This requires more restrictive 440 security control to be placed over the I2NSF interface. The 441 information over the I2NSF interfaces shall be exchanged by 442 using the trusted connection described in section 6.1. 444 When running in an open environment, I2NSF needs to rely on the use 445 of standard I2NSF interfaces to properly verify peer identities 446 (e.g., through an AAA framework). The implementations of identity 447 management functions, as well as the AAA framework, are out of scope 448 for I2NSF. 450 6.3. Interface to vNSFs 452 There are some unique characteristics in interfacing to virtual NSFs: 454 o There could be multiple instantiations of one single NSF that has 455 been distributed across a network. When different instantiations 456 are visible to the I2NSF Controller, different policies may be 457 applied to different instantiations of an individual NSF (e.g., 458 to reflect the different roles that each vNSF is designated for). 459 Therefore, it is recommended that Roles, in addition to the use 460 of robust identities, be used to distinguish between different 461 instantiations of the same vNSF. Note that this also applies to 462 physical NSFs. 464 o When multiple instantiations of one single NSF appear as one 465 single entity to the I2NSF Controller, the I2NSF Controller may 466 need to either get assistance from other entities in the I2NSF 467 Management System, and/or delegate the provisioning of the 468 multiple instantiations of the (single) NSF to other entities in 469 the I2NSF Management System. This is shown in Figure 2 below. 471 o Policies enforced by one vNSF instance may need to be retrieved 472 and moved to another vNSF of the same type when user flows are 473 moved from one vNSF to another. 475 o Multiple vNSFs may share the same physical platform. 477 o There may be scenarios where multiple vNSFs collectively perform 478 the security policies needed. 480 +------------------------+ 481 | I2NSF Controller | 482 +------------------------+ 483 ^ ^ 484 | | 485 +-----------+ +------------+ 486 | | 487 v v 488 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 489 | NSF-A +--------------+ | | NSF-B +--------------+ | 490 | | NSF Manager | | | | NSF Manager | | 491 | +--------------+ | | +--------------+ | 492 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 493 | |+---------+ +---------+| | | |+---------+ +---------+| | 494 | || NSF-A#1 | ... | NSF-A#n || | | || NSF-B#1 | ... | NSF-B#m || | 495 | |+---------+ +---------+| | | |+---------+ +---------+| | 496 | | NSF-A cluster | | | | NSF-B cluster | | 497 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 498 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 500 Figure 2: Cluster of NSF Instantiations Management 502 6.4. Consistency 504 There are three basic models of consistency: 506 o centralized, which uses a single manager to impose behavior 507 o decentralized, in which managers make decisions without being 508 aware of each other (i.e., managers do not exchange information) 509 o distributed, in which managers make explicit use of information 510 exchange to arrive at a decision 512 This document does NOT make a recommendation on which of the above 513 three models to use. I2NSF Policy Rules, coupled with an appropriate 514 management strategy, is applicable to the design and integration of 515 any of the above three consistency models. 517 7. I2NSF Flow Security Policy Structure 519 Even though security functions come in a variety of form factors and 520 have different features, provisioning to flow-based NSFs can be 521 standardized by using policy rules. 523 In this version of I2NSF, policy rules are limited to imperative 524 paradigms. I2NSF is using an Event - Condition - Action (ECA) policy, 525 where: 527 o An Event clause is used to trigger the evaluation of the 528 Condition clause of the Policy Rule. 530 o A Condition clause is used to determine whether or not the set of 531 Actions in the I2NSF Policy Rule can be executed or not. 533 o An Action clause defines the type of operations that may be 534 performed on this packet or flow. 536 Each of the above three clauses are defined to be Boolean clauses. 537 This means that each is a logical statement that evaluates to either 538 TRUE or FALSE. 540 The above concepts are described in detail in 541 [I-D.draft-xibassnez-i2nsf-capability]. 543 7.1. Customer-Facing Flow Security Policy Structure 545 This layer is for the user's network management system to express and 546 monitor the needed flow security policies for their specific flows. 548 Some customers may not have the requisite security skills to express 549 security requirements or policies that are precise enough to 550 implement in an NSF. These customers may instead express 551 expectations (e.g., goals, or intent) of the functionality desired 552 by their security policies. Customers may also express guidelines, 553 such as which types of destinations are (or are not) allowed for 554 certain users. As a result, there could be different levels of 555 content and abstractions used in Service Layer policies. Here 556 are some examples of more abstract security Policies that can be 557 developed based on the I2NSF defined customer-facing interface: 559 Enable Internet access for authenticated users 561 Any operation on a HighValueAsset must use the corporate network 563 The use of FTP from any user except the CxOGroup must be audited 565 Streaming media applications are prohibited on the corporate 566 network during business hours 567 Scan email for malware detection protect traffic to corporate 568 network with integrity and confidentiality 570 Remove tracking data from Facebook [website = *.facebook.com] 572 One flow policy over the Customer-Facing Interface may need multiple 573 NSFs at various locations to achieve the desired enforcement. Some 574 flow security policies from users may not be granted because of 575 resource constraints. [I-D.xie-i2nsf-demo-outline-design] describes 576 an implementation of translating a set of user policies to the flow 577 policies to individual NSFs. 579 I2NSF will first focus on user policies that can be modeled as 580 closely as possible to the flow security policies used by individual 581 NSFs. An I2NSF user flow policy should be similar in structure to 582 the structure of an I2NSF Policy Rule, but with more of a user- 583 oriented expression for the packet content, context, and other parts 584 of an ECA policy rule. This enables the user to construct an I2NSF 585 Policy Rule without having to know the exact syntax of the desired 586 content (e.g., actual tags or addresses) to match in the packets. For 587 example, when used in the context of policy rules over the Client 588 Facing Interface: 590 An Event can be "the client has passed the AAA process" 592 A Condition can be matching user identifier, or from specific 593 ingress or egress points 595 An action can be establishing a IPsec tunnel 597 7.2. NSF-Facing Flow Security Policy Structure 599 The NSF-Facing Interface is to pass explicit rules to individual NSFs 600 to treat packets, as well as methods to monitor the execution status 601 of those functions. 603 Here are some examples of events over the NSF facing interface: 605 time == 08:00 607 notification that a NSF state changes from standby to active 609 user logon or logoff 611 Here are some examples of conditions over the NSF facing interface 613 o Packet content values that look for one or more packet headers, 614 data from the packet payload, bits in the packet, or data that 615 are derived from the packet. 617 o Context values that are based on measured and/or inferred 618 knowledge, which can be used to define the state and environment 619 in which a managed entity exists or has existed. In addition to 620 state data, this includes data from sessions, direction of the 621 traffic, time, and geo-location information. State refers to the 622 behavior of a managed entity at a particular point in time. 623 Hence, it may refer to situations in which multiple pieces of 624 information that are not available at the same time must be 625 analyzed. For example, tracking established TCP connections 626 (connections that have gone through the initial three-way 627 handshake). 629 Actions to individual flow-based NSFs include: 631 o Actions performed on ingress packets, such as pass, drop, 632 rate limiting, and mirroring. 634 o Actions performed on egress packets, such as invoke signaling, 635 tunnel encapsulation, packet forwarding and/or transformation. 637 o Applying a specific functional profile or signature - e.g., an IPS 638 Profile, a signature file, an anti-virus file, or a URL filtering 639 file. Many flow-based NSFs utilize profile and/or signature files 640 to achieve more effective threat detection and prevention. It is 641 not uncommon for a NSF to apply different profiles and/or 642 signatures for different flows. Some profiles/signatures do not 643 require any knowledge of past or future activities, while others 644 are stateful, and may need to maintain state for a specific length 645 of time. 647 The functional profile or signature file is one of the key properties 648 that determine the effectiveness of the NSF, and is mostly NSF- 649 specific today. The rulesets and software interfaces of I2NSF aim to 650 specify the format to pass profile and signature files while 651 supporting specific functionalities of each. 653 Policy consistency among multiple security function instances is very 654 critical because security policies are no longer maintained by one 655 central security device, but instead are enforced by multiple 656 security functions instantiated at various locations. 658 7.3. Differences from ACL Data Models 660 Policy rules are very different from ACLs. An ACL is NOT a policy. 661 Rather, policies are used to manage the construction and lifecycle 662 of an ACL. 664 [I-D.ietf-netmod-acl-model] has defined rules for the Access 665 Control List supported by most routers/switches that forward packets 666 based on packets' L2, L3, or sometimes L4 headers. The actions for 667 Access Control Lists include Pass, Drop, or Redirect. 669 The functional profiles (or signatures) for NSFs are not present in 670 [I-D.ietf-netmod-acl-model] because the functional profiles are 671 unique to specific NSFs. For example, most IPS/IDS implementations 672 have their proprietary functions/profiles. One of the goals of I2NSF 673 is to define a common envelop format for exchanging or sharing 674 profiles among different organizations to achieve more effective 675 protection against threats. 677 The "packet content matching" of the I2NSF policies should not only 678 include the matching criteria specified by 679 [I-D.ietf-netmod-acl-model], but also the L4-L7 fields depending 680 on the NSFs selected. 682 Some Flow-based NSFs need matching criteria that include the context 683 associated with the packets. This may also include metadata. 685 The I2NSF "actions" should extend the actions specified by 686 [I-D.ietf-netmod-acl-model] to include applying statistics 687 functions, threat profiles, or signature files that clients provide. 689 8. Capability Negotiation 691 It is very possible that the underlay network (or provider network) 692 does not have the capability or resource to enforce the flow security 693 policies requested by the overlay network (or enterprise network). 694 Therefore, it is required that the I2NSF system support dynamic 695 discovery capabilities, as well as a query mechanism, so that the 696 I2NSF system can expose appropriate security services using 697 I2NSF capabilities. This may also be used to support negotiation 698 between a user and the I2NSF system. Such dynamic negotiation 699 facilitates the delivery of the required security service(s). The 700 outcome of the negotiation would feed the I2NSF Management System, 701 which would then dynamically allocate appropriate NSFs (along with 702 any resources needed by the allocated NSFs) and configure the set of 703 security services that meet the requirements of the user. 705 When an NSF cannot perform the desired provisioning (e.g., due to 706 resource constraints), it must inform the I2NSF Management System. 708 The protocol needed for this security function/capability negotiation 709 may be somewhat correlated to the dynamic service parameter 710 negotiation procedure described in [RFC7297]. The Connectivity 711 Provisioning Profile (CPP) template, even though currently covering 712 only Connectivity requirements, includes security clauses such as 713 isolation requirements and non-via nodes. Hence, it could be extended 714 as a basis for the negotiation procedure. Likewise, the companion 715 Connectivity Provisioning Negotiation Protocol (CPNP) could be a 716 candidate for the negotiation procedure. 718 "Security-as-a-Service" would be a typical example of the kind of 719 (CPP-based) negotiation procedures that could take place between a 720 corporate customer and a service provider. However, more security 721 specific parameters have to be considered. 723 [I.D.-draft-xibassnez-i2nsf-capability] describes the concepts of 724 capabilities in detail. 726 9. Registration Considerations 728 9.1. Flow-Based NSF Capability Characterization 730 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 731 the commonly deployed flow-based NSFs. However, the differences 732 among them are definitely blurring, due to more powerful technology, 733 integration of platforms, and new threats. Basic types of 734 flow-based NSFs include: 736 o Firewall - A device or a function that analyzes packet headers and 737 enforces policy based on protocol type, source address, 738 destination address, source port, destination port, and/or other 739 attributes of the packet header. Packets that do not match policy 740 are rejected. Note that additional functions, such as logging and 741 notification of a system administrator, could optionally be 742 enforced as well. 744 o IDS (Intrusion Detection System) - A device or function that 745 analyzes packets, both header and payload, looking for known 746 events. When a known event is detected, a log message is 747 generated detailing the event. Note that additional functions, 748 such as notification of a system administrator, could optionally 749 be enforced as well. 751 o IPS (Intrusion Prevention System) - A device or function that 752 analyzes packets, both header and payload, looking for known 753 events. When a known event is detected, the packet is rejected. 754 Note that additional functions, such as logging and notification 755 of a system administrator, could optionally be enforced as well. 757 Flow-based NSFs differ in the depth of packet header or payload they 758 can inspect, the various session/context states they can maintain, 759 and the specific profiles and the actions they can apply. An example 760 of a session is "allowing outbound connection requests and only 761 allowing return traffic from the external network". 763 9.2. Registration Categories 765 Developers can register their NSFs using Packet Content Match 766 categories. The IDR (Inter-Domain Routing) Flow Specification 767 [RFC5575] has specified 12 different packet header matching types. 768 More packet content matching types have been proposed in the IDR WG. 769 I2NSF should re-use the packet matching types being specified as much 770 as possible. More matching types might be added for Flow-based NSFS. 771 Tables 1-4 below list the applicable packet content categories that 772 can be potentially used as packet matching types by Flow-based NSFs: 774 +-----------------------------------------------------------+ 775 | Packet Content Matching Capability Index | 776 +---------------+-------------------------------------------+ 777 | Layer 2 | Layer 2 header fields: | 778 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 779 | | | 780 |---------------+-------------------------------------------+ 781 | Layer 3 | Layer header fields: | 782 | | protocol | 783 | IPv4 Header | dest port | 784 | | src port | 785 | | src address | 786 | | dest address | 787 | | dscp | 788 | | length | 789 | | flags | 790 | | ttl | 791 | | | 792 | IPv6 Header | | 793 | | addr | 794 | | protocol/nh | 795 | | src port | 796 | | dest port | 797 | | src address | 798 | | dest address | 799 | | length | 800 | | traffic class | 801 | | hop limit | 802 | | flow label | 803 | | dscp | 804 | TCP | Port | 805 | SCTP | syn | 806 | DCCP | ack | 807 | | fin | 808 | | rst | 809 | | ? psh | 810 | | ? urg | 811 | | ? window | 812 | | sockstress | 813 | | Note: bitmap could be used to | 814 | | represent all the fields | 815 | UDP | | 816 | | flood abuse | 817 | | fragment abuse | 818 | | Port | 819 | HTTP layer | | 820 | | | hash collision | 821 | | | http - get flood | 822 | | | http - post flood | 823 | | | http - random/invalid url | 824 | | | http - slowloris | 825 | | | http - slow read | 826 | | | http - r-u-dead-yet (rudy) | 827 | | | http - malformed request | 828 | | | http - xss | 829 | | | https - ssl session exhaustion | 830 +---------------+----------+--------------------------------+ 831 | IETF PCP | Configurable | 832 | | Ports | 833 | | | 834 +---------------+-------------------------------------------+ 835 | IETF TRAM | profile | 836 | | | 837 | | | 838 |---------------+-------------------------------------------+ 840 Table 1: Packet Content Matching Capability Index 842 Notes: DCCP: Datagram Congestion Control Protocol 843 PCP: Port Control Protocol 844 TRAM: TURN Revised and Modernized, where TURN stands for 845 Traversal Using Relays around NAT 847 +-----------------------------------------------------------+ 848 | Context Matching Capability Index | 849 +---------------+-------------------------------------------+ 850 | Session | Session state, | 851 | | bidirectional state | 852 | | | 853 +---------------+-------------------------------------------+ 854 | Time | time span | 855 | | time occurrence | 856 +---------------+-------------------------------------------+ 857 | Events | Event URL, variables | 858 +---------------+-------------------------------------------+ 859 | Location | Text string, GPS coords, URL | 860 +---------------+-------------------------------------------+ 861 | Connection | Internet (unsecured), Internet | 862 | Type | (secured by VPN, etc.), Intranet, ... | 863 +---------------+-------------------------------------------+ 864 | Direction | Inbound, Outbound | 865 +---------------+-------------------------------------------+ 866 | State | Authentication State | 867 | | Authorization State | 868 | | Accounting State | 869 | | Session State | 870 +---------------+-------------------------------------------+ 872 Table 2: Context Matching Capability Index 874 +-----------------------------------------------------------+ 875 | Action Capability Index | 876 +---------------+-------------------------------------------+ 877 | Ingress port | SFC header termination, | 878 | | VxLAN header termination | 879 +---------------+-------------------------------------------+ 880 | | Pass | 881 | Actions | Deny | 882 | | Mirror | 883 | | Simple Statistics: Count (X min; Day;..)| 884 | | Client specified Functions: URL | 885 +---------------+-------------------------------------------+ 886 | Egress | Encap SFC, VxLAN, or other header | 887 +---------------+-------------------------------------------+ 889 Table 3: Action Capability Index 891 +-----------------------------------------------------------+ 892 | Functional Profile Index | 893 +---------------+-------------------------------------------+ 894 | Profile types | Name, type, or Flexible | 895 | Signature | Profile/signature URL Command for | 896 | | I2NSF Controller to enable/disable | 897 +---------------+-------------------------------------------+ 899 Table 4: Function Profile Index 901 10. Manageability Considerations 903 Management of NSFs includes: 905 o Lifecycle management and resource management of NSFs 907 o Configuration of devices, such as address configuration, device 908 internal attributes configuration, etc. 910 o Signaling 912 o Policy rules provisioning 914 Currently, I2NSF only focuses on the policy rule provisioning part. 916 11. Security Considerations 918 NSF control and monitoring demand trustworthy, robust, and fully 919 secured access. Therefore, proper secure communication channels 920 have to be carefully specified for carrying the controlling and 921 monitoring information between the NSFs and their management 922 entity or entities. This has been discussed in Section 4. 924 This framework is intended for enterprise users, with or without 925 cloud service offerings. Privacy of users should be provided by 926 using existing standard mechanisms, such as encryption; 927 anonymization of data should also be done (if possible depending 928 on the transport used). Such mechanisms require confidentiality 929 and integrity. 931 12. IANA Considerations 933 This document requires no IANA actions. RFC Editor: Please remove 934 this section before publication. 936 13. Acknowledgements 938 This document includes significant contributions from Christian 939 Jacquenet (Orange), Seetharama Rao Durbha (Cablelabs), Mohamed 940 Boucadair (Orange), Ramki Krishnan (Dell), Anil Lohiya (Juniper 941 Networks), Joe Parrott (BT), Frank Xialing (Huawei), and 942 XiaoJun Zhuang (China Mobile). 944 Some of the results leading to this work have received funding from 945 the European Union Seventh Framework Programme (FP7/2007-2013) under 946 grant agreement no. 611458. 948 14. References 950 14.1. Normative References 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, March 1997, 954 . 956 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 957 and D. McPherson, "Dissemination of Flow Specification 958 Rules", RFC 5575, August 2009, 959 . 961 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 962 Connectivity Provisioning Profile (CPP)", RFC 7297, 963 July 2014, 964 . 966 14.2. Informative References 968 [RFC8192] 969 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 970 Jacquenet, "I2NSF Problem Statement and Use cases", 971 RFC 8192, July 2017 972 https://datatracker.ietf.org/doc/rfc8192/. 974 [I-D.ietf-netmod-acl-model] 975 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 976 "Network Access Control List (ACL) YANG Data Model", 977 draft-ietf-netmod-acl-model-13 (work in progress), 978 October, 2017. 980 [I-D.ietf-i2nsf-terminology] 981 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 982 Birkholz, "Interface to Network Security Functions (I2NSF) 983 Terminology", draft-ietf-i2nsf-terminology-04 (work in 984 progress), July 2017. 986 [I-D.draft-xibassnez-i2nsf-capability] 987 Xia, L., Strassner, J., Basile, C., and Lopez, D., 988 "Information Model of NSFs Capabilities", 989 draft-xibassnez-i2nsf-capability-02.txt (work in 990 progress), July, 2017. 992 [I-D.pastor-i2nsf-remote-attestation] 993 Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation 994 Procedures for Network Security Functions (NSFs) through 995 the I2NSF Security Controller", 996 draft-pastor-i2nsf-nsf-remote-attestation-02 (work in 997 progress), September 2017. 999 [I-D.xie-i2nsf-demo-outline-design] 1000 Xie, Y., Xia, L., and J. Wu, "Interface to Network 1001 Security Functions Demo Outline Design", 1002 draft-xie-i2nsf-demo-outline-design-00 (work in progress), 1003 April 2015. 1005 [gs_NFV] "ETSI NFV Group Specification; Network Functions 1006 Virtualization (NFV) Use Cases. ETSI GS NFV 001v1.1.1", 1007 2013. 1009 Authors' Addresses 1011 Diego R. Lopez 1012 Telefonica I+D 1013 Editor Jose Manuel Lara, 9 1014 Seville, 41013 1015 Spain 1017 Phone: +34 682 051 091 1018 Email: diego.r.lopez@telefonica.com 1020 Edward Lopez 1021 Curveball Networks 1022 Chantilly, Virgina 1023 USA 1025 Phone: +1 703 220 0988 1026 Email: elopez@fortinet.com 1028 Linda Dunbar 1029 Huawei 1031 Email: Linda.Dunbar@huawei.com 1033 John Strassner 1034 Huawei 1036 Email: John.sc.Strassner@huawei.com 1038 Rakesh Kumar 1039 Juniper Networks 1041 Email: rkkumar@juniper.net