draft-ietf-sfc-nsh-21.txt   draft-ietf-sfc-nsh-22.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 21, 2018 Intel Expires: March 26, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
September 17, 2017 September 22, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-21 draft-ietf-sfc-nsh-22
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 21, 2018. This Internet-Draft will expire on March 26, 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . 12
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 Transport . . . . . . . . . . 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 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 29 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 29
11.2. Network Service Header (NSH) Parameters . . . . . . . . 29 11.2. Network Service Header (NSH) Parameters . . . . . . . . 29
11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29 11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29
11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29 11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29
11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29 11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29
11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 30 11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 30
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 31 11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 31
11.2.6. New IETF Assigned Optional Variable Length Metadata 11.2.6. New IETF Assigned Optional Variable Length Metadata
Type Registry . . . . . . . . . . . . . . . . . . . 31 Type Registry . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
2. The ability to easily bind service policy to granular 2. The ability to easily bind service policy to granular
information, such as per-subscriber state. information, such as per-subscriber state.
3. The capability to steer traffic to the requisite service 3. The capability to steer traffic to the requisite service
function(s). function(s).
The Network Service Header (NSH) specification defines a new protocol The Network Service Header (NSH) specification defines a new protocol
and associated encapsulation for the creation of dynamic service and associated encapsulation for the creation of dynamic service
chains, operating at the service plane. The NSH is designed to chains, operating at the service plane. The NSH is designed to
encapsulate an original packet or frame, and in turn be encapsulated encapsulate an original packet or frame, and in turn be encapsulated
by an outer transport (which is used to deliver the NSH to NSH-aware by an outer transport encapsulation (which is used to deliver the NSH
network elements), as shown in Figure 1: to NSH-aware network elements), as shown in Figure 1:
+------------------------------+ +------------------------------+
| Transport Encapsulation | | Transport Encapsulation |
+------------------------------+ +------------------------------+
| Network Service Header (NSH) | | Network Service Header (NSH) |
+------------------------------+ +------------------------------+
| Original Packet / Frame | | Original Packet / Frame |
+------------------------------+ +------------------------------+
Figure 1: Network Service Header Encapsulation Figure 1: Network Service Header Encapsulation
skipping to change at page 5, line 9 skipping to change at page 5, line 9
carried on the NSH's Context Headers. It allows summarizing a carried on the NSH's Context Headers. It allows summarizing a
classification result in the packet itself, avoiding subsequent classification result in the packet itself, avoiding subsequent
re-classifications. Examples of metadata include classification re-classifications. Examples of metadata include classification
information used for policy enforcement and network context for information used for policy enforcement and network context for
forwarding post service delivery. forwarding post service delivery.
Network Locator: Data plane address, typically IPv4 or IPv6, used to Network Locator: Data plane address, typically IPv4 or IPv6, used to
send and receive network traffic. send and receive network traffic.
Network Node/Element: Device that forwards packets or frames based Network Node/Element: Device that forwards packets or frames based
on an outer header (i.e., encapsulation) information. on an outer header (i.e., transport encapsulation) information.
Network Overlay: Logical network built on top of existing network Network Overlay: Logical network built on top of existing network
(the underlay). Packets are encapsulated or tunneled to create (the underlay). Packets are encapsulated or tunneled to create
the overlay network topology. the overlay network topology.
NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH
provides the SFC encapsulation. This specification uses NSH-aware provides the SFC encapsulation. This specification uses NSH-aware
as a more specific term from the more generic term SFC-aware as a more specific term from the more generic term SFC-aware
[RFC7665]. [RFC7665].
skipping to change at page 6, line 34 skipping to change at page 6, line 34
Section 3.3. Examples of metadata include classification Section 3.3. Examples of metadata include classification
information used for policy enforcement and network context for information used for policy enforcement and network context for
forwarding post service delivery. Sharing the metadata allows forwarding post service delivery. Sharing the metadata allows
service functions to share initial and intermediate service functions to share initial and intermediate
classification results with downstream service functions saving classification results with downstream service functions saving
re-classification, where enough information was enclosed. re-classification, where enough information was enclosed.
4. The NSH offers a common and standards-based header for service 4. The NSH offers a common and standards-based header for service
chaining to all network and service nodes. chaining to all network and service nodes.
5. Transport Agnostic: The NSH is encapsulation-independent, meaning 5. Transport Encapsulation Agnostic: The NSH is transport
it can be transported by a variety of protocols. An appropriate encapsulation-independent, meaning it can be transported by a
(for a given deployment) encapsulation protocol can be used to variety of encapsulation protocols. An appropriate (for a given
carry NSH-encapsulated traffic. This transport may form an deployment) encapsulation protocol can be used to carry NSH-
encapsulated traffic. This transport encapsulation may form an
overlay network and if an existing overlay topology provides the overlay network and if an existing overlay topology provides the
required service path connectivity, that existing overlay may be required service path connectivity, that existing overlay may be
used. used.
2. Network Service Header 2. Network Service Header
An NSH is imposed on the original packet/frame. This NSH contains An NSH is imposed on the original packet/frame. This NSH contains
service path information and optionally metadata that are added to a service path information and optionally metadata that are added to a
packet or frame and used to create a service plane. Subsequently, an packet or frame and used to create a service plane. Subsequently, an
outer encapsulation is imposed on the NSH, which is used for network outer transport encapsulation is imposed on the NSH, which is used
forwarding. for network forwarding.
A Service Classifier adds the NSH. The NSH is removed by the last A Service Classifier adds the NSH. The NSH is removed by the last
SFF in the service chain or by an SF that consumes the packet. SFF in the service chain or by an SF that consumes the packet.
2.1. Network Service Header Format 2.1. Network Service Header Format
The NSH is composed of a 4-byte Base Header, a 4-byte Service Path The NSH is composed of a 4-byte Base Header, a 4-byte Service Path
Header and optional Context Headers, as shown in Figure 2 below. Header and optional Context Headers, as shown in Figure 2 below.
0 1 2 3 0 1 2 3
skipping to change at page 16, line 34 skipping to change at page 16, line 34
|(SF) | | | | | | | | |(SF) | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+ +-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | + | | | + | + | | | | + | + | | | + | + | |
|SFC Proxy | | | | | | | | |SFC Proxy | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+ +-----------+-------+-------+-------+-------+-------+-------+-------+
Figure 8: NSH Action and Role Mapping Figure 8: NSH Action and Role Mapping
4. NSH Transport Encapsulation 4. NSH Transport Encapsulation
Once the NSH is added to a packet, an outer encapsulation is used to Once the NSH is added to a packet, an outer transport encapsulation
forward the original packet and the associated metadata to the start is used to forward the original packet and the associated metadata to
of a service chain. The encapsulation serves two purposes: the start of a service chain. The encapsulation serves two purposes:
1. Creates a topologically independent services plane. Packets are 1. Creates a topologically independent services plane. Packets are
forwarded to the required services without changing the forwarded to the required services without changing the
underlying network topology. underlying network topology.
2. Transit network nodes simply forward the encapsulated packets 2. Transit network nodes simply forward the encapsulated packets
without modification. without modification.
The service header is independent of the encapsulation used and is The service header is independent of the transport encapsulation
encapsulated in existing transports. The presence of an NSH is used. Existing transport encapsulations can be used. The presence
indicated via protocol type or other indicator in the outer of an NSH is indicated via a protocol type or another indicator in
encapsulation. the outer transport encapsulation.
5. Fragmentation Considerations 5. Fragmentation Considerations
The NSH and the associated transport header are "added" to the The NSH and the associated transport encapsulation header are "added"
encapsulated packet/frame. This additional information increases the to the encapsulated packet/frame. This additional information
size of the packet. increases the size of the packet.
Within a managed administrative domain, an operator can ensure that Within a managed administrative domain, an operator can ensure that
the underlay MTU is sufficient to carry SFC traffic without requiring the underlay MTU is sufficient to carry SFC traffic without requiring
fragmentation. Given that the intended scope of the NSH is within a fragmentation. Given that the intended scope of the NSH is within a
single provider's operational domain, that approach is sufficient. single provider's operational domain, that approach is sufficient.
However, although explicitly outside the scope of this specification, However, although explicitly outside the scope of this specification,
there might be cases where the underlay MTU is not large enough to there might be cases where the underlay MTU is not large enough to
carry the NSH traffic. Since the NSH does not provide fragmentation carry the NSH traffic. Since the NSH does not provide fragmentation
support at the service plane, the overlay layer ought to provide the support at the service plane, the transport encapsulation protocol
requisite fragmentation handling. For instance, Section 9 of ought to provide the requisite fragmentation handling. For instance,
[I-D.ietf-rtgwg-dt-encap] provides exemplary approaches and guidance Section 9 of [I-D.ietf-rtgwg-dt-encap] provides exemplary approaches
for those scenarios. and guidance for those scenarios.
For example, when the NSH is encapsulated in IP, IP-level For example, when the NSH is encapsulated in IP, IP-level
fragmentation coupled with Path MTU Discovery (PMTUD) is used. When, fragmentation coupled with Path MTU Discovery (PMTUD) is used. When,
on the other hand, the underlay does not support fragmentation on the other hand, the underlay does not support fragmentation
procedures, an error message SHOULD be logged when dropping a packet procedures, an error message SHOULD be logged when dropping a packet
too big. Lastly, NSH-specific fragmentation and reassembly methods too big. Lastly, NSH-specific fragmentation and reassembly methods
may be defined as well, but these methods are outside the scope of may be defined as well, but these methods are outside the scope of
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
skipping to change at page 18, line 21 skipping to change at page 18, line 21
network topology but more importantly, service plane only network topology but more importantly, service plane only
participants (i.e., most SFs) need not be part of the network overlay participants (i.e., most SFs) need not be part of the network overlay
topology and its associated infrastructure (e.g., control plane, topology and its associated infrastructure (e.g., control plane,
routing tables, etc.) SFs need to be able to return a packet to an routing tables, etc.) SFs need to be able to return a packet to an
appropriate SFF (i.e., has the requisite NSH information) when appropriate SFF (i.e., has the requisite NSH information) when
service processing is complete. This can be via the overlay or service processing is complete. This can be via the overlay or
underlay and in some cases require additional configuration on the underlay and in some cases require additional configuration on the
SF. As mentioned above, an existing overlay topology may be used SF. As mentioned above, an existing overlay topology may be used
provided it offers the requisite connectivity. provided it offers the requisite connectivity.
The mapping of SPI to transport occurs on an SFF (as discussed above, The mapping of SPI to transport encapsulation occurs on an SFF (as
the first SFF in the path gets an NSH encapsulated packet from the discussed above, the first SFF in the path gets an NSH encapsulated
Classifier). The SFF consults the SPI/ID values to determine the packet from the Classifier). The SFF consults the SPI/ID values to
appropriate overlay transport protocol (several may be used within a determine the appropriate overlay transport encapsulation protocol
given network) and next hop for the requisite SF. Table 1 below (several may be used within a given network) and next hop for the
depicts an example of a single next-hop SPI/SI to network overlay requisite SF. Table 1 below depicts an example of a single next-hop
network locator mapping. SPI/SI to network overlay network locator mapping.
+------+------+---------------------+-------------------+ +------+------+---------------------+-------------------------+
| SPI | SI | Next hop(s) | Transport | | SPI | SI | Next hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------+ +------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe | | 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | | | | | | |
| 10 | 254 | 198.51.100.10 | GRE | | 10 | 254 | 198.51.100.10 | GRE |
| | | | | | | | | |
| 10 | 251 | 198.51.100.15 | GRE | | 10 | 251 | 198.51.100.15 | GRE |
| | | | | | | | | |
| 40 | 251 | 198.51.100.15 | GRE | | 40 | 251 | 198.51.100.15 | GRE |
| | | | | | | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet | | 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | | | | | | |
| 15 | 212 | Null (end of path) | None | | 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------+ +------+------+---------------------+-------------------------+
Table 1: SFF NSH Mapping Example Table 1: SFF NSH Mapping Example
Additionally, further indirection is possible: the resolution of the Additionally, further indirection is possible: the resolution of the
required SF network locator may be a localized resolution on an SFF, required SF network locator may be a localized resolution on an SFF,
rather than a service function chain control plane responsibility, as rather than a service function chain control plane responsibility, as
per Table 2 and Table 3 below. per Table 2 and Table 3 below.
Please note: VXLAN-gpe and GRE in the above table refer to Please note: VXLAN-gpe and GRE in the above table refer to
[I-D.ietf-nvo3-vxlan-gpe] and [RFC2784] [RFC7676], respectively. [I-D.ietf-nvo3-vxlan-gpe] and [RFC2784] [RFC7676], respectively.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
+------+-----+----------------+ +------+-----+----------------+
| 10 | 3 | SF2 | | 10 | 3 | SF2 |
| | | | | | | |
| 245 | 12 | SF34 | | 245 | 12 | SF34 |
| | | | | | | |
| 40 | 9 | SF9 | | 40 | 9 | SF9 |
+------+-----+----------------+ +------+-----+----------------+
Table 2: NSH to SF Mapping Example Table 2: NSH to SF Mapping Example
+------+-------------------+-------------+ +------+-------------------+-------------------------+
| SF | Next hop(s) | Transport | | SF | Next hop(s) | Transport Encapsulation |
+------+-------------------+-------------+ +------+-------------------+-------------------------+
| SF2 | 192.0.2.2 | VXLAN-gpe | | SF2 | 192.0.2.2 | VXLAN-gpe |
| | | | | | | |
| SF34 | 198.51.100.34 | UDP | | SF34 | 198.51.100.34 | UDP |
| | | | | | | |
| SF9 | 2001:db8::1 | GRE | | SF9 | 2001:db8::1 | GRE |
+------+-------------------+-------------+ +------+-------------------+-------------------------+
Table 3: SF Locator Mapping Example Table 3: SF Locator Mapping Example
Since the SPI is a representation of the service path, the lookup may Since the SPI is a representation of the service path, the lookup may
return more than one possible next-hop within a service path for a return more than one possible next-hop within a service path for a
given SF, essentially a series of weighted (equally or otherwise) given SF, essentially a series of weighted (equally or otherwise)
paths to be used (for load distribution, redundancy, or policy), see paths to be used (for load distribution, redundancy, or policy), see
Table 4. The metric depicted in Table 4 is an example to help Table 4. The metric depicted in Table 4 is an example to help
illustrated weighing SFs. In a real network, the metric will range illustrated weighing SFs. In a real network, the metric will range
from a simple preference (similar to routing next-hop), to a true from a simple preference (similar to routing next-hop), to a true
skipping to change at page 20, line 24 skipping to change at page 20, line 24
| | | | | | | | | |
| 30 | 7 | 192.0.2.10 | 10 | | 30 | 7 | 192.0.2.10 | 10 |
| | | | | | | | | |
| | | 198.51.100.1 | 5 | | | | 198.51.100.1 | 5 |
+------+-----+--------------+---------+ +------+-----+--------------+---------+
(encapsulation type omitted for formatting) (encapsulation type omitted for formatting)
Table 4: NSH Weighted Service Path Table 4: NSH Weighted Service Path
6.2. Mapping the NSH to Network Transport 6.2. Mapping the NSH to Network Topology
As described above, the mapping of SPI to network topology may result As described above, the mapping of SPI to network topology may result
in a single path, or it might result in a more complex topology. in a single path, or it might result in a more complex topology.
Furthermore, the SPI to overlay mapping occurs at each SFF Furthermore, the SPI to overlay mapping occurs at each SFF
independently. Any combination of topology selection is possible. independently. Any combination of topology selection is possible.
Please note, there is no requirement to create a new overlay topology Please note, there is no requirement to create a new overlay topology
if a suitable one already exists. NSH packets can use any (new or if a suitable one already exists. NSH packets can use any (new or
existing) overlay provided the requisite connectivity requirements existing) overlay provided the requisite connectivity requirements
are satisfied. are satisfied.
skipping to change at page 22, line 17 skipping to change at page 22, line 17
application is being instantiated and can communicate this application is being instantiated and can communicate this
information to all NSH nodes via metadata carried in the context information to all NSH nodes via metadata carried in the context
header(s). header(s).
Service Functions: A classifier co-resident with Service Functions Service Functions: A classifier co-resident with Service Functions
often perform very detailed and valuable classification. often perform very detailed and valuable classification.
Regardless of the source, metadata reflects the "result" of Regardless of the source, metadata reflects the "result" of
classification. The granularity of classification may vary. For classification. The granularity of classification may vary. For
example, a network switch, acting as a classifier, might only be able example, a network switch, acting as a classifier, might only be able
to classify based on a 5-tuple, while a service function may be able to classify based on a 2-tuple, or based on a 5-tuple, while a
to inspect application information. Regardless of granularity, the service function may be able to inspect application information.
classification information can be represented in the NSH. Regardless of granularity, the classification information can be
represented in the NSH.
Once the data is added to the NSH, it is carried along the service Once the data is added to the NSH, it is carried along the service
path, NSH-aware SFs receive the metadata, and can use that metadata path, NSH-aware SFs receive the metadata, and can use that metadata
for local decisions and policy enforcement. Figure 9 and Figure 10 for local decisions and policy enforcement. Figure 9 and Figure 10
highlight the relationship between metadata and policy: highlight the relationship between metadata and policy:
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| SFF )------->( SFF |------->| SFF | | SFF )------->( SFF |------->| SFF |
+---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+
^ | | ^ | |
skipping to change at page 23, line 34 skipping to change at page 23, line 34
In both of the examples above, the service functions perform policy In both of the examples above, the service functions perform policy
decisions based on the result of the initial classification: the SFs decisions based on the result of the initial classification: the SFs
did not need to perform re-classification; instead, they rely on a did not need to perform re-classification; instead, they rely on a
antecedent classification for local policy enforcement. antecedent classification for local policy enforcement.
Depending on the information carried in the metadata, data privacy Depending on the information carried in the metadata, data privacy
considerations may need to be considered. For example, if the considerations may need to be considered. For example, if the
metadata conveys tenant information, that information may need to be metadata conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the authenticated and/or encrypted between the originator and the
intended recipients (which may include intended SFs only). The NSH intended recipients (which may include intended SFs only); one
itself does not provide privacy functions, rather it relies on the approach to an optional capability to do this is explored in
transport/overlay layer. An operator can select the appropriate [I-D.reddy-sfc-nsh-encrypt]. The NSH itself does not provide privacy
transport to ensure confidentiality (and other security) functions, rather it relies on the transport encapsulation/overlay.
An operator can select the appropriate set of transport encapsulation
protocols to ensure confidentiality (and other security)
considerations are met. Metadata privacy and security considerations considerations are met. Metadata privacy and security considerations
are a matter for the documents that define metadata format. are a matter for the documents that define metadata format.
7.2. Updating/Augmenting Metadata 7.2. Updating/Augmenting Metadata
Post-initial metadata imposition (typically performed during initial Post-initial metadata imposition (typically performed during initial
service path determination), the metadata may be augmented or service path determination), the metadata may be augmented or
updated: updated:
1. Metadata Augmentation: Information may be added to the NSH's 1. Metadata Augmentation: Information may be added to the NSH's
skipping to change at page 26, line 11 skipping to change at page 26, line 11
or otherwise modified in transit. However, the deployment scope (as or otherwise modified in transit. However, the deployment scope (as
defined in [RFC7665]) of the NSH encapsulation is limited to a single defined in [RFC7665]) of the NSH encapsulation is limited to a single
network administrative domain as a controlled environment, with network administrative domain as a controlled environment, with
trusted devices (e.g., a data center) hence mitigating the risk of trusted devices (e.g., a data center) hence mitigating the risk of
unauthorized manipulation of the encapsulation headers or metadata. unauthorized manipulation of the encapsulation headers or metadata.
Packets originating outside the SFC-enabled domain must be dropped if Packets originating outside the SFC-enabled domain must be dropped if
they contain an NSH. Similarly, packets exiting the SFC-enabled they contain an NSH. Similarly, packets exiting the SFC-enabled
domain must be dropped if they contain an NSH. domain must be dropped if they contain an NSH.
NSH is always encapsulated in a transport protocol (as detailed in NSH is always encapsulated in a transport encapsulation protocol (as
Section 4 of this specification); and, therefore, when required, detailed in Section 4 of this specification); and, therefore, when
existing security protocols that provide authenticity (e.g., required, existing security protocols that provide authenticity
[RFC6071]) can be used. Similarly, if confidentiality is required, (e.g., [RFC6071]) can be used. Similarly, if confidentiality is
existing encryption protocols can be used in conjunction with the NSH required, existing encryption protocols can be used in conjunction
encapsulation. with the NSH encapsulation.
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 Even though much of the metadata carried within the NSH encapsulation
is derived from the packet contents, and thus is not privacy or is derived from the packet contents, and thus is not privacy or
security sensitive, The NSH metadata authenticity and confidentiality security sensitive, the NSH metadata authenticity and confidentiality
must be considered as well. In order to protect the metadata, an needs be considered as well. In order to protect the metadata, an
operator can utilize the aforementioned mechanisms provided by the operator can utilize the aforementioned mechanisms provided by the
transport layer including authenticity and/or confidentiality. An transport encapsulation protocols including authenticity and/or
operator MUST carefully select the transport/underlay services to confidentiality. An operator MUST carefully select the transport
ensure end-to-end security services, when those are desired. For encapsulation/underlay services to ensure end-to-end security
example, if [RFC6071] is used, the operator MUST ensure it can be services, when those are desired. For example, if [RFC6071] is used,
supported by the transport/underlay of all relevant network segments the operator MUST ensure it can be supported by the transport
as well as SFFs, SFs and SFC proxies in the service path. Further, encapsulation/underlay of all relevant network segments as well as
as described under the "SFC Encapsulation" area of the Security SFFs, SFs and SFC proxies in the service path. Further, as described
Considerations of [RFC7665], operators can and should use indirect under the "SFC Encapsulation" area of the Security Considerations of
identification for metadata deemed to be sensitive (such as [RFC7665], operators can and should use indirect identification for
personally identifying information) significantly mitigating the risk metadata deemed to be sensitive (such as personally identifying
of privacy violation. In particular, subscriber identifying information) significantly mitigating the risk of privacy violation.
information should be handled carefully, and in general should be In particular, subscriber identifying information should be handled
obfuscated. This is covered in the Security Considerations of carefully, and in general should be obfuscated. This is covered in
[RFC7665]. For those situations where obfuscation is either the Security Considerations of [RFC7665]. For those situations where
inapplicable or judged to be insufficient, an operator can also obfuscation is either inapplicable or judged to be insufficient, an
encrypt the metadata. An approach to an optional capability to do operator can also encrypt the metadata. An approach to an optional
this was explored in [I-D.reddy-sfc-nsh-encrypt]. For other capability to do this was explored in [I-D.reddy-sfc-nsh-encrypt].
situations where greater assurance is desired, optional mechanisms For other situations where greater assurance is desired, optional
such as [I-D.brockners-proof-of-transit] can be used. Means to mechanisms such as [I-D.brockners-proof-of-transit] can be used.
prevent leaking privacy-related information outside an administrative Means to prevent leaking privacy-related information outside an
domain are natively supported by the NSH given that the last SFF of a administrative domain are natively supported by the NSH given that
service path will systematically remove the NSH encapsulation before the last SFF of a service path will systematically remove the NSH
forwarding a packet exiting the service path. encapsulation before forwarding a packet exiting the service path.
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 placement of SFs is assumed to be bounded within the scope of a
single administrative domain and therefore under direct control of single administrative domain and therefore under direct control of
the operator. the operator.
9. Contributors 9. Contributors
skipping to change at page 31, line 5 skipping to change at page 30, line 49
Table 6: MD Class Value Table 6: MD Class Value
Designated Experts evaluating new allocation requests from the Designated Experts evaluating new allocation requests from the
"Expert Review" range should principally consider whether a new MD "Expert Review" range should principally consider whether a new MD
class is needed compared to adding MD types to an existing class. class is needed compared to adding MD types to an existing class.
The Designated Experts should also encourage the existence of an The Designated Experts should also encourage the existence of an
associated and publicly visible registry of MD types although this associated and publicly visible registry of MD types although this
registry need not be maintained by IANA. registry need not be maintained by IANA.
When evaluating a request for an allocation, the Expert should verify
that the allocation plan includes considerations to handle privacy
and security issues associated with the anticipated individual MD
Types allocated within this class. These plans should consider, when
appropriate, alternatives such as indirection, encryption, and
limited deployment scenarios. Information that can't be directly
derived from viewing the packet contents should be examined for
privacy and security implications.
11.2.5. NSH Base Header Next Protocol 11.2.5. NSH Base Header Next Protocol
IANA is requested to set up a registry of "Next Protocol". These are IANA is requested to set up a registry of "Next Protocol". These are
8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined
in this document (see Table 7. New values are assigned via "Expert in this document (see Table 7. New values are assigned via "Expert
Reviews" as per [RFC8126]. Reviews" as per [RFC8126].
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
skipping to change at page 31, line 36 skipping to change at page 31, line 40
| | | | | | | |
| 0x6..0xFD | Unassigned | | | 0x6..0xFD | Unassigned | |
| | | | | | | |
| 0xFE | Experiment 1 | This document | | 0xFE | Experiment 1 | This document |
| | | | | | | |
| 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.
Designated Experts evaluating new allocation requests from this
registry should consider the potential scarcity of code points for an
8-bit value, and check both for duplications as well as availability
of documentation.
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.
The type values are assigned via Standards Action [RFC8126]. The type values are assigned via Standards Action [RFC8126].
 End of changes. 25 change blocks. 
99 lines changed or deleted 118 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/