idnits 2.17.00 (12 Aug 2021) /tmp/idnits43101/draft-mglt-sfc-security-environment-req-02.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 (October 28, 2016) is 2024 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-sfc-nsh has been published as RFC 8300 == Outdated reference: draft-ietf-sfc-architecture has been published as RFC 7665 == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-00 Summary: 0 errors (**), 0 flaws (~~), 4 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: May 1, 2017 T. Reddy 6 Cisco 7 C. Inacio 8 CERT/SEI/CMU 9 October 28, 2016 11 SFC environment Security requirements 12 draft-mglt-sfc-security-environment-req-02.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 May 1, 2017. 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 4.1. Deployment of SFC Architecture . . . . . . . . . . . . . 6 63 5. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Attacks performed from the SFC Control Plane . . . . . . 8 65 5.2. Attacks performed from the SFC Management Plane . . . . . 9 66 5.3. Attacks performed from the Tenant's Users Plane . . . . . 9 67 5.4. Attacks performed from the SFC Data Plane . . . . . . . . 11 68 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14 69 6.1. Plane Isolation Requirements . . . . . . . . . . . . . . 15 70 6.1.1. SFC Control Plane Isolation . . . . . . . . . . . . . 16 71 6.1.2. SFC Management Plane Isolation . . . . . . . . . . . 17 72 6.1.3. Tenant's Users Data Plane Isolation . . . . . . . . . 18 73 6.2. SFC Data Plane Requirements . . . . . . . . . . . . . . . 19 74 6.3. Additional Requirements . . . . . . . . . . . . . . . . . 22 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 76 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 81 11.2. Informative References . . . . . . . . . . . . . . . . . 24 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 This document provides environment security requirements for the SFC 93 architecture [I-D.ietf-sfc-architecture]. Environment security 94 requirements are independent of the protocols used for SFC - such as 95 NSH [I-D.ietf-sfc-nsh]. As a result, the requirements provided in 96 this document are intended to provide good security practice so SFC 97 can be securely deployed and operated. These security requirements 98 are designated as environment security requirements as opposed to the 99 protocol security requirements. This document is built as follows. 100 Section 4 provides an overall description of the SFC environment with 101 the introduction of the different planes (SFC Control Plane, the SFC 102 Management Plane, the Tenant's user Plane and the SFC Data Plane). 103 Section 6 lists environment security requirements for the SFC. These 104 requirements are intended to prevent attacks, as well as network and 105 SFC misconfigurations. When such events happens, the security 106 recommendations also aim at detecting and identifying the threats or 107 misconfiguration as well as limiting their impact. Recommendations 108 also may apply differently depending on the infrastructure. For 109 example trusted environment may enforce lighter security 110 recommendations than public and open SFC infrastructures. However, 111 one should also consider future evolution of their infrastructure, 112 and consider the requirements as a way to maintain the SFC 113 architecture stable during its complete life cycle. For each 114 requirement this document attempts to provide further guidance on the 115 reasons to enforce it as well as what should be considered while 116 enforcing it or the associated risks of not enforcing it. 118 This document assumes the reader is familiar with the SFC 119 architecture defined in [I-D.ietf-sfc-architecture] as well as the 120 Internet Security Glossary [RFC4949] 122 3. Terminology and Acronyms 124 In addition to the terminology defined in 125 [I-D.ietf-sfc-architecture], the document defines the following 126 terminology: 128 - Tenant: A tenant is one organization that is using SFC. A tenant 129 may use SFC on one's own private infrastructure or on a shared 130 infrastructure. 132 - Tenant's User Data Plane: The tenant may be using SFC to provide 133 service to its customers or users. The communication of these 134 users is designated as Tenant's user Data Plane and includes 135 all communications involving the tenant's users. As a result, 136 if a user is communicating with a server or a user from another 137 domain, the communication with that tenant's user is part of 138 the Tenant's Users Data Plane. 140 4. SFC Environment Overview 142 This section provides an overview of SFC. It is not in the scope to 143 this document to provide an explicit description of SFC. Instead, 144 the reader is expected to read [RFC7498], 146 [I-D.ietf-sfc-architecture], [I-D.ietf-sfc-control-plane] and other 147 SFC related documents. 149 Service Function Chaining (SFC) architecture is defined in 150 [I-D.ietf-sfc-architecture]. This section briefly illustrates the 151 main concepts of the SFC architecture and positions the architecture 152 within an environment. 154 SFC Control Plane 155 ^ ^ ^ 156 -------------------------|---------------|-------------|----|-------- 157 | C1 | C3 | C2 | | C4 158 | | +-----+ | | 159 | | |SF_a | | | 160 | | +-----+ | | 161 | v | | | 162 | +------------+ +-----+ +-----+ | 163 | +->| SFC |---->| SFF |----->| SFF |------+ 164 SFC | | | Classifier |<----| |<-----| | | | 165 Management | | +------------+ +-----+ +-----+ | | 166 Plane | | ^ | | | 167 | | | +-----------+ | 168 | | | | SFC Proxy | | 169 | | | +-----------+ | 170 | | | | | 171 | | | +------+ | 172 | | v | SF_b | | 173 | | +---------+ +------+ | 174 | | | SFP 2 | <------------ SFP 1 -------> | 175 | | +---------+ | 176 | | SFC Data Plane | 177 -----------------|-----------------------------------------------|-- 178 SFC incoming | SFC outgoing | 179 Data traffic | Data traffic v 181 SFC Tenant's Users Data Plane 183 Figure 1: SFC Environment Overview 185 SFC defined a Service Function Path (SFP) which is an ordered set of 186 Service Functions (SF) applied to part of the packets. The figure 187 above represents two SFP: SFP1 and SFP2. SFP2 is not detailled but 188 SFP1 defines a path that goes through SF_a and SF_b. SFP is defined 189 at the SF level, which means the path does not consider the specific 190 instance of an SF for example. A SF may be performed by different 191 instances of SF located at different positions. As a result, a 192 specific packet may pass through different instances of SFC. The 193 ordered set of SF instances a packet goes through is called the 194 Rendered SF Path (RSFP). 196 Upon the receipt of an incoming packet from the tenant's user, the 197 SFC Classifier determines, according to Classifiers, which SFP is 198 associated to that packet. The packet is forwarded from Service 199 Function Forwarders (SFF) to SFF. SFF are then in charge of 200 forwarding the packet to the next SFF or to a SF. Forwarding 201 decisions may be performed using SFP information provided by the SFC 202 Encapsulation. As described in [I-D.ietf-sfc-nsh] the SFC 203 Encapsulation contains SFP information such as the SFP ID and Service 204 Index and eventually (especially for the MD-2 in NSH) some additional 205 metadata. SF may be SFC aware or not. In the case the SFC functions 206 are not SFC aware, a SFC Proxy performs the SFC Decapsulation (resp. 207 SFC Encapsulation) before forwarding the packet to the SF (resp. 208 after receiving the packet from the SF). 210 The environment associated to SFC may be separated into the four main 211 planes: 213 - SFC Management Plane and Control Plane are defined in 214 [I-D.ietf-sfc-control-plane]. The SFC MAnagement Plane can be 215 assimilated to the cloud infrastructure provider allocating 216 various resource to the various SF and eventually active the 217 various SF components. Typically management operations would 218 consist in setting the number of CPU, memory bandwidth 219 associated to the various SFs as well as specific configuration 220 parameters of the SFC components. It is expected that the 221 interface between the various SFC components configuration will 222 be vendor specific. These configurations may be provided by 223 the Cloud infrastructure provider or in the case of 224 multitenancy by the administrator of the virtual network, or by 225 each administrator of the SFC components. The SFC control 226 plane controls and configure the SFC related components. The 227 Control Plane differs from the Management Plane as it only 228 concerns a subset of the parameters and facilities associated 229 to the SF. In general, these parameters are expected to only 230 modify the internal states of the different elements. This 231 aspect confers programmability properties to the Control Plane 232 that are usually not provide to the Management Plane. It is 233 also expected that the SFP are elaborated in this plane before 234 being pushed into the SFC Data Plane, and more generally, the 235 SFP state in the SFF is expected to come from control rather 236 than management. 238 - SFC Data Plane consists in all SF components as well as the 239 data exchanged between the SF components. Communications 240 between SF components includes the packet themselves, their 241 associated metadata, the routing logic - similar to RIB - or SF 242 logic, i.e. what they retuned values are for example. In other 243 words, the SFC Data Plane can also be seen as all the elements 244 that interact with a packet provided by an end user. Of course 245 the end user is not expected to configure any of these element 246 through the SFC Data Plane. Instead it is expected to apply 247 the policies and configurations put in place by the SFC Tenant. 249 - SFC Tenant's Users Data Plane consists in the traffic data 250 provided by the different users of the tenants. When a user is 251 communicating with a server or another user -eventually from 252 another administrative domain - , the communication belongs to 253 the SFC Tenant's Users Data Plane whenever packets are provided 254 by the server of by the user. 256 4.1. Deployment of SFC Architecture 258 This section illustrates a deployment of SFC we consider in this 259 document. 261 A Cloud Provider provides an infrastructure that is shared by 262 multiple SFC Tenants. The Cloud Provider may also provide some 263 servers or hardware that have a dedicated function. Such hardware 264 may be provided to the SFC Tenants under the form of a SF. It may 265 thus be shared by multiple SFC Tenants. Such SF are designated as 266 third party SF. Another case of SF may also consider a local SF 267 proxying the traffic to a remote site or domain. The SF proxy 268 transparently to the SFC elements may forward the traffic out of the 269 boundaries of the Tenant. In some case this may be needed, but in 270 some other case this may be done unbeknownst to the Tenant's. 272 Each SFC Tenant is responsible of its domain, that is to administrate 273 or provision the necessary resource and control all its SFC elements 274 which include defining SFC Paths, configuring the elements... 275 Typically the coordination of the SFC elements is likely to be 276 performed by a SDN controller. 278 Protecting the deployed SFC architecture from attacker is one goal of 279 the security requirements. Some could easily argue that such 280 requirements are not needed for example in a private SFC deployment 281 where SFC components may be considered in a trusted environment and 282 administrated by a single entity. However, even in a single 283 administrative domain, inside attacks are possible. (e.g. inside 284 attacker sniffing the SFC metadata, sending spoofed packets etc.). 285 Then, the trusted domain assumption may not remain valid over time. 286 Suppose, for example, that the SFC architecture is now interconnected 287 with some third party SF or SFF. Such SFC component is now outside 288 the initial trusted domain which has several security implications. 290 Similarly, a single trusted domain with one tenant may evolve over 291 time and become multitenants and share a SFC platform. These 292 tenants, may be trusted as in the case for example where each tenant 293 represents a different department of a single company. 294 Authentication is not sufficient, and relying only on a access 295 control presents some risks. If the tenants are not strongly 296 isolated - with physical or logical networks isolation, they may 297 share a common SFF and one tenant may update the SFP of the other 298 tenant. Such misconfiguration has similar impact as a redirecting 299 attack. This document provide guidance that result in limiting such 300 risks and improve detection for further mitigation. 302 5. Threat Analysis 304 The SFC environment is composed of the following plans: SFC 305 Management Plane, SFC Control Plane, SFC Data Plane and SFC Tenant's 306 User Data Plane. The purpose of these planes is to group a given set 307 of functions while limiting the interactions between these planes. 308 Interactions between planes are only limited - in most cases 309 controlled - but these interactions still exist and so may be used by 310 an attcker. As a result, for each plane, the threat analysis is 311 performed by analysis the vulnerabilities present within each plane 312 as well as those performed via the other planes. 314 Threat analysis of the Management Plane and the Control Plane have 315 been described in [I-D.ietf-sfc-control-plane]. The SFC Tenant's 316 User Plane is out of the boundaries of the SFC administrator. As a 317 result attacks performed on SFC Tenant's User Plan are not considered 318 in this section and this section limits its analysis on teh SFC Data 319 Plan. 321 This section describes potential threats the SFC Data Plane may be 322 exposed. The list of threats is not expected to be complete. More 323 especially, the threats mentioned are provided to illustrate some 324 security requirements for the SFC architecture. For simplicity, this 325 document mostly considers that security breaches are performed by an 326 attacker. However, such breaches may also be non-intentional and may 327 result from misconfiguration for example. 329 Attacks may be performed from inside the SFC Data Plane or from 330 outside the SFC Data plane, in which case, the attacker is in at 331 least one of the following planes: SFC Control Plane, SFC Management 332 Plane or SFC Tenants' Users Plane. Some most sophisticated attacks 333 may involve a coordination of attackers in multiple planes. 335 5.1. Attacks performed from the SFC Control Plane 337 Attacks related to the control plane have been detailed in section 5 338 of [I-D.ietf-sfc-control-plane]. 340 The different interfaces between the SFC Control Plane and the SFC 341 Data Plane are exposed in [draft-ietf-sfc-control-plane]. It 342 includes: 344 - Updating the classification rule of the SFC Classifier (also 345 referred as interface C1). 347 - Updating the forwarding decision of the SFF (also refereed as 348 interface C2). This interface is also used to provide the SFC 349 Control Plane some information for example on the system load, 350 network load or the latency so appropriated SFP may be 351 computed. 353 - Updating SF's internal states (interface C3). This interface 354 is also used to provide the SFC Control Plane some information 355 for example on the system load, network load or the latency so 356 appropriated SFP may be computed. 358 - Updating SFC Proxy's internal states (interface C4). This 359 interface is also used to provide the SFC Control Plane some 360 information for example on the system load, network load or the 361 latency so appropriated SFP may be computed. 363 An attacker may change the SFC Classifier classification and 364 completely modify the services provided by the SFC. Such privileges 365 may be used to avoid some control over the tenant's traffic (like 366 firewalling service). An attacker may also modify the filtering or 367 classification rules to overload heavy processing functions with 368 traffic. In a pay-what-you-use model, this could result in extra 369 cost for the tenant or to trigger a DoS attack on the tenant SFC Data 370 Plane. 372 Attack performed on the SFC Control Plane mostly consists in tenant 373 impersonation or communication hijacking. This would enable an 374 attacker to control the SFC components associated to the tenant. 375 Similarly an attacker may also collect system or network load 376 information in order to better orchestrate a DoS attack for example. 377 An attacker may also inject instructions in order to perform a DoS 378 attack on a given SFC component or to prevent the tenant to control 379 other SFC components. 381 5.2. Attacks performed from the SFC Management Plane 383 Attacks performed on the SFC Management Plane are similar to those 384 performed from the SFC Control Plane. The main difference is that 385 the SFC Management Plan provides usually a greater control of the SFC 386 component that the SFC Control Plane. 388 In addition, the actions performed by the SFC Management Plane have 389 fewer restrictions, which means it may be harder to enforce strong 390 control access policies. 392 5.3. Attacks performed from the Tenant's Users Plane 394 The SFC Tenant's User Plane is not expected to have fine access 395 control policies on the packets sent or received by users. Unless 396 they are filtered, all packets are good candidate to the SFC 397 Classifier. This provides the user some opportunities to test the 398 behavior of the SFC. 400 In addition, the Tenant's Users Plane is not controlled by the SFC 401 Tenant, and users may initiate communications where both ends - the 402 client and the server- are under the control of the same user. Such 403 communications may be seen as user controlled communications (UCC). 405 UCC may enable any user to monitor and measure the health of the SFC. 406 This may be an useful information to infer information on the 407 tenant's activity or to define when a DoS attack may cause more 408 damage. One way to measure the health or load of the tenant's SFC is 409 to regularly send a packet and measure the time it takes to be 410 received, in order to estimate the processing time within the SFC. 412 UCC may enable any user to test the consistency of the SFC. One 413 example of inconsistency could be that SFC decapsulation is not 414 performed - or inconsistently performed - before leaving the SFC, 415 which could leak some metadata with private information. For 416 example, a user may send spoofed packet. Suppose for example, that a 417 request HTTP GET video.example.com/movie is received with some extra 418 header information such as CLIENT_ID: 1234567890, or CLIENT_EMAIL: 419 client@example.foo. If these pieces of information are derived from 420 the source IP address, the attacker may collect them by changing the 421 IP address for example. In this case, the spoofed packets as used to 422 collect private and confidential information of the tenant's users. 423 Note that such threat is not specific to SFC, and results from the 424 combination of spoofed IP and non-authenticated IP address are used 425 to identify a user. What is specific to SFC is that metadata are 426 likely to carry multiple pieces of information - potentially non- 427 authenticated - associated to the user. In the case above, meta-data 428 is carried over the HTTP header. Inserting the metadata in the HTTP 429 header may be performed by a SF that takes its input from the SFC 430 encapsulation. In addition, SFC encapsulation may also leak this 431 information directly to a malicious node if that node belongs to the 432 SFC plane. In this later case, the user builds on the top of and 433 intrusion to the SFC Data Plane that is detailed later. 435 In some case, spoofed packet may impersonate other's tenants. 436 Suppose for example that the same infrastructure is used by multi 437 tenants, and which are identified by the IP address of their users. 438 In this case, spoofing an IP address associated to another tenant may 439 be sufficient to collect the information confidential and private 440 information. The best current practice to prevent such leaks are 441 usually ingress filtering for example, which prevents unlegitimate 442 flows to enter the network. Note that ingress filtering may also be 443 performed at higher layers such as at application layers to prevent 444 unexpected applications to enter the network. When possible, the 445 cost needs to be balanced with the risk by the SFC tenants. 447 Similarly, UCC may enable any user to infer packet has been dropped 448 or is in a loop. Suppose a user send a spoofed packet and receives 449 no response. The attacker may infer that the packet has been dropped 450 or is in a loop. A loop is expect to load the system and sending a 451 "well known packet" over the UCC and measuring the response time may 452 determine whether the packet has been dropped or is in a loop. 454 Correlation of time measurement and spoofed packet over a UCC may 455 provide various type information that could be used by an attacker. 457 - The attacker may correlate spoofed packet and time measurement 458 in order discover the SFC topology or the logic of the SFC 459 Classifier. Typically, it may infer when new SFs are placed in 460 the SFC for example. In addition, as metadata are placed in 461 band, the time response may also provide an indication of the 462 size of the metadata associated to the packet. The combination 463 of these pieces of information may help an attacker to 464 orchestrate a future attack on a specific SF either to maximize 465 the damages or to collect some metadata - like identification 466 credentials. 468 - The attacker may also define the type of packets that require 469 the SFC the more processing. Additional processing may be due 470 a large set of additional metadata that require fragmentation, 471 some packets that are not treated in a coherent and consistent 472 manner within the SFC. Such information may be used for 473 example to optimize a DoS attack. In addition, it could also 474 be used in order to artificially increase the necessary 475 resource of the Tenant in order to increase the cost of 476 operation for running its service. 478 Time measurement and spoofed packet in combination with variable 479 query rate over a UCC may provide information on the orchestration of 480 the SFC itself. For example, the user may be able to detect when 481 elasticity mechanisms are triggered. Such attack is not SFC 482 specific, and may have occured with traditional cloud mechanisms. 483 However, the main difference between SFC and traditional cloud 484 mechanisms is that SFC is a standard way to interconnect SF. In that 485 sense, the use of SFC provides more details to the attack as non 486 standard mechanisms. 488 An attacker may be able to leverage the knowledge that SFC is in use 489 by specific carriers to effect the processing of data using the SFC 490 system as a processor in the attack. This leads to a number of 491 potential weaknesses in the Internet ecosystem. 493 An attacker may be able to characterize the type of client platforms 494 using a web site by carefully crafting data streams that will be 495 modified by the SFC system versus client systems that would view web 496 data unmodified. For example, leveraging SFC and carefully crafted 497 data, a malicious web site operator may be able to create a 498 particularly formatted common file that when modified by a cellular 499 operator for bandwidth savings creates a file that may crash, 500 (creating a DoS attack) on a select set of clients. Clients not 501 accessing that web site using the same RSFP would not experience any 502 issues. Additionally, external examination of the malicious site 503 would not demonstrate any malicious content, relying on the SF to 504 modify the content. 506 A well crafted site could potentially leverage the variances of 507 functionality from different RSFPs in order to GEO locate a user. An 508 example would be creating an image file which when recompressed 509 creates image artifacts rendering the image unusable, but allowing 510 the user to respond to such an event, thereby letting the web site 511 operator know the user has potentially moved from a higher to lower 512 bandwidth network location within the area of a specific network 513 operator. 515 5.4. Attacks performed from the SFC Data Plane 517 This section considers an attacker has been able to take control of 518 an SFC component. As a result, the attacker may become able to 519 modify the traffic and perform, on-path attacks, it may also be able 520 to generate traffic, or redirect traffic to perform some kind of Man- 521 in-the-middle attacks. This is clearly a fault, and security 522 policies should be set to avoid this situation. This section 523 analyses in case this intrusion occurs, the potential consequences on 524 the SFC. As mentioned earlier, this section assumes all these 525 actions are performed by an attacker. However, what is designated by 526 an attack may also result from misconfigurations at various layer. A 527 SF or a SFF may become inadvertently configured or programed which 528 may result in similar outcomes as an attack. Whatever result in what 529 we designate as an attack, the purpose of security requirements will 530 be to detect, to analyse and mitigate such security breaches. 532 The traffic within the SFC Data Plane is composed of multiple layers. 533 The traffic is composed of communications between SFC components. 534 The transport between the SFC component is the transport protocol and 535 is not considered in the SFC. It can typically be a L2 transport 536 layer, or an L3 transport layer using various encapsulation 537 techniques (vLAN, VxLAN, GRE, IPsec tunnels for example). Each of 538 these transport layer adds or remove attack vectors. The transport 539 layer carries SFC Encapsulated that are composed of an SFC 540 Encapsulation envelope that carries metadata and a SFC payload that 541 is the actual packet exchanged between the two end points. 543 As a result, attacker may use the traffic to perform attacks at 544 various layers. More specifically, attacks may be performed at the 545 transport layer, the SFC Encapsulation layer or the SFC payload 546 layer. 548 - Attacks performed at the transport layer may be related to SFC 549 in the sense that illegitimate SFC traffic could be provided to 550 the SF. Typically, a malicious node that is not expected to 551 communicate with that SF may inject packets into the SFC, such 552 malicious node may eventually spoof the IP address of 553 legitimate SF, so the receiving SF may not be able to detect 554 the packet is not legitimate. Threats related to IP spoofing 555 are described in [RFC6959] and may be addresses by 556 authenticated traffic (e.g. using IPsec). Such threats are 557 not related to SFC even though they may impact a given SF. 559 - the SFC Encapsulation as well as the SFC payload are usually 560 considered as input by a SF. As such they may represent 561 efficient vector of attacks for the SF. Attacks performed 562 through SFC payload are similar as the ones described in the 563 Tenant's Users Data Plane section. As a result, such attacks 564 are not considered in this section, and this section mostly 565 considers attacks based on the SFC Encapsulation and malicious 566 metadata. 568 When an attacker is within the SFC Data Plane, it may have a full or 569 partial control of one SF component in which case, the attacker is 570 likely to compromise the associated SFCs. It could for example, 571 modify the expected operation of the SFC. Note that in this case, 572 the SFC may be appropriately provisioned and set, however, the SFC 573 does not operate as expected this may only be detected by monitoring 574 and auditing the SFC Data Plane. 576 Although traffic authentication may be performed at various layers L2 577 L3 or at the SFC Encapsulation layer, this section considers the SFC 578 traffic. As a result, the SFC traffic is authenticated if the SF is 579 able to authenticate the incoming SFC packet. 581 When SFC traffic is not authenticated, an attacker may inject spoofed 582 packet in any SFC component. The attacker may use spoofed packet to 583 discover the logic of the SFC. On the other hand, the attacker may 584 also inject packet in order to perform DoS attack via reflection. In 585 fact, as NSH provides the ability to add metadata, some deployment 586 may end up with payloads carrying large metadata. Addition of such 587 overhead presents a vector for amplification within the SFC Data 588 Plane and thus either load the network or the next SF. Note that 589 amplification may be generated by metadata, the SFC payload, and the 590 attacker may replay packets or completely craft new packets. In 591 addition, the attacker may choose a spoofed packet to increase the 592 CPU load on the SFC components. For example, it could insert 593 additional metadata to generate fragmentation. Similarly, it may 594 also insert unnecessary metadata that may need to be decapsulated and 595 analyzed even though they may not be considered for further actions. 596 Spoofed packet may not only be generated to attack the SFC component 597 at the SFC layer. In fact spoofed packet may also target 598 applications of the SF. For example an attacker may also forge 599 packet for HTTP based application - like a L7 firewall - in order to 600 perform a slowloris [SLOWLORIS] like attack. Note that in this case, 601 such attacks are addressed in the Tenant's Users Data Plane section. 602 The specificity here is that the attacker has a more advanced 603 understanding of the processing of the SFC, and can thus be more 604 efficient. 606 When SFC traffic is not authenticated, an attacker may also modify 607 on-path the packet. By changing some metadata contained in the SFC 608 Encapsulation, the attacker may test and discover the logic of the 609 SFF. Similarly, when the attacker is aware of the logic of a SFC 610 component, the attacker may modify some metadata in order to modify 611 the expected operation of the SFC. Such example includes for example 612 redirection to a SF which could result in overloading the SF and 613 overall affect the complete SFC. Similarly, the attacker may also 614 create loops within the SFC. Note that redirection may not occur 615 only in a given SFC. In fact, the attacker may use SFC branching to 616 affect other SFC. Another example would also include a redirection 617 to a node owned by the attacker and which is completely outside the 618 SFC. Motivation for such redirection would be that the attacker has 619 full administrator privileges on that node, whereas it only has 620 limited capabilities on the corrupted node. Such attack is a man-in- 621 the-middle attack. The important thing to note is that in this case 622 the traffic is brought outside the legitimate SFC domain. In fact, 623 performing a man-in-the-middle attack as described above means that 624 the SFC domain has been extended. This can be easily performed in 625 case all node of the data center or the tenant's virtual network is 626 likely to host a SFC component. A similar scenario may also consider 627 that the traffic could be redirected outside the data center or the 628 tenant's virtual network if the routing of firewall rule enables such 629 policies. 631 A direct consequence is that a corrupted SFC component may affect the 632 whole SFC. This also means that the trust of a given SFC decreases 633 with the number of SF involved as each SF presents a surface of 634 attack. 636 An attacker may also perform passive attacks by listening to traffic 637 exchanged throughout the SFC Data Plane. Such attacks are described 638 in [RFC7258]. Metadata are associated to each packet. These 639 metadata are additional pieces of information not carried in the 640 packet and necessary for each SF to operate. As a result, metadata 641 may contain private information such as identifiers or credentials. 642 In addition, observing the traffic may provide information on the 643 tenant's activity. Note that encryption only may not prevent such 644 attacks, as activity may be inferred by the traffic load. 646 6. Security Requirements 648 This section aims at providing environment security requirements. 649 These requirements are derived from the generalization of the threat 650 analysis described in Section 5. More specifically, the threat 651 analysis section was mostly illustrative, and its generalization 652 leads us to the following requirements. 654 Although the security requirements are derived from described 655 threats, the scope of security should be understood in a much broader 656 way than addressing threats. In fact the primary purpose of the 657 security requirements is to ensure the deployment of the SFC 658 architecture can remain robust and stable. 660 The goal of this section is to provide some security requirements 661 that should be checked against any evolution of the deployment of SFC 662 architecture. The requirements should be understood and the risks of 663 not following them should be evaluated with the current deployment as 664 well as the foreseen evolutions. 666 Similarly, the document provides means to evaluate the consequences 667 of a security breach, as well as means to detect them. 669 The motivations for the security requirements are: 671 a) Preventing attacks 673 b) Preventing misconfigurations - as far as stability and security 674 of the SFC architecture is concerned. 676 c) Providing means to evaluate the consequences of a security breach 678 d) Making possible to audit, and detect any misbehavior that may 679 affect stability and security of the SFC. 681 6.1. Plane Isolation Requirements 683 Plane Isolation consists in limiting the surface of attack of the SFC 684 Data Plane by controlling the interfaces between the SFC Data Plane 685 and the other planes. 687 Complete isolation of the planes is not possible, as there are still 688 some communications that must be enabled in order to benefit from the 689 benefits of SFC. Typically the SFC Control Plane configures the SFC 690 elements used by the SFC Data Plane. Similarly, access to the SFC 691 Control Plane may be performed remotely, in which case interaction 692 between the SFC Tenant's User and the SFC Control Plane may be 693 considered. As a result, isolation should be understood as enabling 694 communications between planes in a controlled way. 696 This section lists the recommendations so communication between 697 planes can be controlled. This involves controlling communications 698 between planes as well as controlling communication within a plane. 700 The requirements listed below applies to all planes, whereas the 701 following subsection are more specific to each plane, providing 702 recommendations on the interface with the SFC Data Plane. 704 REQ1: In order to increase isolation every plane that communicates 705 with another plane SHOULD use a dedicated interface. In our 706 case, the SFC Management Plane, the SFC Control Plane and the 707 SFC Data Plane SHOULD use dedicated networks and dedicated 708 interfaces. Isolation of inter-plane communication may be 709 enforced using different ways. How isolation is enforced 710 depends on the type of traffic, the network environment for 711 example, and within a given SFC architecture different 712 techniques may be used for the different planes. One way to 713 isolate communications is to use completely different network 714 on dedicated NICS. On the other hand, depending on the 715 required level of isolation, a logical isolation may be 716 performed using different IP addresses or ports with network 717 logically isolated - that is using for example different 718 VxLAN, or GRE tunnels. In this case, isolation relies on the 719 trust associated to the different switches and router. In 720 case of a lake of trust on the on-path elements, authenticated 721 encryption may be used to provide a logical isolation. With 722 authenticated encryption, trust is placed on the end points. 723 Note also that encryption can also be used in combination of 724 other isolation mechanisms in order to increase the level of 725 isolation. 727 REQ2: Activity between planes SHOULD be monitored and regularly 728 audited. At least operations performed between the planes as 729 well as the source and destination should be logged. When 730 possible the identity of the identities shoudl also be logged. 731 Activity may be performed indepedently by the different planes 732 as well as by different actors such as the SFC Tenants, te 733 infrastructure provider. The level of information available 734 may also differ between planes and actors. 736 REQ3: Traffic and communications between planes SHOULD be filtered 737 traffic or rate-limited. Filtering and rate-limiting policies 738 may be finer grained and may apply for a subset of traffic. 740 The above requirements mostly corresponds to the architecture best 741 current practice. Isolation is mostly motivated to avoid the planes 742 to interact on each other. For example the load on the SFC Data 743 Plane should not affect the SFC Control Plane and SFC Management 744 Plane communications. Such requirements are also current best 745 practices. 747 Such recommendations are thus strongly recommended even in the case 748 the two planes are considered to belong to trusted environments. 750 6.1.1. SFC Control Plane Isolation 752 In order to limit the risks of an attack from the SFC Control Plane, 753 effort should be made in order to restrict the capabilities and the 754 information provided by the SFC Data Plane to the SFC Control Plane 755 to the authorized tenants only. In this case the authorized tenants 756 are the users or organizations responsible for the SFC domain. 758 REQ4: Tenants of the SFC Control Plane SHOULD authenticate in order 759 to prevent tenant's usurpation or communication hijacking. 761 REQ5: Communications between SFC Control Plane and the SFC Data 762 Plane MUST be authenticated and encrypted in order to preserve 763 privacy. The purpose of encryption in this case prevents an 764 attacker to be aware of the action performed by the SFC 765 Control Plane. Such information may be used to orchestrate an 766 attack - especially when SFC component report their CPU/ 767 network load. 769 REQ6: Strong access control policies SHOULD be enforced. Control 770 SHOULD be performed on the engaged resource (e.g. CPU, 771 memory, disk access for example) and SHOULD be associated 772 explicitly to authorized tenants. By default, a tenant SHOULD 773 be denied any access to resource, and access SHOULD be 774 explicit. 776 Given the SFC Control Plane traffic load that is expected to be light 777 - at least compared to the SFC Tenant's Users Data Plane or the SFC 778 Data Plane. As a result, encryption is not expect to impact the 779 performances of the SFC architecture. Given the effort to migrate 780 from an non authenticated (and non protected) communications to a 781 protected communication, we recommend these requirements to be 782 considered even in trusted environments. By protecting these 783 communications by design, the deployed SFC architecture is also ready 784 for future expansion of the Control Plane outside the initial trusted 785 domain. This coudl typically includes the evoluation to multiple 786 tenants as well as the inclusion of tenants that remotely access the 787 SFC Control Plane. 789 Access Control policies can be enforced in various ways. One way 790 could be to consider the systems of the SF to limit the resources 791 associated to each tenants. Other ways include the use of API in 792 order to limit the scope of possible interactions between the SFC 793 Control Plane and the SFC Data Plane. This is one way to limit the 794 possibilities of the tenants. In addition, each of these actions 795 should be associated an authorized tenant, as well as authorized 796 parameters. The use of API belongs to best practices and so is 797 strongly recommended even in trusted environments. 799 REQ7: Audit SHOULD be performed regularly to check access control 800 policies are still up-to-date and prevent non-authorized users 801 to control the SFC Data Plane. 803 The purpose of audits is to provide evidences when something went 804 wrong. As a result, audit facilities are expected to be provided 805 even in trusted environments. 807 6.1.2. SFC Management Plane Isolation 809 The requirements for the SFC Control Plane and SFC Management Plane 810 are similar. The main difference of the interfaces between the SFC 811 Management Plane and the SFC Control Plane is that it is less likely 812 that APIs could be used to configure the different SFC components. 814 As a result, users of the SFC Management Plane are likely to have a 815 broader and wider control over the SFC component. 817 REQ8: it is RECOMMENDED to enforce stronger authentication 818 mechanisms (for example relying on hardware tokens or keys) 819 and to limit the scope of administrative roles on a per 820 component basis. 822 REQ9: SFC Control Plane and SFC Management Plane may present some 823 overlap. Each SFC component MUST have clear policies in case 824 these two planes enter in conflict. 826 6.1.3. Tenant's Users Data Plane Isolation 828 The Tenant's Users Data Plane is supposed to have less restricted 829 access control than the other SFC Management Plane and SFC Control 830 Planes. A typical use case could be that each tenant are controlling 831 and managing the SFC in order to provide services to their associated 832 users. The number of users interacting with the SFC Data Plane is 833 expected to be larger than the number of tenants interacting with the 834 SFC Control and SFC Management Planes. In addition, the scope of 835 communications initiated or terminating at the user end points is 836 likely to be unlimited compared to the scope of communications 837 between the tenants and the SFC Control Plane or SFC Management 838 Plane. In such cases, the tenant may be provided two roles. One to 839 grant access to the SFC, and another one to control and manage the 840 SFC. These two roles should be able to interact and communicate. 842 REQ10: Users SHOULD be authenticated, and only being granted access 843 to the SFC if authorized. Authorization may be provided by 844 the SFC itself or outside the SFC. 846 REQ11: Filtering policies SHOULD prevent access to a user, or traffic 847 when a malicious behavior is noticed. A malicious activity 848 may be noticed once a given behavioral pattern is detected or 849 when unexpected load is monitored in the SFC Data Plane. 851 REQ12: Tenant's User Plane SHOULD be monitored, in order to detect 852 malicious behaviors. 854 REQ13: When SFC is used by multiple tenants, each tenant's traffic 855 SHOULD be isolated based on authenticated information. More 856 specifically, the use of a Classifier that can easily be 857 spoofed like an IP address SHOULD NOT be used. 859 REQ14: It is RECOMMENDED that user's access authorization be 860 performed outside the SFC. In fact granting access and 861 treating the traffic are two different functions, and we 862 RECOMMEND they remain separated. Then, splitting these two 863 functions makes it possible for a tester to perform tests of 864 an potential attacker, without any contextual information. 865 More specifically, having a traffic identified as associated 866 to test by the SFC reduces the scope of the tests simply 867 because an attacker will not be considered as a tester. For 868 that reason, we RECOMMEND authorization is performed outside 869 the SFC, and SFC deployment may not be designed to 870 authenticate end users. 872 The remaining requirements are associated to monitoring the network 873 and providing interactions between the access and the SFC. This 874 interaction may be provided outside SFC itself. 876 6.2. SFC Data Plane Requirements 878 This section provides requirements and recommendation for the SFC 879 Data Plane. 881 REQ15: Communications within the SFC Data Plane SHOULD be 882 authenticated in order to prevent the traffic to be modified 883 or injected by an attacker. As a result, authentication 884 includes the SFC Encapsulation as well as the SFC payload. 886 REQ16: Communication MUST NOT reveal privacy sensitive metadata. 888 REQ17: The metadata provided in the communication MUST be limited in 889 in term of volume as to limit the amplification factor as well 890 as fragmentation. 892 REQ18: Metadata SHOULD NOT be considered by the SFF for forwarding 893 decision. In fact, the inputs considered for switching the 894 packet to the next SFF or a SF should involve a minimum 895 processing operation to be read. More specifically, these 896 inputs are expected fixed length value fields in the SFC 897 Encapsulation header rather than any TLV format. 899 REQ19: When multiple tenants share a given infrastructure, the 900 traffic associated to each tenant MUST be authenticated and 901 respective Tenant's Users Planes MUST remain isolated. More 902 specifically, if for example, a SFC Classifier is shared 903 between multiple tenants. The Classifier used to associate 904 the SFC MUST be authenticated. This is to limit the use of 905 spoofed Classifiers. In any case, the SFC component that 906 receives traffic from multiple tenants is assumed to be 907 trusted. 909 REQ20: Being a member of a SFC domain SHOULD be explicitly mentioned 910 by the node and means should be provided so the SFC domain the 911 node belongs to may be checked. Such requirement intends to 912 prevent a packet to go outside a SFC domain, for example in 913 the case of a man-in-the-middle attacks, where a redirection 914 occurs outside the SFC domain. It is expected that most 915 deployment will rely on border / port mechanisms that prevent 916 outsider users from injecting packets with spoofed metadata. 917 Although such mechanisms are strongly recommended to deploy, 918 in case of failure, they do not prevent man-in-the-middle 919 attack outside the SFC domain. 921 Authentication of the traffic within the SFC Data Plane is 922 particularly recommended in an open environment where third party SF 923 or SFF are involved. It can also be recommended when a strong 924 isolation of the traffic is crucial for the infrastructure or to meet 925 some level of certification. In addition, authentication may also be 926 performed using various techniques. The whole packet may be 927 authenticated or limited to some parts (like the flow ID). 928 Authenticating the traffic and how or what to authenticate is a trade 929 off between the risk associated and the cost of encryption. When 930 possible we recommend to authenticate, but we also consider that the 931 price may be too high in controlled and small trusted environment. 933 Metadata is an important part of the SFC architecture, and their 934 impact on security should be closely evaluated. It is the 935 responsibility of the SFC administrator to evaluate the privacy 936 associated by the metadata - section 5.2.2 of [RFC6973] - and 937 according to this evaluation to consider appropriated mechanisms to 938 prevent the privacy leakage. Mechanisms should be provided even 939 though they may not be activated. 941 As a general guidance exposing privacy sensitive metadata in any 942 communications between two any SFC component should be avoided. [One 943 way, for example to avoid exposing privacy sensitive metadata is to 944 include a reference to the metadata instead of the metadata itself. 945 Another way could be to encrypt the metadata itself - but that is 946 part of the solution space.] Applying this principle prevents any 947 private oriented data to be leaked. This requirement is mandatory 948 when the SFC is not deployed in a trusted environment. 950 When exposition of the privacy sensitive metadata cannot be avoided 951 and you are in a trusted domain, then exposing privacy sensitive 952 metadata may be considered as long as they do not leak outside the 953 boundaries of the trusted environment. In this case, the security is 954 delegated to the security policies of the trusted environment 955 boundaries, that may be outside the scope of SFC. More especially, 956 the security policies may be for example enforced by a firewall. In 957 this specific case, the trusted environment MUST prevent leakage of 958 the metadata out of the trusted environment and MUST ensure that 959 untrusted node cannot access in any way the communications within the 960 trusted environment. 962 The reason this requirement is set to MUST is to specify that if one 963 does not follow the requirement it is at its your own risk and must 964 provide the necessary means to prevent any leak - in our case 965 enforcing the necessary security policies that your environment / 966 deployment needs. 968 Similarly, it is the responsibility of the administrator to define 969 what an acceptable size for metadata is. Even in trusted 970 environment, we recommend the SFC administrator be able to define and 971 change this level. 973 Processing metadata by the SFF seems also expensive, and it is the 974 responsibility of the SFC administrator to evaluate whether 975 processing metadata by the SFF may impact the SFC architecture. In 976 addition, metadata are expected to be associated to SF as opposed to 977 the forwarding information that are associated to the SFF. These 978 inputs have different functions, are associated to different 979 processing rules, and may be administrated by different parties. It 980 is thus part of the general good practise to split these 981 functionalities. Optimization may require to combine the analysis of 982 metadata and forwarding information, but this should be handled 983 cautiously. 985 Assertion of belonging to a security domain, is especially 986 recommended in open environments. This may also partly be addressed 987 by node authenticating. 989 In addition, the following operational requirements have been 990 identified: 992 REQ21: SFC components SHOULD be uniquely identified and have their 993 own cryptographic material. In other words the use of a 994 shared secret for all nodes SHOULD NOT be considered as one 995 corrupted node would be able to impersonate any node of the 996 SFC Data Plane. This is especially useful for audit. 998 REQ22: Activity in the SFC Data Plane MUST be monitored and audited 999 regularly. Audit and log analysis is especially useful to 1000 check that SFC architecture assessments. They can be useful 1001 to detect a security breach for example before it is being 1002 discovered and exploited by a malicious user. Monitoring the 1003 system is also complementary in order to provide alarms when a 1004 suspicious activity is detected. Monitoring enables the 1005 system to react to unexpected behaviors in a dynamic way. 1006 Both activities are complementary as monitoring enables to 1007 counter suspicious behavior and audit may detect 1008 misconfiguration or deep causes of a malicious behavior. For 1009 these reasons, audit and monitoring facilities are expected 1010 even in trusted environment. 1012 REQ23: Isolate the Plane with border and firewall to restrict access 1013 of SFC components to legitimate traffic. More specifically, 1014 SFC components are supposed to be accessed only via dedicated 1015 interfaces. Outside these interfaces, inbound or outbound 1016 traffic SHOULD be rejected. 1018 6.3. Additional Requirements 1020 REQ24: SFC Encapsulation SHOULD carry some identification so it can 1021 be associated to the appropriated SFP as well as its position 1022 within the SFC or SFP. Indicating the SFP ID may be 1023 sufficient as long as a SFP can uniquely be associated to a 1024 single SFC. Otherwise, the SFC should be also somehow 1025 indicated. This is especially useful for audit and to avoid 1026 traffic coming from one SFC to mix with another SFC. 1027 Authentication of the SFP ID is one way to enforce SFP ID 1028 uniqueness. This may not be mandatory, but large deployment 1029 or deployment that are involving multiple parties are expected 1030 enforce this. In fact assuming SFP ID will have no collision 1031 is an hypothesis that may be hard to fulfill over time. 1033 REQ25: Although this requirement is implementation specific, it is 1034 RECOMMENDED that SFF and SF keep separate roles. SFF should 1035 be focused on SF forwarding. As a result, they are expected 1036 to access a limited information from the packet - mostly fixed 1037 size information. SF on the other hand are service oriented, 1038 and are likely to access all SFC information which includes 1039 metadata for example. The reasons to keep these functions are 1040 clearly different and may involve different entities. For 1041 example, SF management or SF configuration may involve 1042 different administrators as those orchestrating the SFC. 1044 REQ26: SFC Encapsulation SHOULD be integrity protected to prevent 1045 attackers from modifying the SFP ID. See Data Plane 1046 communication Requirements and considerations) 1048 7. Security Considerations 1049 8. Privacy Considerations 1051 9. IANA Considerations 1053 10. Acknowledgments 1055 The authors would like to thank Joel Halpern, Mohamed Boucadair and 1056 Linda Dunbar for their valuable comments. Similarly the authors 1057 would also like to thank Martin Stiemerling for its careful review as 1058 well as its recommendations. 1060 11. References 1062 11.1. Normative References 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, 1066 DOI 10.17487/RFC2119, March 1997, 1067 . 1069 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1070 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1071 . 1073 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 1074 Validation Improvement (SAVI) Threat Scope", RFC 6959, 1075 DOI 10.17487/RFC6959, May 2013, 1076 . 1078 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1079 Morris, J., Hansen, M., and R. Smith, "Privacy 1080 Considerations for Internet Protocols", RFC 6973, 1081 DOI 10.17487/RFC6973, July 2013, 1082 . 1084 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1085 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1086 2014, . 1088 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1089 Service Function Chaining", RFC 7498, 1090 DOI 10.17487/RFC7498, April 2015, 1091 . 1093 11.2. Informative References 1095 [I-D.ietf-sfc-nsh] 1096 Quinn, P. and U. Elzur, "Network Service Header", draft- 1097 ietf-sfc-nsh-01 (work in progress), July 2015. 1099 [I-D.ietf-sfc-architecture] 1100 Halpern, J. and C. Pignataro, "Service Function Chaining 1101 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 1102 in progress), July 2015. 1104 [I-D.ietf-sfc-control-plane] 1105 Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., 1106 Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A., 1107 Halpern, J., Reddy, T., and P. Patil, "Service Function 1108 Chaining (SFC) Control Plane Components & Requirements", 1109 draft-ietf-sfc-control-plane-00 (work in progress), August 1110 2015. 1112 [SLOWLORIS] 1113 Wikipedia, "Slowloris", . 1116 Authors' Addresses 1118 Daniel Migault (editor) 1119 Ericsson 1120 8400 boulevard Decarie 1121 Montreal, QC H4P 2N2 1122 Canada 1124 Phone: +1 514-452-2160 1125 Email: daniel.migault@ericsson.com 1127 Carlos Pignataro 1128 Cisco Systems, Inc. 1129 7200-12 Kit Creek Road 1130 Research Triangle Park, NC 27709 1131 USA 1133 Phone: +1 919-392-7428 1134 Email: cpignata@cisco.com 1135 Tirumaleswar Reddy 1136 Cisco Systems, Inc. 1137 Cessna Business Park, Varthur Hobli 1138 Bangalore, Karnataka 560103 1139 India 1141 Phone: +91 9886 1142 Email: tireddy@cisco.com 1144 Christopher Inacio 1145 CERT, Software Engineering Institute, Carnegie Mellon University 1146 4500 5th Ave 1147 Pittsburgh, PA 15213 1148 USA 1150 Phone: +1 412-268-3098 1151 Email: inacio@cert.org