<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-sfc-nsh PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-01.xml">
<!ENTITY I-D.ietf-sfc-architecture PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-architecture-11.xml">
<!ENTITY I-D.ietf-sfc-control-plane PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-control-plane-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="4"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-reddy-sfc-nsh-security-req-00.txt"
     ipr="trust200902">
  <front>
    <title abbrev="NSH Security and Privacy  requirements">NSH Security and
    Privacy requirements</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <city>Bangalore</city>

          <code>560103</code>

          <region>Karnataka</region>

          <country>India</country>
        </postal>

        <phone>+91 9886</phone>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Daniel Migault" initials="D." surname="Migault">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street>8400 boulevard Decarie</street>

          <city>Montreal, QC</city>

          <code>H4P 2N2</code>

          <country>Canada</country>
        </postal>

        <phone>+1 514-452-2160</phone>

        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>

    <author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>

          <city>Research Triangle Park</city>

          <code>27709</code>

          <region>NC</region>

          <country>USA</country>
        </postal>

        <phone>+1 919-392-7428</phone>

        <email>cpignata@cisco.com</email>
      </address>
    </author>

    <author fullname="Paul Quinn" initials="P." surname="Quinn">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>

          <street></street>

          <city></city>
        </postal>

        <email>paulq@cisco.com</email>
      </address>
    </author>

    <author fullname="Christopher Inacio" initials="C." surname="Inacio">
      <organization abbrev="CERT/SEI/CMU">CERT, Software Engineering
      Institute, Carnegie Mellon University</organization>

      <address>
        <postal>
          <street>4500 5th Ave</street>

          <city>Pittsburgh</city>

          <code>15213</code>

          <region>PA</region>

          <country>USA</country>
        </postal>

        <phone>+1 412-268-3098</phone>

        <email>inacio@cert.org</email>
      </address>
    </author>

    <date />

    <!-- <date day="4" month="March" year="2015"/> -->

    <area>INTERNET Area</area>

    <workgroup>SFC Working Group</workgroup>

    <abstract>
      <t>This document defines Network Service Header (NSH) security and
      privacy requirements.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="sec-intro" title="Introduction">
      <t>Service function chaining (SFC) <xref target="RFC7665"></xref>
      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) <xref target="I-D.ietf-sfc-nsh"></xref> provides a
      mechanism to carry metadata between service functions. The NSH structure
      is defined in <xref target="I-D.ietf-sfc-nsh"></xref> and NSH data can
      be divided into two parts:</t>

      <t><list style="symbols">
          <t>Path information used to construct the SFP such as the SFP ID and
          Service Index.</t>

          <t>Metadata carrying the information about the packets being
          chained.</t>
        </list></t>

      <t>Note that the payload encapsulated by NSH is not part of the NSH
      data.</t>

      <t>This document defines security requirments for NSH data and privacy
      requirements for NSH metadata.</t>
    </section>

    <section title="Requirements notation">
      <t>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 <xref
      target="RFC2119"></xref>.</t>
    </section>

    <section title="NSH Security and Privacy Requirements">
      <t>This section provides requirements and recommendation for the SFC
      Data Plane. <list counter="my_count" style="format REQ%d:">
          <t>In a SFC domain where attackers can modify NSH data or generate
          spoofed NSH data, NSH data MUST be authenticated and integrity
          protected.</t>

          <t>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. </t>

          <t>In a SFC domain where attackers can modify the NSH encapsulated
          packet, NSH encapsulated packet MUST be authenticated and integrity
          protected.</t>

          <t>In a SFC domain where pervasive monitoring <xref
          target="RFC7258"></xref> 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 <xref
          target="RFC6973"></xref>.</t>

          <t>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.</t>

          <t>Negotiation of authentication, message integrity protection and
          encryption algorithms between SF components MUST be capable of
          detecting downgrade attacks.</t>

          <t>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.</t>

          <t>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.</t>
        </list></t>
    </section>

    <section title="IANA Considerations">
      <t>None.</t>
    </section>

    <section title="Security Considerations">
      <t>NSH data is at risk from four primary attacks: <list style="symbols">
          <t>A man-in-the middle attacker modifying NSH data.</t>

          <t>Attacker spoofing NSH data.</t>

          <t>Attacker capturing and replaying NSH data.</t>

          <t>NSH metadata revealing privacy sensitive information to
          attackers.</t>
        </list>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.</t>
    </section>

    <section title="Acknowledgments">
      <t>TODO</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include="reference.RFC.7258.xml"?>
    </references>

    <references title="Informative References">
      &I-D.ietf-sfc-nsh;

      <?rfc include="reference.RFC.7665.xml"?>

      <?rfc include="reference.RFC.6973.xml"?>
    </references>
  </back>
</rfc>
