idnits 2.17.1 draft-mglt-sfc-security-environment-req-01.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 date (April 4, 2016) is 2944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-01 == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Working Group D. Migault, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational C. Pignataro 5 Expires: October 6, 2016 T. Reddy 6 Cisco 7 C. Inacio 8 CERT/SEI/CMU 9 April 4, 2016 11 SFC environment Security requirements 12 draft-mglt-sfc-security-environment-req-01.txt 14 Abstract 16 This document provides environment security requirements for the SFC 17 architecture. Environment security requirements are independent of 18 the protocols used for SFC - such as NSH for example. As a result, 19 the requirements provided in this document are intended to provide 20 good security practices so SFC can be securely deployed and operated. 21 These security requirements are designated as environment security 22 requirements as opposed to the protocol security requirements. 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 October 6, 2016. 41 Copyright Notice 43 Copyright (c) 2016 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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 61 4. SFC Environment Overview . . . . . . . . . . . . . . . . . . 3 62 5. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Attacks performed from the SFC Control Plane . . . . . . 5 64 5.2. Attacks performed from the SFC Management Plane . . . . . 6 65 5.3. Attacks performed from the Tenant's Users Plane . . . . . 6 66 5.4. Attacks performed from the SFC Data Plane . . . . . . . . 8 67 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 68 6.1. Plane Isolation Requirements . . . . . . . . . . . . . . 12 69 6.1.1. SFC Control Plane Isolation . . . . . . . . . . . . . 13 70 6.1.2. SFC Management Plane Isolation . . . . . . . . . . . 14 71 6.1.3. Tenant's Users Data Plane Isolation . . . . . . . . . 15 72 6.2. SFC Data Plane Requirements . . . . . . . . . . . . . . . 16 73 6.3. Additional Requirements . . . . . . . . . . . . . . . . . 19 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 11.2. Informative References . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 This document provides environment security requirements for the SFC 92 architecture [I-D.ietf-sfc-architecture]. Environment security 93 requirements are independent of the protocols used for SFC - such as 94 NSH [I-D.ietf-sfc-nsh]. As a result, the requirements provided in 95 this document are intended to provide good security practice so SFC 96 can be securely deployed and operated. These security requirements 97 are designated as environment security requirements as opposed to the 98 protocol security requirements. This document is built as follows. 99 Section 4 provides an overall description of the SFC environment with 100 the introduction of the different planes (SFC Control Plane, the SFC 101 Management Plane, the Tenant's user Plane and the SFC Data Plane). 102 Section 6 lists environment security requirements for the SFC. These 103 requirements are intended to prevent attacks, as well as network and 104 SFC misconfigurations. When such events happens, the security 105 recommendations also aim at detecting and identifying the threats or 106 misconfiguration as well as limiting their impact. Recommendations 107 also may apply differently depending on the infrastructure. For 108 example trusted environment may enforce lighter security 109 recommendations than public and open SFC infrastructures. However, 110 one should also consider future evolution of their infrastructure, 111 and consider the requirements as a way to maintain the SFC 112 architecture stable during its complete life cycle. For each 113 requirement this document attempts to provide further guidance on the 114 reasons to enforce it as well as what should be considered while 115 enforcing it or the associated risks of not enforcing it. 117 This document assumes the reader is familiar with the SFC 118 architecture defined in [I-D.ietf-sfc-architecture]. 120 3. Terminology and Acronyms 122 - Tenant: A tenant is one organization that is using SFC. A tenant 123 may use SFC on one's own private infrastructure or on a shared 124 infrastructure. 126 - Tenant's User Data Plane: The tenant may be using SFC to provide 127 service to its customers or users. The communication of these 128 users is designated as Tenant's user Data Plane and includes 129 all communications involving the tenant's users. As a result, 130 if a user is communicating with a server or a user from another 131 domain, the communication with that tenant's user is part of 132 the Tenant's Users Data Plane. 134 4. SFC Environment Overview 136 This section provides an overview of SFC. It is not in the scope to 137 this document to provide an explicit description of SFC. Instead, 138 the reader is expected to read [I-D.ietf-sfc-architecture], 139 [I-D.ietf-sfc-control-plane] and other SFC related documents. 141 Service Function Chaining (SFC) architecture is defined in 142 [I-D.ietf-sfc-architecture]. This section briefly illustrates the 143 main concepts of the SFC architecture and positions the architecture 144 within an environment. 146 SFC Control Plane 147 ^ ^ ^ 148 -------------------------|---------------|-------------|----|-------- 149 | C1 | C3 | C2 | | C4 150 | | +-----+ | | 151 | | | SF | | | 152 | | +-----+ | | 153 | v | | | 154 | +------------+ +-----+ +-----+ | 155 | +->| SFC |---->| SFF |----->| SFF |------+ 156 SFC | | | Classifier |<----| |<-----| | | | 157 Management | | +------------+ +-----+ +-----+ | | 158 Plane | | ^ | | | 159 | | | +-----------+ | 160 | | | | SFC Proxy | | 161 | | | +-----------+ | 162 | | | | | 163 | | | +------+ | 164 | | v | SF | | 165 | | +---------+ +------+ | 166 | | | SFC 2 | <------------ SFC 1 -------> | 167 | | +---------+ | 168 | | SFC Data Plane | 169 -----------------|-----------------------------------------------|-- 170 SFC incoming | SFC outgoing | 171 Data traffic | Data traffic v 173 SFC Tenant's Users Data Plane 175 SFC Environment Overview 177 SFC defined a Service Function Path (SFP) which is an ordered set of 178 Service Functions (SF) applied to packets. SFP is defined at the SF 179 level. A SF may be performed by different instances of SF located at 180 different positions. As a result, a specific packet may pass through 181 different instances of SFC. The ordered set of SF instances a packet 182 goes through is called the Rendered SF Path (RSFP). 184 Upon the receipt of an incoming packet from the tenant's user, the 185 SFC Classifier determines, according to Classifiers, which SFP is 186 associated to that packet. The packet is forwarded from Service 187 Function Forwarders (SFF) to SFF. SFF are then in charge of 188 forwarding the packet to the next SFF or to a SF. Forwarding 189 decisions may be performed using SFP information provided by the SFC 190 Encapsulation. As described in [I-D.ietf-sfc-nsh] the SFC 191 Encapsulation contains SFP information such as the SFP ID and Service 192 Index and eventually (especially for the MD-2 in NSH) some additional 193 metadata. SF may be SFC aware or not. In the case the SFC functions 194 are not SFC aware, a SFC Proxy performs the SFC Decapsulation (resp. 195 SFC Encapsulation) before forwarding the packet to the SF (resp. 196 after receiving the packet from the SF). 198 The environment associated to SFC may be separated into three main 199 planes: 201 - SFC Management Plane and Control Plane are defined in 202 [I-D.ietf-sfc-control-plane]. 204 - SFC Data Plane consists in all SF components as well as the 205 data exchanged between the SF components. Communications 206 between SF components includes the packet themselves, their 207 associated metadata, the routing logic - similar to RIB - or SF 208 logic, i.e. what they retuned values are for example. 210 - SFC Tenant's Users Data Plane consists in the traffic data 211 provided by the different users of the tenants. When a user is 212 communicating with a server or another user -eventually from 213 another administrative domain - , the communication belongs to 214 the SFC Tenant's Users Data Plane whenever packets are provided 215 by the server of by the user. 217 5. Threat Analysis 219 This section describes potential threats the SFC Data Plane may be 220 exposed. The list of threats is not expected to be complete. More 221 especially, the threats mentioned are provided to illustrate some 222 security requirements for the SFC architecture. For simplicity, this 223 document mostly considers that security breaches are performed by an 224 attacker. However, such breaches may also be non-intentional and may 225 result from misconfiguration for example. 227 Attacks may be performed from inside the SFC Data Plane or from 228 outside the SFC Data plane, in which case, the attacker is in at 229 least one of the following planes: SFC Control Plane, SFC Management 230 Plane or SFC Tenants' Users Plane. Some most sophisticated attacks 231 may involve a coordination of attackers in multiple planes. 233 5.1. Attacks performed from the SFC Control Plane 235 Attacks related to the control plane have been detailed in section 5 236 of [I-D.ietf-sfc-control-plane]. 238 5.2. Attacks performed from the SFC Management Plane 240 Attacks performed on the SFC Management Plane are similar to those 241 performed from the SFC Control Plane. The main difference is that 242 the SFC Management Plan provides usually a greater control of the SFC 243 component that the SFC Control Plane. 245 In addition, the actions performed by the SFC Management Plane have 246 fewer restrictions, which means it may be harder to enforce strong 247 control access policies. 249 5.3. Attacks performed from the Tenant's Users Plane 251 The SFC Tenant's User Plane is not expected to have fine access 252 control policies on the packets sent or received by users. Unless 253 they are filtered, all packets are good candidate to the SFC 254 Classifier. This provides the user some opportunities to test the 255 behavior of the SFC. 257 In addition, the Tenant's Users Plane is not controlled by the SFC 258 Tenant, and users may initiate communications where both ends - the 259 client and the server- are under the control of the same user. Such 260 communications may be seen as user controlled communications (UCC). 262 UCC may enable any user to monitor and measure the health of the SFC. 263 This may be an useful information to infer information on the 264 tenant's activity or to define when a DoS attack may cause more 265 damage. One way to measure the health or load of the tenant's SFC is 266 to regularly send a packet and measure the time it takes to be 267 received, in order to estimate the processing time within the SFC. 269 UCC may enable any user to test the consistency of the SFC. One 270 example of inconsistency could be that SFC decapsulation is not 271 performed - or inconsistently performed - before leaving the SFC, 272 which could leak some metadata with private information. For 273 example, a user may send spoofed packet. Suppose for example, that a 274 request HTTP GET video.example.com/movie is received with some extra 275 header information such as CLIENT_ID: 1234567890, or CLIENT_EMAIL: 276 client@example.foo. If these pieces of information are derived from 277 the source IP address, the attacker may collect them by changing the 278 IP address for example. In this case, the spoofed packets as used to 279 collect private and confidential information of the tenant's users. 280 Note that such threat is not specific to SFC, and results from the 281 combination of spoofed IP and non-authenticated IP address are used 282 to identify a user. What is specific to SFC is that metadata are 283 likely to carry multiple pieces of information - potentially non- 284 authenticated - associated to the user. In the case above, meta-data 285 is carried over the HTTP header. Inserting the metadata in the HTTP 286 header may be performed by a SF that takes its input from the SFC 287 encapsulation. In addition, SFC encapsulation may also leak this 288 information directly to a malicious node if that node belongs to the 289 SFC plane. In this later case, the user builds on the top of and 290 intrusion to the SFC Data Plane that is detailed later. 292 In some case, spoofed packet may impersonate other's tenants. 293 Suppose for example that the same infrastructure is used by multi 294 tenants, and which are identified by the IP address of their users. 295 In this case, spoofing an IP address associated to another tenant may 296 be sufficient to collect the information confidential and private 297 information. 299 Similarly, UCC may enable any user to infer packet has been dropped 300 or is in a loop. Suppose a user send a spoofed packet and receives 301 no response. The attacker may infer that the packet has been dropped 302 or is in a loop. A loop is expect to load the system and sending a 303 "well known packet" over the UCC and measuring the response time may 304 determine whether the packet has been dropped or is in a loop. 306 Correlation of time measurement and spoofed packet over a UCC may 307 provide various type information that could be used by an attacker. 309 - The attacker may correlate spoofed packet and time measurement 310 in order discover the SFC topology or the logic of the SFC 311 Classifier. Typically, it may infer when new SFs are placed in 312 the SFC for example. In addition, as metadata are placed in 313 band, the time response may also provide an indication of the 314 size of the metadata associated to the packet. The combination 315 of these pieces of information may help an attacker to 316 orchestrate a future attack on a specific SF either to maximize 317 the damages or to collect some metadata - like identification 318 credentials. 320 - The attacker may also define the type of packets that require 321 the SFC the more processing. Additional processing may be due 322 a large set of additional metadata that require fragmentation, 323 some packets that are not treated in a coherent and consistent 324 manner within the SFC. Such information may be used for 325 example to optimize a DoS attack. In addition, it could also 326 be used in order to artificially increase the necessary 327 resource of the Tenant in order to increase the cost of 328 operation for running its service. 330 Time measurement and spoofed packet in combination with variable 331 query rate over a UCC may provide information on the orchestration of 332 the SFC itself. For example, the user may be able to detect when 333 elasticity mechanisms are triggered. 335 An attacker may be able to leverage the knowledge that SFC is in use 336 by specific carriers to effect the processing of data using the SFC 337 system as a processor in the attack. This leads to a number of 338 potential weaknesses in the Internet ecosystem. 340 An attacker may be able to characterize the type of client platforms 341 using a web site by carefully crafting data streams that will be 342 modified by the SFC system versus client systems that would view web 343 data unmodified. For example, leveraging SFC and carefully crafted 344 data, a malicious web site operator may be able to create a 345 particularly formatted common file that when modified by a cellular 346 operator for bandwidth savings creates a file that may crash, 347 (creating a DoS attack) on a select set of clients. Clients not 348 accessing that web site using the same RSFP would not experience any 349 issues. Additionally, external examination of the malicious site 350 would not demonstrate any malicious content, relying on the SF to 351 modify the content. 353 A well crafted site could potentially leverage the variances of 354 functionality from different RSFPs in order to GEO locate a user. An 355 example would be creating an image file which when recompressed 356 creates image artifacts rendering the image unusable, but allowing 357 the user to respond to such an event, thereby letting the web site 358 operator know the user has potentially moved from a higher to lower 359 bandwidth network location within the area of a specific network 360 operator. 362 5.4. Attacks performed from the SFC Data Plane 364 This section considers an attacker has been able to take control of 365 an SFC component. As a result, the attacker may become able to 366 modify the traffic and perform, on-path attacks, it may also be able 367 to generate traffic, or redirect traffic to perform some kind of Man- 368 in-the-middle attacks. This is clearly a fault, and security 369 policies should be set to avoid this situation. This section 370 analyses in case this intrusion occurs, the potential consequences on 371 the SFC. As mentioned earlier, this section assumes all these 372 actions are performed by an attacker. However, what is designated by 373 an attack may also result from misconfigurations at various layer. A 374 SF or a SFF may become inadvertently configured or programed which 375 may result in similar outcomes as an attack. Whatever result in what 376 we designate as an attack, the purpose of security requirements will 377 be to detect, to analyse and mitigate such security breaches. 379 The traffic within the SFC Data Plane is composed of multiple layers. 380 The traffic is composed of communications between SFC components. 381 The transport between the SFC component is the transport protocol and 382 is not considered in the SFC. It can typically be a L2 transport 383 layer, or an L3 transport layer using various encapsulation 384 techniques (vLAN, VxLAN, GRE, IPsec tunnels for example). The 385 transport layer carries SFC Encapsulated that are composed of an SFC 386 Encapsulation envelope that carries metadata and a SFC payload that 387 is the actual packet exchanged between the two end points. 389 As a result, attacker may use the traffic to perform attacks at 390 various layers. More specifically, attacks may be performed at the 391 transport layer, the SFC Encapsulation layer or the SFC payload 392 layer. 394 - Attacks performed at the transport layer may be related to SFC 395 in the sense that illegitimate SFC traffic could be provided to 396 the SF. Typically, a malicious node that is not expected to 397 communicate with that SF may inject packets into the SFC, such 398 malicious node may eventually spoof the IP address of 399 legitimate SF, so the receiving SF may not be able to detect 400 the packet is not legitimate. Threats related to IP spoofing 401 are described in [RFC6959] and may be addresses by 402 authenticated traffic (e.g. using IPsec). Such threats are 403 not related to SFC even though they may impact a given SF. 405 - the SFC Encapsulation as well as the SFC payload are usually 406 considered as input by a SF. As such they may represent 407 efficient vector of attacks for the SF. Attacks performed 408 through SFC payload are similar as the ones described in the 409 Tenant's Users Data Plane section. As a result, such attacks 410 are not considered in this section, and this section mostly 411 considers attacks based on the SFC Encapsulation and malicious 412 metadata. 414 When an attacker is within the SFC Data Plane, it may have a full or 415 partial control of one SF component in which case, the attacker is 416 likely to compromise the associated SFCs. It could for example, 417 modify the expected operation of the SFC. Note that in this case, 418 the SFC may be appropriately provisioned and set, however, the SFC 419 does not operate as expected this may only be detected by monitoring 420 and auditing the SFC Data Plane. 422 Although traffic authentication may be performed at various layers L2 423 L3 or at the SFC Encapsulation layer, this section considers the SFC 424 traffic. As a result, the SFC traffic is authenticated if the SF is 425 able to authenticate the incoming SFC packet. 427 When SFC traffic is not authenticated, an attacker may inject spoofed 428 packet in any SFC component. The attacker may use spoofed packet to 429 discover the logic of the SFC. On the other hand, the attacker may 430 also inject packet in order to perform DoS attack via reflection. In 431 fact, some SF may carry large metadata, which may provide a vector 432 for amplification within the SFC Data Plane and thus either load the 433 network or the next SF. Note that amplification may be generated by 434 metadata, the SFC payload, and the attacker may replay packets or 435 completely craft new packets. In addition, the attacker may choose a 436 spoofed packet to increase the CPU load on the SFC components. For 437 example, it could insert additional metadata to generate 438 fragmentation. Similarly, it may also insert unnecessary metadata 439 that may need to be decapsulated and analyzed even though they may 440 not be considered for further actions. Spoofed packet may not only 441 be generated to attack the SFC component at the SFC layer. In fact 442 spoofed packet may also target applications of the SF. For example 443 an attacker may also forge packet for HTTP based application - like a 444 L7 firewall - in order to perform a slowloris [SLOWLORIS] like 445 attack. Note that in this case, such attacks are addressed in the 446 Tenant's Users Data Plane section. The specificity here is that the 447 attacker has a more advanced understanding of the processing of the 448 SFC, and can thus be more efficient. 450 When SFC traffic is not authenticated, an attacker may also modify 451 on-path the packet. By changing some metadata contained in the SFC 452 Encapsulation, the attacker may test and discover the logic of the 453 SFF. Similarly, when the attacker is aware of the logic of a SFC 454 component, the attacker may modify some metadata in order to modify 455 the expected operation of the SFC. Such example includes for example 456 redirection to a SF which could result in overloading the SF and 457 overall affect the complete SFC. Similarly, the attacker may also 458 create loops within the SFC. Note that redirection may not occur 459 only in a given SFC. In fact, the attacker may use SFC branching to 460 affect other SFC. Another example would also include a redirection 461 to a node owned by the attacker and which is completely outside the 462 SFC. Motivation for such redirection would be that the attacker has 463 full administrator privileges on that node, whereas it only has 464 limited capabilities on the corrupted node. Such attack is a man-in- 465 the-middle attack. The important thing to note is that in this case 466 the traffic is brought outside the legitimate SFC domain. In fact, 467 performing a man-in-the-middle attack as described above means that 468 the SFC domain has been extended. This can be easily performed in 469 case all node of the data center or the tenant's virtual network is 470 likely to host a SFC component. A similar scenario may also consider 471 that the traffic could be redirected outside the data center or the 472 tenant's virtual network if the routing of firewall rule enables such 473 policies. 475 A direct consequence is that a corrupted SFC component may affect the 476 whole SFC. This also means that the trust of a given SFC decreases 477 with the number of SF involved as each SF presents a surface of 478 attack. 480 An attacker may also perform passive attacks by listening to traffic 481 exchanged throughout the SFC Data Plane. Such attacks are described 482 in [RFC7258]. Metadata are associated to each packet. These 483 metadata are additional pieces of information not carried in the 484 packet and necessary for each SF to operate. As a result, metadata 485 may contain private information such as identifiers or credentials. 486 In addition, observing the traffic may provide information on the 487 tenant's activity. Note that encryption only may not prevent such 488 attacks, as activity may be inferred by the traffic load. 490 6. Security Requirements 492 This section aims at providing environment security requirements. 493 These requirements are derived from the threat analysis provided in 494 Section 5 496 Although the security requirements are derived from described 497 threats, the scope of security should be understood in a much broader 498 way than addressing threats. In fact the primary purpose of the 499 security requirements is to ensure the SFC architecture can remain 500 robust and stable. 502 Protecting the SFC architecture from attacker is one goal of the 503 security requirements. Some could easily argue that such 504 requirements are not needed for example in a private SFC deployment 505 where SFC components may be considered in a trusted environment and 506 administrated by a single entity. However, even in a single 507 administrative domain, inside attacks are possible. (e.g. inside 508 attacker sniffing the SFC metadata, sending spoofed packets etc.). 509 Then, the trusted domain assumption may not remain valid over time. 510 Suppose, for example, that the SFC architecture is now interconnected 511 with some third party SF or SFF. Such SFC component is now outside 512 the initial trusted domain which has several security implications. 513 Similarly, a single trusted domain with one tenant may evolve over 514 time and become multitenants and share a SFC platform. These 515 tenants, may be trusted as in the case for example where each tenant 516 represents a different department of a single company. 517 Authentication is not sufficient, and relying only on a access 518 control presents some risks. If the tenants are not strongly 519 isolated - with physical or logical networks isolation, they may 520 share a common SFF and one tenant may update the SFP of the other 521 tenant. Such misconfiguration has similar impact as a redirecting 522 attack. This document provide guidance that result in limiting such 523 risks and improve detection for further mitigation. 525 As a result, the goal of this document is to provide some security 526 requirements that should be checked against any evolution of the SFC 527 architecture. The requirements should be understand and the risks of 528 not following them should be evaluated with the current deployment as 529 well as the foreseen evolutions. 531 Similarly, the document provides means to evaluate the consequences 532 of a security breach, as well as means to detect them. 534 The motivations for the security requirements are: 536 a) Preventing attacks 538 b) Preventing misconfigurations - as far as stability and security 539 of the SFC architecture is concerned. 541 c) Providing means to evaluate the consequences of a security breach 543 d) Making possible to audit, and detect any misbehavior that may 544 affect stability and security of the SFC. 546 6.1. Plane Isolation Requirements 548 Plane Isolation consists in limiting the surface of attack of the SFC 549 Data Plane by controlling the interfaces between the SFC Data Plane 550 and the other planes. 552 Complete isolation of the planes is not possible, as there are still 553 some communications that must be enabled in order to benefit from the 554 benefits of SFC. As a result, isolation should be understood as 555 enabling communications between planes in a controlled way. 557 This section lists the recommendations so communication between 558 planes can be controlled. This involves controlling communications 559 between planes as well as controlling communication within a plane. 561 The requirements listed below applies to all planes, whereas the 562 following subsection are more specific to each plane, providing 563 recommendations on the interface with the SFC Data Plane. 565 REQ1: In order to increase isolation every plane that communicates 566 with another plane SHOULD use a dedicated interface. In our 567 case, the SFC Management Plane, the SFC Control Plane and the 568 SFC Data Plane SHOULD use dedicated networks and dedicated 569 interfaces. Isolation of inter-plane communication may be 570 enforced using different ways. How isolation is enforced 571 depends on the type of traffic, the network environment for 572 example, and within a given SFC architecture different 573 techniques may be used for the different planes. One way to 574 isolate communications is to use completely different network 575 on dedicated NICS. On the other hand, depending on the 576 required level of isolation, a logical isolation may be 577 performed using different IP addresses or ports with network 578 logically isolated - that is using for example different 579 VxLAN, or GRE tunnels. In this case, isolation relies on the 580 trust associated to the different switches and router. In 581 case of a lake of trust on the on-path elements, authenticated 582 encryption may be used to provide a logical isolation. With 583 authenticated encryption, trust is placed on the end points. 584 Note also that encryption can also be used in combination of 585 other isolation mechanisms in order to increase the level of 586 isolation. 588 REQ2: Activity on each interface between planes SHOULD be monitored 589 and regularly audited. 591 REQ3: Each interface between planes SHOULD be provided means to 592 filter traffic or rate-limit the traffic. Filtering and rate- 593 limiting policies may be finer grained and may apply for a 594 subset of traffic. 596 The above requirements mostly corresponds to the architecture best 597 current practice. Isolation is mostly motivated to avoid the planes 598 to interact on each other. For example the load on the SFC Data 599 Plane should not affect the SFC Control Plane and SFC Management 600 Plane communications. The purpose of the encryption is to prevent 601 the communication to be visible outside the SFC components involved 602 and to be authenticated. 604 The two remaining requirements provides means to be informed and to 605 to protect the planes at their boundaries. Such requirements are 606 also current best practices. 608 Such recommendations are thus strongly recommended even in the case 609 the two planes are considered to belong to trusted environments. 611 6.1.1. SFC Control Plane Isolation 613 In order to limit the risks of an attack from the SFC Control Plane, 614 effort should be made in order to restrict the capabilities and the 615 information provided by the SFC Data Plane to the SFC Control Plane 616 to the authorized tenants only. In this case the authorized tenants 617 are the users or organizations responsible for the SFC domain. 619 REQ4: Tenants of the SFC Control Plane SHOULD authenticate in order 620 to prevent tenant's usurpation or communication hijacking. 622 REQ5: Communications between SFC Control Plane and the SFC Data 623 Plane MUST be authenticated and encrypted in order to preserve 624 privacy. The purpose of encryption in this case prevents an 625 attacker to be aware of the action performed by the SFC 626 Control Plane. Such information may be used to orchestrate an 627 attack - especially when SFC component report their CPU/ 628 network load. 630 REQ6: Strong access control policies SHOULD be enforced. Control 631 SHOULD be performed on the engaged resource (e.g. CPU, 632 memory, disk access for example) and SHOULD be associated 633 explicitly to authorized tenants. By default, a tenant SHOULD 634 be denied any access to resource, and access SHOULD be 635 explicit. 637 Given the SFC Control Plane traffic load that is expected to be light 638 - at least compared to the SFC Tenant's Users Data Plane or the SFC 639 Data Plane. As a result, encryption is not expect to impact the 640 performances of the SFC architecture. Given the effort to migrate 641 from an non authenticated (and non protected) communications to a 642 protected communication, we recommend these requirements to be 643 considered even in trusted environments. 645 Access Control policies can be enforced in various ways. One way 646 could be to consider the systems of the SF to limit the resources 647 associated to each tenants. Other ways include the use of API in 648 order to limit the scope of possible interactions between the SFC 649 Control Plane and the SFC Data Plane. This is one way to limit the 650 possibilities of the tenants. In addition, each of these actions 651 should be associated an authorized tenant, as well as authorized 652 parameters. The use of API belongs to best practices and so is 653 strongly recommended even in trusted environments. 655 REQ7: Audit SHOULD be performed regularly to check access control 656 policies are still up-to-date and prevent non-authorized users 657 to control the SFC Data Plane. 659 The purpose of audits is to provide evidences when something went 660 wrong. As a result, audit facilities are expected to be provided 661 even in trusted environments. 663 6.1.2. SFC Management Plane Isolation 665 The requirements for the SFC Control Plane and SFC Management Plane 666 are similar. The main difference of the interfaces between the SFC 667 Management Plane and the SFC Control Plane is that it is less likely 668 that APIs could be used to configure the different SFC components. 669 As a result, users of the SFC Management Plane are likely to have a 670 broader and wider control over the SFC component. 672 REQ8: it is RECOMMENDED to enforce stronger authentication 673 mechanisms (for example relying on hardware tokens or keys) 674 and to limit the scope of administrative roles on a per 675 component basis. 677 REQ9: SFC Control Plane and SFC Management Plane may present some 678 overlap. Each SFC component MUST have clear policies in case 679 these two planes enter in conflict. 681 6.1.3. Tenant's Users Data Plane Isolation 683 The Tenant's Users Data Plane is supposed to have less restricted 684 access control than the other SFC Management Plane and SFC Control 685 Planes. A typical use case could be that each tenant are controlling 686 and managing the SFC in order to provide services to their associated 687 users. The number of users interacting with the SFC Data Plane is 688 expected to be larger than the number of tenants interacting with the 689 SFC Control and SFC Management Planes. In addition, the scope of 690 communications initiated or terminating at the user end points is 691 likely to be unlimited compared to the scope of communications 692 between the tenants and the SFC Control Plane or SFC Management 693 Plane. In such cases, the tenant may be provided two roles. One to 694 grant access to the SFC, and another one to control and manage the 695 SFC. These two roles should be able to interact and communicate. 697 REQ10: Users SHOULD be authenticated, and only being granted access 698 to the SFC if authorized. Authorization may be provided by 699 the SFC itself or outside the SFC. 701 REQ11: Filtering policies SHOULD prevent access to a user, or traffic 702 when a malicious behavior is noticed. A malicious activity 703 may be noticed once a given behavioral pattern is detected or 704 when unexpected load is monitored in the SFC Data Plane. 706 REQ12: Tenant's User Plane SHOULD be monitored, in order to detect 707 malicious behaviors. 709 REQ13: When SFC is used by multiple tenants, each tenant's traffic 710 SHOULD be isolated based on authenticated information. More 711 specifically, the use of a Classifier that can easily be 712 spoofed like an IP address SHOULD NOT be used. 714 It is RECOMMENDED that user's access authorization be performed 715 outside the SFC. In fact granting access and treating the traffic 716 are two different functions, and we RECOMMEND they remain separated. 717 Then, splitting these two functions makes it possible for a tester to 718 perform tests of an potential attacker, without any contextual 719 information. More specifically, having a traffic identified as 720 associated to test by the SFC reduces the scope of the tests simply 721 because an attacker will not be considered as a tester. For that 722 reason, we RECOMMEND authorization is performed outside the SFC, and 723 SFC deployment may not be designed to authenticate end users. 725 The remaining requirements are associated to monitoring the network 726 and providing interactions between the access and the SFC. This 727 interaction may be provided outside SFC itself. 729 6.2. SFC Data Plane Requirements 731 This section provides requirements and recommendation for the SFC 732 Data Plane. 734 REQ14: Communications within the SFC Data Plane SHOULD be 735 authenticated in order to prevent the traffic to be modified 736 by an attacker. As a result, authentication includes the SFC 737 Encapsulation as well as the SFC payload. 739 REQ15: Communication MUST NOT reveal privacy sensitive metadata. 741 REQ16: The metadata provided in the communication MUST be limited in 742 in term of volume as to limit the amplification factor as well 743 as fragmentation. 745 REQ17: Metadata SHOULD NOT be considered by the SFF for forwarding 746 decision. In fact, the inputs considered for switching the 747 packet to the next SFF or a SF should involve a minimum 748 processing operation to be read. More specifically, these 749 inputs are expected fixed length value fields in the SFC 750 Encapsulation header rather than any TLV format. 752 REQ18: When multiple tenants share a given infrastructure, the 753 traffic associated to each tenant MUST be authenticated and 754 respective Tenant's Users Planes MUST remain isolated. More 755 specifically, if for example, a SFC Classifier is shared 756 between multiple tenants. The Classifier used to associate 757 the SFC MUST be authenticated. This is to limit the use of 758 spoofed Classifiers. In any case, the SFC component that 759 receives traffic from multiple tenants is assumed to be 760 trusted. 762 REQ19: Being a member of a SFC domain SHOULD be explicitly mentioned 763 by the node and means should be provided so the SFC domain the 764 node belongs to may be checked. Such requirement intends to 765 prevent a packet to go outside a SFC domain, for example in 766 the case of a man-in-the-middle attacks, where a redirection 767 occurs outside the SFC domain. It is expected that most 768 deployment will rely on border / port mechanisms that prevent 769 outsider users from injecting packets with spoofed metadata. 770 Although such mechanisms are strongly recommended to deploy, 771 in case of failure, they do not prevent man-in-the-middle 772 attack outside the SFC domain. 774 Authentication of the traffic within the SFC Data Plane is 775 particularly recommended in an open environment where third party SF 776 or SFF are involved. It can also be recommended when a strong 777 isolation of the traffic is crucial for the infrastructure or to meet 778 some level of certification. In addition, authentication may also be 779 performed using various techniques. The whole packet may be 780 authenticated or limited to some parts (like the flow ID). 781 Authenticating the traffic and how or what to authenticate is a trade 782 off between the risk associated and the cost of encryption. When 783 possible we recommend to authenticate, but we also consider that the 784 price may be too high in controlled and small trusted environment. 786 Metadata is an important part of the SFC architecture, and their 787 impact on security should be closely evaluated. It is the 788 responsibility of the SFC administrator to evaluate the privacy 789 associated by the metadata - section 5.2.2 of [RFC6973] - and 790 according to this evaluation to consider appropriated mechanisms to 791 prevent the privacy leakage. Mechanisms should be provided even 792 though they may not be activated. 794 As a general guidance exposing privacy sensitive metadata in any 795 communications between two any SFC component should be avoided. [One 796 way, for example to avoid exposing privacy sensitive metadata is to 797 include a reference to the metadata instead of the metadata itself. 798 Another way could be to encrypt the metadata itself - but that is 799 part of the solution space.] Applying this principle prevents any 800 private oriented data to be leaked. This requirement is mandatory 801 when the SFC is not deployed in a trusted environment. 803 When exposition of the privacy sensitive metadata cannot be avoided 804 and you are in a trusted domain, then exposing privacy sensitive 805 metadata may be considered as long as they do not leak outside the 806 boundaries of the trusted environment. In this case, the security is 807 delegated to the security policies of the trusted environment 808 boundaries, that may be outside the scope of SFC. More especially, 809 the security policies may be for example enforced by a firewall. In 810 this specific case, the trusted environment MUST prevent leakage of 811 the metadata out of the trusted environment and MUST ensure that 812 untrusted node cannot access in any way the communications within the 813 trusted environment. 815 The reason this requirement is set to MUST is to specify that if one 816 does not follow the requirement it is at its your own risk and must 817 provide the necessary means to prevent any leak - in our case 818 enforcing the necessary security policies that your environment / 819 deployment needs. 821 Similarly, it is the responsibility of the administrator to define 822 what an acceptable size for metadata is. Even in trusted 823 environment, we recommend the SFC administrator be able to define and 824 change this level. 826 Processing metadata by the SFF seems also expensive, and it is the 827 responsibility of the SFC administrator to evaluate whether 828 processing metadata by the SFF may impact the SFC architecture. In 829 addition, metadata are expected to be associated to SF as opposed to 830 the forwarding information that are associated to the SFF. These 831 inputs have different functions, are associated to different 832 processing rules, and may be administrated by different parties. It 833 is thus part of the general good practise to split these 834 functionalities. Optimization may require to combine the analysis of 835 metadata and forwarding information, but this should be handled 836 cautiously. 838 Assertion of belonging to a security domain, is especially 839 recommended in open environments. This may also partly be addressed 840 by node authenticating. 842 In addition, the following operational requirements have been 843 identified: 845 REQ20: SFC components SHOULD be uniquely identified and have their 846 own cryptographic material. In other words the use of a 847 shared secret for all nodes SHOULD NOT be considered as one 848 corrupted node would be able to impersonate any node of the 849 SFC Data Plane. This is especially useful for audit. 851 REQ21: Activity in the SFC Data Plane MUST be monitored and audited 852 regularly. Audit and log analysis is especially useful to 853 check that SFC architecture assessments. They can be useful 854 to detect a security breach for example before it is being 855 discovered and exploited by a malicious user. Monitoring the 856 system is also complementary in order to provide alarms when a 857 suspicious activity is detected. Monitoring enables the 858 system to react to unexpected behaviors in a dynamic way. 859 Both activities are complementary as monitoring enables to 860 counter suspicious behavior and audit may detect 861 misconfiguration or deep causes of a malicious behavior. For 862 these reasons, audit and monitoring facilities are expected 863 even in trusted environment. 865 REQ22: Isolate the Plane with border and firewall to restrict access 866 of SFC components to legitimate traffic. More specifically, 867 SFC components are supposed to be accessed only via dedicated 868 interfaces. Outside these interfaces, inbound or outbound 869 traffic SHOULD be rejected. 871 6.3. Additional Requirements 873 REQ23: SFC Encapsulation SHOULD carry some identification so it can 874 be associated to the appropriated SFP as well as its position 875 within the SFC or SFP. Indicating the SFP ID may be 876 sufficient as long as a SFP can uniquely be associated to a 877 single SFC. Otherwise, the SFC should be also somehow 878 indicated. This is especially useful for audit and to avoid 879 traffic coming from one SFC to mix with another SFC. 880 Authentication of the SFP ID is one way to enforce SFP ID 881 uniqueness. This may not be mandatory, but large deployment 882 or deployment that are involving multiple parties are expected 883 enforce this. In fact assuming SFP ID will have no collision 884 is an hypothesis that may be hard to fulfill over time. 886 REQ24: It is RECOMMENDED that SFF and SF keep separate roles. SFF 887 should be focused on SF forwarding. As a result, they are 888 expected to access a limited information from the packet - 889 mostly fixed size information. SF on the other hand are 890 service oriented, and are likely to access all SFC information 891 which includes metadata for example. The reasons to keep 892 these functions are clearly different and may involve 893 different entities. For example, SF management or SF 894 configuration may involve different administrators as those 895 orchestrating the SFC. 897 REQ25: SFC Encapsulation SHOULD be integrity protected to prevent 898 attackers from modifying the SFP ID. See Data Plane 899 communication Requirements and considerations) 901 7. Security Considerations 903 8. Privacy Considerations 905 9. IANA Considerations 906 10. Acknowledgments 908 The authors would like to thank Joel Halpern, Mohamed Boucadair and 909 Linda Dunbar for their valuable comments. 911 11. References 913 11.1. Normative References 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 921 Validation Improvement (SAVI) Threat Scope", RFC 6959, 922 DOI 10.17487/RFC6959, May 2013, 923 . 925 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 926 Morris, J., Hansen, M., and R. Smith, "Privacy 927 Considerations for Internet Protocols", RFC 6973, 928 DOI 10.17487/RFC6973, July 2013, 929 . 931 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 932 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 933 2014, . 935 11.2. Informative References 937 [I-D.ietf-sfc-nsh] 938 Quinn, P. and U. Elzur, "Network Service Header", draft- 939 ietf-sfc-nsh-01 (work in progress), July 2015. 941 [I-D.ietf-sfc-architecture] 942 Halpern, J. and C. Pignataro, "Service Function Chaining 943 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 944 in progress), July 2015. 946 [I-D.ietf-sfc-control-plane] 947 Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., 948 Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A., 949 Halpern, J., Reddy, T., and P. Patil, "Service Function 950 Chaining (SFC) Control Plane Components & Requirements", 951 draft-ietf-sfc-control-plane-00 (work in progress), August 952 2015. 954 [SLOWLORIS] 955 Wikipedia, "Slowloris", . 958 Authors' Addresses 960 Daniel Migault (editor) 961 Ericsson 962 8400 boulevard Decarie 963 Montreal, QC H4P 2N2 964 Canada 966 Phone: +1 514-452-2160 967 Email: daniel.migault@ericsson.com 969 Carlos Pignataro 970 Cisco Systems, Inc. 971 7200-12 Kit Creek Road 972 Research Triangle Park, NC 27709 973 USA 975 Phone: +1 919-392-7428 976 Email: cpignata@cisco.com 978 Tirumaleswar Reddy 979 Cisco Systems, Inc. 980 Cessna Business Park, Varthur Hobli 981 Bangalore, Karnataka 560103 982 India 984 Phone: +91 9886 985 Email: tireddy@cisco.com 987 Christopher Inacio 988 CERT, Software Engineering Institute, Carnegie Mellon University 989 4500 5th Ave 990 Pittsburgh, PA 15213 991 USA 993 Phone: +1 412-268-3098 994 Email: inacio@cert.org