idnits 2.17.1 draft-ietf-i2nsf-framework-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 12, 2017) is 2357 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-14 == 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 (~~), 5 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: May 12, 2018 Curveball Networks 5 L. Dunbar 6 J. Strassner 7 Huawei 8 R. Kumar 9 Juniper Networks 10 November 12, 2017 12 Framework for Interface to Network Security Functions 13 draft-ietf-i2nsf-framework-09 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 May 12, 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 . . . . . . . 10 71 6.3. Interface to vNSFs . . . . . . . . . . . . . . . . . . . . 11 72 6.4. Consistency . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. I2NSF Flow Security Policy Structure . . . . . . . . . . . . . 12 74 7.1. Customer-Facing Flow Security Policy Structure . . . . . . 12 75 7.2. NSF-Facing Flow Security Policy Structure . . . . . . . . 13 76 7.3. Differences from ACL Data Models . . . . . . . . . . . . . 15 77 8. Capability Negotiation . . . . . . . . . . . . . . . . . . . . 16 78 9. Registration Considerations . . . . . . . . . . . . . . . . . 16 79 9.1. Flow-Based NSF Capability Characterization . . . . . . . . 16 80 9.2. Registration Categories . . . . . . . . . . . . . . . . . 17 81 10. Manageability Considerations . . . . . . . . . . . . . . . . 20 82 11. Security Considerations . . . . . . . . . . . . . . . . . . 21 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 87 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 This document describes the framework for the Interface to Network 93 Security Functions (I2NSF), and defines a reference model (including 94 major functional components) for I2NSF. This includes an analysis of 95 the threats implied by the deployment of Network Security Functions 96 (NSFs) that are externally provided. It also describes how I2NSF 97 facilitates implementing security functions in a technology- and 98 vendor-independent manner in Software-Defined Networking (SDN) and 99 Network Function Virtualization (NFV) environments, while avoiding 100 potential constraints that could limit the capabilities of NSFs. 102 The I2NSF use cases [RFC8192] call for standard interfaces for users 103 of an I2NSF system (e.g., applications, overlay or cloud network 104 management system, or enterprise network administrator or management 105 system), to inform the I2NSF system which I2NSF functions should be 106 applied to which traffic (or traffic patterns). The I2NSF system 107 realizes this as a set of security rules for monitoring and 108 controlling the behavior of different traffic. It also provides 109 standard interfaces for users to monitor flow-based security 110 functions hosted and managed by different administrative domains. 112 [RFC8192] also describes the motivation and the problem space for 113 an Interface to Network Security Functions system. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 Note: as this is an informational document, no normative [RFC2119] 124 [RFC8174] key words are used. 126 2.1. Acronyms 128 The following acronyms are used in this document: 130 DOTS Distributed Denial-of-Service Open Threat Signaling 131 IDS Intrusion Detection System 132 IoT Internet of Things 133 IPS Intrusion Protection System 134 NSF Network Security Function 136 2.2. Definitions 138 The following terms, which are used in this document, are defined in 139 the I2NSF terminology document [I-D.ietf-i2nsf-terminology]: 141 Capability 143 Controller 145 Firewall 147 I2NSF Consumer 149 I2NSF NSF-Facing Interface 151 I2NSF Policy Rule 153 I2NSF Producer 155 I2NSF Registration Interface 157 I2NSF Registry 159 Interface 161 Interface Group 163 Intrusion Detection System 165 Intrusion Protection System 167 Network Security Function 169 Role 171 3. I2NSF Reference Model 173 Figure 1 shows a reference model (including major functional 174 components and interfaces) for an I2NSF system. This figure is drawn 175 from the point-of-view of the Network Operator Management System; 176 hence, this view does not assume any particular management 177 architecture for either the NSFs or for how NSFs are managed (on the 178 developer's side). In particular, the Network Operator Management 179 System does not participate in NSF data plane activities. 181 Note that the term "Controller" is defined in 182 [I-D.ietf-i2nsf-terminology]. 184 +-------------------------------------------------------+ 185 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 186 | Network Mgmt, another network domain's mgmt, etc.) | 187 +--------------------+----------------------------------+ 188 | 189 | I2NSF Consumer-Facing Interface 190 | 191 | I2NSF 192 +------------+---------+ Registration +-------------+ 193 | Network Operator Mgmt| Interface | Developer's | 194 | System | < --------- > | Mgmt System | 195 +----------------+-----+ +-------------+ 196 | 197 | I2NSF NSF-Facing Interface 198 | 199 +---------------+----+------------+---------------+ 200 | | | | 201 +---+---+ +---+---+ +---+---+ +---+---+ 202 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-m | ... 203 +-------+ +-------+ +-------+ +-------+ 205 Developer Mgmt System A Developer Mgmt System B 207 Figure 1: I2NSF Reference Model 209 When defining I2NSF interfaces, this framework adheres to the 210 following principles: 212 o Agnostic of network topology and NSF location in the network 214 o Agnostic of provider of the NSF (i.e., independent of the way that 215 the provider makes an NSF available, as well as how the provider 216 allows the NSF to be managed) 218 o Agnostic of any vendor-specific operational, administrative, and 219 management implementation, hosting environment, and form-factor 220 (physical or virtual) 222 o Agnostic to NSF control plane implementation (e.g., signaling 223 capabilities) 225 o Agnostic to NSF data plane implementation (e.g., encapsulation 226 capabilities) 228 In general, all I2NSF interfaces should require at least mutual 229 authentication and authorization for their use. Other security and 230 privacy considerations are specified in Section 11. 232 3.1. I2NSF Consumer-Facing Interface 234 The I2NSF Consumer-Facing Interface is used to enable different users 235 of a given I2NSF system to define, manage, and monitor security 236 policies for specific flows within an administrative domain. The 237 location and implementation of I2NSF policies are irrelevant to the 238 consumer of I2NSF policies. 240 Some examples of I2NSF Consumers include: 242 o A videoconference network manager that needs to dynamically inform 243 the underlay network to allow, rate-limit, or deny flows (some of 244 which are encrypted) based on specific fields in the packets for a 245 certain time span. 247 o Enterprise network administrators and management systems that need 248 to request their provider network to enforce specific I2NSF 249 policies for particular flows. 251 o An IoT management system sending requests to the underlay network 252 to block flows that match a set of specific conditions. 254 3.2. I2NSF NSF-Facing Interface 256 The I2NSF NSF-Facing Interface (NSF-Facing Interface for short) is 257 used to specify and monitor flow-based security policies enforced by 258 one or more NSFs. Note that the I2NSF Management System does not 259 need to use all features of a given NSF, nor does it need to use all 260 available NSFs. Hence, this abstraction enables NSF features to be 261 treated as building blocks by an NSF system; thus, developers are 262 free to use the security functions defined by NSFs independent of 263 vendor and technology. 265 Flow-based NSFs [RFC8192] inspect packets in the order that they 266 are received. Note that all Interface Groups require the NSF to be 267 registered using the Registration Interface. The Interface to 268 flow-based NSFs can be categorized as follows: 270 1. NSF Operational and Administrative Interface: an Interface Group 271 used by the I2NSF Management System to program the operational 272 state of the NSF; this also includes administrative control 273 functions. I2NSF Policy Rules represent one way to change this 274 Interface Group in a consistent manner. Since applications and 275 I2NSF Components need to dynamically control the behavior of 276 traffic that they send and receive, much of the I2NSF effort is 277 focused on this Interface Group. 279 2. Monitoring Interface: an Interface Group used by the the I2NSF 280 Management System to obtain monitoring information from one or 281 more selected NSFs. Each interface in this Interface Group could 282 be a query- or a report-based interface. The difference is that 283 a query-based interface is used by the the I2NSF Management 284 System to obtain information, whereas a report-based interface 285 is used by the NSF to provide information. The functionality of 286 this Interface Group may also be defined by other protocols, 287 such as SYSLOG and DOTS (Distributed Denial-of-Service Open 288 Threat Signaling). The I2NSF Management System may take one or 289 more actions based on the receipt of information; this should be 290 specified by an I2NSF Policy Rule. This Interface Group does 291 NOT change the operational state of the NSF. 293 This document uses the flow-based paradigm to develop the NSF-Facing 294 Interface. A common trait of flow-based NSFs is in the processing 295 of packets based on the content (e.g., header/payload) and/or 296 context (e.g., session state, authentication state) of the 297 received packets. This feature is one of the requirements for 298 defining the behavior of I2NSF. 300 3.3. I2NSF Registration Interface 302 NSFs provided by different vendors may have different capabilities. 303 In order to automate the process of utilizing multiple types of 304 security functions provided by different vendors, it is necessary to 305 have a dedicated interface for vendors to define the capabilities of 306 (i.e., register) their NSFs. This Interface is called the 307 I2NSF Registration Interface. 309 An NSF's capabilities can either be pre-configured or retrieved 310 dynamically through the I2NSF Registration Interface. If a new 311 function that is exposed to the consumer is added to an NSF, then 312 the capabilities of that new function should be registered in the 313 I2NSF Registry via the I2NSF Registration Interface, so that 314 interested management and control entities may be made aware of them. 316 4. Threats Associated with Externally Provided NSFs 318 While associated with a much higher flexibility, and in many cases a 319 necessary approach given the deployment conditions, the usage of 320 externally provided NSFs implies several additional concerns in 321 security. The most relevant threats associated with a security 322 platform of this nature are: 324 o An unknown/unauthorized user can try to impersonate another user 325 that can legitimately access external NSF services. This attack 326 may lead to accessing the I2NSF Policy Rules and applications of 327 the attacked user, and/or to generate network traffic outside the 328 security functions with a falsified identity. 330 o An authorized user may misuse assigned privileges to alter the 331 network traffic processing of other users in the NSF underlay or 332 platform. 334 o A user may try to install malformed elements (e.g., I2NSF Policy 335 Rules, or configuration files), trying to directly take the 336 control of a NSF or the whole provider platform. For example, 337 a user may exploit a vulnerability on one of the functions, or 338 may try to intercept or modify the traffic of other users in the 339 same provider platform. 341 o A malicious provider can modify the software (e.g., the operating 342 system or the specific NSF implementation) to alter the behavior 343 of one or more NSFs. This event has a high impact on all users 344 accessing NSFs, since the provider has the highest level of 345 privileges controlling the operation of the software. 347 o A user that has physical access to the provider platform can 348 modify the behavior of the hardware/software components, or the 349 components themselves. For example, the user can access a serial 350 console (most devices offer this interface for maintenance 351 reasons) to access the NSF software with the same level of 352 privilege of the provider. 354 The use of authentication, authorization, accounting, and audit 355 mechanisms is recommended for all users and applications to access 356 the I2NSF environment. This can be further enhanced by requiring 357 attestation to be used to detect changes to the I2NSF environment 358 by authorized parties. The characteristics of these procedures will 359 define the level of assurance of the I2NSF environment. 361 5. Avoiding NSF Ossification 363 A basic tenet in the introduction of I2NSF standards is that the 364 standards should not make it easier for attackers to compromise the 365 network. Therefore, in constructing standards for I2NSF Interfaces 366 as well as I2NSF Policy Rules, it is equally important to allow 367 support for specific functions, as this enables the introduction of 368 NSFs that evolve to meet new threats. Proposed standards for I2NSF 369 Interfaces to communicate with NSFs, as well as I2NSF Policy Rules 370 to control NSF functionality, should not: 372 o Narrowly define NSF categories, or their roles, when implemented 373 within a network. Security is a constantly evolving discipline. 374 The I2NSF framework relies on an object-oriented information 375 model, which provides an extensible definition of NSF information 376 elements and categories; it is recommended that implementations 377 follow this model. 379 o Attempt to impose functional requirements or constraints, either 380 directly or indirectly, upon NSF developers. Implementations 381 should be free to realize and apply NSFs in a way that best 382 suits the needs of the applications and environment using them. 384 o Be a limited lowest common denominator approach, where interfaces 385 can only support a limited set of standardized functions, without 386 allowing for developer-specific functions. NSFs, interfaces, and 387 the data communicated should be extensible, so that they can 388 evolve to protect against new threats. 390 o Be seen as endorsing a best common practice for the implementation 391 of NSFs; rather, this document describes the conceptual structure 392 and reference model of I2NSF. The purpose of this reference model 393 is to define a common set of concepts in order to facilitate the 394 flexible implementation of an I2NSF system. 396 To prevent constraints on NSF developers' creativity and innovation, 397 this document recommends the Flow-based NSF interfaces to be designed 398 from the paradigm of processing packets in the network. Flow-based 399 NSFs ultimately are packet-processing engines that inspect packets 400 traversing networks, either directly or in the context of sessions in 401 which the packet is associated. The goal is to create a workable 402 interface to NSFs that aids in their integration within legacy, SDN, 403 and/or NFV environments, while avoiding potential constraints which 404 could limit their functional capabilities. 406 6. The Network Connecting I2NSF Components 407 6.1. Network Connecting I2NSF Users and the I2NSF Controller 409 As a general principle, in the I2NSF environment, users directly 410 interact with the I2NSF Controller. Given the role of the I2NSF 411 Controller, a mutual authentication of users and the I2NSF 412 Controller is required. I2NSF does not mandate a specific 413 authentication scheme; it is up to the users to choose available 414 authentication schemes based on their needs. 416 Upon successful authentication, a trusted connection between the 417 user and the I2NSF Controller (or an endpoint designated by it) will 418 be established. This means that a direct, physical point-to-point 419 connection, with physical access restricted according to access 420 control, must be used. All traffic to and from the NSF environment 421 will flow through this connection. The connection is intended not 422 only to be secure, but trusted in the sense that it should be bound 423 to the mutual authentication between the user and the I2NSF 424 Controller, as described in [I-D.pastor-i2nsf-remote-attestation]. 425 The only possible exception is when the required level of assurance 426 is lower, (see Section 4.1 of [I-D.pastor-i2nsf-remote-attestation]), 427 in which case the user must be made aware of this circumstance. 429 6.2. Network Connecting the I2NSF Controller and NSFs 431 Most likely the NSFs are not directly attached to the I2NSF 432 Controller; for example, NSFs can be distributed across the network. 433 The network that connects the I2NSF Controller with the NSFs can be 434 the same network that carries the data traffic, or can be a dedicated 435 network for management purposes only. In either case, packet loss 436 could happen due to failure, congestion, or other reasons. 438 Therefore, the transport mechanism used to carry management data and 439 information must be secure. It does not have to be a reliable 440 transport; rather, a transport-independent reliable messaging 441 mechanism is required, where communication can be performed reliably 442 (e.g., by establishing end-to-end communication sessions and by 443 introducing explicit acknowledgement of messages into the 444 communication flow). Latency requirements for control message 445 delivery must also be evaluated. Note that monitoring does not 446 require reliable transport. 448 The network connection between the I2NSF Controller and NSFs can 449 rely either on: 451 o Open environments, where one or more NSFs can be hosted in one or 452 more external administrative domains that are reached via secure 453 external network connections. This requires more restrictive 454 security control to be placed over the I2NSF interface. The 455 information over the I2NSF interfaces shall be exchanged by 456 using the trusted connection described in section 6.1. 458 o Closed environments, where there is only one administrative 459 domain. Such environments provide a more **isolated** 460 environment, but still communicate over the same set of I2NSF 461 interfaces present in open environments (see above). Hence, the 462 security control and access requirements for closed environments 463 are the same as those for open environments. 465 The network connection between the I2NSF Controller and NSFs will 466 use the trusted connection mechanisms described in section 6.1. 467 Following these mechanisms, the connections need to rely on the use 468 of properly verified peer identities (e.g., through an AAA 469 framework). The implementations of identity management functions, as 470 well as the AAA framework, are out of scope for I2NSF. 472 6.3. Interface to vNSFs 474 There are some unique characteristics in interfacing to virtual NSFs: 476 o There could be multiple instantiations of one single NSF that has 477 been distributed across a network. When different instantiations 478 are visible to the I2NSF Controller, different policies may be 479 applied to different instantiations of an individual NSF (e.g., 480 to reflect the different roles that each vNSF is designated for). 481 Therefore, it is recommended that Roles, in addition to the use 482 of robust identities, be used to distinguish between different 483 instantiations of the same vNSF. Note that this also applies to 484 physical NSFs. 486 o When multiple instantiations of one single NSF appear as one 487 single entity to the I2NSF Controller, the I2NSF Controller may 488 need to either get assistance from other entities in the I2NSF 489 Management System, and/or delegate the provisioning of the 490 multiple instantiations of the (single) NSF to other entities in 491 the I2NSF Management System. This is shown in Figure 2 below. 493 o Policies enforced by one vNSF instance may need to be retrieved 494 and moved to another vNSF of the same type when user flows are 495 moved from one vNSF to another. 497 o Multiple vNSFs may share the same physical platform. 499 o There may be scenarios where multiple vNSFs collectively perform 500 the security policies needed. 502 +------------------------+ 503 | I2NSF Controller | 504 +------------------------+ 505 ^ ^ 506 | | 507 +-----------+ +------------+ 508 | | 509 v v 510 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 511 | NSF-A +--------------+ | | NSF-B +--------------+ | 512 | | NSF Manager | | | | NSF Manager | | 513 | +--------------+ | | +--------------+ | 514 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 515 | |+---------+ +---------+| | | |+---------+ +---------+| | 516 | || NSF-A#1 | ... | NSF-A#n || | | || NSF-B#1 | ... | NSF-B#m || | 517 | |+---------+ +---------+| | | |+---------+ +---------+| | 518 | | NSF-A cluster | | | | NSF-B cluster | | 519 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 520 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 522 Figure 2: Cluster of NSF Instantiations Management 524 6.4. Consistency 526 There are three basic models of consistency: 528 o centralized, which uses a single manager to impose behavior 529 o decentralized, in which managers make decisions without being 530 aware of each other (i.e., managers do not exchange information) 531 o distributed, in which managers make explicit use of information 532 exchange to arrive at a decision 534 This document does NOT make a recommendation on which of the above 535 three models to use. I2NSF Policy Rules, coupled with an appropriate 536 management strategy, is applicable to the design and integration of 537 any of the above three consistency models. 539 7. I2NSF Flow Security Policy Structure 541 Even though security functions come in a variety of form factors and 542 have different features, provisioning to flow-based NSFs can be 543 standardized by using policy rules. 545 In this version of I2NSF, policy rules are limited to imperative 546 paradigms. I2NSF is using an Event - Condition - Action (ECA) policy, 547 where: 549 o An Event clause is used to trigger the evaluation of the 550 Condition clause of the Policy Rule. 552 o A Condition clause is used to determine whether or not the set of 553 Actions in the I2NSF Policy Rule can be executed or not. 555 o An Action clause defines the type of operations that may be 556 performed on this packet or flow. 558 Each of the above three clauses are defined to be Boolean clauses. 559 This means that each is a logical statement that evaluates to either 560 TRUE or FALSE. 562 The above concepts are described in detail in 563 [I-D.draft-xibassnez-i2nsf-capability]. 565 7.1. Customer-Facing Flow Security Policy Structure 567 This layer is for the user's network management system to express and 568 monitor the needed flow security policies for their specific flows. 570 Some customers may not have the requisite security skills to express 571 security requirements or policies that are precise enough to 572 implement in an NSF. These customers may instead express 573 expectations (e.g., goals, or intent) of the functionality desired 574 by their security policies. Customers may also express guidelines, 575 such as which types of destinations are (or are not) allowed for 576 certain users. As a result, there could be different levels of 577 content and abstractions used in Service Layer policies. Here 578 are some examples of more abstract security Policies that can be 579 developed based on the I2NSF defined customer-facing interface: 581 Enable Internet access for authenticated users 583 Any operation on a HighValueAsset must use the corporate network 585 The use of FTP from any user except the CxOGroup must be audited 587 Streaming media applications are prohibited on the corporate 588 network during business hours 590 Scan email for malware detection protect traffic to corporate 591 network with integrity and confidentiality 593 Remove tracking data from Facebook [website = *.facebook.com] 595 One flow policy over the Customer-Facing Interface may need multiple 596 NSFs at various locations to achieve the desired enforcement. Some 597 flow security policies from users may not be granted because of 598 resource constraints. [I-D.xie-i2nsf-demo-outline-design] describes 599 an implementation of translating a set of user policies to the flow 600 policies to individual NSFs. 602 I2NSF will first focus on user policies that can be modeled as 603 closely as possible to the flow security policies used by individual 604 NSFs. An I2NSF user flow policy should be similar in structure to 605 the structure of an I2NSF Policy Rule, but with more of a user- 606 oriented expression for the packet content, context, and other parts 607 of an ECA policy rule. This enables the user to construct an I2NSF 608 Policy Rule without having to know the exact syntax of the desired 609 content (e.g., actual tags or addresses) to match in the packets. For 610 example, when used in the context of policy rules over the Client 611 Facing Interface: 613 An Event can be "the client has passed the AAA process" 615 A Condition can be matching user identifier, or from specific 616 ingress or egress points 618 An action can be establishing a IPsec tunnel 620 7.2. NSF-Facing Flow Security Policy Structure 622 The NSF-Facing Interface is to pass explicit rules to individual NSFs 623 to treat packets, as well as methods to monitor the execution status 624 of those functions. 626 Here are some examples of events over the NSF facing interface: 628 time == 08:00 630 notification that a NSF state changes from standby to active 632 user logon or logoff 634 Here are some examples of conditions over the NSF facing interface 636 o Packet content values that look for one or more packet headers, 637 data from the packet payload, bits in the packet, or data that 638 are derived from the packet. 640 o Context values that are based on measured and/or inferred 641 knowledge, which can be used to define the state and environment 642 in which a managed entity exists or has existed. In addition to 643 state data, this includes data from sessions, direction of the 644 traffic, time, and geo-location information. State refers to the 645 behavior of a managed entity at a particular point in time. 646 Hence, it may refer to situations in which multiple pieces of 647 information that are not available at the same time must be 648 analyzed. For example, tracking established TCP connections 649 (connections that have gone through the initial three-way 650 handshake). 652 Actions to individual flow-based NSFs include: 654 o Actions performed on ingress packets, such as pass, drop, 655 rate limiting, and mirroring. 657 o Actions performed on egress packets, such as invoke signaling, 658 tunnel encapsulation, packet forwarding and/or transformation. 660 o Applying a specific functional profile or signature - e.g., an IPS 661 Profile, a signature file, an anti-virus file, or a URL filtering 662 file. Many flow-based NSFs utilize profile and/or signature files 663 to achieve more effective threat detection and prevention. It is 664 not uncommon for a NSF to apply different profiles and/or 665 signatures for different flows. Some profiles/signatures do not 666 require any knowledge of past or future activities, while others 667 are stateful, and may need to maintain state for a specific length 668 of time. 670 The functional profile or signature file is one of the key properties 671 that determine the effectiveness of the NSF, and is mostly NSF- 672 specific today. The rulesets and software interfaces of I2NSF aim to 673 specify the format to pass profile and signature files while 674 supporting specific functionalities of each. 676 Policy consistency among multiple security function instances is very 677 critical because security policies are no longer maintained by one 678 central security device, but instead are enforced by multiple 679 security functions instantiated at various locations. 681 7.3. Differences from ACL Data Models 683 Policy rules are very different from ACLs. An ACL is NOT a policy. 684 Rather, policies are used to manage the construction and lifecycle 685 of an ACL. 687 [I-D.ietf-netmod-acl-model] has defined rules for the Access 688 Control List supported by most routers/switches that forward packets 689 based on packets' L2, L3, or sometimes L4 headers. The actions for 690 Access Control Lists include Pass, Drop, or Redirect. 692 The functional profiles (or signatures) for NSFs are not present in 693 [I-D.ietf-netmod-acl-model] because the functional profiles are 694 unique to specific NSFs. For example, most IPS/IDS implementations 695 have their proprietary functions/profiles. One of the goals of I2NSF 696 is to define a common envelop format for exchanging or sharing 697 profiles among different organizations to achieve more effective 698 protection against threats. 700 The "packet content matching" of the I2NSF policies should not only 701 include the matching criteria specified by 702 [I-D.ietf-netmod-acl-model], but also the L4-L7 fields depending 703 on the NSFs selected. 705 Some Flow-based NSFs need matching criteria that include the context 706 associated with the packets. This may also include metadata. 708 The I2NSF "actions" should extend the actions specified by 709 [I-D.ietf-netmod-acl-model] to include applying statistics 710 functions, threat profiles, or signature files that clients provide. 712 8. Capability Negotiation 714 It is very possible that the underlay network (or provider network) 715 does not have the capability or resource to enforce the flow security 716 policies requested by the overlay network (or enterprise network). 717 Therefore, it is required that the I2NSF system support dynamic 718 discovery capabilities, as well as a query mechanism, so that the 719 I2NSF system can expose appropriate security services using 720 I2NSF capabilities. This may also be used to support negotiation 721 between a user and the I2NSF system. Such dynamic negotiation 722 facilitates the delivery of the required security service(s). The 723 outcome of the negotiation would feed the I2NSF Management System, 724 which would then dynamically allocate appropriate NSFs (along with 725 any resources needed by the allocated NSFs) and configure the set of 726 security services that meet the requirements of the user. 728 When an NSF cannot perform the desired provisioning (e.g., due to 729 resource constraints), it must inform the I2NSF Management System. 731 The protocol needed for this security function/capability negotiation 732 may be somewhat correlated to the dynamic service parameter 733 negotiation procedure described in [RFC7297]. The Connectivity 734 Provisioning Profile (CPP) template, even though currently covering 735 only Connectivity requirements, includes security clauses such as 736 isolation requirements and non-via nodes. Hence, it could be extended 737 as a basis for the negotiation procedure. Likewise, the companion 738 Connectivity Provisioning Negotiation Protocol (CPNP) could be a 739 candidate for the negotiation procedure. 741 "Security-as-a-Service" would be a typical example of the kind of 742 (CPP-based) negotiation procedures that could take place between a 743 corporate customer and a service provider. However, more security 744 specific parameters have to be considered. 746 [I.D.-draft-xibassnez-i2nsf-capability] describes the concepts of 747 capabilities in detail. 749 9. Registration Considerations 751 9.1. Flow-Based NSF Capability Characterization 753 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 754 the commonly deployed flow-based NSFs. However, the differences 755 among them are definitely blurring, due to more powerful technology, 756 integration of platforms, and new threats. Basic types of 757 flow-based NSFs include: 759 o Firewall - A device or a function that analyzes packet headers and 760 enforces policy based on protocol type, source address, 761 destination address, source port, destination port, and/or other 762 attributes of the packet header. Packets that do not match policy 763 are rejected. Note that additional functions, such as logging and 764 notification of a system administrator, could optionally be 765 enforced as well. 766 o IDS (Intrusion Detection System) - A device or function that 767 analyzes packets, both header and payload, looking for known 768 events. When a known event is detected, a log message is 769 generated detailing the event. Note that additional functions, 770 such as notification of a system administrator, could optionally 771 be enforced as well. 773 o IPS (Intrusion Prevention System) - A device or function that 774 analyzes packets, both header and payload, looking for known 775 events. When a known event is detected, the packet is rejected. 776 Note that additional functions, such as logging and notification 777 of a system administrator, could optionally be enforced as well. 779 Flow-based NSFs differ in the depth of packet header or payload they 780 can inspect, the various session/context states they can maintain, 781 and the specific profiles and the actions they can apply. An example 782 of a session is "allowing outbound connection requests and only 783 allowing return traffic from the external network". 785 9.2. Registration Categories 787 Developers can register their NSFs using Packet Content Match 788 categories. The IDR (Inter-Domain Routing) Flow Specification 789 [RFC5575] has specified 12 different packet header matching types. 791 IPFIX data [IPFIX-D] defines IP flow information and mechanisms to 792 transmit such information. This includes flow attributes as well as 793 information about the metering and exporting processes is also 794 included. Such contain may be stored in a IPFIX registry [IPFIX-R]. 795 As such, IPFIX information should be considered for defining 796 categories of registration information. 798 More packet content matching types have been proposed in the IDR WG. 799 I2NSF should re-use the packet matching types being specified as much 800 as possible. More matching types might be added for Flow-based NSFS. 802 Tables 1-4 below list the applicable packet content categories that 803 can be potentially used as packet matching types by Flow-based NSFs: 805 +-----------------------------------------------------------+ 806 | Packet Content Matching Capability Index | 807 +---------------+-------------------------------------------+ 808 | Layer 2 | Layer 2 header fields: | 809 | Header | Source | 810 | | Destination | 811 | | s-VID | 812 | | c-VID | 813 | | Ethertype | 814 |---------------+-------------------------------------------+ 815 | Layer 3 | Layer header fields: | 816 | | protocol | 817 | IPv4 Header | dest port | 818 | | src port | 819 | | src address | 820 | | dest address | 821 | | dscp | 822 | | length | 823 | | flags | 824 | | ttl | 825 | IPv6 Header | | 826 | | protocol/nh | 827 | | src port | 828 | | dest port | 829 | | src address | 830 | | dest address | 831 | | length | 832 | | traffic class | 833 | | hop limit | 834 | | flow label | 835 | | dscp | 836 |---------------+-------------------------------------------+ 837 | Layer 4 | Layer header fields: | 838 | TCP | Port | 839 | SCTP | syn | 840 | DCCP | ack | 841 | | fin | 842 | | rst | 843 | | ? psh | 844 | | ? urg | 845 | | ? window | 846 | | sockstress | 847 | | Note: bitmap could be used to | 848 | | represent all the fields | 849 | UDP | | 850 | | flood abuse | 851 | | fragment abuse | 852 | | Port | 853 |---------------+-------------------------------------------+ 854 | HTTP layer | | 855 | | | hash collision | 856 | | | http - get flood | 857 | | | http - post flood | 858 | | | http - random/invalid url | 859 | | | http - slowloris | 860 | | | http - slow read | 861 | | | http - r-u-dead-yet (rudy) | 862 | | | http - malformed request | 863 | | | http - xss | 864 | | | https - ssl session exhaustion | 865 +---------------+----------+--------------------------------+ 866 | IETF PCP | Configurable | 867 | | Ports | 868 +---------------+-------------------------------------------+ 869 | IETF TRAM | profile | 870 +---------------+-------------------------------------------+ 872 Table 1: Packet Content Matching Capability Index 874 Notes: DCCP: Datagram Congestion Control Protocol 875 PCP: Port Control Protocol 876 TRAM: TURN Revised and Modernized, where TURN stands for 877 Traversal Using Relays around NAT 879 +-----------------------------------------------------------+ 880 | Context Matching Capability Index | 881 +---------------+-------------------------------------------+ 882 | Session | Session state, | 883 | | bidirectional state | 884 +---------------+-------------------------------------------+ 885 | Time | time span | 886 | | time occurrence | 887 +---------------+-------------------------------------------+ 888 | Events | Event URL, variables | 889 +---------------+-------------------------------------------+ 890 | Location | Text string, GPS coords, URL | 891 +---------------+-------------------------------------------+ 892 | Connection | Internet (unsecured), Internet | 893 | Type | (secured by VPN, etc.), Intranet, ... | 894 +---------------+-------------------------------------------+ 895 | Direction | Inbound, Outbound | 897 +---------------+-------------------------------------------+ 898 | State | Authentication State | 899 | | Authorization State | 900 | | Accounting State | 901 | | Session State | 902 +---------------+-------------------------------------------+ 904 Table 2: Context Matching Capability Index 906 Note: These fields are used to provide context information for I2NSF 907 Policy Rules to make decisions on how to handle traffic. For 908 example, GPS coordinates define the location of the traffic that 909 is entering and exiting an I2NSF system; this enables the 910 developer to apply different rules for ingress and egress 911 traffic handling. 913 +-----------------------------------------------------------+ 914 | Action Capability Index | 915 +---------------+-------------------------------------------+ 916 | Ingress port | SFC header termination, | 917 | | VxLAN header termination | 918 +---------------+-------------------------------------------+ 919 | | Pass | 920 | Actions | Deny | 921 | | Mirror | 922 | | Simple Statistics: Count (X min; Day;..)| 923 | | Client specified Functions: URL | 924 +---------------+-------------------------------------------+ 925 | Egress | Encap SFC, VxLAN, or other header | 926 +---------------+-------------------------------------------+ 928 Table 3: Action Capability Index 930 +-----------------------------------------------------------+ 931 | Functional Profile Index | 932 +---------------+-------------------------------------------+ 933 | Profile types | Name, type, or Flexible | 934 | Signature | Profile/signature URL Command for | 935 | | I2NSF Controller to enable/disable | 936 +---------------+-------------------------------------------+ 938 Table 4: Function Profile Index 940 10. Manageability Considerations 942 Management of NSFs includes: 944 o Lifecycle management and resource management of NSFs 946 o Configuration of devices, such as address configuration, device 947 internal attributes configuration, etc. 949 o Signaling 951 o Policy rules provisioning 953 Currently, I2NSF only focuses on the policy rule provisioning part. 955 11. Security Considerations 957 The configuration, control, and monitoring of NSFs provide access to 958 and information about security functions that are critical for 959 delivering network security and for protecting end-to-end traffic. 960 Therefore, it is important that the messages that are exchanged 961 within this architecture utilize a trustworthy, robust, and fully 962 secure communication channel. The mechanisms adopted within the 963 solution space must include proper secure communication channels 964 that are carefully specified for carrying the controlling and 965 monitoring information between the NSFs and their management entity 966 or entities. The threats associated with remotely managed NSFs are 967 discussed in Section 4, and solutions must address those concerns. 969 This framework is intended for enterprise users, with or without 970 cloud service offerings. Privacy of users must be provided by 971 using existing standard mechanisms, such as encryption; 972 anonymization of data should also be done if possible (depending 973 on the transport used). Such mechanisms require confidentiality 974 and integrity. 976 12. IANA Considerations 978 This document requires no IANA actions. RFC Editor: Please remove 979 this section before publication. 981 13. Acknowledgements 983 This document includes significant contributions from Christian 984 Jacquenet (Orange), Seetharama Rao Durbha (Cablelabs), Mohamed 985 Boucadair (Orange), Ramki Krishnan (Dell), Anil Lohiya (Juniper 986 Networks), Joe Parrott (BT), Frank Xialing (Huawei), and 987 XiaoJun Zhuang (China Mobile). 989 Some of the results leading to this work have received funding from 990 the European Union Seventh Framework Programme (FP7/2007-2013) under 991 grant agreement no. 611458. 993 14. References 995 14.1. Normative References 997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 998 Requirement Levels", BCP 14, RFC 2119, March 1997, 999 . 1001 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1002 and D. McPherson, "Dissemination of Flow Specification 1003 Rules", RFC 5575, August 2009, 1004 1006 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1007 Connectivity Provisioning Profile (CPP)", RFC 7297, 1008 July 2014, 1009 1011 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 1012 RFC 2119 Key Words", RFC 8174, May 2017, 1013 1015 [IPFIX-D] https://datatracker.ietf.org/wg/ipfix/documents/ 1017 [IPFIX-R] https://www.iana.org/assignments/ipfix/ipfix.xhtml 1019 14.2. Informative References 1021 [RFC8192] Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 1022 Jacquenet, "I2NSF Problem Statement and Use cases", 1023 RFC 8192, July 2017 1024 https://datatracker.ietf.org/doc/rfc8192/. 1026 [I-D.ietf-netmod-acl-model] 1027 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 1028 "Network Access Control List (ACL) YANG Data Model", 1029 draft-ietf-netmod-acl-model-14 (work in progress), 1030 October, 2017. 1032 [I-D.ietf-i2nsf-terminology] 1033 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1034 Birkholz, "Interface to Network Security Functions (I2NSF) 1035 Terminology", draft-ietf-i2nsf-terminology-04 (work in 1036 progress), July 2017. 1038 [I-D.draft-xibassnez-i2nsf-capability] 1039 Xia, L., Strassner, J., Basile, C., and Lopez, D., 1040 "Information Model of NSFs Capabilities", 1041 draft-xibassnez-i2nsf-capability-02.txt (work in 1042 progress), July, 2017. 1044 [I-D.pastor-i2nsf-remote-attestation] 1045 Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation 1046 Procedures for Network Security Functions (NSFs) through 1047 the I2NSF Security Controller", 1048 draft-pastor-i2nsf-nsf-remote-attestation-02 (work in 1049 progress), September 2017. 1051 [I-D.xie-i2nsf-demo-outline-design] 1052 Xie, Y., Xia, L., and J. Wu, "Interface to Network 1053 Security Functions Demo Outline Design", 1054 draft-xie-i2nsf-demo-outline-design-00 (work in progress), 1055 April 2015. 1057 [gs_NFV] "ETSI NFV Group Specification; Network Functions 1058 Virtualization (NFV) Use Cases. ETSI GS NFV 001v1.1.1", 1059 2013. 1061 Authors' Addresses 1063 Diego R. Lopez 1064 Telefonica I+D 1065 Editor Jose Manuel Lara, 9 1066 Seville, 41013 1067 Spain 1069 Phone: +34 682 051 091 1070 Email: diego.r.lopez@telefonica.com 1072 Edward Lopez 1073 Curveball Networks 1074 Chantilly, Virgina 1075 USA 1077 Phone: +1 703 220 0988 1078 Email: elopez@fortinet.com 1080 Linda Dunbar 1081 Huawei 1083 Email: Linda.Dunbar@huawei.com 1085 John Strassner 1086 Huawei 1088 Email: John.sc.Strassner@huawei.com 1090 Rakesh Kumar 1091 Juniper Networks 1093 Email: rkkumar@juniper.net