The UDP Tunnel Transport mode
draft-fairhurst-6man-tsvwg-udptt-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 15, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document proposes a standards track protocol called the the UDP Tunnel Transport. This protocol updates the UDP processing of RFC 2460 for hosts and routers. The update enables a sender to generate a UDP datagram where the UDP checksum is replaced by a header check determined only by the protocol header information. The document also updates the way the IPv6 UDP length field is interpreted. The use of this mode is intended to minimise the processing cost for the transport of tunnel packets using UDP.

Table of Contents

1.  Introduction
    1.1.  Background
    1.2.  Use of UDP Tunnels
2.  Update to RFC 2460 to support UDTT
    2.1.  Terminology
    2.2.  UDPTT Next Header Value
    2.3.  UDPTT Header Format
    2.4.  UDP and UDPTT Datagrams with no payload
    2.5.  Calculation of Header Check
    2.6.  Multicast support for UDPTT
3.  Using UDPTT
    3.1.  Guidelines for Application Designers
    3.2.  Backwards compatibility with RFC 2460
    3.3.  Middlebox Traversal and Incremental Checksum Update
4.  Acknowledgements
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative Refe.xmlrences
Appendix A.  Why do we need a checksum? Stuff
    A.1.  IPv4 Compatibility
    A.2.  Why not set the IPv6 UDP checksum to zero?
Appendix B.  Document Change History
§  Author's Address

1.  Introduction

The UDP Tunnel Transport (UDPTT) is a protocol that updates the UDP processing of RFC2460 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460] for hosts and routers. UDPTT is intended to transport datagrams that carry tunnel-encapsulated packets,

A UDPTT end point may be either a host or a router. The tunneling protocol introduces a header check that validates the delivery of the packet to the correct endpoint. This check is not intended as an authentication check (in the manner of a security protocol), but is introduced to reduce the probability that the endpoint stacks receive erroneous packets that may corrupt internal state, introduce unnecessary packet processing, or lead to ambiguous packet counts.

The way in which the header check is computed in UDPTT will usually result in a constant value for each UDP flow. This value may be cached as part of the tunnel endpoint flow state. Once the tunnel has been created, this requires a 16-bit comparison operation, rather than a 1's complement checksum. this approach was driven by a desire to eliminate expensive computation in routers that may need to handle many flows operating at high rate.

The next section provides background information on UDP variants and the use of UDP and UDP for tunneling. Section 2 defines the UDPTT protocol and section 3 provides information about the use of UDPTT.

1.1.  Background

The User Datagram Protocol (UDP) is defined in [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.). This supports two checksum behaviours when used with IPv4. The normal behaviour is for the sender to calculate a checksum over a block of data that includes a pseudo header and the UDP datagram payload. The receiver validates.

The UDP header includes an optional, 16-bit one's complement checksum that provides an a statistical guarantee that the payload was not corrupted in transit. It also allows the receiver to verify that it was the intended destination of the datagram, because it includes a pseudo header that covers the IP addresses, port numbers, and Next Header value corresponding to the UDP transport protocol. This verifies that the datagram is not truncated or padded, because it covers the size field. It therefore protects an application against receiving corrupted payload data in place of, or in addition to, the data that was sent. Applications are recommended to enable UDP checksums [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.), although UDP (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] permits the option to be disabled when used with IPv4.

Unlike IPv4, when UDP datagrams are originated by an IPv6 node, the UDP checksum is not optional. The use of the UDP checksum is required when applications transmit UDP over IPv6 [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.), since there is no network-layer integrity check. UDPTT provides an alternative intended to achieve at least equivalent protection to using IPv4 (with the associated header checksum) and UDP (with the checksum disabled). The offered protection is identical to that provided by UDP-Lite using minimal checksum coverage.

