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 25, 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 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. Requirements notation
• 3. NSH Security and Privacy Requirements
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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:

• Path information used to construct the SFP such as the SFP ID and Service Index.
• 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].

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.

5. Security Considerations

NSH data is at risk from four primary attacks:

• A man-in-the middle attacker modifying NSH data.
• Attacker spoofing NSH data.
• Attacker capturing and replaying NSH data.
• 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

7.2. Informative References

Authors' Addresses