Internet DRAFT - draft-kumar-sfc-nsh-udp-transport
draft-kumar-sfc-nsh-udp-transport
Service Function Chaining S. Kumar, Ed.
Internet-Draft L. Kreeger, Ed.
Intended status: Standards Track Cisco Systems, Inc.
Expires: August 26, 2017 S. Majee
F5 Networks
W. Haeffner
Vodafone
R. Manur
Broadcom
D. Melman
Marvell
February 22, 2017
UDP Transport for Network Service Header
draft-kumar-sfc-nsh-udp-transport-03
Abstract
This draft describes the transport encapsulation to carry Network
Service Header (NSH) over UDP transport protocol. This enables
applications and services using NSH to communicate over a simple
layer-3 network without topological constraints. It brings down the
barrier to deploy NSH by not requiring additional overhead as is
typical of overlay encapsulation mechanisms designed on top of UDP.
As a first benefit, this method eases the deployment of Service
Function Chaining (SFC) by allowing SFC components to utilize the
basic UDP/IP stack available in virtually all network elements and
end systems to setup the virtual network and realize Service Function
Chains (SFCs).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2017.
Kumar, et al. Expires August 26, 2017 [Page 1]
Internet-Draft NSH UDP Transport February 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability and Operating Environments . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. NSH UDP Overlay Transport Encapsulation . . . . . . . . . . . 5
3.1. Stacking And Layering . . . . . . . . . . . . . . . . . . 5
3.2. NSH UDP Overlay Packet Format . . . . . . . . . . . . . . 5
4. UDP Encapsulation Considerations . . . . . . . . . . . . . . 7
4.1. UDP Transport End-points . . . . . . . . . . . . . . . . 7
4.2. UDP Source Port Considerations . . . . . . . . . . . . . 7
4.3. Checksum Considerations . . . . . . . . . . . . . . . . . 8
4.3.1. IPv4 Checksum Processing . . . . . . . . . . . . . . 8
4.3.2. IPv6 Checksum Processing . . . . . . . . . . . . . . 8
4.3.3. UDP-Lite Considerations . . . . . . . . . . . . . . . 10
4.4. Congestion Considerations . . . . . . . . . . . . . . . . 10
4.5. MTU and Fragmentation Considerations . . . . . . . . . . 11
4.6. Middlebox Considerations . . . . . . . . . . . . . . . . 12
4.7. Differentiated Services and ECN Considerations . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
NSH is an encapsulation designed to carry SFC specific information
and metadata. It is very flexible in providing fixed and variable
length encapsulation options while allowing for a high degree of
Kumar, et al. Expires August 26, 2017 [Page 2]
Internet-Draft NSH UDP Transport February 2017
extensibility. NSH in addition allows for carrying a variety of
packets as payload, there by acting as a shim header between the
inner payload and the outer transport.
NSH focuses on the application aspect of the encapsulation while
leaving the transport mechanisms out of scope. This design choice is
meant to allow NSH to be carried on any transport as required by the
application and the use cases.
The transport independence aspect of NSH makes it necessary for
existing transport protocols or new ones to carry NSH encapsulated
packet as a payload. Given that IP networks are ubiquitous with
virtually every device, element, node connected to the IP network
possessing the ability to support UDP datagram transport over IP
layer, it is one of the most basic of the transports to carry NSH.
UDP as a transport provides many benefits which has made it the de-
facto choice for creating virtual networks such as VxLAN [RFC7348].
By nature it is a datagram service and trades reliability for
simplicity and reduced overhead. It allows for sufficient entropy,
for the network to exploit, in load balancing packets across paths in
the network. Likewise, end hosts exploit it to distribute packets
between the NICs and processor cores, for optimum performance. To
this end, network elements and end hosts, both hardware and software,
implement specific mechanisms to optimize UDP packet processing.
UDP datagram service and efficient implementations of it in existing
networks is thus a forgone conclusion. These benefits among others,
coupled with extensibility aspect of NSH - to implement security,
header verification, etc., makes UDP a very simple, widely available
and foundational choice for transporting NSH encapsulated packets.
This draft describes the considerations for the creation of on-demand
point-to-point lightweight UDP tunnels to transport NSH encapsulated
packets, hereafter abbreviated as NSH-OVER-UDP.
1.1. Applicability and Operating Environments
NSH is an encapsulation carrying control information and metadata in
addition to the packet or frame for service delivery. NSH base
header contains the next protocol field to specify the payload type
encapsulated. Supported payload types include IPv4, IPv6 and
Ethernet, not including the experimental types. UDP as a transport
for NSH hence is tunneling IPv4, IPv6 and Ethernet packets or frames
encapsulated in NSH.
This draft follows the usage guidelines outlined in
[I-D.ietf-tsvwg-rfc5405bis] in specifying the usage of UDP as a
Kumar, et al. Expires August 26, 2017 [Page 3]
Internet-Draft NSH UDP Transport February 2017
transport for NSH. [I-D.ietf-tsvwg-rfc5405bis] offers guidelines for
application and protocol designers to consider and adopt when using
UDP as a transport. It primarily focusses on congestion control to
prevent congestion collapse and to provide fairness for all users of
capacity along the path while also providing other recommendations.
In particular, it identifies two types of applicability for the
specification of applications, such as this draft: 1) General
Internet and 2) Controlled Environment. Former is broadly the
specification targeting the use of UDP for applications over the
Internet, which seems to have become inevitable for successful
applications even when those applications start out in limited
networks. The latter on the other hand is the specification
targeting the use of UDP for applications in a controlled
environment. Controlled environments are assumed to be well
coordinated and well managed. Further, such environments have
additional means, in the form carrier grade or other tools and
hardware to manage congestion rather than rely on application built-
in mechanisms.
NSH and more broadly SFC, in its initial specification, targets only
a single administrative domain and falls into the applicability type
2: controlled environment. It is assumed that SFC is deployed over a
single or even multiple connected IP networks that are all under the
same administrative domain or cooperating domains. It is thus
assumed that these controlled networks are traffic engineered and
manage congestion through external means. Deploying SFC over the
Internet and hence the use of UDP to carry NSH over the Internet is
out of scope for this draft.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Definition Of Terms
This document uses some terms defined in SFC architecture
[I-D.ietf-sfc-architecture] and NSH [I-D.ietf-sfc-nsh] drafts as mere
examples for ease of understanding.
Kumar, et al. Expires August 26, 2017 [Page 4]
Internet-Draft NSH UDP Transport February 2017
3. NSH UDP Overlay Transport Encapsulation
3.1. Stacking And Layering
A NSH encapsulated packet when carried over an UDP transport looks as
depicted in Figure 1.
The original payload, L2 frame, L3 packet, NSH OAM message, etc., is
first encapsulated in NSH shim header. The NSH encapsulated packet
then becomes the payload for the UDP packet carried over an IPv4 or
IPv6 network. The UDP header serves as the L4 transport for NSH and
its payload.
Although depicted as a layer3 IP over an L2 network, nothing is
assumed about how the L3 network is designed and deployed. It is
entirely possible for IPinIP or MPLS or other underpinnings.
+-------------------------------------------------------------+
| NSH Payload |
| (Original L2/L3 frame/packet or other as signaled by NSH) |
+-------------------------------------------------------------+
| |
| Network Service Header (NSH) |
+-------------------------------------------------------------+
| |
| L4 UDP Header |
+-------------------------------------------------------------+
| |
| L3 (IPv4|IPv6) Header |
+-------------------------------------------------------------+
| |
| L2 (Ethernet) Header |
+-------------------------------------------------------------+
Figure 1: NSH UDP Stack
3.2. NSH UDP Overlay Packet Format
Figure 2 shows the format of the NSH encapsulation transported over
UDP.
Kumar, et al. Expires August 26, 2017 [Page 5]
Internet-Draft NSH UDP Transport February 2017
Rest of the document assumes UDP destination port to be set to NSH-
UDP-PORT unless stated otherwise explicitly, when carrying a NSH
encapsulated payload packet in UDP transport.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Source Port = XXXXX | Dest Port = NSH-UDP-PORT | UDP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | Hdr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | UDP
~ Network Service Header (NSH) ~
| | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a
| | y
| | l
~ NSH Payload ~ o
| (Original L2/L3 frame/packet or other as signaled by NSH) | a
| | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 2: NSH UDP Overlay Encapsulation Format
Source Port :
The UDP port number computed to provide entropy. See Section 4.2
for details.
Dest Port :
UDP port number assigned to NSH: NSH-UDP-PORT.
Length :
Length of the UDP payload. This includes both the UDP header and
payload as specified in [RFC0768].
Checksum :
UDP checksum computed over the pseudo header, NSH and NSH payload
or zero. See Section 4.3
NSH :
The NSH encapsulation header.
NSH Payload :
The original frame or packet being carried or OAM message, etc.
Kumar, et al. Expires August 26, 2017 [Page 6]
Internet-Draft NSH UDP Transport February 2017
4. UDP Encapsulation Considerations
4.1. UDP Transport End-points
The UDP transport extends between the two end-points involved in
carrying the NSH traffic. The control plane provisioning the NSH
encapsulation MUST specify the location of the transport destination
when using UDP as the transport, such as the IPv4 or IPv6 address of
the end-point.
In the case of SFC, this UDP transport extends between two SFC
components: Classifier and SFF or any two SFFs or SFF and SF or SFF
and SFC-proxy. The destination of the UDP transport is thus the IP
address used by these components to receive the NSH encapsulated
traffic. When UDP transport is required to carry NSH encapsulated
traffic, SFC control plane MUST provision the UDP transport
destination and the use of UDP as transport.
4.2. UDP Source Port Considerations
The source port used in the UDP transport SHOULD be computed to
provide entropy for load balancing along the transmission path,
including network elements such as routers and switches as well as
end points such as servers. This behavior may in turn be controlled
by local-policy at the encapsulating entity.
The source port number SHOULD stay constant and not change for the
flow represented within the NSH payload. This is typically done by
computing the source UDP port number as a hash over the invariant
part of the NSH payload. This could be IP and UDP or IP and TCP part
of the NSH payload when the next-protocol field in NSH base header is
set to IPv4, for instance. This avoids inducing packet reordering
due to the use of NSH UDP transport.
The recommended selection of source port as per [RFC6335], is the
dynamic range: 49152-65535. A number in this range SHOULD be
selected to reflect the flow contained in NSH payload.
The source port number SHOULT NOT be set to zero by the UDP transport
encapsulating entity to mitigate data injection attacks by off-path
devices.
In case of carrying UDP over IPv6, network flow label [RFC6437]
SHOULD be used with the same value as set in the UDP source port.
This allows devices processing NSH encapsulated UDP packets to ECMP
[RFC6438] load balance and route at the IP level as opposed to
looking inside the UDP header.
Kumar, et al. Expires August 26, 2017 [Page 7]
Internet-Draft NSH UDP Transport February 2017
The end point receiving and processing the UDP transported NSH
packets SHOULD perform checks to filter packets with invalid source
port numbers.
4.3. Checksum Considerations
UDP header checksum is essential to ensure UDP payload is not
corrupted. In case of IPv4, IP header checksum enables detection of
delivering to the wrong destination. UDP checksum over IPv6 on the
other hand enables the detection of UDP payload corruption in
addition to the detection of wrong destination. UDP checksum MUST be
handled as per [RFC0768] [RFC2460] by both the decapsulator and the
encapsulator.
NSH is capable of carrying both IP and non-IP packets. In case of IP
packets, NSH payload may already have checksum protection. In such
cases the vulnerable portion of the UDP transport carrying NSH is
just the NSH header part of the UDP payload. However, given the
controlled network environment, this may be low risk and hence
checksum protection is optional as per discussion below.
4.3.1. IPv4 Checksum Processing
IPv4 allows for zero checksum and hence the decapsulator MUST accept
UDP datagrams received with zero checksum. Checksum in the UDP
header MAY be set to zero for performance or other implementation
specific reasons by the encapsulator of NSH packet (classifier, SFF,
SF-proxy or SF). When a non-zero checksum is set by the
encapsulator, it MUST be computed over the IP, UDP headers and the
data as defined in the UDP specification [RFC0768]. The receiving
entity thus MUST accept a UDP encapsulated NSH packet with non-zero
UDP checksum. Receiving entities, of UDP encapsulated NSH packets
with non-zero checksum, MUST verify the checksum before accepting the
packet.
4.3.2. IPv6 Checksum Processing
IPv6 header does not itself have a checksum but relies on the upper
layers such as UDP. UDP over IPv6 hence protects both the source and
destination addresses in addition to the payload.
[RFC2460] does not allow the use of zero checksum with UDP.
[RFC6935] and [RFC6936] define the guidelines and requirements to be
met for using zero checksum with IPv6. Since SFC and NSH are
constrained within a single administrative domain, zero checksum
method MUST be configurable to override the default option.
Kumar, et al. Expires August 26, 2017 [Page 8]
Internet-Draft NSH UDP Transport February 2017
The following are the requirements and recommendations for using NSH-
OVER-UDP, over an IPv6 transport not performing UDP checksum to
verify the integrity of the transport end points.
1. By default, NSH encapsulator node SHOULD use non zero UDP
checksum for NSH-OVER-UDP packets.
2. By default, NSH encapsulator node SHOULD NOT send packets with
zero checksum for NSH-OVER-UDP packets.
3. By default NSH decapsulator node SHOULD discard NSH-OVER-UDP
packets received with zero checksum.
4. NSH encapsulator and decapsulator nodes MUST be configurable to
use the zero checksum method for NSH-OVER-UDP packets.
5. When zero checksum method is enabled for use with NSH-OVER-UDP
packets, it is RECOMMENDED that it be done for specific IP
addresses. The decapsulator MUST check for the validity of the
source and destination IP addresses by comparing them against the
set of IP address enabled for zero checksum method.
6. NSH encapsulator MAY send both zero and non-zero checksum NSH-
OVER-UDP packets to the same destination and the decapsulator
nodes MUST receive both zero and non-zero checksum NSH-OVER-UDP
packets from the same source
7. A middlebox, if present in the path of NSH-OVER-UDP packets, MUST
allow forwarding of NSH-OVER-UDP packets with both zero and non-
zero checksum.
8. While using zero checksum, the network administrator MUST ensure
that the corruption of packets in the environment is low through
means outside the scope of this draft, such as monitoring and
analysis of network traffic.
9. Encapsulator and decapsulator components MUST verify the non-zero
checksum when in use and provide an integrity mechanism to
isolate the cause of corruption when the corruption rate
increases.
The above requirements do not change the requirements specified in
[RFC2460], further updated in [RFC6935] or, the requirements in
[RFC6936] but are adopted for transporting NSH over UDP.
Since NSH is specified for controlled environments, which provides
visibility and control over packet corruption in the environment, the
Kumar, et al. Expires August 26, 2017 [Page 9]
Internet-Draft NSH UDP Transport February 2017
network operator is expected to keep the packet corruption to an
acceptably low level. The above requirements further contribute to
reducing the corruption rates and hence they are not expected to
increase in any way as compared to using UDP win non NSH-OVER-UDP
packets in the same environment. Requirements 2, 3 and 5 in section
5 of [RFC6936] are hence satisfied.
Since NSH is an encapsulation header with no requirement on sate
maintenance at either the encapsulator or the decapsulator and NSH-
OVER-UDP adds no additional state requirements, requirement 4 in
section 5 of [RFC6936] is not applicable.
NSH-OVER-UDP has no control feedback mechanism as it does not specify
a protocol or additional semantics for its use, requirements 6 and 7
in section 5 of [RFC6936] do not apply.
Since NSH-OVER-UDP is unidirectional, requirement 10 in section 5 of
[RFC6936] does not apply.
In summary, NSH-OVER-UDP may use zero checksum method while carried
over IPv6 in accordance with the drafts sighted in the above
discussion.
4.3.3. UDP-Lite Considerations
NSH when transported over UDP with zero checksum method, either in
IPv4 or IPv6 packets, looses the integrity verification provided by
the checksum. However, as discussed in Section 4.3.2, deployment in
a controlled environment is expected to minimize packet corruption.
NSH payload may consist of packets that may or may not have their own
integrity verification mechanisms as in IPv4 or TCP or UDP packets
inside NSH. In light of this, if implementations require integrity
verification of the payload but want to avoid the redundant integrity
checks or, require integrity checks only for the NSH header, should
seriously consider UDP-Lite [RFC3828]. UDP-lite shares the UDP name
space but uses IP protocol identifier to distinguish itself from UDP.
4.4. Congestion Considerations
Congestion control with a connection less protocol like UDP is a very
important consideration to prevent congestion collapse as discussed
in depth in [RFC5405] updated by [I-D.ietf-tsvwg-rfc5405bis]. In
particular, senders of UDP traffic are expected to control the rate
at which packets are sent to a destination in order to minimize the
congestions effects along the path to the destination which is shared
with other flows between different source and destination tuples.
Kumar, et al. Expires August 26, 2017 [Page 10]
Internet-Draft NSH UDP Transport February 2017
NSH-OVER-UDP is expected to transport both IP and non IP traffic
although former is expected to be the dominant use case. Where IP
traffic is carried, it is assumed to be congestion controlled. In
such scenarios, additional congestion control in NSH-OVER-UDP is
assumed to be unnecessary. However, when non-IP traffic is carried,
such as link layer traffic, the rate at which packets are sent to the
destination by an NSH-OVER-UDP encapsulator may not be controlled and
hence may run into congestion issues in the network impacting
throughput of not only other senders and receivers but the throughput
of this sender as well. The network operator(s) can minimize or
avoid these situations by carful planning to control the rate of
transmission of such packets through means outside the scope of NSH-
OVER-UDP.
Since NSH-OVER-UDP is expected to be deployed in controlled
environments, it is suitable for deployment in such network
environments. It MUST NOT be deployed over general Internet unless
explicit guarantees are in place to control the sender of such
packets to prevent congestion.
The operator of the networks where NSH-OVER-UDP is deployed is
expected to impose checks at the egress points of those networks to
ensure any traffic that is not congestion controlled does not escape
to the Internet.
4.5. MTU and Fragmentation Considerations
Fragmentation severely impacts the performance and efficiency of the
elements that process the packet fragments, which includes the
routers and middleboxes among others, and the network in general.
Fragmentation creates more packets in the network, requires resources
in the network elements to buffer and reassemble, which only gets
worse if the fragments are re-ordered (for instance they take
different paths in the network), adds processing overhead, to name a
few disadvantages. Further, it leads to loss of an entire packet and
even flow, if a single fragment is lost. A firewall enforcing
policies on the packet content requires entire packet to be
reassembled and a loss of a fragment results in dropping the all
fragments and blocking the corresponding flow.
An application, as a result, SHOULD NOT send packets that exceed the
MTU along the path of the packet. This requires Operators of
networks deploying NSH-OVER-UDP are RECOMMENDED to configure the MTU
of the network to accommodate NSH and UDP transport encapsulation
overhead. This is only feasible when the networks are under single
administrative domain or co-operating administrative domains or
managed networks. Where it is not possible to set the network-wide
MTU to accommodate NSH-OVER-UDP packet overhead, NSH-OVER-UDP
Kumar, et al. Expires August 26, 2017 [Page 11]
Internet-Draft NSH UDP Transport February 2017
encapsulators SHOULD use path MTU (PMTU) discovery to determine the
MTU along the path. Ideally, such PMTU discovery SHOULD be performed
by the end application and lower the packet MTU. Such a method fails
when the packet traverses multiple administrative domains or the
Internet as ICMP messages required for successful operation of PMTU
are increasingly being filtered.
Within the same administrative domain, PMTU discovery SHOULD be used
by the NSH-OVER-UDP encapsulators to determine the MTU along the
path. The determined PMTU MUST over-ride the configured MTU. NSH-
OVER-UDP encapsulators MUST fragment the packet being encapsulated
prior to encapsulating in UDP. This may result in NSH itself spread
across multiple fragments in extreme cases and hence reassembly
becomes a requirement to process NSH.
When fragmentation is indeed performed by the NSH-OVER-UDP
encapsulators, same source port number MUST be used on all the
fragments of the same packet.
4.6. Middlebox Considerations
Middle boxes typically build state and have a notion of flow.
Policies are often applied by the operator of such networks and
middleboxes to the flow in one direction while expecting the same
policy to be applied automatically in the opposite direction of the
flow by the middlebox. State-full behavior of the middleboxes
enables such functionality.
NSH-OVER-UDP creates a point-to-point unidirectional tunnel. NSH-
UDP-PORT is the destination port while a random port is chosen as the
source port as explained in Section 4.2. Since NSH is deployed in a
controlled environment, the operator MUST update the middleboxes to
allow packets destined to NSH-UDP-PORT. It may further be
constrained to specific source and destination IP addresses.
In case of SFC, NSH is used to steer traffic to middleboxes and the
middleboxes are expected to parse NSH-OVER-UDP packets to service the
NSH payload packets and hence presence of middle boxes are expected.
4.7. Differentiated Services and ECN Considerations
IP Packets carried as payload of NSH inside NSH-OVER-UDP may have
differentiated services (DS) [RFC2475] or ECN [RFC3168] or both
markings on them. It becomes important to determine the markings for
the encapsulating IP packet such as NSH-OVER-UDP when carrying such a
marked packet as payload. [RFC2983] and [RFC6040] discuss DS and ECN
topics in depth, respectively, as it applies to tunnels.
Kumar, et al. Expires August 26, 2017 [Page 12]
Internet-Draft NSH UDP Transport February 2017
5. Acknowledgements
The authors would like to thank David Black, Alia Atlas and others
for their feedback, review comments and guidance.
6. IANA Considerations
IANA is requested to assign a well-known UDP port number for the
purpose defined in this draft, referred to as NSH-UDP-PORT.
7. Security Considerations
Encapsulating NSH in UDP does not alter the security risk of NSH
encapsulation and payload and hence security of the payload is as per
[I-D.ietf-sfc-nsh]
NSH-OVER-UDP is expected to predominantly carry IP traffic which is
checksumed. In increasing number of cases, as in mobile service
provider networks, the traffic is also encrypted. Although it is
allowed to use zero UDP checksum with NSH-OVER-UDP, non-zero checksum
SHOULD be used to protect against corruption to mitigate privacy
concerns.
Use of computed port number for NSH-OVER-UDP source port, as
discussed in Section 4.2, provides minimal protection against off-
path attacks although it is not a substitute for encryption
techniques. However, where source port computation for entropy is
disabled a random port SHOULD be selected to mitigate exposure to
off-path attacks as described in [RFC6056].
8. References
8.1. Normative References
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-11 (work in progress), February 2017.
[I-D.ietf-tsvwg-rfc5405bis]
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in
progress), October 2016.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
Kumar, et al. Expires August 26, 2017 [Page 13]
Internet-Draft NSH UDP Transport February 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
Kumar, et al. Expires August 26, 2017 [Page 14]
Internet-Draft NSH UDP Transport February 2017
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<http://www.rfc-editor.org/info/rfc6438>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013,
<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>.
8.2. Informative References
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-11 (work
in progress), July 2015.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
Authors' Addresses
Surendra Kumar (editor)
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
US
Email: smkumar@cisco.com
Kumar, et al. Expires August 26, 2017 [Page 15]
Internet-Draft NSH UDP Transport February 2017
Larry Kreeger (editor)
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
US
Email: kreeger@cisco.com
Sumandra Majee
F5 Networks
90 Rio Robles
San Jose, CA 95134
US
Email: S.Majee@F5.com
Walter Haeffner
Vodafone
Ferdinand-Braun-Platz 1
Duesseldorf 40549
DE
Email: walter.haeffner@vodafone.com
Rajeev Manur
Broadcom
Email: rmanur@broadcom.com
David Melman
Marvell
Email: davidme@marvell.com
Kumar, et al. Expires August 26, 2017 [Page 16]