UDP-Lite (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) [RFC3828] provides a checksum with an optional partial coverage. When using this option, a datagram is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). Errors in the insensitive part will not cause the packet to be discarded by the transport layer at the receiving end host. When the checksum covers the entire packet, which should be the default, UDP-Lite is semantically identical to UDP. UDP-Lite is specified for use with IPv4 and IPv6, and uses an IP protocol type (or IPv6 next header) with a value of 136 decimal.

While UDP-Lite benefits from differential link error treatment, where the packet header is afforded higher protection on a radio link compared to the payload, this is explicitly not the goal of UDPTT. For UDPTT, the payload will normally be protected by other integrity checks, and generally all parts of the packet will seek equal protection, as for UDP and TCP.

1.2.  Use of UDP Tunnels

One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by middleboxes that may exist along the path, because many middleboxes support transmission using UDP. In this use, the receiving endpoint decapsulates the UDP datagrams and forwards the original packets contained in the payload [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.). Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology and can be used to create virtual (private) networks.

This is expected to be the normal use of UDPTT, where UDPTT may replace UDP as the tunnel transport when there is a desire to reduce processing costs at the tunnel endpoints. The end point for the UDPTT may be either a host or a router.

{Note: The current specification targets use with IPv6, however the method may also be applicable to IPv4}

2.  Update to RFC 2460 to support UDTT

This section defines the update to IPv6 [RFC2460], if this document is approved for publication by the IETF.

2.1.  Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.2.  UDPTT Next Header Value

UDPTT datagrams are carried in the payload of IPv6 packets. UDP and UDPTT share the next header protocol number (decimal 17) and are differentiated only by the Length of the IP payload.

2.3.  UDPTT Header Format

The UDPTT header is shown in figure udptt_format (UDPTT Header Format) . The use of this format resembles that of UDP, and is a subset of the format specified for UDP-Lite [RFC3828] (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.).

 0              15 16             31
+--------+--------+--------+--------+
|     Source      |   Destination   |
|      Port       |      Port       |
+--------+--------+--------+--------+
|                 |     Header      |
|    0x0008       |      Check      |
+--------+--------+--------+--------+
|                                   |
:           UDPTT Payload           :
|  (no additional integrity check)  |
+-----------------------------------+

The source and destination ports are used in the same way as for UDP and UDP-Lite. UDPTT does not provide any additional information to identify the type of tunnel being supported or the format of the tunnel encapsulation.

In UDPTT, the Length field has been replaced by a constant value of 8 (corresponding to the size of the UDP pseudo-header). The length of the payload part is determined by the size information provided by the IP module in the same manner as for TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793].

The Header Check field is a 16-bit value calculated as specified in the next section. This value is set by the sender and validated by the receiver.

2.4.  UDP and UDPTT Datagrams with no payload

It is normally expected that UDPTT datagrams will carry a tunnel-encapsulated packet as payload. A UDPTT datagram with no payload is indistinguishable from a UDP datagram with no payload. Both have the same representation on the wire, and the same semantics at the sender and receiver. There is no need for a receiver to differentiate these packets.

2.5.  Calculation of Header Check

The Header Check is computed as the 16-bit one's complement of the one's complement sum [RFC1071] (Braden, R., Borman, D., Partridge, C., and W. Plummer, “Computing the Internet checksum,” September 1988.) of a pseudo-header of information collected from the IPv6 and UDP header fields [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.).

Prior to computation, the checksum field MUST be set to zero. If the computed checksum is 0, it is transmitted as all ones (the equivalent in one's complement arithmetic) [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) specifies that IPv6 receivers must discard UDP datagrams containing a zero checksum, and should log the error. This processing is preserved in this update.

The pseudo header is different from the pseudo header of UDP in one way: The value of the Upper-Layer Packet Length field of the pseudo header[RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) is not taken from the UDPTT header, but rather from information provided by the IP module. This computation is perfomed in the same manner as for TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793], where the Length field in the pseudo header includes the UDPTT header and all subsequent bytes in the IPv6 payload.

IPv6 Jumbograms are NOT supported in the UDPTT protocol. If required, such packets may be sent using UDP.

