RFC 8300
Network Service Header (NSH)
7. Policy Enforcement with NSH
7.1. NSH Metadata and Policy Enforcement
As described in Section 2, NSH provides the ability to carry metadata along a service path. This metadata may be derived from several sources. Common examples include: Network nodes/devices: Information provided by network nodes can indicate network-centric information (such as VPN Routing and Forwarding (VRF) or tenant) that may be used by Service Functions or conveyed to another network node post service path egress. External (to the network) systems: External systems, such as orchestration systems, often contain information that is valuable for Service Function policy decisions. In most cases, this information cannot be deduced by network nodes. For example, a cloud orchestration platform placing workloads "knows" what application is being instantiated and can communicate this information to all NSH nodes via metadata carried in the Context Header(s). Service Functions: A Classifier co-resident with Service Functions often performs very detailed and valuable classification. Regardless of the source, metadata reflects the "result" of classification. The granularity of classification may vary. For example, a network switch, acting as a Classifier, might only be able to classify based on a 2-tuple, or based on a 5-tuple, while a Service Function may be able to inspect application information. 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 path. NSH-aware SFs receive the metadata, and can use that metadata for local decisions and policy enforcement. Figures 9 and 10 highlight the relationship between metadata and policy. +-------+ +-------+ +-------+ | SFF )------->( SFF |------->| SFF | +---+---+ +---+---+ +---+---+ ^ | | ,-|-. ,-|-. ,-|-. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ ify / \ / \ / `---' `---' `---' 5-tuple: Permit Inspect Tenant A Tenant A AppY AppY Figure 9: Metadata and Policy +-----+ +-----+ +-----+ | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ^ | | ,-+-. ,-+-. ,-+-. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ ify / \ / \ / `-+-' `---' `---' | Permit Deny AppZ +---+---+ employees | | +-------+ External system: Employee AppZ Figure 10: External Metadata and Policy In both of the examples above, the Service Functions perform policy decisions based on the result of the initial classification: the SFs did not need to perform re-classification; instead, they rely on an antecedent classification for local policy enforcement. Depending on the information carried in the metadata, data privacy impact needs to be considered. For example, if the metadata conveys tenant information, that information may need to be authenticated
and/or encrypted between the originator and the intended recipients (which may include intended SFs only); one approach to an optional capability to do this is explored in [NSH-ENCRYPT]. The NSH itself does not provide privacy 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 are a matter for the documents that define metadata format.7.2. Updating/Augmenting Metadata
Post-initial metadata imposition (typically, performed during initial service path determination), the metadata may be augmented or updated: 1. Metadata Augmentation: Information may be added to the NSH's existing metadata, as depicted in Figure 11. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with deep packet inspection (DPI) or server load balancing (SLB)) may augment the tenant classification with application information, and impose that new information in NSH metadata. The tenant classification is still valid and present, but additional information has been added to it. 2. Metadata Update: Subsequent Classifiers may update the initial classification if it is determined to be incorrect or not descriptive enough. For example, the initial Classifier adds metadata that describes the traffic as "Internet", but a security Service Function determines that the traffic is really "attack". Figure 12 illustrates an example of updating metadata.
+-----+ +-----+ +-----+ | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ^ | | ,---. ,---. ,---. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ / \ / \ / `-+-' `---' `---' | Inspect Deny +---+---+ employees employee+ | | Class=AppZ appZ +-------+ External system: Employee Figure 11: Metadata Augmentation +-----+ +-----+ +-----+ | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ^ | | ,---. ,---. ,---. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ / \ / \ / `---' `---' `---' 5-tuple: Inspect Deny Tenant A Tenant A attack --> attack Figure 12: Metadata Update7.3. Service Path Identifier and Metadata
Metadata information may influence the service path selection since the Service Path Identifier values can represent the result of classification. A given SPI can be defined based on classification results (including metadata classification). The imposition of the SPI and SI results in the packet being placed on the newly specified SFP at the position indicated by the imposed SPI and SI. This relationship provides the ability to create a dynamic service plane based on complex classification, without requiring each node to be capable of such classification or requiring a coupling to the network topology. This yields Service Graph functionality as
described in Section 6.4. Figure 13 illustrates an example of this behavior. +-----+ +-----+ +-----+ | SFF |---------> | SFF |------+---> | SFF | +--+--+ +--+--+ | +--+--+ | | | | ,---. ,---. | ,---. / \ / SF1 \ | / \ ( SCL ) ( + ) | ( SF2 ) \ / \SCL2 / | \ / `---' `---' +-----+ `---' 5-tuple: Inspect | SFF | Original Tenant A Tenant A +--+--+ next SF --> DoS | V ,-+-. / \ ( SF10 ) \ / `---' DoS "Scrubber" Legend: SCL = Service Classifier Figure 13: Path ID and Metadata Specific algorithms for mapping metadata to an SPI are outside the scope of this document.8. Security Considerations
NSH security must be considered in the contexts of the SFC architecture and operators' environments. One important characteristic of NSH is that it is not an end-to-end protocol. As opposed to a protocol that "starts" on a host and "ends" on a server or another host, NSH is typically imposed by a network device on ingress to the SFC domain and removed at the egress of the SFC domain. As such, and as with any other network-centric protocols (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider- Provisioned Virtual Private Networks), there is an underlying trust in the network devices responsible for imposing, removing, and acting on NSH information. The following sections detail an analysis and present a set of requirements and recommendations in those two areas.
8.1. NSH Security Considerations from Operators' Environments
Trusted Devices All Classifiers, SFFs and SFs (hereinafter referred to as "SFC devices") within an operator's environment are assumed to have been selected, vetted, and actively maintained; therefore, they are trusted by that operator. This assumption differs from the oft held view that devices are untrusted, often referred to as the "zero-trust model". Operators SHOULD regularly monitor (i.e., continuously audit) these devices to help ensure compliant behavior. This trust, therefore, extends into NSH operations: SFC devices are not, themselves, considered to be attack vectors. This assumption, and the resultant conclusion is reasonable since this is the very basis of an operator posture; the operator depends on this reality to function. If these devices are not trusted, and indeed are compromised, almost the entirety of the operator's standard-based IP and MPLS protocol suites are vulnerable; therefore, the operation of the entire network is compromised. Although there are well-documented monitoring-based methods for detecting compromise (such as included continuous monitoring and 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 documented and outside the scope of this document. Single Domain Boundary As per [RFC7665], NSH is designed for use within a single administrative domain. This scoping provides two important characteristics: i) Clear NSH boundaries NSH egress devices MUST strip the NSH headers before they send the users' packets or frames out of the NSH domain. Means to prevent leaking privacy-related information outside an administrative domain are natively supported by the NSH given that the last SFF of a service path will systematically remove the NSH encapsulation before forwarding a packet exiting the service path. The second step in such prevention is to filter the transport encapsulation protocol used by NSH at the domain edge. The transport encapsulation protocol MUST be filtered and MUST NOT leave the domain edge.
Depending upon the transport encapsulation protocol used for NSH,
this can be done either by completely blocking the transport
encapsulation (e.g., if MPLS is the chosen NSH transport
encapsulation protocol, it is therefore never allowed to leave the
domain) or by examining the carried protocol with the transport
encapsulation (e.g., if VXLAN-gpe is used as the NSH transport
encapsulation protocol, all domain edges need to filter based on
the carried protocol in the VXLAN-gpe.)
The other consequence of this bounding is that ingress packets
MUST also be filtered to prevent attackers from sending in NSH
packets with service path identification and metadata of their own
selection. The same filters as described above for both the NSH
at SFC devices and for the transport encapsulation protocol as
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.
ii) Mitigation of external threats
As per the trusted SFC device points raised above, given that NSH
is scoped within an operator's domain, that operator can ensure
that the environment and its transitive properties comply with
that operator's required security posture. Continuous audits for
assurance are recommended with this reliance on a fully trusted
environment. The term "continuous audits" describes a method
(automated or manual) of checking security-control compliance on a
regular basis, at some set period of time.
8.2. NSH Security Considerations from the SFC Architecture
The SFC architecture defines functional roles (e.g., SFF), as well as
protocol elements (e.g., Metadata). This section considers each role
and element in the context of threats posed in the areas of integrity
and confidentiality. As with routing, the distributed computation
model assumes a distributed trust model.
An important consideration is that NSH contains mandatory-to-mute
fields, and further, the SFC architecture describes cases where other
fields in NSH change, all on a possible SFP hop-by-hop basis. This
means that any cryptographic solution requires complex key
distribution and life-cycle operations.
8.2.1. Integrity
SFC devices SFC devices MAY perform various forms of verification on received NSH packets such as only accepting NSH packets from expected devices, checking that NSH SPI and SI values received from expected devices conform to expected values and so on. Implementation of these additional checks are a local matter and, thus, out of scope of this document. NSH Base and Service Path Headers Attackers who can modify packets within the operator's network may be able to modify the SFP, path position, and/or the metadata associated with a packet. One specific concern is an attack in which a malicious modification of the SPI/SI results in an alteration of the path to avoid security devices. The options discussed in this section help thwart that attack, and so does the use of the optional "Proof of Transit" method [PROOF-OF-TRANSIT]. As stated above, SFC devices are trusted; in the case where an SFC device is compromised, NSH integrity protection would be subject to forging (in many cases) as well. NSH itself does not mandate protocol-specific integrity protection. However, if an operator deems protection is required, several options are viable: 1. SFF/SF NSH verification Although, strictly speaking, not integrity protection, some of the techniques mentioned above, such as checking expected NSH values are received from expected SFC device(s), can provide a form of verification without incurring the burden of a full- fledged integrity-protection deployment. 2. Transport Security NSH is always encapsulated by an outer transport encapsulation as detailed in Section 4 of this specification, and as depicted in Figure 1. If an operator deems cryptographic integrity protection necessary due to their risk analysis, then an outer transport encapsulation that provides such protection [RFC6071], such as IPsec, MUST be used.
Although the threat model and recommendations of Section 5 of
BCP 72 [RFC3552] 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
secure transport, such as IPsec can be used for carry NSH.
IPsec can be used either alone or in conjunction with other
transport encapsulation protocols, in turn, encapsulating NSH.
Operators MUST ensure the selected transport encapsulation
protocol can be supported by the transport encapsulation/
underlay of all relevant network segments as well as SFFs,
SFs, and SFC Proxies in the service path.
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
Lastly, NSH MD Type 2 provides, via variable-length headers,
the ability to append cryptographic integrity protection to
the NSH packet. The implementation of such a scheme is
outside the scope of this document.
NSH metadata
As with the Base and Service Path Headers, if an operator deems
cryptographic integrity protection needed, then an existing,
standard transport protocol MUST be used since the integrity
protection applies to entire encapsulated NSH packets. As
mentioned above, a risk assessment that deems data-plane traffic
subject to tampering will apply not only to NSH but to the
transport information; therefore, the use of a secure transport is
likely needed already to protect the entire stack.
If an MD Type 2 variable header integrity scheme is in place, then
the integrity of the metadata can be ensured via that mechanism as
well.
8.2.2. Confidentiality
SFC devices SFC devices can "see" (and need to use) NSH information. NSH Base and Service Path Headers SPI and other base / service path information does not typically require confidentiality; however, if an operator does deem confidentiality to be required, then, as with integrity, an existing transport encapsulation that provides encryption MUST be utilized. NSH metadata An attacker with access to the traffic in an operator's network can potentially observe the metadata NSH carries with packets, potentially discovering privacy-sensitive information. Much of the metadata carried by NSH is not sensitive. It often reflects information that can be derived from the underlying packet or frame. Direct protection of such information is not necessary, as the risks are simply those of carrying the underlying packet or frame. Implementers and operators MUST be aware that metadata can have privacy implications, and those implications are sometimes hard to predict. Therefore, attached metadata should be limited to that necessary for correct operation of the SFP. Further, [RFC8165] defines metadata considerations that operators can take into account when using NSH. Protecting NSH metadata information between SFC components can be done using transport encapsulation protocols with suitable security capabilities, along the lines discussed above. If a security analysis deems these protections necessary, then security features in the transport encapsulation protocol (such as IPsec) MUST be used. One useful element of providing privacy protection for sensitive metadata is described under the "SFC Encapsulation" area of the Security Considerations of [RFC7665]. Operators can and should use indirect identification for metadata deemed to be sensitive (such as personally identifying information), significantly mitigating the risk of a privacy violation. In particular, subscriber-identifying information should be handled carefully, and, in general, SHOULD be obfuscated.
For those situations where obfuscation is either inapplicable or
judged to be insufficient, an operator can also encrypt the
metadata. An approach to an optional capability to do this was
explored in [NSH-ENCRYPT]. For other situations where greater
assurance is desired, optional mechanisms such as
[PROOF-OF-TRANSIT] can be used.
9. IANA Considerations
9.1. NSH Parameters
IANA has created a new "Network Service Header (NSH) Parameters"
registry. The following subsections detail new registries within the
"Network Service Header (NSH) Parameters" registry.
9.1.1. NSH Base Header Bits
There are five unassigned bits (U bits) in the NSH Base Header, and
one assigned bit (O bit). New bits are assigned via Standards Action
[RFC8126].
Bit 2 - O (OAM) bit
Bit 3 - Unassigned
Bits 16-19 - Unassigned
9.1.2. NSH Version
IANA has set up the "NSH Version" registry. New values are assigned
via Standards Action [RFC8126].
+-------------+---------------------------------+-----------+
| Version | Description | Reference |
+-------------+---------------------------------+-----------+
| Version 00b | Protocol as defined by RFC 8300 | RFC 8300 |
| Version 01b | Reserved | RFC 8300 |
| Version 10b | Unassigned | |
| Version 11b | Unassigned | |
+-------------+---------------------------------+-----------+
Table 5: NSH Version
9.1.3. NSH MD Types
IANA has set up the "NSH MD Types" registry, which contains 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in this document; see Table 6. Registry entries are assigned via the "IETF Review" policy defined in RFC 8126 [RFC8126]. +-----------+-----------------+-----------+ | MD Type | Description | Reference | +-----------+-----------------+-----------+ | 0x0 | Reserved | RFC 8300 | | | | | | 0x1 | NSH MD Type 1 | RFC 8300 | | | | | | 0x2 | NSH MD Type 2 | RFC 8300 | | | | | | 0x3 - 0xE | Unassigned | | | | | | | 0xF | Experimentation | RFC 8300 | +-----------+-----------------+-----------+ Table 6: MD Type Values9.1.4. NSH MD Class
IANA has set up the "NSH MD Class" registry, which contains 16-bit values. New allocations are to be made according to the following policies: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review IANA has assigned the values as follows: +------------------+------------------------+------------+ | Value | Meaning | Reference | +------------------+------------------------+------------+ | 0x0000 | IETF Base NSH MD Class | RFC 8300 | | | | | | 0xfff6 to 0xfffe | Experimental | RFC 8300 | | | | | | 0xffff | Reserved | RFC 8300 | +------------------+------------------------+------------+ Table 7: NSH MD Class A registry for Types for the MD Class of 0x0000 is defined in Section 9.1.5.
Designated Experts evaluating new allocation requests from the "Expert Review" range should principally consider whether a new MD class is needed compared to adding MD Types to an existing class. The Designated Experts should also encourage the existence of an associated and publicly visible registry of MD Types although this 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.9.1.5. NSH IETF-Assigned Optional Variable-Length Metadata Types
The Type values within the IETF Base NSH MD Class, i.e., when the MD Class is set to 0x0000 (see Section 9.1.4), are the Types owned by the IETF. Per this document, IANA has created a registry for the Type values for the IETF Base NSH MD Class called the "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry, as specified in Section 2.5.1. The type values are assigned via Standards Action [RFC8126]. No initial values are assigned at the creation of the registry.
9.1.6. NSH Next Protocol
IANA has set up the "NSH Next Protocol" registry, which contains 8-bit values. Next Protocol values 0, 1, 2, 3, 4, and 5 are defined in this document (see Table 8). New values are assigned via "Expert Review" as per [RFC8126]. +---------------+--------------+-----------+ | Next Protocol | Description | Reference | +---------------+--------------+-----------+ | 0x00 | Unassigned | | | | | | | 0x01 | IPv4 | RFC 8300 | | | | | | 0x02 | IPv6 | RFC 8300 | | | | | | 0x03 | Ethernet | RFC 8300 | | | | | | 0x04 | NSH | RFC 8300 | | | | | | 0x05 | MPLS | RFC 8300 | | | | | | 0x06 - 0xFD | Unassigned | | | | | | | 0xFE | Experiment 1 | RFC 8300 | | | | | | 0xFF | Experiment 2 | RFC 8300 | +---------------+--------------+-----------+ Table 8: NSH Base Header Next Protocol Values Expert Review requests MUST include a single codepoint per request. Designated Experts evaluating new allocation requests from this registry should consider the potential scarcity of codepoints for an 8-bit value, and check both for duplications and availability of documentation. If the actual assignment of the Next Protocol field allocation reaches half of the range (that is, when there are 128 unassigned values), IANA needs to alert the IESG. At that point, a new more strict allocation policy SHOULD be considered.10. NSH-Related Codepoints
10.1. NSH Ethertype
An IEEE Ethertype, 0x894F, has been allocated for NSH.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.11.2. Informative References
[NSH-BROADBAND-ALLOCATION] Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. Boucadair, "NSH Context Header Allocation -- Broadband", Work in Progress, draft-napper-sfc-nsh-broadband- allocation-04, November 2017. [NSH-DC-ALLOCATION] Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)", Work in Progress, draft-guichard-sfc-nsh-dc-allocation-07, August 2017. [NSH-ENCRYPT] Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, "Authenticated and encrypted NSH service chains", Work in Progress, draft-reddy-sfc-nsh-encrypt-00, April 2015.
[PROOF-OF-TRANSIT] Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof of Transit", Work in Progress, draft-brockners-proof- of-transit-04, October 2017. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <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 Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/info/rfc3692>. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>. [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>. [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, <https://www.rfc-editor.org/info/rfc7325>. [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>. [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, <https://www.rfc-editor.org/info/rfc7676>.
[RFC8165] Hardie, T., "Design Considerations for Metadata Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, <https://www.rfc-editor.org/info/rfc8165>. [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>. [RTG-ENCAP] Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation Considerations", Work in Progress, draft-ietf-rtgwg-dt-encap-02, October 2016. [SFC-CONTROL-PLANE] Boucadair, M., "Service Function Chaining (SFC) Control Plane Components & Requirements", Work in Progress, draft-ietf-sfc-control-plane-08, October 2016. [SFC-OAM-FRAMEWORK] Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, R., and A. Ghanwani, "Service Function Chaining (SFC) Operation, Administration and Maintenance (OAM) Framework", Work in Progress, draft-ietf-sfc-oam-framework-03, September 2017. [VXLAN-GPE] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-05, October 2017.Acknowledgments
The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Mizrahi, and Ken Gray for their detailed reviews, comments, and contributions. A special thank you goes to David Ward and Tom Edsall for their guidance and feedback. Additionally, the authors would like to thank Larry Kreeger for his invaluable ideas and contributions, which are reflected throughout this document. Loa Andersson provided a thorough review and valuable comments; we thank him for that.
Reinaldo Penno deserves a particular thank you for his architecture and implementation work that helped guide the protocol concepts and design. The editors also acknowledge comprehensive reviews and respective useful suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder, Acee Lindem, and Kathleen Moriarty. Lastly, David Dolson has provided significant review, feedback, and suggestions throughout the evolution of this document. His contributions are very much appreciated.Contributors
This WG document originated as draft-quinn-sfc-nsh; the following are its coauthors and contributors along with their respective affiliations at the time of WG adoption. The editors of this document would like to thank and recognize them and their contributions. These coauthors and contributors provided invaluable concepts and content for this document's creation. o Jim Guichard, Cisco Systems, Inc. o Surendra Kumar, Cisco Systems, Inc. o Michael Smith, Cisco Systems, Inc. o Wim Henderickx, Alcatel-Lucent o Tom Nadeau, Brocade o Puneet Agarwal o Rajeev Manur, Broadcom o Abhishek Chauhan, Citrix o Joel Halpern, Ericsson o Sumandra Majee, F5 o David Melman, Marvell o Pankaj Garg, Microsoft o Brad McConnell, Rackspace o Chris Wright, Red Hat, Inc. o Kevin Glavin, Riverbed o Hong (Cathy) Zhang, Huawei US R&D o Louis Fourie, Huawei US R&D o Ron Parker, Affirmed Networks o Myo Zarny, Goldman Sachs o Andrew Dolganow, Alcatel-Lucent o Rex Fernando, Cisco Systems, Inc. o Praveen Muley, Alcatel-Lucent o Navindra Yadav, Cisco Systems, Inc.
Authors' Addresses
Paul Quinn (editor) Cisco Systems, Inc. Email: paulq@cisco.com Uri Elzur (editor) Intel Email: uri.elzur@intel.com Carlos Pignataro (editor) Cisco Systems, Inc. Email: cpignata@cisco.com