draft-ietf-sfc-nsh-26.txt   draft-ietf-sfc-nsh-27.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: April 8, 2018 Intel Expires: April 23, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
October 5, 2017 October 20, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-26 draft-ietf-sfc-nsh-27
Abstract Abstract
This document describes a Network Service Header (NSH) imposed on This document describes a Network Service Header (NSH) imposed on
packets or frames to realize service function paths. The NSH also packets or frames to realize service function paths. The NSH also
provides a mechanism for metadata exchange along the instantiated provides a mechanism for metadata exchange along the instantiated
service paths. The NSH is the SFC encapsulation required to support service paths. The NSH is the SFC encapsulation required to support
the Service Function Chaining (SFC) architecture (defined in the Service Function Chaining (SFC) architecture (defined in
RFC7665). RFC7665).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 8, 2018. This Internet-Draft will expire on April 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17
6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17
6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 21 6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 21
6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21
6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 22 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 22
7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22
7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22
7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 24 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 24
7.3. Service Path Identifier and Metadata . . . . . . . . . . 25 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Transport Encapsulation Protocol Security . . . . . . . . 27 8.1. NSH Security Considerations from Operators' Environments 27
8.2. Boundary Protection . . . . . . . . . . . . . . . . . . . 27 8.2. NSH Security Considerations from the SFC Architecture . . 28
8.3. Metadata Considerations . . . . . . . . . . . . . . . . . 28 8.2.1. Integrity . . . . . . . . . . . . . . . . . . . . . . 29
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Network Service Header (NSH) Parameters . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 31 11.1. Network Service Header (NSH) Parameters . . . . . . . . 33
11.1.2. NSH Version . . . . . . . . . . . . . . . . . . . . 31 11.1.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 33
11.1.3. MD Type Registry . . . . . . . . . . . . . . . . . . 31 11.1.2. NSH Version . . . . . . . . . . . . . . . . . . . . 34
11.1.4. MD Class Registry . . . . . . . . . . . . . . . . . 32 11.1.3. MD Type Registry . . . . . . . . . . . . . . . . . . 34
11.1.4. MD Class Registry . . . . . . . . . . . . . . . . . 34
11.1.5. New IETF Assigned Optional Variable Length Metadata 11.1.5. New IETF Assigned Optional Variable Length Metadata
Type Registry . . . . . . . . . . . . . . . . . . . 33 Type Registry . . . . . . . . . . . . . . . . . . . 35
11.1.6. NSH Base Header Next Protocol . . . . . . . . . . . 33 11.1.6. NSH Base Header Next Protocol . . . . . . . . . . . 35
12. NSH-Related Codepoints . . . . . . . . . . . . . . . . . . . 34
12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 34 12. NSH-Related Codepoints . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 13.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Service functions are widely deployed and essential in many networks. Service functions are widely deployed and essential in many networks.
These service functions provide a range of features such as security, These service functions provide a range of features such as security,
WAN acceleration, and server load balancing. Service functions may WAN acceleration, and server load balancing. Service functions may
be instantiated at different points in the network infrastructure be instantiated at different points in the network infrastructure
such as the wide area network, data center, and so forth. such as the wide area network, data center, and so forth.
Prior to development of the SFC architecture [RFC7665] and the Prior to development of the SFC architecture [RFC7665] and the
skipping to change at page 11, line 22 skipping to change at page 11, line 22
| Service Path Identifier (SPI) | Service Index | | Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Path Identifier (SPI): 24 bits Service Path Identifier (SPI): 24 bits
Service Index (SI): 8 bits Service Index (SI): 8 bits
Figure 4: NSH Service Path Header Figure 4: NSH Service Path Header
The meaning of these fields is as follows: The meaning of these fields is as follows:
Service Path Identifier (SPI): Identifies a service path. Service Path Identifier (SPI): Uniquely identifies a service function
Participating nodes MUST use this identifier for Service Function path. Participating nodes MUST use this identifier for Service
Path selection. The initial classifier MUST set the appropriate SPI Function Path selection (SFP). The initial classifier MUST set the
for a given classification result. appropriate SPI for a given classification result.
Service Index (SI): Provides location within the SFP. The initial Service Index (SI): Provides location within the SFP. The initial
classifier for a given SFP SHOULD set the SI to 255, however the classifier for a given SFP SHOULD set the SI to 255, however the
control plane MAY configure the initial value of SI as appropriate control plane MAY configure the initial value of SI as appropriate
(i.e., taking into account the length of the service function path). (i.e., taking into account the length of the service function path).
The Service Index MUST be decremented by a value of 1 by Service The Service Index MUST be decremented by a value of 1 by Service
Functions or by SFC Proxy nodes after performing required services Functions or by SFC Proxy nodes after performing required services
and the new decremented SI value MUST be used in the egress packet's and the new decremented SI value MUST be used in the egress packet's
NSH. The initial Classifier MUST send the packet to the first SFF in NSH. The initial Classifier MUST send the packet to the first SFF in
the identified SFP for forwarding along an SFP. If re-classification the identified SFP for forwarding along an SFP. If re-classification
skipping to change at page 12, line 31 skipping to change at page 12, line 31
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NSH MD Type=0x1 Figure 5: NSH MD Type=0x1
This specification does not make any assumptions about the content of This specification does not make any assumptions about the content of
the 16 byte Context Header that must be present when the MD Type the 16 byte Context Header that must be present when the MD Type
field is set to 1, and does not describe the structure or meaning of field is set to 1, and does not describe the structure or meaning of
the included metadata. the included metadata.
An SFC-aware SF or SFC Proxy needs to receive the data semantics An SFC-aware SF or SFC Proxy needs to receive the data structure and
first in order to process the data placed in the mandatory context semantics first in order to process the data placed in the mandatory
field. The data semantics include both the allocation schema and the context field. The data structure and semantics include both the
meaning of the included data. How an SFC-aware SF or SFC Proxy gets allocation schema and order, and the meaning of the included data.
the data semantics is outside the scope of this specification. How an SFC-aware SF or SFC Proxy gets the data structure and
semantics is outside the scope of this specification.
An SF or SFC Proxy that does not know the format or semantics of the An SF or SFC Proxy that does not know the format or semantics of the
Context Header for an NSH with MD Type 1 MUST discard any packet with Context Header for an NSH with MD Type 1 MUST discard any packet with
such an NSH (i.e., MUST NOT ignore the metadata that it cannot such an NSH (i.e., MUST NOT ignore the metadata that it cannot
process), and MUST log the event at least once per the SPI for which process), and MUST log the event at least once per the SPI for which
the event occurs (subject to thresholding). the event occurs (subject to thresholding).
[I-D.guichard-sfc-nsh-dc-allocation] and [I-D.guichard-sfc-nsh-dc-allocation] and
[I-D.napper-sfc-nsh-broadband-allocation] provide specific examples [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples
of how metadata can be allocated. of how metadata can be allocated.
skipping to change at page 26, line 35 skipping to change at page 26, line 35
DoS DoS
"Scrubber" "Scrubber"
Figure 13: Path ID and Metadata Figure 13: Path ID and Metadata
Specific algorithms for mapping metadata to an SPI are outside the Specific algorithms for mapping metadata to an SPI are outside the
scope of this document. scope of this document.
8. Security Considerations 8. Security Considerations
NSH is designed for use within a single operator environment. As NSH security must be considered in the contexts of the SFC
such, it does not include any mandatory security mechanisms. As with architecture and operators' environments. One important
many other protocols, by itself and without extensions, the NSH characteristic of NSH is that it is not an end-to-end protocol. As
encapsulation can be spoofed and is subject to snooping and opposed to a protocol that "starts" on a host, and "ends" on a server
modification in transit. However, the deployment scope (as defined or another host, NSH is typically imposed by a network device on
in [RFC7665]) of the NSH encapsulation is limited to a single network ingress to the SFC domain and removed at the egress of the SFC
administrative domain as a controlled environment, with trusted domain. As such, and as with any other network-centric protocol
devices (e.g., a data center) hence mitigating the risk of (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider
unauthorized manipulation of the encapsulation headers or metadata. Provisioned Virtual Private Networks) there an underlying trust that
This controlled environment is an important assumption for NSH. the network devices responsible for imposing, removing and acting on
There is one additional important assumption: All of the service NSH information are trusted.
functions used by an operator in service chains are assumed to be
selected and vetted by the operator.
An attacker with access to the traffic in an operators network can The following sections detail an analysis and present a set of
potentially observe the metadata NSH carries with packets, requirements and recommendations in those two areas.
potentially discovering privacy sensitive information. Similarly,
attackers who can modify packets within the operators network may be
able to modify the service function path, path position, and / or the
metadata associated with a packet. If an attacker can compromise SFC
Classifiers, Service Function Forwarders, or Service Functions, then
they can inspect any of the NSH information.
8.1. Transport Encapsulation Protocol Security 8.1. NSH Security Considerations from Operators' Environments
NSH is always encapsulated in a transport encapsulation protocol Trusted Devices
between SFC components (as detailed in Section 4 of this
specification). In selecting the transport encapsulation protocol to
use in a particular deployment, operators SHOULD evaluate the degree
of protection from e.g., intermediate observation and modification
that is needed. Operators SHOULD then select a transport
encapsulation protocol such as one that supports [RFC6071] to provide
the needed protection (e.g., authenticity, confidentiality) for the
traffic between SFC components. Operators MUST ensure the selected
transport encapsulation protocol can be supported by the transport
encapsulation/underlay of all relevant network segments as well as
SFFs, SFs and SFC proxies in the service path.
One example where transport encapsulation protocol security is highly All classifiers, SFFs and SFSs (hereinafter referred to as "SFC
applicable is when an operator is using the public Internet to devices") within an operator's environment are assumed to have
provide communication between two parts of their own administrative been selected, vetted, and actively maintained, therefore trusted
domain. by that operator. This assumption differs from the oft held view
that devices are untrusted, often refered to as zero trust model.
Operators SHOULD regularly monitor (i.e. continuously audit) these
devices to help ensure complaint behavior. This trust, therefore,
extends into NSH operations: SFC devices are not, themselves,
considered as attack vectors. This assumption, and the resultant
conclusion is reasonable since this is the very basis of an
operator posture; the operator depends on this reality to
function. If these devices are not trusted, and indeed
compromised, almost the entirety of the operator's standard- based
IP and MPLS protocol suites are vulnerable, and therefore the
operation of the entire network is compromised. Methods for
detecting a compromise are well documented, and include continous
monitoring, audit and log review.
[I-D.ietf-rtgwg-dt-encap] provides additional transport encapsulation Methods and best practices to secure devices are also widely
considerations. documented and outside the scope of this document.
8.2. Boundary Protection Single Domain Boundary
Given the potential sensitivity of NSH information, it is important As per [RFC7665], NSH is designed for use within a single
that operators ensure that NSH encapsulated packets do not leave the administrative domain. This scoping provides two important
operator domain. The first step in such is that NSH egress devices characteristics:
MUST strip the NSH headers before they send the users packets or
frames out of the NSH domain. Means to prevent leaking privacy-
related information outside an administrative domain are natively
supported by the NSH given that the last SFF of a service path will
systematically remove the NSH encapsulation before forwarding a
packet exiting the service path.
The second step in such prevention is to filter the transport i) Clear NSH boundaries
encapsulation protocol used by NSH at the doamin edge. Depending
upon the transport encapsulation protocol used for NSH, this can
either be done by completely blocking the transport encapsulation
(for example if MPLS is the chosen NSH transport encapsulation
protocol, and is never allowed to leave the domain) or by examing the
carried protocol with the transport encapsulation (for example if
VxLAN-gpe is used as the NSH transport encapsulation protocol, all
domain edges need to filter based on the carried protocol in the
VxLAN-gpe.)
The other consequence of this sensitivity is that ingress packets NSH egress devices MUST strip the NSH headers before they send the
MUST also be filtered to prevent attackers from sending in NSH users' packets or frames out of the NSH domain.
packets with service path identification and metadata of their own
selection. The same filters as described above for both the NSH
devices and for the general edge protections MUST be applied on
ingress.
In summary, packets originating outside the SFC-enabled domain must Means to prevent leaking privacy-related information outside an
be dropped if they contain an NSH. Similarly, packets exiting the administrative domain are natively supported by the NSH given that
SFC-enabled domain must be dropped if they contain an NSH. the last SFF of a service path will systematically remove the NSH
encapsulation before forwarding a packet exiting the service path.
8.3. Metadata Considerations The second step in such prevention is to filter the transport
encapsulation protocol used by NSH at the domain edge. The
transport encapsulation protocol MUST be filtered and MUST NOT
leave the domain edge.
Much of the metadata carried by NSH is not sensitive. It often Depending upon the transport encapsulation protocol used for NSH,
reflects information that can be derived from the underlying packet this can either be done by completely blocking the transport
or frame. Direct protection of such information is not necessary, as encapsulation (e.g., if MPLS is the chosen NSH transport
the risks are simply those of carrying the underlying packet or encapsulation protocol, it is therefore never allowed to leave the
frame. Protection of traffic at that level is the responsibility of domain) or by examining the carried protocol with the transport
the end systems. encapsulation (e.g., if VxLAN-gpe is used as the NSH transport
encapsulation protocol, all domain edges need to filter based on
the carried protocol in the VxLAN-gpe.)
Having said that, some of the metadata can be either privacy or The other consequence of this bounding is that ingress packets
operationally sensitive. For example, mdofiying the metadata MUST also be filtered to prevent attackers from sending in NSH
indicating the charging category of packets can cause subscribers to packets with service path identification and metadata of their own
underpay or overpay the operator in certain environments. The selection. The same filters as described above for both the NSH
service path identification and position is often itself sensitive, at SFC devices and for the transport encapsulation protocol as
since modification of that information can cause packets to avoid general edge protections MUST be applied on ingress.
service functions the customer or operator intend the packet to
visit.
Protecting such information between SFC components can be done using In summary, packets originating outside the SFC-enabled domain
transport encapsulation protocols with suitable security capabilites, MUST be dropped if they contain an NSH. Similarly, packets
along the lines discussed above. Protecting the information at SFC exiting the SFC-enabled domain MUST be dropped if they contain an
components is more complicated as re-classifers are permitted to NSH.
modify NSH fields (with the caveats noted above regarding the flag
bits); SFFs read the service function path information and modify the
service function path index; and in general service functions need to
read, and potentially modify NSH metadata.
One useful element of providing privacy protection for sensitive ii) Mitigation of external threats
metadata is described under the "SFC Encapsulation" area of the
Security Considerations of [RFC7665]. Operators can and should use
indirect identification for metadata deemed to be sensitive (such as
personally identifying information) significantly mitigating the risk
of privacy violation. In particular, subscriber identifying
information should be handled carefully, and in general should be
obfuscated.
For those situations where obfuscation is either inapplicable or As per the trusted SFC devices points raised above, given that NSH
judged to be insufficient, an operator can also encrypt the metadata. is scoped within an operator's domain, that operator can ensure
An approach to an optional capability to do this was explored in that the environment, and its transitive properties, comply to
[I-D.reddy-sfc-nsh-encrypt]. For other situations where greater that operator's required security posture. Continuous audits for
assurance is desired, optional mechanisms such as assurance are recommended with this reliance on a fully trusted
[I-D.brockners-proof-of-transit] can be used. environment. The term 'continuous audits' describes a method
(automated or manual) of checking security control compliance on a
regular basis, at some set period of time.
Lastly, SF security, although out of scope of this document, should 8.2. NSH Security Considerations from the SFC Architecture
be considered, particularly if an SF needs to access, authenticate,
or update the NSH encapsulation or metadata. However, again, the The SFC architecture defines functional roles (e.g., SFF), as well as
selection and placement of SFs is assumed to be bounded within the protocol element (e.g. Metadata). This section considers each role
scope of a single administrative domain and therefore under direct and element in the context of threats posed in the areas of integrity
control of the operator. and confidentiality. As with routing, the distributed computation
model assumes a distributed trust model.
An important consideration is that NSH contains mandatory to mute
fields, and further, the SFC architecture describes cases where other
fields in NSH change, all on a possible SFP hop-by-hop basis. This
means that any cryptographic solution requires complex key
distribution and lifecycle operations.
8.2.1. Integrity
SFC devices
SFC devices MAY perform various forms of verification on received
NSH packets such as only accepting NSH packets from expected
devices, checking that NSH SPI and SI values received from
expected devices conform to expected values and so on.
Implementation of these additional checks are a local matter and
thus out of scope of this document.
NSH Base and Service Path Headers
Attackers who can modify packets within the operator's network may
be able to modify the service function path, path position, and /
or the metadata associated with a packet.
One specific concern is an attack in which a malicious
modification of the SPI/SI results in an alteration of the path to
avoid security devices. The options discussed in this section
help twart that attack, and so does the use of the optional "Proof
of Transit" method [I-D.brockners-proof-of-transit].
As stated above, SFC devices are trusted; in the case where an SFC
device is compromised, NSH integrity protection would be subject
to forging (in many cases) as well.
NSH itself does not mandate protocol-specific integrity
protection. However, if an operator deems protection required,
several options are viable:
1. SFF/SF NSH verification
Although strictly speaking not integrity protection, some of
the techniques mentioned above such as checking expected NSH
values are received from expected SFC device(s) can provide a
form of verification without incurring the burden of a full-
fledged integrity protection deployment.
2. Transport Security
NSH is always encapsulated by an outer transport encapsulation
as detailed in Section 4 of this specification, and as
depicted in Figure 1. If an operator deems cryptographic
integrity protection necessary due to their risk analysis,
then an outer transport encapsulation that provides such
protection [RFC6071], such as IPsec, MUST be used.
Given that NSH is transport independent, as mentioned above, a
secure transport, such as IPsec can be used for carry NSH.
IPsec can be used either alone, or in conjunction with other
transport encapsulation protocols in turn encapsulating NSH.
Operators MUST ensure the selected transport encapsulation
protocol can be supported by the transport encapsulation/
underlay of all relevant network segments as well as SFFs, SFs
and SFC proxies in the service path.
3. NSH Variable Header-based Integrity
Lastly, NSH MD-Type 2 provides, via variable length headers,
the ability to append cryptographic integrity protection to
the NSH packet. The implementation of such a scheme is
outside the scope of this document.
NSH metadata
As with the base and service path headers, if an operator deems
cryptographic integrity protection needed, then an existing,
standard transport protocol MUST be used since the integrity
protection applies to entire encapsulated NSH packets. As
mentioned above, a risk assessment that deems dataplane traffic
subject to tampering will apply not only to NSH but to the
transport information and therefore the use of a secure transport
is likely needed already to protect the entire stack.
If an MD-Type 2 variable header integrity scheme is in place, then
the integrity of the metadata can be ensured via that mechanism as
well.
8.2.2. Confidentiality
SFC devices
SFC devices can "see" (and need to use) NSH information.
NSH base and service path headers
SPI and other base/service path information does not typically
require confidentiality; however, if an operator does deem
confidentiality required, then, as with integrity, an existing
transport encapsulation that provides encryption MUST be utilized.
NSH metadata
An attacker with access to the traffic in an operator's network
can potentially observe the metadata NSH carries with packets,
potentially discovering privacy sensitive information.
Much of the metadata carried by NSH is not sensitive. It often
reflects information that can be derived from the underlying
packet or frame. Direct protection of such information is not
necessary, as the risks are simply those of carrying the
underlying packet or frame.
Implementers and operators MUST be aware that metadata can have
privacy implications, and those implications are sometimes hard to
predict. Therefore, attached metadata should be limited to that
necessary for correct operation of the SFP. Further, [RFC8165]
defines metadata considerations that operators can take into
account when using NSH.
Protecting NSH metadata information between SFC components can be
done using transport encapsulation protocols with suitable
security capabilities, along the lines discussed above. If a
security analysis deems these protections necessary, then security
features in the transport encapsulation protocol (such as IPsec)
MUST be used.
One useful element of providing privacy protection for sensitive
metadata is described under the "SFC Encapsulation" area of the
Security Considerations of [RFC7665]. Operators can and should
use indirect identification for metadata deemed to be sensitive
(such as personally identifying information) significantly
mitigating the risk of a privacy violation. In particular,
subscriber identifying information should be handled carefully,
and in general SHOULD be obfuscated.
For those situations where obfuscation is either inapplicable or
judged to be insufficient, an operator can also encrypt the
metadata. An approach to an optional capability to do this was
explored in [I-D.reddy-sfc-nsh-encrypt]. For other situations
where greater assurance is desired, optional mechanisms such as
[I-D.brockners-proof-of-transit] can be used.
9. Contributors 9. Contributors
This WG document originated as draft-quinn-sfc-nsh; the following are This WG document originated as draft-quinn-sfc-nsh; the following are
its co-authors and contributors along with their respective its co-authors and contributors along with their respective
affiliations at the time of WG adoption. The editors of this affiliations at the time of WG adoption. The editors of this
document would like to thank and recognize them and their document would like to thank and recognize them and their
contributions. These co-authors and contributors provided invaluable contributions. These co-authors and contributors provided invaluable
concepts and content for this document's creation. concepts and content for this document's creation.
skipping to change at page 30, line 50 skipping to change at page 33, line 27
this document. this document.
Loa Andersson provided a thorough review and valuable comments, we Loa Andersson provided a thorough review and valuable comments, we
thank him for that. thank him for that.
Reinaldo Penno deserves a particular thank you for his architecture Reinaldo Penno deserves a particular thank you for his architecture
and implementation work that helped guide the protocol concepts and and implementation work that helped guide the protocol concepts and
design. design.
The editors also acknowledge comprehensive reviews and respective The editors also acknowledge comprehensive reviews and respective
suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder, useful suggestions by Med Boucadair, Adrian Farrel, Juergen
and Acee Lindem. Schoenwaelder, Acee Lindem, and Kathleen Moriarty.
Lastly, David Dolson has provides significant review, feedback and Lastly, David Dolson has provides significant review, feedback and
suggestions throughout the evolution of this document. His suggestions throughout the evolution of this document. His
contributions are very much appreciated. contributions are very much appreciated.
11. IANA Considerations 11. IANA Considerations
11.1. Network Service Header (NSH) Parameters 11.1. Network Service Header (NSH) Parameters
IANA is requested to create a new "Network Service Header (NSH) IANA is requested to create a new "Network Service Header (NSH)
skipping to change at page 37, line 5 skipping to change at page 39, line 5
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
[RFC8165] Hardie, T., "Design Considerations for Metadata
Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017,
<https://www.rfc-editor.org/info/rfc8165>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 28 change blocks. 
146 lines changed or deleted 265 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/