The way in which the header check is computed in UDPTT will usually result in a constant value for each UDP flow. This value may be cached as part of the tunnel endpoint flow state. Once the tunnel has been created, a sender MAY insert the cached value instead of computing teh checksum, and a receiver may then use a 16-bit comparison of the received value against the cached value, rather than a 1's complement checksum. This approach may be desirable to eliminate expensive computation in routers that need to handle many UDPTT flows operating at high rate.

2.6.  Multicast support for UDPTT

Like UDP and UDP-Lite, UDPTT MAY be used as a transport for multicast datagrams.

3.  Using UDPTT

This section provides information for implementors and users of UDPTT.

3.1.  Guidelines for Application Designers

Implementors may use UDPTT in the same way as UDP providing that the application does not need to validate the UDP datagram payload. The protocol is not constrained to the semantics of one particular tunnel usage, and is belived compatible with a range of tunnel mechanisms. Like UDP-Lite, this protocol does not provide an integrity check of the payload data, in this case assumed to be a tunneled packet. This is consistent with other IETF-defined tunnel encapsulations. If the tunnel requires greater assurance that data is correct or has been delivered to the correct end point (e.g. where control data is carried over UDPTT), then the tunnel encapsulation SHOULD introduce its own integrity checks.

Implementors may use cache the Header Check value (as described in section 2.5) to reduce per-packet processing cost for established tunnels.

The UDP Usage Guidelines (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.) [RFC5405] provides guidance for application designers the use of UDP to support tunneling. These guidelines also apply to this protocol.

3.2.  Backwards compatibility with RFC 2460

There are three possible behaviours when a UDPTT datagram is received by an IPv6 host that only supports UDP as defined in (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460].

1. A receiver with a checksum that uses the Upper-Layer Packet Length from the IP Length field. A receiver that uses the UDP-Length field will silently discard the packet, because a mismatching pseudo header would cause the UDP checksum to fail. This behaviour is safe, but no tunnel can be established until the stack is updated to support UDPTT.
2. A receiver with a checksum that uses the Upper-Layer Packet Length from the UDP Length field, and forwards a number of bytes corresponding to the UDP Length field. A receiver that uses the UDP-Length field will calculate a correct checksum. The transport layer will forward a truncated UDP packet (with the payload part removed), since the UDP Length will be interpreted as indicating there is no payload part. This behaviour may result in an application receiving null UDP packets. Application designers are encouraged to design their applications to be robust to such packets [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.). Since no data is passed to the application, there is no danger of inserting unwanted bytes into the data stream at the receiver. This behaviour is safe, but no tunnel can be established until the stack is updated to support UDPTT.
3. A receiver with a checksum that uses the Upper-Layer Packet Length from the UDP Length field, and forwards a number of bytes corresponding to the IP Length field. A receiver that uses the UDP-Length field will calculate a correct checksum. The transport layer will forward the UDP packet towards the application with the payload part. This is also the expected behaviour for UDPTT.

3.3.  Middlebox Traversal and Incremental Checksum Update

Middlebox traversal needs to be considered when planning the deployment of any new transport protocol. Middleboxes are known to exist that verify the correctness of the UDP header. Following publication of this specification it is expected that middleboxes will support UDPTT:

• Middleboxes SHOULD NOT truncate IPv6 datagrams where the IP length exceeds the Length specified in the UDP Header.
• If required to update the transport checksum (UDPTT Header Check), a middlebox MAY use the increemental checksum update procedure (Mallory, T. and A. Kullberg, “Incremental updating of the Internet checksum,” January 1990.) [RFC1141].
• If required to validate the transport checksum (UDPTT Header Check), a middlebox MUST use the method defined in this document.

This document does not modify the requirement that IPv6 receivers must discard UDP datagrams containing a zero checksum zero checksum (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460].

4.  Acknowledgements

5.  IANA Considerations

The IANA IPv6 Next Header registry entry for the decimal value 17 needs to reference this document in addition to the RFC 2460.

