draft-ietf-sfc-nsh-27.txt   draft-ietf-sfc-nsh-28.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: April 23, 2018 Intel Expires: May 7, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
October 20, 2017 November 3, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-27 draft-ietf-sfc-nsh-28
Abstract Abstract
This document describes a Network Service Header (NSH) imposed on This document describes a Network Service Header (NSH) imposed on
packets or frames to realize service function paths. The NSH also packets or frames to realize service function paths. The NSH also
provides a mechanism for metadata exchange along the instantiated provides a mechanism for metadata exchange along the instantiated
service paths. The NSH is the SFC encapsulation required to support service paths. The NSH is the SFC encapsulation required to support
the Service Function Chaining (SFC) architecture (defined in the Service Function Chaining (SFC) architecture (defined in
RFC7665). RFC7665).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2018. This Internet-Draft will expire on May 7, 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 40 skipping to change at page 2, line 40
6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21
6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 22 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 22
7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22
7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22
7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 24 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 24
7.3. Service Path Identifier and Metadata . . . . . . . . . . 25 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. NSH Security Considerations from Operators' Environments 27 8.1. NSH Security Considerations from Operators' Environments 27
8.2. NSH Security Considerations from the SFC Architecture . . 28 8.2. NSH Security Considerations from the SFC Architecture . . 28
8.2.1. Integrity . . . . . . . . . . . . . . . . . . . . . . 29 8.2.1. Integrity . . . . . . . . . . . . . . . . . . . . . . 29
8.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 30 8.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 31
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Network Service Header (NSH) Parameters . . . . . . . . 33 11.1. Network Service Header (NSH) Parameters . . . . . . . . 34
11.1.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 33 11.1.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 34
11.1.2. NSH Version . . . . . . . . . . . . . . . . . . . . 34 11.1.2. NSH Version . . . . . . . . . . . . . . . . . . . . 34
11.1.3. MD Type Registry . . . . . . . . . . . . . . . . . . 34 11.1.3. MD Type Registry . . . . . . . . . . . . . . . . . . 34
11.1.4. MD Class Registry . . . . . . . . . . . . . . . . . 34 11.1.4. MD Class Registry . . . . . . . . . . . . . . . . . 35
11.1.5. New IETF Assigned Optional Variable Length Metadata 11.1.5. New IETF Assigned Optional Variable Length Metadata
Type Registry . . . . . . . . . . . . . . . . . . . 35 Type Registry . . . . . . . . . . . . . . . . . . . 36
11.1.6. NSH Base Header Next Protocol . . . . . . . . . . . 35 11.1.6. NSH Base Header Next Protocol . . . . . . . . . . . 36
12. NSH-Related Codepoints . . . . . . . . . . . . . . . . . . . 36 12. NSH-Related Codepoints . . . . . . . . . . . . . . . . . . . 37
12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 36 12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1. Normative References . . . . . . . . . . . . . . . . . . 36 13.1. Normative References . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . 37 13.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 3, line 41 skipping to change at page 3, line 41
1. The movement of service functions and application workloads in 1. The movement of service functions and application workloads in
the network. the network.
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 data
and associated encapsulation for the creation of dynamic service plane protocol, which is an encapsulation for service function
chains, operating at the service plane. The NSH is designed to chains. The NSH is designed to encapsulate an original packet or
encapsulate an original packet or frame, and in turn be encapsulated frame, and in turn be encapsulated by an outer transport
by an outer transport encapsulation (which is used to deliver the NSH encapsulation (which is used to deliver the NSH to NSH-aware network
to NSH-aware network elements), as shown in Figure 1: 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 27, line 21 skipping to change at page 27, line 21
been selected, vetted, and actively maintained, therefore trusted been selected, vetted, and actively maintained, therefore trusted
by that operator. This assumption differs from the oft held view by that operator. This assumption differs from the oft held view
that devices are untrusted, often refered to as zero trust model. that devices are untrusted, often refered to as zero trust model.
Operators SHOULD regularly monitor (i.e. continuously audit) these Operators SHOULD regularly monitor (i.e. continuously audit) these
devices to help ensure complaint behavior. This trust, therefore, devices to help ensure complaint behavior. This trust, therefore,
extends into NSH operations: SFC devices are not, themselves, extends into NSH operations: SFC devices are not, themselves,
considered as attack vectors. This assumption, and the resultant considered as attack vectors. This assumption, and the resultant
conclusion is reasonable since this is the very basis of an conclusion is reasonable since this is the very basis of an
operator posture; the operator depends on this reality to operator posture; the operator depends on this reality to
function. If these devices are not trusted, and indeed function. If these devices are not trusted, and indeed
compromised, almost the entirety of the operator's standard- based compromised, almost the entirety of the operator's standard-based
IP and MPLS protocol suites are vulnerable, and therefore the IP and MPLS protocol suites are vulnerable, and therefore the
operation of the entire network is compromised. Methods for operation of the entire network is compromised. Although there
detecting a compromise are well documented, and include continous are well documented monitoring-based methods for detecting
monitoring, audit and log review. compromise, such as include continous monitoring, audit and log
review, these may not be sufficient to contain damage by a
completely compromised element.
Methods and best practices to secure devices are also widely Methods and best practices to secure devices are also widely
documented and outside the scope of this document. documented and outside the scope of this document.
Single Domain Boundary Single Domain Boundary
As per [RFC7665], NSH is designed for use within a single As per [RFC7665], NSH is designed for use within a single
administrative domain. This scoping provides two important administrative domain. This scoping provides two important
characteristics: characteristics:
skipping to change at page 30, line 7 skipping to change at page 30, line 7
2. Transport Security 2. Transport Security
NSH is always encapsulated by an outer transport encapsulation NSH is always encapsulated by an outer transport encapsulation
as detailed in Section 4 of this specification, and as as detailed in Section 4 of this specification, and as
depicted in Figure 1. If an operator deems cryptographic depicted in Figure 1. If an operator deems cryptographic
integrity protection necessary due to their risk analysis, integrity protection necessary due to their risk analysis,
then an outer transport encapsulation that provides such then an outer transport encapsulation that provides such
protection [RFC6071], such as IPsec, MUST be used. protection [RFC6071], such as IPsec, MUST be used.
Although the threat model and recommendations of BCP 72
[RFC3552] Section 5 would normally require cryptographic data
origin authentication for the header, this document does not
mandate such mechanisms in order to reflect the operational
and technical realities of deployment.
Given that NSH is transport independent, as mentioned above, a Given that NSH is transport independent, as mentioned above, a
secure transport, such as IPsec can be used for carry NSH. secure transport, such as IPsec can be used for carry NSH.
IPsec can be used either alone, or in conjunction with other IPsec can be used either alone, or in conjunction with other
transport encapsulation protocols in turn encapsulating NSH. transport encapsulation protocols in turn encapsulating NSH.
Operators MUST ensure the selected transport encapsulation Operators MUST ensure the selected transport encapsulation
protocol can be supported by the transport encapsulation/ protocol can be supported by the transport encapsulation/
underlay of all relevant network segments as well as SFFs, SFs underlay of all relevant network segments as well as SFFs, SFs
and SFC proxies in the service path. and SFC proxies in the service path.
If connectivity between SFC-enabled devices traverses the
public Internet, then such connectivity MUST be secured at the
transport encapsulation layer. IPsec is an example of such a
transport.
3. NSH Variable Header-based Integrity 3. NSH Variable Header-based Integrity
Lastly, NSH MD-Type 2 provides, via variable length headers, Lastly, NSH MD-Type 2 provides, via variable length headers,
the ability to append cryptographic integrity protection to the ability to append cryptographic integrity protection to
the NSH packet. The implementation of such a scheme is the NSH packet. The implementation of such a scheme is
outside the scope of this document. outside the scope of this document.
NSH metadata NSH metadata
As with the base and service path headers, if an operator deems As with the base and service path headers, if an operator deems
skipping to change at page 37, line 20 skipping to change at page 38, line 20
[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>.
13.2. Informative References 13.2. Informative References
[I-D.brockners-proof-of-transit] [I-D.brockners-proof-of-transit]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
of Transit", draft-brockners-proof-of-transit-03 (work in of Transit", draft-brockners-proof-of-transit-04 (work in
progress), March 2017. progress), October 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-05 (work
in progress), April 2017. in progress), October 2017.
[I-D.ietf-rtgwg-dt-encap] [I-D.ietf-rtgwg-dt-encap]
Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
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-
skipping to change at page 38, line 21 skipping to change at page 39, line 21
[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, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[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, DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-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, DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>. <https://www.rfc-editor.org/info/rfc6071>.
 End of changes. 17 change blocks. 
31 lines changed or deleted 49 lines changed or added

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