draft-ietf-sfc-nsh-23.txt   draft-ietf-sfc-nsh-24.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: March 26, 2018 Intel Expires: March 28, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
September 22, 2017 September 24, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-23 draft-ietf-sfc-nsh-24
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 March 26, 2018. This Internet-Draft will expire on March 28, 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 14 skipping to change at page 2, line 14
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6
1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 5 1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 6
2. Network Service Header . . . . . . . . . . . . . . . . . . . 6 2. Network Service Header . . . . . . . . . . . . . . . . . . . 7
2.1. Network Service Header Format . . . . . . . . . . . . . . 7 2.1. Network Service Header Format . . . . . . . . . . . . . . 7
2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7
2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 10 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 10
2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 11 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 11
2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1. Optional Variable Length Metadata . . . . . . . . . . 12 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 13
3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16
5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . 20 6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 20
6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21
6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21
7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21
7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21
7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23
7.3. Service Path Identifier and Metadata . . . . . . . . . . 25 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Transport Encapsulation Protocol Security . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Boundary Protection . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8.3. Metadata Considerations . . . . . . . . . . . . . . . . . 27
11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Network Service Header (NSH) Parameters . . . . . . . . 29 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 30
11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29 11.2. Network Service Header (NSH) Parameters . . . . . . . . 30
11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 30 11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 30
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 31 11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 30
11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 31
11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 31
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 32
11.2.6. New IETF Assigned Optional Variable Length Metadata 11.2.6. New IETF Assigned Optional Variable Length Metadata
Type Registry . . . . . . . . . . . . . . . . . . . 32 Type Registry . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 17, line 40 skipping to change at page 17, line 40
this document, and subject for future work. this document, and subject for future work.
6. Service Path Forwarding with NSH 6. Service Path Forwarding with NSH
6.1. SFFs and Overlay Selection 6.1. SFFs and Overlay Selection
As described above, the NSH contains a Service Path Identifier (SPI) As described above, the NSH contains a Service Path Identifier (SPI)
and a Service Index (SI). The SPI is, as per its name, an and a Service Index (SI). The SPI is, as per its name, an
identifier. The SPI alone cannot be used to forward packets along a identifier. The SPI alone cannot be used to forward packets along a
service path. Rather the SPI provides a level of indirection between service path. Rather the SPI provides a level of indirection between
the service path/topology and the network transport. Furthermore, the service path/topology and the network transport encapsulation.
there is no requirement, or expectation of an SPI being bound to a Furthermore, there is no requirement, or expectation of an SPI being
pre-determined or static network path. bound to a pre-determined or static network path.
The Service Index provides an indication of location within a service The Service Index provides an indication of location within a service
path. The combination of SPI and SI provides the identification of a path. The combination of SPI and SI provides the identification of a
logical SF and its order within the service plane, and is used to logical SF and its order within the service plane, and is used to
select the appropriate network locator(s) for overlay forwarding. select the appropriate network locator(s) for overlay forwarding.
The logical SF may be a single SF, or a set of eligible SFs that are The logical SF may be a single SF, or a set of eligible SFs that are
equivalent. In the latter case, the SFF provides load distribution equivalent. In the latter case, the SFF provides load distribution
amongst the collection of SFs as needed. amongst the collection of SFs as needed.
SI serves as a mechanism for detecting invalid service function SI serves as a mechanism for detecting invalid service function
skipping to change at page 25, line 49 skipping to change at page 25, line 49
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
As with many other protocols, the NSH encapsulation could be spoofed NSH is designed for use within operator environments. As such, it
or otherwise modified in transit. However, the deployment scope (as does not include any mandatory security mechanisms. As with many
defined in [RFC7665]) of the NSH encapsulation is limited to a single other protocols, without enhancements, the NSH encapsulation can be
network administrative domain as a controlled environment, with spoofed and is subject to snooping and modification in transit.
trusted devices (e.g., a data center) hence mitigating the risk of
unauthorized manipulation of the encapsulation headers or metadata.
Packets originating outside the SFC-enabled domain must be dropped if However, the deployment scope (as defined in [RFC7665]) of the NSH
they contain an NSH. Similarly, packets exiting the SFC-enabled encapsulation is limited to a single network administrative domain as
domain must be dropped if they contain an NSH. a controlled environment, with trusted devices (e.g., a data center)
hence mitigating the risk of unauthorized manipulation of the
encapsulation headers or metadata. This controlled environment is an
important assumption for NSH. There is one additional important
assumption: All of the service functions used by an operator in
service chains are assumed to be selected and vetted by the operator.
NSH is always encapsulated in a transport encapsulation protocol (as An attacker with access to the traffic in an operators network can
detailed in Section 4 of this specification); and, therefore, when potentially observe the metadata NSH carries with packets,
required, existing security protocols that provide authenticity potentially discovering privacy sensitive information. Similarly,
(e.g., [RFC6071]) can be used. Similarly, if confidentiality is attackers who can modify packets within the operators network may be
required, existing encryption protocols can be used in conjunction able to modify the service function path, path position, and / or the
with the NSH encapsulation. metadata associated with a packet. If an attacker can compromise SFC
Classifiers, Service Function Forwarders, or Service Functions, then
they can inspect any or the NSH information.
8.1. Transport Encapsulation Protocol Security
NSH is always encapsulated in a transport encapsulation protocol
between SFC components (as detailed in Section 4 of this
specification). In selecting the transport encapsulation protocol to
use in a partciular 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
applicable is when an operator is using the public Internet to
provide communication between two parts of their own administrative
domain.
Further, existing best practices, such as [BCP38] SHOULD be deployed Further, existing best practices, such as [BCP38] SHOULD be deployed
at the network layer to ensure that traffic entering the service path at the network layer to ensure that traffic entering the service path
is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional
transport encapsulation considerations. transport encapsulation considerations.
Even though much of the metadata carried within the NSH encapsulation 8.2. Boundary Protection
is derived from the packet contents, and thus is not privacy or
security sensitive, the NSH metadata authenticity and confidentiality Given the potential sensitivity of NSH information, it is important
needs be considered as well. In order to protect the metadata, an that operators ensure that NSH encapsulated packets do not leave the
operator can utilize the aforementioned mechanisms provided by the operator domain. The first step in such is that NSH Egress devices
transport encapsulation protocols including authenticity and/or MUST strip the NSH headers before they send the users packets or
confidentiality. An operator MUST carefully select the transport frames out of the NSH domain. Means to prevent leaking privacy-
encapsulation/underlay services to ensure end-to-end security related information outside an administrative domain are natively
services, when those are desired. For example, if [RFC6071] is used, supported by the NSH given that the last SFF of a service path will
the operator MUST ensure it can be supported by the transport systematically remove the NSH encapsulation before forwarding a
encapsulation/underlay of all relevant network segments as well as packet exiting the service path.
SFFs, SFs and SFC proxies in the service path. Further, as described
under the "SFC Encapsulation" area of the Security Considerations of The second step in such prevention is to filter the transport
[RFC7665], operators can and should use indirect identification for encapsulation protocol used by NSH at the doamin edge. Depending
metadata deemed to be sensitive (such as personally identifying upon the transport encapsulation protocol used for NSH, this can
information) significantly mitigating the risk of privacy violation. either be done by completely blocking the transport encapsulation
In particular, subscriber identifying information should be handled (for example if MPLS is the chosen NSH transport encapsulation
carefully, and in general should be obfuscated. This is covered in protocol, and is never allowed to leave the domain) or by examing the
the Security Considerations of [RFC7665]. For those situations where carried protocol with the transport encapsulation (for example if
obfuscation is either inapplicable or judged to be insufficient, an VxLAN-gpe is used as the NSH transport encapsulation protocol, all
operator can also encrypt the metadata. An approach to an optional domain edges MUST filter based on the carried protocol in the VxLAN-
capability to do this was explored in [I-D.reddy-sfc-nsh-encrypt]. gpe.)
For other situations where greater assurance is desired, optional
mechanisms such as [I-D.brockners-proof-of-transit] can be used. The other consequence of this sensitivity is that ingress packets
Means to prevent leaking privacy-related information outside an MUST also be filtered to prevent attackers from sending in NSH
administrative domain are natively supported by the NSH given that packets with service path identification and metadata of their own
the last SFF of a service path will systematically remove the NSH selection. The same filters as described above for both the NSH
encapsulation before forwarding a packet exiting the service path. devices and for the general edge protections MUST be applied on
ingress.
In summary, packets originating outside the SFC-enabled domain must
be dropped if they contain an NSH. Similarly, packets exiting the
SFC-enabled domain must be dropped if they contain an NSH.
8.3. Metadata Considerations
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. Protection of traffic at that level is the responsibility of
the end systems.
Having said that, some of the metadata can be either privacy or
operationally sensitive. For example, mdofiying the metadata
indicating the charging category of packets can cause subscribers to
underpay or overpay the operator in certain environments. The
service path identification and position is often itself sensitive,
since modification of that information can cause packets to avoid
service functions the customer or operator intend the packet to
visit.
Protecting such information between SFC components can be done using
transport encapsulation protocols with suitable security capabilites,
along the lines discussed above. Protecting the information at SFC
components is more complicated as re-classifers are permitted to
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
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
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.
Lastly, SF security, although out of scope of this document, should Lastly, SF security, although out of scope of this document, should
be considered, particularly if an SF needs to access, authenticate, be considered, particularly if an SF needs to access, authenticate,
or update the NSH encapsulation or metadata. However, again, the or update the NSH encapsulation or metadata. However, again, the
placement of SFs is assumed to be bounded within the scope of a selection and placement of SFs is assumed to be bounded within the
single administrative domain and therefore under direct control of scope of a single administrative domain and therefore under direct
the operator. control of the operator.
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 31, line 45 skipping to change at page 33, line 10
| 0xFF | Experiment 2 | This document | | 0xFF | Experiment 2 | This document |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
Table 7: NSH Base Header Next Protocol Values Table 7: NSH Base Header Next Protocol Values
Expert Review requests MUST include a single code point per request. Expert Review requests MUST include a single code point per request.
Designated Experts evaluating new allocation requests from this Designated Experts evaluating new allocation requests from this
registry should consider the potential scarcity of code points for an registry should consider the potential scarcity of code points for an
8-bit value, and check both for duplications as well as availability 8-bit value, and check both for duplications as well as availability
of documentation. If the actual assignment of the Next Protocol of documentation. If the actual assignment of the Next Protocol
field allocation exceeds half of the range, that is when there are field allocation reaches half of the range, that is when there are
128 unassigned values, IANA needs to alert the IESG. At this point, 128 unassigned values, IANA needs to alert the IESG. At this point,
a new more strict allocation policy SHOULD be considered. a new more strict allocation policy SHOULD be considered.
11.2.6. New IETF Assigned Optional Variable Length Metadata Type 11.2.6. New IETF Assigned Optional Variable Length Metadata Type
Registry Registry
This document requests IANA to create a registry for the type values This document requests IANA to create a registry for the type values
owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF
Assigned Optional Variable Length Metadata Type Registry", as Assigned Optional Variable Length Metadata Type Registry", as
specified in Section 2.5.1. specified in Section 2.5.1.
 End of changes. 15 change blocks. 
73 lines changed or deleted 149 lines changed or added

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