idnits 2.17.1 draft-reddy-sfc-nsh-security-req-00.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 (January 21, 2016) is 3017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Working Group T. Reddy 3 Internet-Draft Cisco 4 Intended status: Informational D. Migault 5 Expires: July 24, 2016 Ericsson 6 C. Pignataro 7 P. Quinn 8 Cisco 9 C. Inacio 10 CERT/SEI/CMU 11 January 21, 2016 13 NSH Security and Privacy requirements 14 draft-reddy-sfc-nsh-security-req-00.txt 16 Abstract 18 This document defines Network Service Header (NSH) security and 19 privacy requirements. 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 July 24, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 57 3. NSH Security and Privacy Requirements . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Service function chaining (SFC) [RFC7665] involves steering traffic 69 flows through a set of service functions in a specific order, such an 70 ordered list of service functions is called a Service Function Chain 71 (SFC). The actual forwarding path used to realize an SFC is called 72 the Service Function Path (SFP). Network Service Headers (NSH) 73 [I-D.ietf-sfc-nsh] provides a mechanism to carry metadata between 74 service functions. The NSH structure is defined in 75 [I-D.ietf-sfc-nsh] and NSH data can be divided into two parts: 77 o Path information used to construct the SFP such as the SFP ID and 78 Service Index. 80 o Metadata carrying the information about the packets being chained. 82 Note that the payload encapsulated by NSH is not part of the NSH 83 data. 85 This document defines security requirments for NSH data and privacy 86 requirements for NSH metadata. 88 2. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. NSH Security and Privacy Requirements 96 This section provides requirements and recommendation for the SFC 97 Data Plane. 99 REQ1: In a SFC domain where attackers can modify NSH data or 100 generate spoofed NSH data, NSH data MUST be authenticated and 101 integrity protected. 103 REQ2: In a SFC domain where attackers can capture and replay NSH 104 data, NSH data MUST provide a mechanism for replay detection 105 and replay prevention mechanism MUST be enforced by the SF 106 component processing the NSH data. 108 REQ3: In a SFC domain where attackers can modify the NSH 109 encapsulated packet, NSH encapsulated packet MUST be 110 authenticated and integrity protected. 112 REQ4: In a SFC domain where pervasive monitoring [RFC7258] is 113 possible, NSH metadata MUST be encrypted and MUST NOT reveal 114 privacy sensitive metadata to attackers. Privacy specific 115 threats are discussed in Section 5.2 of [RFC6973]. 117 REQ5: TBD: To avoid fragmentation and amplification attacks, NSH 118 data MUST be kept under Maximum Transmission Unit (MTU) 119 including the byte overhead of the encapsulated packet. 121 REQ6: Negotiation of authentication, message integrity protection 122 and encryption algorithms between SF components MUST be 123 capable of detecting downgrade attacks. 125 REQ7: No device other than the SF components in the SFP SHOULD be 126 able to update the integrity protected NSH data. SF 127 components not in the SFP SHOULD NOT hold the keying material 128 to act on the NSH data. 130 REQ8: No device other than the SF components in the SFP SHOULD be 131 able to decrypt and update the NSH metadata. SF components 132 not in the SFP SHOULD NOT hold the keying material to decrypt 133 the NSH metadata. 135 4. IANA Considerations 137 None. 139 5. Security Considerations 141 NSH data is at risk from four primary attacks: 143 o A man-in-the middle attacker modifying NSH data. 145 o Attacker spoofing NSH data. 147 o Attacker capturing and replaying NSH data. 149 o NSH metadata revealing privacy sensitive information to attackers. 151 In a SFC domain where all the above attacks are possible, NSH data 152 MUST be authenticated, integrity protected, replay protection MUST be 153 supported and NSH metadata MUST be encrypted for confidentiality. 155 6. Acknowledgments 157 TODO 159 7. References 161 7.1. Normative References 163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 164 Requirement Levels", BCP 14, RFC 2119, 165 DOI 10.17487/RFC2119, March 1997, 166 . 168 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 169 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 170 2014, . 172 7.2. Informative References 174 [I-D.ietf-sfc-nsh] 175 Quinn, P. and U. Elzur, "Network Service Header", draft- 176 ietf-sfc-nsh-01 (work in progress), July 2015. 178 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 179 Chaining (SFC) Architecture", RFC 7665, 180 DOI 10.17487/RFC7665, October 2015, 181 . 183 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 184 Morris, J., Hansen, M., and R. Smith, "Privacy 185 Considerations for Internet Protocols", RFC 6973, 186 DOI 10.17487/RFC6973, July 2013, 187 . 189 Authors' Addresses 191 Tirumaleswar Reddy 192 Cisco Systems, Inc. 193 Cessna Business Park, Varthur Hobli 194 Bangalore, Karnataka 560103 195 India 197 Phone: +91 9886 198 Email: tireddy@cisco.com 200 Daniel Migault 201 Ericsson 202 8400 boulevard Decarie 203 Montreal, QC H4P 2N2 204 Canada 206 Phone: +1 514-452-2160 207 Email: daniel.migault@ericsson.com 209 Carlos Pignataro 210 Cisco Systems, Inc. 211 7200-12 Kit Creek Road 212 Research Triangle Park, NC 27709 213 USA 215 Phone: +1 919-392-7428 216 Email: cpignata@cisco.com 218 Paul Quinn 219 Cisco Systems, Inc. 221 Email: paulq@cisco.com 222 Christopher Inacio 223 CERT, Software Engineering Institute, Carnegie Mellon University 224 4500 5th Ave 225 Pittsburgh, PA 15213 226 USA 228 Phone: +1 412-268-3098 229 Email: inacio@cert.org