idnits 2.17.1 draft-ietf-i2nsf-framework-04.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 756 has weird spacing: '...| Layer heade...' == Line 819 has weird spacing: '...context match...' -- The document date (October 30, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3060' is defined on line 920, but no explicit reference was found in the text == Unused Reference: 'RFC3460' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 972, but no explicit reference was found in the text == Unused Reference: 'NW-2011' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'SC-MobileNetwork' is defined on line 980, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-02 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF D. Lopez 3 Internet-Draft Telefonica I+D 4 Intended status: Informational E. Lopez 5 Expires: May 3, 2017 Fortinet 6 L. Dunbar 7 J. Strassner 8 Huawei 9 R. Kumar 10 Juniper Networks 11 October 30, 2016 13 Framework for Interface to Network Security Functions 14 draft-ietf-i2nsf-framework-04 16 Abstract 18 This document describes the framework for the Interface to Network 19 Security Functions (I2NSF), and defines a reference model (including 20 major functional components) for I2NSF. Network security functions 21 (NSFs) are packet-processing engines that inspect and optionally 22 modify packets traversing networks, either directly or in the context 23 of sessions in which the packet is associated. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 3, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. I2NSF Reference Model . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Consumer-Facing Interface . . . . . . . . . . . . . . . . 6 65 3.2. NSF-Facing Interface . . . . . . . . . . . . . . . . . . . 6 66 3.3. Registration Interface . . . . . . . . . . . . . . . . . . 7 67 4. Threats Associated with Externally Provided NSFs . . . . . . . 8 68 5. Avoiding NSF Ossification . . . . . . . . . . . . . . . . . . 9 69 6. The Network Connecting I2NSF Components . . . . . . . . . . . 9 70 6.1. Network Connecting I2NSF Users and I2NSF Controller . . . 9 71 6.2. Network Connecting the Security Controller and NSFs . . . 10 72 6.3. Interface to vNSFs . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . 14 76 7.3. Differences from ACL Data Models . . . . . . . . . . . . . 15 77 8. Capability Negotiation . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 20 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 87 14.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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 NSFs that are externally 96 provided. It also describes how I2NSF facilitates Software-Defined 97 Networking (SDN) and Network Function Virtualization (NFV) control, 98 while avoiding potential constraints that could limit the internal 99 functionality and capabilities of NSFs. 101 The I2NSF use cases [I-D.ietf-i2nsf-problem-and-use-cases] call for 102 standard interfaces for users of an I2NSF system (e.g., applications, 103 overlay or cloud network management system, or enterprise network 104 administrator or management system), to inform the I2NSF system which 105 I2NSF functions should be applied to which traffic (or traffic 106 patterns). The I2NSF system realizes this as a set of security rules 107 for monitoring and controlling the behavior of different traffic. It 108 also provides standard interfaces for users to monitor flow-based 109 security functions hosted and managed by different administrative 110 domains. 112 [I-D.ietf-i2nsf-problem-and-use-cases] also describes the motivation 113 and the problem space for an Interface to Network Security Functions 114 system. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 In this document, these words will appear with that interpretation 123 only when in ALL CAPS. Lower case uses of these words are not to be 124 interpreted as carrying RFC-2119 significance. 126 2.1. Acronyms 128 The following acronyms are used in this document: 130 BSS Business Support System 132 CDN Content Delivery Networks 133 ICN Information-Centric Networks 135 IDS Intrusion Detection System 137 IoT Internet of Things 139 IPS Intrusion Protection System 141 NSF Network Security Function 143 OSS Operation Support System 145 2.2. Definitions 147 The following terms, which are used in this document, are defined in 148 the I2NSF terminology document [I-D.ietf-i2nsf-terminology]: 150 Capability 152 Consumer 154 Controller 156 Firewall 158 Interface 160 Interface Group 162 Intrusion Detection System 164 Intrusion Protection System 166 Network Security Function 168 Role 170 3. I2NSF Reference Model 172 Figure 1 shows a reference model (including major functional 173 components and interfaces) for an I2NSF system. This figure is drawn 174 from the point-of-view of the security controller; hence, this view 175 does not assume any particular management architecture for either the 176 NSFs or for how NSFs are managed (on the developer's side). In 177 particular, the security controller does not participate in NSF data 178 plane activities. 180 +-------------------------------------------------------+ 181 | I2NSF User (e.g., Overlay Network Mgnt, Enterprise | 182 | network Mgnt, another network domain's mgnt, etc.) | 183 +--------------------+----------------------------------+ 184 | 185 | Consumer-Facing Interface 186 | 187 +------------+---------+ Registration +-------------+ 188 | Network Operator Mgmt| Interface | Developer's | 189 | Security Controller | < --------- > | Mgnt System | 190 +----------------+-----+ +-------------+ 191 | 192 | NSF-Facing Interface 193 | 194 +---------------+----+------------+---------------+ 195 | | | | 196 +---+---+ +---+---+ +---+---+ +---+---+ 197 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-m | ... 198 +-------+ +-------+ +-------+ +-------+ 200 Developer Mgnt System A Developer Mgnt System B 202 Figure 1: I2NSF Reference Model 204 When defining controller interfaces, this framework adheres to the 205 following principles: 207 o Agnostic of network topology and NSF location in the network 209 o Agnostic of provider of the NSF (i.e., independent of the way that 210 the provider makes an NSF available, as well as how the provider 211 allows the NSF to be managed) 213 o Agnostic of any vendor-specific operational, administrative, and 214 management implementation, hosting environment, and form-factor 215 (physical or virtual) 217 o Agnostic to NSF control plane implementation (e.g., signaling 218 capabilities) 220 o Agnostic to NSF data plane implementation (e.g., encapsulation 221 capabilities) 223 3.1. Consumer-Facing Interface 225 The Consumer-Facing Interface is used to enable different users of a 226 given I2NSF system to define, manage, and monitor security policies 227 for specific flows within an administrative domain. In today's 228 world, where everything is connected, preventing unwanted traffic has 229 become a key challenge. More and more networks are implemented as a 230 form of overlay network, with their paths or links among nodes being 231 provided by other networks (a.k.a. underlay networks). 233 The overlay network's own security solutions cannot prevent various 234 attacks from saturating the access links to the overlay network 235 nodes, which may cause various components of one or more overlay 236 nodes (e.g., CPU or link bandwidth) to become overloaded, and unable 237 to handle their own legitimate traffic. An I2NSF system can be used 238 by overlay networks to request certain flow-based security rules to 239 be enforced by underlay networks. This operates in a similar manner 240 to how traditional networks use firewalls or IPS devices to enforce 241 traffic rules. The I2NSF system can reduce, or even eliminate, 242 unwanted traffic, which prevents unwanted traffic from consuming 243 critical node resources. The same approach can be used by enterprise 244 networks to request their specific flow security policies to be 245 enforced by the provider network that interconnects their users. The 246 location and implementation of I2NSF policies are irrelevant to the 247 consumer of I2NSF policies. 249 Some examples of I2NSF Consumers include: 251 o A videoconference network manager that needs to dynamically inform 252 the underlay network to allow, rate-limit, or deny flows (some of 253 which are encrypted) based on specific fields in the packets for a 254 certain time span 256 o Enterprise network administrators and management systems that need 257 to request their provider network to enforce specific I2NSF 258 policies for particular flows 260 o An IoT management system sending requests to the underlay network 261 to block flows that match a set of specific conditions. 263 3.2. NSF-Facing Interface 265 The NSF-Facing Interface is used to specify and monitor flow-based 266 security policies enforced by one or more NSFs. Note that the 267 controller does not need to use all features of a given NSF, nor does 268 it need to use all available NSFs. Hence, this abstraction enables 269 the different features from the set of NSFs that make up able given 270 I2NSF system to be treated as building blocks, so that developers are 271 free to use the security functions needed independent of vendor and 272 technology. 274 Flow-based NSFs [I-D.ietf-i2nsf-problem-and-use-cases] inspect 275 packets in the order that they are received. The Interface to flow- 276 based NSFs can be grouped into the following types of Interface 277 Groups: 279 1. NSF Operational and Administrative Interface: an Interface Group 280 used by a controller to program the operational state of the NSF; 281 this also includes administrative control functions. Since 282 applications and controllers need to dynamically control the 283 behavior of traffic that they send and receive, much of the I2NSF 284 effort is focused on this Interface Group. 286 2. Monitoring Interface: an Interface Group used by a controller to 287 obtain monitoring information from one or more selected NSFs. 288 Each interface in this Interface Group could be a query- or a 289 report-based interface (as dedcribed above). This Interface 290 Group includes logging and query functions between the NSF and 291 external systems. The functionality of this Interface Group may 292 also be defined by other protocols, such as SYSLOG and DOTS. 294 3. Notification Interface: an Interface Group used by a controller 295 to receive notification events (e.g., alarms) from NSFs. This 296 requires the NSF to be registered. The controller may take an 297 action based on the event; this SHOULD be specified by an I2NSF 298 policy. This Interface Group does NOT change the operational 299 state of the NSF. 301 This draft proposes that the flow-based paradigm is used to develop 302 the NSF-Facing Interface. A common trait of flow-based NSFs is in 303 the processing of packets based on the content (e.g., header/payload) 304 and/or context (e.g., session state, authentication state) of the 305 received packets. 307 3.3. Registration Interface 309 NSFs provided by different vendors may have different capabilities. 310 In order to automate the process of utilizing multiple types of 311 security functions provided by different vendors, it is necessary to 312 have an interface for vendors to define the capabilities of their 313 NSFs. This Interface Group is called the Registration Interface 314 Group. 316 An NSF's capabilities can either be pre-configured or retrieved 317 dynamically through the Registration Interface Group. If a new 318 function that is exposed to the consumer is added to an NSF, then 319 those capabilities SHOULD be notified to security controllers via the 320 Registration Interface Group. 322 4. Threats Associated with Externally Provided NSFs 324 While associated with a much higher flexibility, and in many cases a 325 necessary approach given the deployment conditions, the usage of 326 externally provided NSFs implies several additional concerns in 327 security. The most relevant threats associated with a security 328 platform of this nature are: 330 o An unknown/unauthorized user can try to impersonate another user 331 that can legitimately access external NSF services. This attack 332 may lead to accessing the policies and applications of the 333 attacked user or to generate network traffic outside the security 334 functions with a falsified identity. 336 o An authorized user may misuse assigned privileges to alter the 337 network traffic processing of other users in the NSF underlay or 338 platform. This can become especially serious when such a user has 339 higher (or even administration) privileges granted by the provider 340 (the direct NSF provider, the ISP or the underlay network 341 operator). 343 o A usermay try to install malformed elements (policy or 344 configuration), trying to directly take the control of a NSF or 345 the whole provider platform, for example by exploiting a 346 vulnerability on one of the functions, or may try to intercept or 347 modify the traffic of other users in the same provider platform. 349 o A malicious provider can modify the software providing the 350 functions (the operating system or the specific NSF 351 implementations) to alter the behavior of the latter. This event 352 has a high impact on all users accessing NSFs as the provider has 353 the highest level of privilege on the software in execution. 355 o A user that has physical access to the provider platform can 356 modify the behavior of the hardware/software components, or the 357 components themselves. Furthermore, it can access a serial 358 console (most devices offer this interface for maintenance 359 reasons) to access the NSF software with the same level of 360 privilege of the provider. 362 The authentication between the user and the NSF environment and, what 363 is more important, the attestation of the elements in the NSF 364 environment by users could address these threats to an acceptable 365 level of risk. Periodical attestation enables users to detect 366 alterations in the NSFs and their supporting infrastructure, and 367 raises the degree of physical control necessary to perform an 368 untraceable malicious modification of the environment. 370 5. Avoiding NSF Ossification 372 An important concept underlying this framework is the fact that 373 attackers do not have standards as to how to attack networks, so it 374 is equally important not to constrain NSF developers to offering a 375 limited set of security functions. In other words, the introduction 376 of I2NSF standards should not make it easier for attackers to 377 compromise the network. Therefore, in constructing standards for 378 rules provisioning interfaces to NSFs, it is equally important to 379 allow support for specific functions, as this enables the 380 introduction of NSFs that evolve to meet new threats. Proposed 381 standards for rules provisioning interfaces to NSFs SHOULD NOT: 383 o Narrowly define NSF categories, or their roles when implemented 384 within a network 386 o Attempt to impose functional requirements or constraints, either 387 directly or indirectly, upon NSF developers 389 o Be a limited lowest common denominator approach, where interfaces 390 can only support a limited set of standardized functions, without 391 allowing for developer-specific functions 393 o Be seen as endorsing a best common practice for the implementation 394 of NSFs 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 408 6.1. Network Connecting I2NSF Users and I2NSF Controller 410 [TBD: should we add the Remote Attestation to this section?] 411 As a general principle, in the I2NSF environment users directly 412 interact with the controller. Given the role of the Security 413 Controller, a mutual authentication of users and the Security 414 Controller maybe required. I2NSF does not mandate a specific 415 authentication scheme; it is up to the users to choose available 416 authentication scheme based on their needs. 418 Upon successful authentication, a trusted connection between the user 419 and the Security Controller (or an endpoint designated by it) SHALL 420 be established. All traffic to and from the NSF environment will 421 flow through this connection. The connection is intended not only to 422 be secure, but trusted in the sense that it SHOULD be bound to the 423 mutual authentication between user and Security Controller, as 424 described in [I-D.pastor-i2nsf-vnsf-attestation], with the only 425 possible exception of the application of the lowest levels of 426 assurance, in which case the user MUST be made aware of this 427 circumstance. 429 6.2. Network Connecting the Security 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 the control messages 439 and monitoring information should provide reliable message delivery. 440 Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the 441 Stream Control Transmission Protocol (SCTP) will need to be evaluated 442 for applicability. Latency requirements for control message delivery 443 must also be evaluated. 445 The network connection between the Security Controller and NSFs can 446 rely either on: 448 o Closed environments, where there is only one administrative 449 domain. Less restrictive access control and simpler validation 450 can be used inside the domain because of the protected 451 environment. 453 o Open environments, where some NSFs can be hosted in external 454 administrative domains or reached via secure external network 455 domains. This requires more restrictive security control to be 456 placed over the I2NSF interface. The information over the I2NSF 457 interfaces SHALL be exchanged used trusted channels as described 458 in the previous section. 460 When running in an open environment, I2NSF needs to rely on 461 interfaces to properly verify peer identities e.g. through an AAA 462 framework. The implementation of identity management functions is 463 out of scope for I2NSF. 465 6.3. Interface to vNSFs 467 Even though there is no difference between virtual network security 468 functions (vNSF) and physical NSFs from the policy provisioning 469 perspective, there are some unique characteristics in interfacing to 470 the vNSFs: 472 o There could be multiple instantiations of one single NSF that has 473 been distributed across a network. When different instantiations 474 are visible to the Security Controller, different policies may be 475 applied to different instantiations of an individual NSF (e.g., to 476 reflect the different roles that each vNSF is designated for). 478 o When multiple instantiations of one single NSF appear as one 479 single entity to the Security Controller, the policy provisioning 480 has to be sent to the NSF Manager, which in turn disseminates the 481 polices to the corresponding instantiations of the NSF, as shown 482 in Figure 2 below. 484 o Policies to one vNSF may need to be retrieved and moved to another 485 vNSF of the same type when user flows are moved from one vNSF to 486 another. 488 o Multiple vNSFs may share the same physical platform. 490 o There may be scenarios where multiple vNSFs collectively perform 491 the security policies needed. 493 +------------------------+ 494 | Security Controller | 495 +------------------------+ 496 ^ ^ 497 | | 498 +-----------+ +------------+ 499 | | 500 v v 501 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 502 | NSF-A +--------------+ | | NSF-B +--------------+ | 503 | |NSF Manager | | | |NSF Manager | | 504 | +--------------+ | | +--------------+ | 505 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 506 | |+---------+ +---------+| | | |+---------+ +---------+| | 507 | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | 508 | |+---------+ +---------+| | | |+---------+ +---------+| | 509 | | NSF-A cluster | | | | NSF-B cluster | | 510 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 511 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 513 Figure 2: Cluster of NSF Instantiations Management 515 7. I2NSF Flow Security Policy Structure 517 Even though security functions come in a variety of form factors and 518 have different features, provisioning to flow-based NSFs can be 519 standardized by using Event - Condition - Action (ECA) policy 520 rulesets. 522 Event is used to determine whether the condition clause of the Policy 523 Rule can be evaluated or not. 525 A Condition, when used in the context of policy rules for flow-based 526 NSFs, is used to determine whether or not the set of Actions in that 527 Policy Rule can be executed or not. A condition can be based on 528 various combinations of the content (header/payload) and/or the 529 context (session state, authentication state, etc) of the received 530 packets. 532 Action can be simple permit/deny/rate-limiting, applying specify 533 profile, or establishing specific secure tunnels, etc. 535 7.1. Customer-Facing Flow Security Policy Structure 537 This layer is for user's network management system to express and 538 monitor the needed flow security policies for their specific flows. 540 Some customers may not have security skills. As such, they are not 541 able to express requirements or security policies that are precise 542 enough. These customers may instead express expectations or intent 543 of the functionality desired by their security policies. Customers 544 may also express guidelines such as which certain types of 545 destinations are not allowed for certain groups. As a result, there 546 could be different depths or layers of Service Layer policies. Here 547 are some examples of more abstract security Policies that can be 548 developed based on the I2NSF defined customer-facing interfaces: 550 Pass for Subscriber "xxx" 552 Enable basic parental control 554 Enable "school protection control" 556 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 ECA policy rule 578 without having to know actual tags or addresses in the packets. 580 For example, when used in the context of policy rules over the Client 581 Facing Interface: 583 An Event can be "the client has passed AAA process" 585 A Condition can be matching user identifier, or from specific 586 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 something 605 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 [I-D.bogdanovic-netmod-acl-model] has defined rules for the Access 650 Control List supported by most routers/switches that forward packets 651 based on packets' L2, L3, or sometimes L4 headers. The actions for 652 Access Control Lists include Pass, Drop, or Redirect. 654 The functional profiles (or signatures) for NSFs are not present in 655 [I-D.bogdanovic-netmod-acl-model] because the functional profiles are 656 unique to specific NSFs. For example, most IPS/IDS implementations 657 have their proprietary functions/profiles. One of the goals of I2NSF 658 is to define a common envelop format for exchanging or sharing 659 profiles among different organizations to achieve more effective 660 protection against threats. 662 The "packet content matching" of the I2NSF policies should not only 663 include the matching criteria specified by 664 [I-D.bogdanovic-netmod-acl-model] but also the L4-L7 fields depending 665 on the NSFs selected. 667 Some Flow-based NSFs need matching criteria that include the context 668 associated with the packets. 670 The I2NSF "actions" should extend the actions specified by 671 [I-D.bogdanovic-netmod-acl-model] to include applying statistics 672 functions, threat profiles, or signature files that clients provide. 674 8. Capability Negotiation 676 It is very possible that the underlay network (or provider network) 677 does not have the capability or resource to enforce the flow security 678 policies requested by the overlay network (or enterprise network). 679 Therefore, it is very important to have capability discovery or 680 inquiry mechanism over the I2NSF Customer-Facing Interface for the 681 clients to discover if the needed flow polices can be supported or 682 not. 684 When an NSF cannot perform the desired provisioning (e.g., due to 685 resource constraints), it MUST inform the controller. 687 The protocol needed for this security function/capability negotiation 688 may be somewhat correlated to the dynamic service parameter 689 negotiation procedure described in [RFC7297]. The Connectivity 690 Provisioning Profile (CPP) template, even though currently covering 691 only Connectivity requirements (but includes security clauses such as 692 isolation requirements, non-via nodes, etc.), could be extended as a 693 basis for the negotiation procedure. Likewise, the companion 694 Connectivity Provisioning Negotiation Protocol (CPNP) could be a 695 candidate to proceed with the negotiation procedure. 697 The "security as a service" would be a typical example of the kind of 698 (CPP-based) negotiation procedures that could take place between a 699 corporate customer and a service provider. However, more security 700 specific parameters have to be considered. 702 9. Registration Considerations 704 9.1. Flow-Based NSF Capability Characterization 706 There are many types of flow-based NSFs. Firewall, IPS, and IDS are 707 the commonly deployed flow-based NSFs. However, the differences 708 among them are definitely blurring, due to technological capacity 709 increases, integration of platforms, and new threats. At their core: 711 o Firewall - A device or a function that analyzes packet headers and 712 enforces policy based on protocol type, source address, 713 destination address, source port, destination port, and/or other 714 attributes of the packet header. Packets that do not match policy 715 are rejected. Note that additional functions, such as logging and 716 notification of a system administrator, could optionally be 717 enforced as well. 719 o IDS (Intrusion Detection System) - A device or function that 720 analyzes packets, both header and payload, looking for known 721 events. When a known event is detected, a log message is 722 generated detailing the event. Note that additional functions, 723 such as notification of a system administrator, could optionally 724 be enforced as well. 726 o IPS (Intrusion Prevention System) - A device or function that 727 analyzes packets, both header and payload, looking for known 728 events. When a known event is detected, the packet is rejected. 729 Note that additional functions, such as logging and notification 730 of a system administrator, could optionally be enforced as well. 732 Flow-based NSFs differ in the depth of packet header or payload they 733 can inspect, the various session/context states they can maintain, 734 and the specific profiles and the actions they can apply. An example 735 of a session is "allowing outbound connection requests and only 736 allowing return traffic from the external network". 738 9.2. Registration Categories 740 Developers can register their NSFs using Packet Content Match 741 categories. The IDR Flow Specification [RFC5575] has specified 12 742 different packet header matching types. More packet content matching 743 types have been proposed in the IDR WG. I2NSF should re-use the 744 packet matching types being specified as much as possible. More 745 matching types might be added for Flow-based NSFS. Tables 1-4 below 746 list the applicable packet content categories that can be potentially 747 used as packet matching types by Flow-based NSFs: 749 +-----------------------------------------------------------+ 750 | Packet Content Matching Capability Index | 751 +---------------+-------------------------------------------+ 752 | Layer 2 | Layer 2 header fields: | 753 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 754 | | | 755 |---------------+-------------------------------------------+ 756 | Layer 3 | Layer header fields: | 757 | | protocol | 758 | IPv4 Header | dest port | 759 | | src port | 760 | | src address | 761 | | dest address | 762 | | dscp | 763 | | length | 764 | | flags | 765 | | ttl | 766 | | | 767 | IPv6 Header | | 768 | | addr | 769 | | protocol/nh | 770 | | src port | 771 | | dest port | 772 | | src address | 773 | | dest address | 774 | | length | 775 | | traffic class | 776 | | hop limit | 777 | | flow label | 778 | | dscp | 779 | | | 780 | TCP | Port | 781 | SCTP | syn | 782 | DCCP | ack | 783 | | fin | 784 | | rst | 785 | | ? psh | 786 | | ? urg | 787 | | ? window | 788 | | sockstress | 789 | | Note: bitmap could be used to | 790 | | represent all the fields | 791 | | | 792 | UDP | | 793 | | flood abuse | 794 | | fragment abuse | 795 | | Port | 796 | HTTP layer | | 797 | | | hash collision | 798 | | | http - get flood | 799 | | | http - post flood | 800 | | | http - random/invalid url | 801 | | | http - slowloris | 802 | | | http - slow read | 803 | | | http - r-u-dead-yet (rudy) | 804 | | | http - malformed request | 805 | | | http - xss | 806 | | | https - ssl session exhaustion | 807 +---------------+----------+--------------------------------+ 808 | IETF PCP | Configurable | 809 | | Ports | 810 | | | 811 +---------------+-------------------------------------------+ 812 | IETF TRAM | profile | 813 | | | 814 | | | 815 |---------------+-------------------------------------------+ 817 Table 1: Subject Capability Index 818 +-----------------------------------------------------------+ 819 | context matching Capability Index | 820 +---------------+-------------------------------------------+ 821 | Session | Session state, | 822 | | bidirectional state | 823 | | | 824 +---------------+-------------------------------------------+ 825 | Time | time span | 826 | | time occurrence | 827 +---------------+-------------------------------------------+ 828 | Events | Event URL, variables | 829 +---------------+-------------------------------------------+ 830 | Location | Text string, GPS coords, URL | 831 +---------------+-------------------------------------------+ 832 | Connection | Internet (unsecured), Internet | 833 | Type | (secured by VPN, etc.), Intranet, ... | 834 +---------------+-------------------------------------------+ 835 | Direction | Inbound, Outbound | 836 +---------------+-------------------------------------------+ 837 | State | Authentication State | 838 | | Authorization State | 839 | | Accounting State | 840 | | Session State | 841 +---------------+-------------------------------------------+ 843 Table 2: Object Capability Index 845 +-----------------------------------------------------------+ 846 | Action Capability Index | 847 +---------------+-------------------------------------------+ 848 | Ingress port | SFC header termination, | 849 | | VxLAN header termination | 850 +---------------+-------------------------------------------+ 851 | | Pass | 852 | Actions | Deny | 853 | | Mirror | 854 | | Simple Statistics: Count (X min; Day;..)| 855 | | Client specified Functions: URL | 856 +---------------+-------------------------------------------+ 857 | Egress | Encap SFC, VxLAN, or other header | 858 +---------------+-------------------------------------------+ 860 Table 3: Action Capability Index 861 +-----------------------------------------------------------+ 862 | Functional profile Index | 863 +---------------+-------------------------------------------+ 864 | Profile types | Name, type, or | 865 | Signature | Flexible Profile/signature URL | 866 | | Command for Controller to enable/disable | 867 | | | 868 +---------------+-------------------------------------------+ 870 Table 4: Function Capability Index 872 10. Manageability Considerations 874 Management of NSFs usually includes: 876 o Lifecycle management and resource management of NSFs 878 o Configuration of devices, such as address configuration, device 879 internal attributes configuration, etc. 881 o Signaling 883 o Policy rules provisioning 885 I2NSF only focuses on the policy rule provisioning part, i.e. the 886 last bullet listed above. 888 11. Security Considerations 890 Having a secure access to control and monitor NSFs is crucial for 891 hosted security services. Therefore, proper secure communication 892 channels have to be carefully specified for carrying the controlling 893 and monitoring information between the NSFs and their management 894 entity or entities. 896 12. IANA Considerations 898 This document requires no IANA actions. RFC Editor: Please remove 899 this section before publication. 901 13. Acknowledgements 903 This document includes significant contributions from Seetharama Rao 904 Durbha (Cablelabs), Ramki Krishnan (Dell), Anil Lohiya (Juniper 905 Networks), Joe Parrott (BT), and XiaoJun Zhuang (China Mobile). 907 Some of the results leading to this work have received funding from 908 the European Union Seventh Framework Programme (FP7/2007-2013) under 909 grant agreement no. 611458. 911 14. References 913 14.1. Normative References 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 917 RFC2119, March 1997, 918 . 920 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 921 "Policy Core Information Model -- Version 1 922 Specification", RFC 3060, DOI 10.17487/RFC3060, 923 February 2001, . 925 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 926 Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, 927 . 929 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 930 and D. McPherson, "Dissemination of Flow Specification 931 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 932 . 934 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 935 Connectivity Provisioning Profile (CPP)", RFC 7297, 936 DOI 10.17487/RFC7297, July 2014, 937 . 939 14.2. Informative References 941 [I-D.bogdanovic-netmod-acl-model] 942 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 943 "Network Access Control List (ACL) YANG Data Model", 944 draft-bogdanovic-netmod-acl-model-02 (work in progress), 945 October 2014. 947 [I-D.ietf-i2nsf-problem-and-use-cases] 948 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 949 Jacquenet, "I2NSF Problem Statement and Use cases", 950 draft-ietf-i2nsf-problem-and-use-cases-02 (work in 951 progress), October 2016. 953 [I-D.ietf-i2nsf-terminology] 954 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 955 Birkholz, "Interface to Network Security Functions (I2NSF) 956 Terminology", draft-ietf-i2nsf-terminology-02 (work in 957 progress), October 2016. 959 [I-D.pastor-i2nsf-vnsf-attestation] 960 Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation 961 Procedures for Network Security Functions (NSFs) through 962 the I2NSF Security Controller", 963 draft-pastor-i2nsf-vnsf-attestation-03 (work in progress), 964 July 2016. 966 [I-D.xie-i2nsf-demo-outline-design] 967 Xie, Y., Xia, L., and J. Wu, "Interface to Network 968 Security Functions Demo Outline Design", 969 draft-xie-i2nsf-demo-outline-design-00 (work in progress), 970 April 2015. 972 [ITU-T-X1036] 973 "ITU-T Recommendation X.1036 - Framework for creation, 974 storage, distribution and enforcement of policies for 975 network security", November 2007. 977 [NW-2011] Burke, J., "The Pros and Cons of a Cloud-Based Firewall", 978 November 2011. 980 [SC-MobileNetwork] 981 Haeffner, W. and N. Leymann, "Network Based Services in 982 Mobile Network", July 2013. 984 [gs_NFV] "ETSI NFV Group Specification; Network Functions 985 Virtualization (NFV) Use Cases. ETSI GS NFV 001v1.1.1", 986 2013. 988 Authors' Addresses 990 Diego R. Lopez 991 Telefonica I+D 992 Editor Jose Manuel Lara, 9 993 Seville, 41013 994 Spain 996 Phone: +34 682 051 091 997 Email: diego.r.lopez@telefonica.com 999 Edward Lopez 1000 Fortinet 1001 899 Kifer Road 1002 Sunnyvale, CA 94086 1003 USA 1005 Phone: +1 703 220 0988 1006 Email: elopez@fortinet.com 1008 Linda Dunbar 1009 Huawei 1011 Email: Linda.Dunbar@huawei.com 1013 John Strassner 1014 Huawei 1016 Email: John.sc.Strassner@huawei.com 1018 Rakesh Kumar 1019 Juniper Networks 1021 Email: rkkumar@juniper.net