idnits 2.17.1 draft-vu-sfc-sf-access-control-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2489 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-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining Vu Anh Vu 3 Internet-Draft Younghan Kim 4 Intended status: Informational Kyoungjae Sun 5 Expires: January 4, 2018 Van-Ca Nguyen 6 Soongsil University 7 July 3, 2017 9 Controlling Service Function Access to Network Service Header 10 draft-vu-sfc-sf-access-control-02 12 Abstract 14 This document describes a mechanism to control Service Function 15 access to the Network Service Header (NSH). It addresses the Service 16 Function trust issue and provide a method to enforce predefined 17 access control lists to limit Service Function access to Service 18 Function Chain information in the NSH in NSH-based Service Chaining. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 57 1.3. Definition Of Terms . . . . . . . . . . . . . . . . . . . 3 58 2. SF Access Control List . . . . . . . . . . . . . . . . . . . 4 59 3. Access Control Enforcing Mechanisms . . . . . . . . . . . . . 4 60 4. Consideration for NSH Concealment . . . . . . . . . . . . . . 7 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 1.1. Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 1.2. Problem Statement 77 SFC Architecture document [RFC7665] defines architectural concepts 78 and core components, including Service Functions (SFs), Service 79 Function Forwarder (SFF), Classifier (CF), SFC Proxy. These 80 terminologies will be used in this documents. 82 It is argued that whether or not we should trust the SFs in SFC. In 83 SFC general use cases, SFs vary from virtual services hosted in 84 general-purpose servers to legacy service functions with dedicated 85 hardware. Most of the time, these SFs are deployed and operated by 86 their service provider. Therefore they are highly trusted. Despite 87 being in private and relatively safe service provider networks, SFs 88 are not invulnerable to all security threats. Indeed, several 89 reasons cause the misbehavior of SFs. For instance, they can still 90 be manipulated by multiple types of malware. Furthermore, 91 malfunctioned and misconfigured SFs can have anomaly behaviors as 92 well. 94 Aside from their own SFs, service providers may use SFs from other 95 sources such as third party service providers (in case they want to 96 outsource their SFs), SFs on customer premise, and legacy black-box 97 SFs. In addition, enterprises are also trying to outsource their SFs 98 to service providers, while still manage the SFC by themselves. 99 Although service providers always have some SLAs for each SF, these 100 SFs need to be verified and security checked frequently. 102 Even if the SFs are trusted and secured, we still need to concern 103 about the security of transportation layer. Traffic between SFs and 104 forwarding components (SFF, Classifier, SFC proxy) can be harmed by 105 other threats such as man-in-the-middle attacks and spoofing, 106 especially in geographically distributed data centers. 108 As described in [I-D.ietf-sfc-nsh], NSH can be used to encapsulate 109 SFC information to the packets in NSH-based Service Chaining. There 110 have been considerations about the security of this encapsulation. 111 Problem Statement for Service Function Chaining [RFC7498] and SFC 112 Architecture document [RFC7665] express concerns about SFC 113 Encapsulation Security, which emphasize the importance of securing 114 sensitive metadata carried by the encapsulation and state the 115 requirement of an "appropriate protective treatment of NSH 116 information". Specifically, the NSH document [I-D.ietf-sfc-nsh] 117 suggests some options (e.g. IP Sec) to provide NSH metadata 118 authenticity and confidentiality, most of them involve NSH 119 encryption. 121 As described in [I-D.ietf-sfc-control-plane], control-plane store 122 and manage the access policies for SFs. Classifiers follow the 123 policies to push/pop NSH for packets. 125 [I-D.mglt-sfc-security-environment-req] lists requirements for SFC 126 security, including data plane requirements, which emphasize the need 127 of preventing the privacy leakage in SFC metadata. The document also 128 recommends some solutions such as metadata encryption and replacing 129 metadata by its reference, which is our method in this document. 131 Certainly, NSH encryption can provide rather strong security for the 132 SFC metadata in an SFC-enabled domain, but it is also costly. Both 133 header encryption and key distribution require lots of resources and 134 probably cause performance penalties to the SFC. In this document, 135 we describe an inexpensive mechanism to protect the sensitive 136 metadata in NSH from either corrupted SFs or underlay networks 137 security threats in NSH-based Service Chaining. 139 1.3. Definition Of Terms 141 o Access-Controlled Segment (ACS): an ACS is an area/field within 142 NSH that carries a piece of sensitive SFC information needed to be 143 protected. The access to this information from SFs should be 144 limited and be controlled. 146 o SF Access Control List (SF ACL): a list describes the access 147 permission of an SF to each ACS in the packet passing through it. 148 Each SF should have an SF ACL. 150 o Ingress Subsequent Classifier (Ingress S-CF): a logical classifier 151 located BEFORE an access-controlled SF. S-CFs are responsible for 152 classify packets going into the SF and update their NSH. 154 o Egress Subsequent Classifier (Egress S-CF): a logical classifier 155 located AFTER an access-controlled SF. S-CFs are responsible for 156 classify packets going out of the SF and update their NSH. 158 o NSH-state: a set of value/information stored in the NSH of a 159 packet at a particular moment. For example, the value of Service 160 Index, Service Path Index, Mandatory Context Header 1-4. An NSH- 161 state usually consists of some ACS values. 163 2. SF Access Control List 165 Currently, without packet encryption, all SFs have full access to the 166 packets they process and, in particular, the SFC information. 167 Consequently, an SF can read and modify any unencrypted information 168 within the NSH during its packet handling process. Depend on what 169 metadata stored in NSH, a corrupted SF can manipulate a part of 170 information for harmful purposes such as changing service path, SF 171 spoofing, gathering tenant information. 173 In most situations, a SF might not need to know all SFC 174 information to process its incoming packets. An Access Control List 175 (ACL) of an SF contains access permissions of the SF to each ACS in 176 the NSH, including NSH base header, Service Path Index (SPI), 177 Service Index (SI),and Metadata (MD). For MD type 1, each of the 4 178 Mandatory Context Header(MCH) can become an ACS. MD type 2 has 179 variable length MCH, therefore SF ACL should be defined according 180 to the MD structure. Wepropose three levels of permission to 181 access an ACS of NSH: 183 o Hidden: the SF cannot view the information in this ACS 185 o Read-only: the SF can view, but cannot modify the information in 186 this ACS 188 o Full access: the SF can view and modify the information in this 189 ACS 191 3. Access Control Enforcing Mechanisms 193 In this section, we propose a mechanism to enforce SF ACLs in SFC. 194 The mechanism has two principles: 196 1. Only give SFs what information they need to access. 198 2. SFFs cannot control SFs not to modify SFC information, but they 199 can choose not to accept the modification. 201 Figure 1 shows the components involved in the mechanism. 202 Occasionally, an SF is attached to an SFF. However, according [I- 203 D.ietf-sfc-nsh], SFFs CANNOT perform NSH updating, which is the 204 essential requirement of this mechanism. Therefore, Ingress/Egress 205 S-CFs are added and coordinate with SFF to classify packets and 206 update NSH. 208 When a packet come to an SFF on its way to the next SF in the SFP, 209 the SFF will forward it to the ingress S-CF corresponds to the SF. 210 Next, the ingress S-CF will check the SF ACL to get the SF permission 211 to each ACS. If the SF has Hidden permission to an ACS, the data 212 contained in that ACS will be stored by the S-CF and erased from the 213 packet (i.e. set all byte to zero). As a result, sensitive 214 information will be obscured from the SF, hence reduce the 215 possibility of leaking information. Besides, the ingress S-CF does 216 not store only the erased ACS but also the ACSes that the SF has 217 read-only permission for later use. 219 After processing the packet, the SF forwards it back to an egress 220 S-CF, which could be the same one as the aforementioned ingress S-CF. 221 This S-CF checks the SF ACL and 1) With Hidden ACS, it gets the 222 stored NSH-state (consists of ACS values) from the ingress S-CF and 223 put it back to the packet, 2) With read-only ACS, it also gets the 224 value from the NSH-state stored in the ingress S-CF and compares to 225 the current value. If the value is changed, the SF has tried to 226 modify the ACS and egress S-CF would recover the ACS from the NSH- 227 state stored by ingress S-CF. Using this method, we can preserve the 228 original SFC information, as well as detect abnormal SF behaviors. 230 +----------------------------+ 231 | | 232 +----+ Control Plane +----+ 233 | | | | 234 | +-+------------------------+-+ | 235 | | | | 236 | | | | 237 | | | | 238 | | | | 239 | | | | 240 v | | | 241 +---------+ +---+---+ | | +---v---+ 242 | | | | | | | | 243 | Initial | ... | SFF | | | | SFF | ... 244 | CF | | | | | | | 245 +---------+ +---+---+ | | +---+---+ 246 | | | ^ 247 | v v | 248 | +----+----+ +------+ +----+----+ | 249 | | | | | | | | 250 +-> Ingress +---> SF +---> Egress +-+ 251 | S-CF | | | | S-CF | 252 +---------+ +------+ +---------+ 254 Figure 1: Controlling SFs access to NSH in SFC architecture 256 In this mechanism, the ingress and egress S-CF must exchange stored 257 ACS data in either way: 259 o Shared storage 261 o Send the data to the SFC control plane 263 Another key point of this mechanism is the method to track packets 264 between ingress and egress S-CFs to recover the appropriate NSH 265 metadata. In detail, a packet encapsulation (including NSH) and 266 payload might be changed after it traverses the SF between ingress 267 and egress S-CFs. The egress S-CF must know which NSH-state saved by 268 the ingress SFF corresponds with a packet it receives. Current 269 solutions for this include: 271 o Reclassification: The packet will be classified (i.e. Using 272 5-tuple) after it exits the SF and goes to the egress S-CF. The 273 appropriate NSH will be determined based on the classification 274 result. Nevertheless, this approach cannot work with SFs which 275 change 5-tuple (such as NAT) 277 o Using Metadata: In this approach, the ingress S-CF put a unique ID 278 named NSH-state ID into the NSH metadata of the packets. The 279 egress S-CF get the ID from a packet and use it to determine the 280 packet's original NSH-state. Figure 2 presents an example of NSH 281 having Metadata type 1 with NSH-state ID. Also, NSH-state ID can 282 be defined per-flow or per-packet. Nevertheless, the disadvantage 283 is that we have to reserve a part of Metadata, which also can be 284 access by SFs, for NSH-state ID. 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Service Path Identifier | Service Index | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | NSH-State ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Mandatory Context Header | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Mandatory Context Header | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Mandatory Context Header | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 2: NSH-state ID in NSH Metadata type 1 303 This mechanism guarantees the consistency of sensitive SFC data 304 within NSH when packets travel from an ingress SFF to an egress SFF 305 through an SF, which means it can eliminate potential threats from 306 the SF as well as the transportation networks between SFs and SFFs. 308 4. Consideration for NSH Concealment 310 In the previous section, we describe a mechanism to obscure ACS in 311 NSH from SFs. However, it is not limited to controlling the access 312 to NSH of only SFs but other components as well. Indeed, the 313 mechanism can be extended to conceal ACS between two any points on 314 the service function path of a packet. In other words, an ingress 315 and an egress SFFs can be any SFF on the SFP, not just the SFF which 316 is directly attached to an SF. 318 Moreover, the mechanism can be used to perform simple and low-cost 319 NSH encryptions. For example, the ingress SFF will save an ACS value 320 and replace it with another value. The mapping table which maps 321 those two values will be given to the egress SFF and the all 322 authorized SFs. 324 5. Acknowledgements 326 TBD 328 6. IANA Considerations 330 This document does not require any IANA actions. 332 7. Security Considerations 334 Secure communications between SFC control plane and components is 335 required, as described in [I-D.ietf-sfc-control-plane], in order to 336 secure access control policies during policy propagation from the 337 control plane to enforcing components (such as SFFs and classifiers). 339 Furthermore, if the NSH state table of an ingress S-CF is leaked, the 340 controlling mechanism can be easily bypassed by spoofing. Therefore, 341 NSH state exchange process, which is either between CF-control plane 342 or CF-CF, should be secured as well. 344 8. Normative References 346 [I-D.ietf-sfc-control-plane] 347 Boucadair, M., "Service Function Chaining (SFC) Control 348 Plane Components & Requirements", draft-ietf-sfc-control- 349 plane-08 (work in progress), October 2016. 351 [I-D.ietf-sfc-nsh] 352 Quinn, P. and U. Elzur, "Network Service Header", draft- 353 ietf-sfc-nsh-13 (work in progress), June 2017. 355 [I-D.mglt-sfc-security-environment-req] 356 Migault, D., Pignataro, C., Reddy, T., and C. Inacio, "SFC 357 environment Security requirements", draft-mglt-sfc- 358 security-environment-req-02 (work in progress), October 359 2016. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 367 Service Function Chaining", RFC 7498, 368 DOI 10.17487/RFC7498, April 2015, 369 . 371 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 372 Chaining (SFC) Architecture", RFC 7665, 373 DOI 10.17487/RFC7665, October 2015, 374 . 376 Authors' Addresses 378 Vu Anh Vu 379 Soongsil University 380 369 Sangdo-ro 381 Dongjak-gu, Seoul 06978 382 South Korea 384 Email: vuva@dcn.ssu.ac.kr 386 Younghan Kim 387 Soongsil University 388 369 Sangdo-ro 389 Dongjak-gu, Seoul 06978 390 South Korea 392 Email: younghak@ssu.ac.kr 394 Kyoungjae Sun 395 Soongsil University 396 369 Sangdo-ro 397 Dongjak-gu, Seoul 06978 398 South Korea 400 Email: gomjae@ssu.ac.kr 402 Van-Ca Nguyen 403 Soongsil University 404 369 Sangdo-ro 405 Dongjak-gu, Seoul 06978 406 South Korea 408 Email: canguyen@dcn.ssu.ac.kr