SFC Working Group T. Reddy Internet-Draft Cisco Intended status: Informational D. Migault Expires: July 24, 2016 Ericsson C. Pignataro P. Quinn Cisco C. Inacio CERT/SEI/CMU January 21, 2016 NSH Security and Privacy requirements draft-reddy-sfc-nsh-security-req-00.txt Abstract This document defines Network Service Header (NSH) security and privacy requirements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 24, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Reddy, et al. Expires July 24, 2016 [Page 1] Internet-Draft NSH Security and Privacy requirements January 2016 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 3. NSH Security and Privacy Requirements . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Service function chaining (SFC) [RFC7665] involves steering traffic flows through a set of service functions in a specific order, such an ordered list of service functions is called a Service Function Chain (SFC). The actual forwarding path used to realize an SFC is called the Service Function Path (SFP). Network Service Headers (NSH) [I-D.ietf-sfc-nsh] provides a mechanism to carry metadata between service functions. The NSH structure is defined in [I-D.ietf-sfc-nsh] and NSH data can be divided into two parts: o Path information used to construct the SFP such as the SFP ID and Service Index. o Metadata carrying the information about the packets being chained. Note that the payload encapsulated by NSH is not part of the NSH data. This document defines security requirments for NSH data and privacy requirements for NSH metadata. 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Reddy, et al. Expires July 24, 2016 [Page 2] Internet-Draft NSH Security and Privacy requirements January 2016 3. NSH Security and Privacy Requirements This section provides requirements and recommendation for the SFC Data Plane. REQ1: In a SFC domain where attackers can modify NSH data or generate spoofed NSH data, NSH data MUST be authenticated and integrity protected. REQ2: In a SFC domain where attackers can capture and replay NSH data, NSH data MUST provide a mechanism for replay detection and replay prevention mechanism MUST be enforced by the SF component processing the NSH data. REQ3: In a SFC domain where attackers can modify the NSH encapsulated packet, NSH encapsulated packet MUST be authenticated and integrity protected. REQ4: In a SFC domain where pervasive monitoring [RFC7258] is possible, NSH metadata MUST be encrypted and MUST NOT reveal privacy sensitive metadata to attackers. Privacy specific threats are discussed in Section 5.2 of [RFC6973]. REQ5: TBD: To avoid fragmentation and amplification attacks, NSH data MUST be kept under Maximum Transmission Unit (MTU) including the byte overhead of the encapsulated packet. REQ6: Negotiation of authentication, message integrity protection and encryption algorithms between SF components MUST be capable of detecting downgrade attacks. REQ7: No device other than the SF components in the SFP SHOULD be able to update the integrity protected NSH data. SF components not in the SFP SHOULD NOT hold the keying material to act on the NSH data. REQ8: No device other than the SF components in the SFP SHOULD be able to decrypt and update the NSH metadata. SF components not in the SFP SHOULD NOT hold the keying material to decrypt the NSH metadata. 4. IANA Considerations None. Reddy, et al. Expires July 24, 2016 [Page 3] Internet-Draft NSH Security and Privacy requirements January 2016 5. Security Considerations NSH data is at risk from four primary attacks: o A man-in-the middle attacker modifying NSH data. o Attacker spoofing NSH data. o Attacker capturing and replaying NSH data. o NSH metadata revealing privacy sensitive information to attackers. In a SFC domain where all the above attacks are possible, NSH data MUST be authenticated, integrity protected, replay protection MUST be supported and NSH metadata MUST be encrypted for confidentiality. 6. Acknowledgments TODO 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . 7.2. Informative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-01 (work in progress), July 2015. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . Reddy, et al. Expires July 24, 2016 [Page 4] Internet-Draft NSH Security and Privacy requirements January 2016 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . Authors' Addresses Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Bangalore, Karnataka 560103 India Phone: +91 9886 Email: tireddy@cisco.com Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160 Email: daniel.migault@ericsson.com Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA Phone: +1 919-392-7428 Email: cpignata@cisco.com Paul Quinn Cisco Systems, Inc. Email: paulq@cisco.com Reddy, et al. Expires July 24, 2016 [Page 5] Internet-Draft NSH Security and Privacy requirements January 2016 Christopher Inacio CERT, Software Engineering Institute, Carnegie Mellon University 4500 5th Ave Pittsburgh, PA 15213 USA Phone: +1 412-268-3098 Email: inacio@cert.org Reddy, et al. Expires July 24, 2016 [Page 6]