idnits 2.17.1 draft-ietf-i2nsf-framework-06.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 764 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 (July 2, 2017) is 2483 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-11 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 == Outdated reference: A later version (-02) exists of draft-xibassnez-i2nsf-capability-01 == Outdated reference: A later version (-07) exists of draft-pastor-i2nsf-nsf-remote-attestation-01 Summary: 1 error (**), 0 flaws (~~), 7 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: November 3, 2017 Curveball Networks 5 L. Dunbar 6 J. Strassner 7 Huawei 8 R. Kumar 9 Juniper Networks 10 July 2, 2017 12 Framework for Interface to Network Security Functions 13 draft-ietf-i2nsf-framework-06 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 November 3, 2017. 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 . . . . . . . 8 67 5. Avoiding NSF Ossification . . . . . . . . . . . . . . . . . . 9 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 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 . . . . . . . . 14 75 7.3. Differences from ACL Data Models . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 20 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 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 Software-Defined Networking (SDN) and Network Function 97 Virtualization (NFV) control, while avoiding potential constraints 98 that could limit the internal functionality and capabilities of NSFs. 100 The I2NSF use cases [I-D.ietf-i2nsf-problem-and-use-cases] call for 101 standard interfaces for users of an I2NSF system (e.g., applications, 102 overlay or cloud network management system, or enterprise network 103 administrator or management system), to inform the I2NSF system which 104 I2NSF functions should be applied to which traffic (or traffic 105 patterns). The I2NSF system realizes this as a set of security rules 106 for monitoring and controlling the behavior of different traffic. It 107 also provides standard interfaces for users to monitor flow-based 108 security functions hosted and managed by different administrative 109 domains. 111 [I-D.ietf-i2nsf-problem-and-use-cases] also describes the motivation 112 and the problem space for an Interface to Network Security Functions 113 system. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 In this document, these words will appear with that interpretation 122 only when in ALL CAPS. Lower case uses of these words are not to be 123 interpreted as carrying RFC-2119 significance. 125 Note: as this is an informational document, no RFC-2119 key words 126 are used. 128 2.1. Acronyms 130 The following acronyms are used in this document: 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 Controller; hence, this view does not 177 assume any particular management architecture for either the NSFs 178 or for how NSFs are managed (on the developer's side). In 179 particular, the controller does not participate in NSF data 180 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 Mgnt, Enterprise | 187 | network Mgnt, another network domain's mgnt, etc.) | 188 +--------------------+----------------------------------+ 189 | 190 | I2NSF Consumer-Facing Interface 191 | 192 | I2NSF 193 +------------+---------+ Registration +-------------+ 194 | Network Operator Mgmt| Interface | Developer's | 195 | Controller | < --------- > | Mgnt System | 196 +----------------+-----+ +-------------+ 197 | 198 | I2NSF NSF-Facing Interface 199 | 200 +---------------+----+------------+---------------+ 201 | | | | 202 +---+---+ +---+---+ +---+---+ +---+---+ 203 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-m | ... 204 +-------+ +-------+ +-------+ +-------+ 206 Developer Mgnt System A Developer Mgnt System B 208 Figure 1: I2NSF Reference Model 210 When defining controller 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 controller does not need to use all 256 features of a given NSF, nor does it need to use all available NSFs. 257 Hence, this abstraction enables the different features from the set 258 of NSFs that make up able given I2NSF system to be treated as 259 building blocks, so that developers are free to use the security 260 functions needed independent of vendor and technology. 262 Flow-based NSFs [I-D.ietf-i2nsf-problem-and-use-cases] inspect 263 packets in the order that they are received. The Interface to flow- 264 based NSFs can be grouped into the following types of Interface 265 Groups: 267 1. NSF Operational and Administrative Interface: an Interface Group 268 used by a controller to program the operational state of the NSF; 269 this also includes administrative control functions. I2NSF 270 Policy Rules represent one way to change this Interface Group in 271 a consistent manner. Since applications and controllers need to 272 dynamically control the behavior of traffic that they send and 273 receive, much of the I2NSF effort is focused on this 274 Interface Group. 276 2. Monitoring Interface: an Interface Group used by a controller to 277 obtain monitoring information from one or more selected NSFs. 278 Each interface in this Interface Group could be a query- or a 279 report-based interface (as described above). This Interface 280 Group includes logging and query functions between the NSF and 281 external systems. The functionality of this Interface Group may 282 also be defined by other protocols, such as SYSLOG and DOTS 283 (DDoS Open Threat Signaling). This Interface Group does NOT 284 change the operational state of the NSF. 286 3. Notification Interface: an Interface Group used by a controller 287 to receive notification events (e.g., alarms) from NSFs. This 288 requires the NSF to be registered. The controller may take an 289 action based on the event; this should be specified by an I2NSF 290 Policy Rule. This Interface Group does NOT change the 291 operational state of the NSF. 293 This draft proposes that the flow-based paradigm is used to develop 294 the NSF-Facing Interface. A common trait of flow-based NSFs is in 295 the processing of packets based on the content (e.g., header/payload) 296 and/or context (e.g., session state, authentication state) of the 297 received packets. 299 3.3. I2NSF Registration Interface 301 NSFs provided by different vendors may have different capabilities. 302 In order to automate the process of utilizing multiple types of 303 security functions provided by different vendors, it is necessary to 304 have a dedicated interface for vendors to define the capabilities of 305 (i.e., register) their NSFs. This Interface is called the 306 I2NSF Registration Interface. 308 An NSF's capabilities can either be pre-configured or retrieved 309 dynamically through the I2NSF Registration Interface. If a new 310 function that is exposed to the consumer is added to an NSF, then 311 the capabilities of that new function should be registered in the 312 I2NSF Registry via the I2NSF Registration Interface, so that 313 interested management and control entities may be made aware of them. 315 4. Threats Associated with Externally Provided NSFs 317 While associated with a much higher flexibility, and in many cases a 318 necessary approach given the deployment conditions, the usage of 319 externally provided NSFs implies several additional concerns in 320 security. The most relevant threats associated with a security 321 platform of this nature are: 323 o An unknown/unauthorized user can try to impersonate another user 324 that can legitimately access external NSF services. This attack 325 may lead to accessing the I2NSF Policy Rules and applications of 326 the attacked user, and/or to generate network traffic outside the 327 security functions with a falsified identity. 329 o An authorized user may misuse assigned privileges to alter the 330 network traffic processing of other users in the NSF underlay or 331 platform. 333 o A user may try to install malformed elements (e.g., I2NSF Policy 334 Rules, or configuration files), trying to directly take the 335 control of a NSF or the whole provider platform. For example, 336 a user may exploit a vulnerability on one of the functions, or 337 may try to intercept or modify the traffic of other users in the 338 same provider platform. 340 o A malicious provider can modify the software (e.g., the operating 341 system or the specific NSF implementation) to alter the behavior 342 of one or more NSFs. This event has a high impact on all users 343 accessing NSFs, since the provider has the highest level of 344 privileges controlling the operation of the software. 346 o A user that has physical access to the provider platform can 347 modify the behavior of the hardware/software components, or the 348 components themselves. For example, the user can access a serial 349 console (most devices offer this interface for maintenance 350 reasons) to access the NSF software with the same level of 351 privilege of the provider. 353 The above threats may be mitigated by requiring the use of an AAA 354 framework for all users to access the I2NSF environment. This could 355 be further enhanced by requiring attestation to be used to detect 356 changes to the I2NSF environment by authorized parties. Note that 357 periodical attestation enables users to detect alterations in 358 the NSFs and their supporting infrastructure, and raises the degree 359 of physical control necessary to perform an untraceable malicious 360 modification of the I2NSF environment. 362 5. Avoiding NSF Ossification 364 An important concept underlying this framework is the fact that 365 attackers do not have standards as to how to attack networks, so it 366 is equally important to not constrain NSF developers to offering a 367 limited set of security functions. In other words, the introduction 368 of I2NSF standards should not make it easier for attackers to 369 compromise the network. Therefore, in constructing standards for 370 I2NSF Interfaces as well as I2NSF Policy Rules, it is equally 371 important to allow support for specific functions, as this enables 372 the introduction of NSFs that evolve to meet new threats. Proposed 373 standards for I2NSF Interfaces to communicate with NSFs, as well as 374 I2NSF Policy Rules to control NSF functionality, should not: 376 o Narrowly define NSF categories, or their roles, when implemented 377 within a network 379 o Attempt to impose functional requirements or constraints, either 380 directly or indirectly, upon NSF developers 382 o Be a limited lowest common denominator approach, where interfaces 383 can only support a limited set of standardized functions, without 384 allowing for developer-specific functions 386 o Be seen as endorsing a best common practice for the implementation 387 of NSFs 389 To prevent constraints on NSF developers' creativity and innovation, 390 this document recommends the Flow-based NSF interfaces to be designed 391 from the paradigm of processing packets in the network. Flow-based 392 NSFs ultimately are packet-processing engines that inspect packets 393 traversing networks, either directly or in the context of sessions in 394 which the packet is associated. The goal is to create a workable 395 interface to NSFs that aids in their integration within legacy, SDN, 396 and/or NFV environments, while avoiding potential constraints which 397 could limit their functional capabilities. 399 6. The Network Connecting I2NSF Components 401 6.1. Network Connecting I2NSF Users and I2NSF Controller 403 As a general principle, in the I2NSF environment users directly 404 interact with the controller. Given the role of the Security 405 Controller, a mutual authentication of users and the Security 406 Controller maybe required. I2NSF does not mandate a specific 407 authentication scheme; it is up to the users to choose available 408 authentication scheme based on their needs. 410 Upon successful authentication, a trusted connection between the 411 user and the Controller (or an endpoint designated by it) shall 412 be established. All traffic to and from the NSF environment will 413 flow through this connection. The connection is intended not only to 414 be secure, but trusted in the sense that it should be bound to the 415 mutual authentication between the user and the Controller, as 416 described in [I-D.pastor-i2nsf-remote-attestation]. The only 417 possible exception is when the required level of assurance is lower, 418 (see Section 4.1 of [I-D.pastor-i2nsf-remote-attestation], in which 419 case the user must be made aware of this circumstance. 421 [TBD: should we add the Remote Attestation to this section?] 423 6.2. Network Connecting the Controller and NSFs 425 Most likely the NSFs are not directly attached to the I2NSF 426 Controller; for example, NSFs can be distributed across the network. 427 The network that connects the I2NSF Controller with the NSFs can be 428 the same network that carries the data traffic, or can be a dedicated 429 network for management purposes only. In either case, packet loss 430 could happen due to failure, congestion, or other reasons. 432 Therefore, the transport mechanism used to carry the control messages 433 and monitoring information should provide reliable message delivery. 434 Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the 435 Stream Control Transmission Protocol (SCTP) will need to be evaluated 436 for applicability. Latency requirements for control message delivery 437 must also be evaluated. 439 The network connection between the Controller and NSFs can rely 440 either on: 442 o Closed environments, where there is only one administrative 443 domain. Less restrictive access control and simpler validation 444 can be used inside the domain because of the protected nature of 445 a closed environment. 447 o Open environments, where one or more NSFs can be hosted in one or 448 more external administrative domains that are reached via secure 449 external network connections. This requires more restrictive 450 security control to be placed over the I2NSF interface. The 451 information over the I2NSF interfaces shall be exchanged used 452 trusted channels as described in the previous section. 454 When running in an open environment, I2NSF needs to rely on 455 interfaces to properly verify peer identities (e.g., through an AAA 456 framework). The implementations of identity management functions, 457 as well as the AAA framework, are out of scope for I2NSF. 459 6.3. Interface to vNSFs 461 There are some unique characteristics in interfacing to virtual NSFs: 463 o There could be multiple instantiations of one single NSF that has 464 been distributed across a network. When different instantiations 465 are visible to the Controller, different policies may be applied 466 to different instantiations of an individual NSF (e.g., to 467 reflect the different roles that each vNSF is designated for). 468 Therefore, it is recommended that Roles, in addition to the use 469 of robust identities, be used to distinguish between different 470 instantiations of the same vNSF. 472 o When multiple instantiations of one single NSF appear as one 473 single entity to the Controller, the Controller may need to 474 either get assistance from other entities in the I2NSF 475 Management System, and/or delegate the provisioning of the 476 multiple instantiations of the (single) NSF to other entities in 477 the I2NSF Management System. This is shown in Figure 2 below. 479 o Policies to one vNSF may need to be retrieved and moved to another 480 vNSF of the same type when user flows are moved from one vNSF to 481 another. 483 o Multiple vNSFs may share the same physical platform. 485 o There may be scenarios where multiple vNSFs collectively perform 486 the security policies needed. 488 +------------------------+ 489 | Controller | 490 +------------------------+ 491 ^ ^ 492 | | 493 +-----------+ +------------+ 494 | | 495 v v 496 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 497 | NSF-A +--------------+ | | NSF-B +--------------+ | 498 | |NSF Manager | | | |NSF Manager | | 499 | +--------------+ | | +--------------+ | 500 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 501 | |+---------+ +---------+| | | |+---------+ +---------+| | 502 | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | 503 | |+---------+ +---------+| | | |+---------+ +---------+| | 504 | | NSF-A cluster | | | | NSF-B cluster | | 505 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 506 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 508 Figure 2: Cluster of NSF Instantiations Management 510 7. I2NSF Flow Security Policy Structure 512 Even though security functions come in a variety of form factors and 513 have different features, provisioning to flow-based NSFs can be 514 standardized by using policy rules. 516 In this version of I2NSF, policy rules are limited to imperative 517 paradigms. I2NSF is using an Event - Condition - Action (ECA) policy, 518 where: 520 o An Event clause is used to trigger the evaluation of the 521 Condition clause of the Policy Rule. 523 o A Condition clause is used to determine whether or not the set of 524 Actions in the I2NSF Policy Rule can be executed or not. 526 o An Action clause defines the type of operations that may be 527 performed on this packet or flow. 529 Each of the above three clauses are defined to be Boolean clauses. 530 This means that each is a logical statement that evaluates to either 531 TRUE or FALSE. 533 The above concepts are described in detail in 534 [I-D.draft-xibassnez-i2nsf-capability]. 536 7.1. Customer-Facing Flow Security Policy Structure 538 This layer is for user's network management system to express and 539 monitor the needed flow security policies for their specific flows. 541 Some customers may not have security skills. As such, they are not 542 able to express requirements or security policies that are precise 543 enough. These customers may instead express expectations or intent 544 of the functionality desired by their security policies. Customers 545 may also express guidelines such as which certain types of 546 destinations are not allowed for certain groups. As a result, there 547 could be different depths or layers of Service Layer policies. Here 548 are some examples of more abstract security Policies that can be 549 developed based on the I2NSF defined customer-facing interfaces: 551 Pass for Subscriber "xxx" 553 Enable basic parental control 555 Enable "school protection control" 557 Allow Internet traffic from 8:30 to 20:00 558 Scan email for malware detection protect traffic to corporate 559 network with integrity and confidentiality 561 Remove tracking data from Facebook [website = *.facebook.com] 563 My son is allowed to access Facebook from 18:30 to 20:00 565 One flow policy over Customer-Facing Interface may need multiple 566 network functions at various locations to achieve the enforcement. 567 Some flow security policies from users may not be granted because of 568 resource constraints. [I-D.xie-i2nsf-demo-outline-design] describes 569 an implementation of translating a set of user policies to the flow 570 policies to individual NSFs. 572 I2NSF will first focus on simple client policies that can be modeled 573 as closely as possible to the flow security policies to individual 574 NSFs. The I2NSF simple client flow policies should have similar 575 structure as the policies to NSFs, but with more of a client-oriented 576 expression for the packet content, context, and other parts of an ECA 577 policy rule. This enables the client to construct an I2NSF Policy 578 Rule without having to know actual tags or addresses in the packets. 579 For example, when used in the context of policy rules over the Client 580 Facing Interface: 582 An Event can be "the client has passed AAA process" 584 A Condition can be matching user identifier, or from specific 585 ingress or egress points 587 An action can be establishing a IPSec tunnel 589 7.2. NSF-Facing Flow Security Policy Structure 591 The NSF-Facing Interface is to pass explicit rules to individual NSFs 592 to treat packets, as well as methods to monitor the execution status 593 of those functions. 595 Here are some examples of events over the NSF facing interface: 597 time == 08:00 599 a NSF state change from standby to active 601 Here are some examples of conditions over the NSF facing interface 603 o Packet content values are based on one or more packet headers, 604 data from the packet payload, bits in the packet, or data that 605 are derived from the packet 607 o Context values are based on measured and inferred knowledge that 608 define the state and environment in which a managed entity exists 609 or has existed. In addition to state data, this includes data 610 from sessions, direction of the traffic, time, and geo-location 611 information. State refers to the behavior of a managed entity at 612 a particular point in time. Hence, it may refer to situations in 613 which multiple pieces of information that are not available at the 614 same time must be analyzed. For example, tracking established TCP 615 connections (connections that have gone through the initial three- 616 way handshake). 618 Actions to individual flow-based NSFs include: 620 o Action ingress processing, such as pass, drop, rate limiting, 621 mirroring, etc. 623 o Action egress processing, such as invoke signaling, tunnel 624 encapsulation, packet forwarding and/or transformation. 626 o Applying a specific functional profile or signature - e.g., an IPS 627 Profile, a signature file, an anti-virus file, or a URL filtering 628 file. Many flow-based NSFs utilize profile and/or signature files 629 to achieve more effective threat detection and prevention. It is 630 not uncommon for a NSF to apply different profiles and/or 631 signatures for different flows. Some profiles/signatures do not 632 require any knowledge of past or future activities, while others 633 are stateful, and may need to maintain state for a specific length 634 of time. 636 The functional profile or signature file is one of the key properties 637 that determine the effectiveness of the NSF, and is mostly NSF- 638 specific today. The rulesets and software interfaces of I2NSF aim to 639 specify the format to pass profile and signature files while 640 supporting specific functionalities of each. 642 Policy consistency among multiple security function instances is very 643 critical because security policies are no longer maintained by one 644 central security device, but instead are enforced by multiple 645 security functions instantiated at various locations. 647 7.3. Differences from ACL Data Models 649 Policy rules are very different from ACLs. An ACL is NOT a policy. 650 Rather, policies are used to manage the construction and lifecycle 651 of an ACL. 653 [I-D.ietf-netmod-acl-model] has defined rules for the Access 654 Control List supported by most routers/switches that forward packets 655 based on packets' L2, L3, or sometimes L4 headers. The actions for 656 Access Control Lists include Pass, Drop, or Redirect. 658 The functional profiles (or signatures) for NSFs are not present in 659 [I-D.ietf-netmod-acl-model] because the functional profiles are 660 unique to specific NSFs. For example, most IPS/IDS implementations 661 have their proprietary functions/profiles. One of the goals of I2NSF 662 is to define a common envelop format for exchanging or sharing 663 profiles among different organizations to achieve more effective 664 protection against threats. 666 The "packet content matching" of the I2NSF policies should not only 667 include the matching criteria specified by 668 [I-D.ietf-netmod-acl-model], but also the L4-L7 fields depending 669 on the NSFs selected. 671 Some Flow-based NSFs need matching criteria that include the context 672 associated with the packets. This may also include metadata. 674 The I2NSF "actions" should extend the actions specified by 675 [I-D.ietf-netmod-acl-model] to include applying statistics 676 functions, threat profiles, or signature files that clients provide. 678 8. Capability Negotiation 680 It is very possible that the underlay network (or provider network) 681 does not have the capability or resource to enforce the flow security 682 policies requested by the overlay network (or enterprise network). 683 Therefore, it is very important to have a capability discovery or 684 inquiry mechanism over the I2NSF Customer-Facing Interface for the 685 clients to discover if the needed flow polices can be supported or 686 not. 688 When an NSF cannot perform the desired provisioning (e.g., due to 689 resource constraints), it must inform the controller. 691 The protocol needed for this security function/capability negotiation 692 may be somewhat correlated to the dynamic service parameter 693 negotiation procedure described in [RFC7297]. The Connectivity 694 Provisioning Profile (CPP) template, even though currently covering 695 only Connectivity requirements, includes security clauses such as 696 isolation requirements and non-via nodes. Hence, could be extended 697 as a basis for the negotiation procedure. Likewise, the companion 698 Connectivity Provisioning Negotiation Protocol (CPNP) could be a 699 candidate for the negotiation procedure. 701 "Security-as-a-Service" would be a typical example of the kind of 702 (CPP-based) negotiation procedures that could take place between a 703 corporate customer and a service provider. However, more security 704 specific parameters have to be considered. 706 [I.D.-draft-xibassnez-i2nsf-capability] describes the concepts of 707 capabilities in detail. 709 9. Registration Considerations 711 9.1. Flow-Based NSF Capability Characterization 713 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 714 the commonly deployed flow-based NSFs. However, the differences 715 among them are definitely blurring, due to more powerful technology, 716 integration of platforms, and new threats. Basic types of 717 flow-based NSFs include: 719 o Firewall - A device or a function that analyzes packet headers and 720 enforces policy based on protocol type, source address, 721 destination address, source port, destination port, and/or other 722 attributes of the packet header. Packets that do not match policy 723 are rejected. Note that additional functions, such as logging and 724 notification of a system administrator, could optionally be 725 enforced as well. 727 o IDS (Intrusion Detection System) - A device or function that 728 analyzes packets, both header and payload, looking for known 729 events. When a known event is detected, a log message is 730 generated detailing the event. Note that additional functions, 731 such as notification of a system administrator, could optionally 732 be enforced as well. 734 o IPS (Intrusion Prevention System) - A device or function that 735 analyzes packets, both header and payload, looking for known 736 events. When a known event is detected, the packet is rejected. 737 Note that additional functions, such as logging and notification 738 of a system administrator, could optionally be enforced as well. 740 Flow-based NSFs differ in the depth of packet header or payload they 741 can inspect, the various session/context states they can maintain, 742 and the specific profiles and the actions they can apply. An example 743 of a session is "allowing outbound connection requests and only 744 allowing return traffic from the external network". 746 9.2. Registration Categories 748 Developers can register their NSFs using Packet Content Match 749 categories. The IDR (Inter-Domain Routing) Flow Specification 750 [RFC5575] has specified 12 different packet header matching types. 751 More packet content matching types have been proposed in the IDR WG. 752 I2NSF should re-use the packet matching types being specified as much 753 as possible. More matching types might be added for Flow-based NSFS. 754 Tables 1-4 below list the applicable packet content categories that 755 can be potentially used as packet matching types by Flow-based NSFs: 757 +-----------------------------------------------------------+ 758 | Packet Content Matching Capability Index | 759 +---------------+-------------------------------------------+ 760 | Layer 2 | Layer 2 header fields: | 761 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 762 | | | 763 |---------------+-------------------------------------------+ 764 | Layer 3 | Layer header fields: | 765 | | protocol | 766 | IPv4 Header | dest port | 767 | | src port | 768 | | src address | 769 | | dest address | 770 | | dscp | 771 | | length | 772 | | flags | 773 | | ttl | 774 | | | 775 | IPv6 Header | | 776 | | addr | 777 | | protocol/nh | 778 | | src port | 779 | | dest port | 780 | | src address | 781 | | dest address | 782 | | length | 783 | | traffic class | 784 | | hop limit | 785 | | flow label | 786 | | dscp | 787 | TCP | Port | 788 | SCTP | syn | 789 | DCCP | ack | 790 | | fin | 791 | | rst | 792 | | ? psh | 793 | | ? urg | 794 | | ? window | 795 | | sockstress | 796 | | Note: bitmap could be used to | 797 | | represent all the fields | 798 | | | 799 | UDP | | 800 | | flood abuse | 801 | | fragment abuse | 802 | | Port | 803 | HTTP layer | | 804 | | | hash collision | 805 | | | http - get flood | 806 | | | http - post flood | 807 | | | http - random/invalid url | 808 | | | http - slowloris | 809 | | | http - slow read | 810 | | | http - r-u-dead-yet (rudy) | 811 | | | http - malformed request | 812 | | | http - xss | 813 | | | https - ssl session exhaustion | 814 +---------------+----------+--------------------------------+ 815 | IETF PCP | Configurable | 816 | | Ports | 817 | | | 818 +---------------+-------------------------------------------+ 819 | IETF TRAM | profile | 820 | | | 821 | | | 822 |---------------+-------------------------------------------+ 824 Table 1: Packet Content Matching Capability Index 826 Note: DCCP: Datagram Congestion Control Protocol 827 PCP: Port Control Protocol 828 TRAM: TURN Revised and Modernized, where TURN stands for 829 Traversal Using Relays around NAT 831 +-----------------------------------------------------------+ 832 | Context Matching Capability Index | 833 +---------------+-------------------------------------------+ 834 | Session | Session state, | 835 | | bidirectional state | 836 | | | 837 +---------------+-------------------------------------------+ 838 | Time | time span | 839 | | time occurrence | 840 +---------------+-------------------------------------------+ 841 | Events | Event URL, variables | 842 +---------------+-------------------------------------------+ 843 | Location | Text string, GPS coords, URL | 844 +---------------+-------------------------------------------+ 845 | Connection | Internet (unsecured), Internet | 846 | Type | (secured by VPN, etc.), Intranet, ... | 847 +---------------+-------------------------------------------+ 848 | Direction | Inbound, Outbound | 849 +---------------+-------------------------------------------+ 850 | State | Authentication State | 851 | | Authorization State | 852 | | Accounting State | 853 | | Session State | 854 +---------------+-------------------------------------------+ 856 Table 2: Context Matching Capability Index 857 +-----------------------------------------------------------+ 858 | Action Capability Index | 859 +---------------+-------------------------------------------+ 860 | Ingress port | SFC header termination, | 861 | | VxLAN header termination | 862 +---------------+-------------------------------------------+ 863 | | Pass | 864 | Actions | Deny | 865 | | Mirror | 866 | | Simple Statistics: Count (X min; Day;..)| 867 | | Client specified Functions: URL | 868 +---------------+-------------------------------------------+ 869 | Egress | Encap SFC, VxLAN, or other header | 870 +---------------+-------------------------------------------+ 872 Table 3: Action Capability Index 874 +-----------------------------------------------------------+ 875 | Functional Profile Index | 876 +---------------+-------------------------------------------+ 877 | Profile types | Name, type, or | 878 | Signature | Flexible Profile/signature URL | 879 | | Command for Controller to enable/disable | 880 | | | 881 +---------------+-------------------------------------------+ 883 Table 4: Function Profile Index 885 10. Manageability Considerations 887 Management of NSFs includes: 889 o Lifecycle management and resource management of NSFs 891 o Configuration of devices, such as address configuration, device 892 internal attributes configuration, etc. 894 o Signaling 896 o Policy rules provisioning 898 Currently, I2NSF only focuses on the policy rule provisioning part, 899 (i.e., the last bullet listed above). 901 11. Security Considerations 903 Having a secure access to control and monitor NSFs is crucial for 904 hosted security services. Therefore, proper secure communication 905 channels have to be carefully specified for carrying the controlling 906 and monitoring information between the NSFs and their management 907 entity or entities. 909 12. IANA Considerations 911 This document requires no IANA actions. RFC Editor: Please remove 912 this section before publication. 914 13. Acknowledgements 916 This document includes significant contributions from Seetharama Rao 917 Durbha (Cablelabs), Ramki Krishnan (Dell), Anil Lohiya (Juniper 918 Networks), Joe Parrott (BT), and XiaoJun Zhuang (China Mobile). 920 Some of the results leading to this work have received funding from 921 the European Union Seventh Framework Programme (FP7/2007-2013) under 922 grant agreement no. 611458. 924 14. References 926 14.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 930 RFC2119, March 1997, 931 . 933 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 934 and D. McPherson, "Dissemination of Flow Specification 935 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 936 . 938 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 939 Connectivity Provisioning Profile (CPP)", RFC 7297, 940 DOI 10.17487/RFC7297, July 2014, 941 . 943 14.2. Informative References 945 [I-D.ietf-i2nsf-problem-and-use-cases] 946 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 947 Jacquenet, "I2NSF Problem Statement and Use cases", 948 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 949 progress), May 2017. 951 [I-D.ietf-netmod-acl-model] 952 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 953 "Network Access Control List (ACL) YANG Data Model", 954 draft-ietf-netmod-acl-model-11 (work in progress), 955 June, 2017. 957 [I-D.ietf-i2nsf-terminology] 958 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 959 Birkholz, "Interface to Network Security Functions (I2NSF) 960 Terminology", draft-ietf-i2nsf-terminology-03 (work in 961 progress), March 2017. 963 [I-D.draft-xibassnez-i2nsf-capability] 964 Xia, L., Strassner, J., Basile, C., and Lopez, D., 965 "Information Model of NSFs Capabilities", 966 draft-xibassnez-i2nsf-capability-01.txt (work in 967 progress), March, 2017. 969 [I-D.pastor-i2nsf-remote-attestation] 970 Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation 971 Procedures for Network Security Functions (NSFs) through 972 the I2NSF Security Controller", 973 draft-pastor-i2nsf-nsf-remote-attestation-01 (work in 974 progress), March 2017. 976 [I-D.xie-i2nsf-demo-outline-design] 977 Xie, Y., Xia, L., and J. Wu, "Interface to Network 978 Security Functions Demo Outline Design", 979 draft-xie-i2nsf-demo-outline-design-00 (work in progress), 980 April 2015. 982 [gs_NFV] "ETSI NFV Group Specification; Network Functions 983 Virtualization (NFV) Use Cases. ETSI GS NFV 001v1.1.1", 984 2013. 986 Authors' Addresses 988 Diego R. Lopez 989 Telefonica I+D 990 Editor Jose Manuel Lara, 9 991 Seville, 41013 992 Spain 994 Phone: +34 682 051 091 995 Email: diego.r.lopez@telefonica.com 997 Edward Lopez 998 Curveball Networks 999 Chantilly, Virgina 1000 USA 1002 Phone: +1 703 220 0988 1003 Email: elopez@fortinet.com 1005 Linda Dunbar 1006 Huawei 1008 Email: Linda.Dunbar@huawei.com 1010 John Strassner 1011 Huawei 1013 Email: John.sc.Strassner@huawei.com 1015 Rakesh Kumar 1016 Juniper Networks 1018 Email: rkkumar@juniper.net