idnits 2.17.1 draft-wang-sfc-nsh-ns-allocation-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-sfc-nsh], [I-D.wang-sfc-ns-use-cases]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Session SHOULD be bi-directional so that both directions of Service Paths are associated with the same Service Function instance. Service Path reclassification for the same session MUST not change the Session ID. -- The document date (June 28, 2017) is 2493 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-12 == Outdated reference: A later version (-03) exists of draft-wang-sfc-ns-use-cases-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining E. Wang 3 Internet-Draft K. Leung 4 Intended status: Informational A. Ossipov 5 Expires: December 30, 2017 Cisco Systems Inc. 6 June 28, 2017 8 Network Service Header (NSH) Context Header Allocation (Network 9 Security) 10 draft-wang-sfc-nsh-ns-allocation-03 12 Abstract 14 This document provides a recommended default allocation of the 15 mandatory fixed context headers for a Network Service Header (NSH) 16 relevant to Service Function Chaining (SFC) for network security 17 Service Functions. NSH is defined in [I-D.ietf-sfc-nsh]. This 18 allocation is intended to support the use cased described in 19 [I-D.wang-sfc-ns-use-cases]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 30, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 57 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 2 58 3. Network Service Header (NSH) Context Headers . . . . . . . . 3 59 4. Recommended Security Mandatory Context Allocation . . . . . . 3 60 4.1. Network Security Allocation Specifics . . . . . . . . . . 4 61 5. Context Allocation and Control Plane Considerations . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 9.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Service Function Chaining (SFC) provides a mechanism for network 73 traffic to go through a set of Service Functions in sequence. 74 Network Service Header (NSH) allows metadata to be shared between 75 Service Functions along with the packets. Such metadata is carried 76 by either a fixed number of 32-bit context headers (MD-Type 1) or a 77 variable number of TLVs (MD-Type 2), as defined in NSH 78 [I-D.ietf-sfc-nsh]. This document provides a recommended default 79 allocation of the fixed size context headers for network security 80 Service Functions forming a Service Function Chain. The allocation 81 may also form a MD-Type 2 metadata TLV. Supporting use cases for a 82 metadata definition in this context are described in SFC-NS-Use-Cases 83 [I-D.wang-sfc-ns-use-cases] . This document does not define any other 84 variable TLVs. It does not address the control plane mechanisms. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Definition Of Terms 94 This document uses the terms as defined in RFC 7498 [RFC7498], 95 [RFC7665] and [I-D.ietf-sfc-nsh]. 97 3. Network Service Header (NSH) Context Headers 99 NSH MD-Type 1 is composed of three parts as described in 100 [I-D.ietf-sfc-nsh]: a 4-byte base header, a 4-byte service path 101 header, and four 4-byte mandatory context headers. 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |Ver|O|C|R|R|R|R|R|R| Length | MD-Type = 1 | Next Protocol | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Service Path ID | Service Index | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Mandatory Context Header | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Mandatory Context Header | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Mandatory Context Header | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Mandatory Context Header | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: Network Service Header - MD-Type 1 120 4. Recommended Security Mandatory Context Allocation 122 The following context header allocation provides information used to 123 support SFC operation within a generic network security environment. 124 The 16-byte context headers are used to deliver metadata and 125 classification results between security Service Functions. Service 126 Functions may use the metadata for local policy enforcement, security 127 actions, classification refinement, and other functionality. 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Session ID | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |D|P| Application Session ID | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Destination Class / Reserved | Source Class | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |B|U|T|D| Rsvd | Tenant ID | Dst Score | Src Score | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 2: NSH Security Context Allocation 142 4.1. Network Security Allocation Specifics 144 The specific 16-byte allocation of the mandatory context headers is 145 as follows: 147 Session ID: Session ID is used to identify a particular 148 connection, transaction, or any unit that the security Service 149 Functions use to maintain states. Session ID may be used to 150 associate a packet with existing states even if the packet does 151 not contain all the network headers for deriving the Session ID, 152 or if the network headers are modified by a Service Function. It 153 may appear in events and logs for correlation between Service 154 Functions in the SFC-domain. 156 The Session SHOULD be bi-directional so that both directions of 157 Service Paths are associated with the same Service Function 158 instance. Service Path reclassification for the same session MUST 159 not change the Session ID. 161 Flag bits of the 2nd word: 163 D bit: The D-bit is used to indicate whether the Destination 164 Class field in the 3rd word is used. If D-bit is not set then 165 the 3rd word is reserved. 167 P bit: The P-bit is set to 1 if the session indicated by 168 Session ID is classified as a parent connection among all 169 sessions under the particular application session ID. Examples 170 of parent connection are FTP control connection and SIP 171 signaling connection. 173 Application Session ID: Application Session ID is unique for every 174 set of sessions that belong to the same application session. For 175 example, there could be four HTTP connections (session IDs 0x1, 176 0x2, 0x3, and 0x4) and two application sessions (0xA and 0xB) of 177 type "App-X". Sessions 0x1 and 0x2 correspond to application 178 session 0xA, and Sessions 0x3 and 0x4 correspond to session 0xB. 179 Application Session ID helps Service Functions handle related 180 sessions in a holistic manner for operations such as inspection, 181 security analysis and QoS. 183 Destination Class: The destination class represents the logical 184 classification of the destination of the traffic. This field is 185 optional and/or the Destination Class may not be known. The D-bit 186 is used to indicate that this field contains a valid Destination 187 Class. 189 Source Class: represents the logical classification of the source 190 of the traffic. For example, this might represent a source 191 application, a group of like endpoints, or a set of users 192 originating the traffic. Class may also be a compound 193 classification, for example, combination of network zone and group 194 of users. This grouping is done for the purposes of applying 195 policy. Policy is applied to groups rather than individual 196 endpoints. 198 Offload Control Flags: The 4th word contains flags to control the 199 desired behavior of SFC offload. The definitions of these flags 200 B, U, T & D are described in [I-D.kumar-sfc-offloads] 202 Tenant ID: The tenant identifier is used to represent the tenant 203 or security policy domain that the Service Function Chain is being 204 applied to. The Tenant ID is a unique value assigned by a control 205 plane. 207 The 4th word also contains security classification results for 208 communicating immediate actions and accumulated verdicts to 209 downstream Service Functions. 211 Score: Security Score is a numeric value for participating Service 212 Functions to deliver security classification results based on 213 their processing of the packet data. The Score value may be set 214 by one Service Function and refined by a subsequent Service 215 Function to produce an accumulated result. Alternatively, each 216 Service Function may set a different score value which is 217 collected by a control point. The Score value is interpreted 218 consistently in the SFC-domain. For example, a Score value of -5 219 may trigger additional scanning functions to be conducted by the 220 subsequent Service Function for the Session. As another example, 221 a Score value -20 may result in block of the source or destination 222 host by a Service Function. The interpretation of the Score is 223 distributed by a control plane and is outside the scope of the 224 document. 226 5. Context Allocation and Control Plane Considerations 228 This document describes an allocation scheme for the NSH context 229 headers in the context of network security SFC use cases. 231 The suggested allocation in this document would be considered as a 232 guideline only. Some of the allocated fields are specific to certain 233 use cases. A control plane mechanism is required to ensure 234 consistency among the SFC components participating in the allocation 235 scheme. The actual control plane mechanism is out of the scope of 236 this document. 238 6. Security Considerations 240 The SFC control plane responsible for identifying and distributing 241 the allocation scheme should ensure the communication mechanism is 242 secure. 244 The metadata defined in this document carries important information 245 for participating Service Functions to make security policy 246 decisions. Some of the metadata such as the security score may be 247 accumulated before a Service Function takes an action. There is a 248 risk that the metadata may be intercepted or even spoofed by an 249 unauthorized party. Proper precaution must be taken to ensure the 250 confidentiality and integrity of the metadata fields. 252 7. Acknowledgments 254 Authors would like to thank Jeremy Felix and Jay Iyer for their 255 contributions. 257 8. IANA Considerations 259 This document includes no request to IANA. 261 9. References 263 9.1. Normative References 265 [I-D.ietf-sfc-nsh] 266 Quinn, P. and U. Elzur, "Network Service Header", draft- 267 ietf-sfc-nsh-12 (work in progress), February 2017. 269 [I-D.kumar-sfc-offloads] 270 Surendra, S., Guichard, J., Quinn, P., Halpern, J., and S. 271 Majee, "Service Function Simple Offloads", draft-kumar- 272 sfc-offloads-03 (work in progress), October 2016. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 280 Service Function Chaining", RFC 7498, 281 DOI 10.17487/RFC7498, April 2015, 282 . 284 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 285 Chaining (SFC) Architecture", RFC 7665, 286 DOI 10.17487/RFC7665, October 2015, 287 . 289 9.2. Informative References 291 [I-D.wang-sfc-ns-use-cases] 292 Wang, E., Leung, K., Felix, J., and J. Iyer, "Service 293 Function Chaining Use Cases for Network Security", draft- 294 wang-sfc-ns-use-cases-02 (work in progress), October 2016. 296 Authors' Addresses 298 Eric Wang 299 Cisco Systems Inc. 300 170 W Tasman Dr 301 San Jose, CA 95134 302 U.S.A. 304 Email: ejwang@cisco.com 306 Kent Leung 307 Cisco Systems Inc. 308 170 W Tasman Dr 309 San Jose, CA 95134 310 U.S.A. 312 Email: kleung@cisco.com 314 Andrew Ossipov 315 Cisco Systems Inc. 316 170 W Tasman Dr 317 San Jose, CA 95134 318 U.S.A. 320 Email: aossipov@cisco.com