6.  Security Considerations

{This section to be expanded in future revisions}

Checks provide the first stage of protection for the stack, although they can not be considered authentication mechanisms.

Checks are desirable to ensure packet counters correctly log actual activity, and can spot unusual behaviours.

Section 3.3 describes middlebox traversal. Firewalls and other security devices may need to be updated to correctly process UDPTT datagrams.

A section describes issues relating to backwards compatibility in hosts. This section may also be applicable to middleboxes that manipulate the transport-layer information.

UDPTT is compatible with the IPsec Encapsulation Security Protocol, ESP (Kent, S. and R. Atkinson, “IP Encapsulating Security Payload (ESP),” November 1998.) [RFC2406], and the Authentication Header, AH (Kent, S. and R. Atkinson, “IP Authentication Header,” November 1998.) [RFC2402].

7.  References

7.1. Normative References

7.2. Informative Refe.xmlrences

Appendix A.  Why do we need a checksum? Stuff

{This section to be expanded in future revisions}

Previous research showed malformed packets can be received across the Internet, a side effect of broken internal processing (internal transfer errors) in routers or hosts. When the checksum is used with UDP/IPv6, it significantly reduces the impact of such errors, reducing the probability of undetected corruption of state (and data) on both the host stack and the applications using the transport service.

Corruption in the network may result in:

• a datagram being mis-delivered to the wrong host/router or the wring transport entity within a host/router. Such a datagram should be discarded.
• a datagram payload being corrupted and delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that has its own integrity checks.
• a datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded.

The decision to omit an integrity check at the IPv6 level means that the transport check is overloaded with many functions including validating:

• the endpoint address was not corrupted within a router - this packet was meant for this destination and a wrong header has not been spliced to a different payload.
• the extension header processing is correctly delimited - the start of data has not been corrupted. The protocol types does this also to some extent.
• reassembly processing, when used.
• the length of the payload.
• the port values - i.e. the correct application gets the payload (applications should also check source ports/address).
• the payload integrity.

In IPv4, the first 4 checks are made by the IPv4 header checksum.

In IPv6, this checking occurs within the stack using the UDP checksum information. UDPTT also performs these checks.

In tunnel encapsulations, payload integrity may be provided by higher layer tunnel encapsulations (often using the IPv4, UDP, UDP-lIte, or TCP checksums).

There are implications on the detectability of mis-delivery of a packet to an incorrect endpoint/socket, and the robustness of the internet infrastructure.

The IETF has defined other tunneling protocols that do not include a check value. However, these are typically layered directly over the Internet layer and are not also used as endpoint transport protocols. Specifically packets are only delivered to protocol modules that process a specific next header value. The next header field therefore provides a first-level check of correct demultiplexing. Since the UDP port space is shared many diverse application, this check is not available when UDP is used as transport and therefore the demultiplexing relies solely on the destination port number.

Deterministic reporting of statistics is desirable: router/endpoint MIBs and other statistics gathering methods have the ability to detect this type of error, rather than recording this as valid traffic between spurious endpoints.

Some IPv6 aware middleware and firewalls may drop or truncate UDPTT datagrams.

{Note: The author would be glad to know of specific cases of truncation and other behaviours.}

A.1.  IPv4 Compatibility

The current version of this document does not specify encapsulation using IPv4 [RFC0791] (Postel, J., “Internet Protocol,” September 1981.). For this network protocol. UDP is permitted to disable the UDP checksum and rely on the IPv4 header checksum.

{Future versions of this document could also consider support for IPv4 if the WG considers this useful|}

A.2.  Why not set the IPv6 UDP checksum to zero?

{This section to be expanded in future revisions}

Topics to be discussed:

• RFC2460
• Behaviour of NAT/Middleboxes
• Implications on host acting as routers and transport end points.

Appendix B.  Document Change History

{RFC EDITOR NOTE: This section must be deleted prior to publication}

Individual Draft 00

This is the first presentation of this document.

Author's Address