draft-ietf-sfc-nsh-20.txt   draft-ietf-sfc-nsh-21.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 5, 2018 Intel Expires: March 21, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
September 1, 2017 September 17, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-20 draft-ietf-sfc-nsh-21
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).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 5, 2018. This Internet-Draft will expire on March 21, 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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 . . . . . . . . . . . . . . . . . . . . . 28 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 29
11.2. Network Service Header (NSH) Parameters . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 29 11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 30
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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
such as the wide area network, data center, campus, 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
protocol specified in this document, current service function protocol specified in this document, current service function
deployment models have been relatively static and bound to topology deployment models have been relatively static and bound to topology
for insertion and policy selection. Furthermore, they do not adapt for insertion and policy selection. Furthermore, they do not adapt
well to elastic service environments enabled by virtualization. well to elastic service environments enabled by virtualization.
New data center network and cloud architectures require more flexible New data center network and cloud architectures require more flexible
service function deployment models. Additionally, the transition to service function deployment models. Additionally, the transition to
virtual platforms demands an agile service insertion model that virtual platforms demands an agile service insertion model that
skipping to change at page 4, line 19 skipping to change at page 4, line 19
3. Optional, per packet metadata (fixed length or variable). 3. Optional, per packet metadata (fixed length or variable).
The NSH is designed to be easy to implement across a range of The NSH is designed to be easy to implement across a range of
devices, both physical and virtual, including hardware platforms. devices, both physical and virtual, including hardware platforms.
The intended scope of the NSH is for use within a single provider's The intended scope of the NSH is for use within a single provider's
operational domain. This deployment scope is deliberately operational domain. This deployment scope is deliberately
constrained, as explained also in [RFC7665], and limited to a single constrained, as explained also in [RFC7665], and limited to a single
network administrative domain. In this context, a "domain" is a set network administrative domain. In this context, a "domain" is a set
of network entities within a single administration. For example, a of network entities within a single administration. For example, a
network administrative domain can include a single data center, a network administrative domain can include a single data center, or an
campus physical network, or an overlay domain using virtual overlay domain using virtual connections and tunnels. A corollary is
connections and tunnels. A corollary is that a network that a network administrative domain has a well defined perimeter.
administrative domain has a well defined perimeter.
An NSH-aware control plane is outside the scope of this document. An NSH-aware control plane is outside the scope of this document.
[RFC7665] provides an overview of a service chaining architecture [RFC7665] provides an overview of a service chaining architecture
that clearly defines the roles of the various elements and the scope that clearly defines the roles of the various elements and the scope
of a service function chaining encapsulation. The NSH is the SFC of a service function chaining encapsulation. The NSH is the SFC
encapsulation referenced in [RFC7665]. encapsulation referenced in [RFC7665].
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 26, line 7 skipping to change at page 26, line 7
8. Security Considerations 8. Security Considerations
As with many other protocols, the NSH encapsulation could be spoofed As with many other protocols, the NSH encapsulation could be spoofed
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
they contain an NSH. Similarly, packets exiting the SFC-enabled
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 protocol (as detailed in
Section 4 of this specification); and, therefore, when required, Section 4 of this specification); and, therefore, when required,
existing security protocols that provide authenticity (e.g., existing security protocols that provide authenticity (e.g.,
[RFC6071]) can be used. Similarly, if confidentiality is required, [RFC6071]) can be used. Similarly, if confidentiality is required,
existing encryption protocols can be used in conjunction with the NSH existing encryption protocols can be used in conjunction with the NSH
encapsulation. 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
skipping to change at page 26, line 40 skipping to change at page 26, line 44
as described under the "SFC Encapsulation" area of the Security as described under the "SFC Encapsulation" area of the Security
Considerations of [RFC7665], operators can and should use indirect Considerations of [RFC7665], operators can and should use indirect
identification for metadata deemed to be sensitive (such as identification for metadata deemed to be sensitive (such as
personally identifying information) significantly mitigating the risk personally identifying information) significantly mitigating the risk
of privacy violation. In particular, subscriber identifying of privacy violation. In particular, subscriber identifying
information should be handled carefully, and in general should be information should be handled carefully, and in general should be
obfuscated. This is covered in the Security Considerations of obfuscated. This is covered in the Security Considerations of
[RFC7665]. For those situations where obfuscation is either [RFC7665]. For those situations where obfuscation is either
inapplicable or judged to be insufficient, an operator can also inapplicable or judged to be insufficient, an operator can also
encrypt the metadata. An approach to an optional capability to do encrypt the metadata. An approach to an optional capability to do
this was explored in [I-D.reddy-sfc-nsh-encrypt]. Means to prevent this was explored in [I-D.reddy-sfc-nsh-encrypt]. For other
leaking privacy-related information outside an administrative domain situations where greater assurance is desired, optional mechanisms
are natively supported by the NSH given that the last SFF of a such as [I-D.brockners-proof-of-transit] can be used. 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 service path will systematically remove the NSH encapsulation before
forwarding a packet exiting the service path. 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.
skipping to change at page 31, line 42 skipping to change at page 32, line 4
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].
No initial values are assigned at the creation of the registry. No initial values are assigned at the creation of the registry.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, <https://www.rfc- DOI 10.17487/RFC7665, October 2015,
editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
12.2. Informative References 12.2. Informative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[I-D.brockners-proof-of-transit]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
of Transit", draft-brockners-proof-of-transit-03 (work in
progress), March 2017.
[I-D.guichard-sfc-nsh-dc-allocation] [I-D.guichard-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network
Service Header (NSH) MD Type 1: Context Header Allocation Service Header (NSH) MD Type 1: Context Header Allocation
(Data Center)", draft-guichard-sfc-nsh-dc-allocation-07 (Data Center)", draft-guichard-sfc-nsh-dc-allocation-07
(work in progress), August 2017. (work in progress), August 2017.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work
skipping to change at page 32, line 47 skipping to change at page 33, line 12
Considerations", draft-ietf-rtgwg-dt-encap-02 (work in Considerations", draft-ietf-rtgwg-dt-encap-02 (work in
progress), October 2016. progress), October 2016.
[I-D.ietf-sfc-control-plane] [I-D.ietf-sfc-control-plane]
Boucadair, M., "Service Function Chaining (SFC) Control Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", draft-ietf-sfc-control- Plane Components & Requirements", draft-ietf-sfc-control-
plane-08 (work in progress), October 2016. plane-08 (work in progress), October 2016.
[I-D.ietf-sfc-oam-framework] [I-D.ietf-sfc-oam-framework]
Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan,
R., and A. Ghanwani, "Service Function Chaining Operation, R., and A. Ghanwani, "Service Function Chaining (SFC)
Administration and Maintenance Framework", draft-ietf-sfc- Operation, Administration and Maintenance (OAM)
oam-framework-02 (work in progress), July 2017. Framework", draft-ietf-sfc-oam-framework-03 (work in
progress), September 2017.
[I-D.napper-sfc-nsh-broadband-allocation] [I-D.napper-sfc-nsh-broadband-allocation]
Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. Napper, J., Kumar, S., Muley, P., Henderickx, W., and M.
Boucadair, "NSH Context Header Allocation -- Broadband", Boucadair, "NSH Context Header Allocation -- Broadband",
draft-napper-sfc-nsh-broadband-allocation-03 (work in draft-napper-sfc-nsh-broadband-allocation-03 (work in
progress), July 2017. progress), July 2017.
[I-D.reddy-sfc-nsh-encrypt] [I-D.reddy-sfc-nsh-encrypt]
Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, Reddy, T., Patil, P., Fluhrer, S., and P. Quinn,
"Authenticated and encrypted NSH service chains", draft- "Authenticated and encrypted NSH service chains", draft-
reddy-sfc-nsh-encrypt-00 (work in progress), April 2015. reddy-sfc-nsh-encrypt-00 (work in progress), April 2015.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, <https://www.rfc- DOI 10.17487/RFC2784, March 2000,
editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004, <https://www.rfc- DOI 10.17487/RFC3692, January 2004,
editor.org/info/rfc3692>. <https://www.rfc-editor.org/info/rfc3692>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011, <https://www.rfc- DOI 10.17487/RFC6071, February 2011,
editor.org/info/rfc6071>. <https://www.rfc-editor.org/info/rfc6071>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <https://www.rfc-editor.org/info/rfc7325>. August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[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, <https://www.rfc- DOI 10.17487/RFC7498, April 2015,
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, <https://www.rfc- DOI 10.17487/RFC7676, October 2015,
editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: paulq@cisco.com Email: paulq@cisco.com
Uri Elzur (editor) Uri Elzur (editor)
Intel Intel
Email: uri.elzur@intel.com Email: uri.elzur@intel.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 25 change blocks. 
38 lines changed or deleted 50 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/