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