Network Working Group J. Manner
Internet-Draft N. Varis
Intended status: Experimental Aalto University
Expires: September 9, 2010 March 8, 2010
Generic UDP Tunnelling (GUT)
draft-manner-tsvwg-gut-01.txt
Abstract
Deploying new transport protocols on the Internet is a well-known
problem, as NATs and firewall drop packets with new protocol types.
Tunnelling over UDP is one way to make IP packets hide the actual
payload and enable end-to-end delivery. This draft proposes a simple
UDP tunnelling encapsulation and end-host operation to enable new
(and old) IP payloads, e.g., new transport protocols, to be deployed
on the Internet.
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 September 9, 2010.
Copyright Notice
Copyright (c) 2010 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
Manner & Varis Expires September 9, 2010 [Page 1]
Internet-Draft GUT March 2010
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 BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Sender operation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Receiver operation . . . . . . . . . . . . . . . . . . . . 6
3.3. Example with one NAT-PT between the initiator and
responder . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
5. Encapsulation of protocols without port numbers . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Manner & Varis Expires September 9, 2010 [Page 2]
Internet-Draft GUT March 2010
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 BCP 14, RFC 2119
[RFC2119].
In addition, we use the following terms:
Native: the IP protocol that will, or has been, encapsulated by GUT,
e.g., DCCP, SCTP, etc., even protocols like ICMP or RSVP. We also
refer to native IP packet as the IP packet that carries the native IP
protocol.
Initiator: the node that has sent the first packet belonging to an
exchange by the native protocol.
Responder: the node that received the first packet of the native
protocol.
2. Introduction
New IP paylods, e.g., transport layer technologies, such as SCTP
[RFC4960] and DCCP [RFC4340], have well-known problems with
deployment on the Internet. Firewalls drop IP packets with unknown
(too new) transport protocol types, and NAT boxes do not know how to
translate these protocols.
Tunnelling over UDP has often been mentioned as a means to traverse
middleboxes. Mostly the solutions are ad-hoc and protocol-specific.
In order to make deployment of UDP tunnelling at least somewhat
consistent, this draft proposes a simple mechanism to realise the
goal. The benefit is that with a generic solution we avoid the need
to define tunneling specifications for each IP protocol separetely.
The fundamental goal of GUT is to mitigate the problem of existing
NATs and firewalls, while still allowing middleboxes that
deliberately want to block to do so.
The basic idea of GUT is to encapsulate the native transport protocol
and its payload (in general the whole IP payload) within a UDP packet
destined to the well-known port GUT_P. Between the outer UDP header
and the inner transport header, we have a 4-byte GUT header that
carries information about the encapsulated protocol.
GUT does not specify, nor need, a specific tunnel setup protocol. It
just encapsulates the native protocol and its payload - to any
middlebox on the way this looks like a normal UDP flow to port GUT_P.
Manner & Varis Expires September 9, 2010 [Page 3]
Internet-Draft GUT March 2010
In other words, this specification, i.e, GUT, only defines
The encapsulation of the native IP payload,
The GUT header structure and content, and
The state machine on the initiator and responder sides.
If the native protocol has a handshake or any back-and-forth
messaging, these are run automatically within the UDP-tunnel created
by GUT: GUT is meant to be fully transparent to the native protocol.
Note that GUT can also tunnel protocol types which do not have any
port informations, such as RSVP or ICMP. The GUT encapsulation is
agnostic to the IP protocol version being used (IPv4 or IPv6).
3. Basic operation
The basic idea of the protocol is to encapsulate the problematic
native IP payload within a UDP header and send the packet to a well-
known UDP port GUT_P - any return packets from the responder will be
tunneled the UDP source port used by the initiator. The responder
will get the UDP packets, check the encapsulated payload and evaluate
if it wants to receive the packet, reconstruct the native IP packet,
and forward it for further processing within the network stack.
Figure 1 shows the encapsulation.
+------------------+ +------------------+
| | ------> | |
| | | |
| Payload data | ------> | Payload data |
| | | |
| | ------> | |
+------------------+ +------------------+
| | ------> | |
| Nat. payload hdr | | Nat. payload hdr |
| (DCCP, SCTP,...) | | (DCCP, SCTP,...) |
| | ------> | |
+------------------+ +------------------+ <--|
| | | GUT header | |
| IP header | \ | Next header|IHL | N
| | \ +------------------+ E
+------------------+ \ | | W
\ | UDP header | |
\ +------------------+ <--|
\ | |
\-> | IP header |
| |
+------------------+
Manner & Varis Expires September 9, 2010 [Page 4]
Internet-Draft GUT March 2010
Figure 1: GUT encapsulation
The GUT header is 32 bits and carries two pieces of information that
enable reconstructing the native IP packet.
1. The IPv4 Header Length (IHL, 4 bits) field from the native IPv4
packet.
2. The IP protocol number (next header, 8 bits) of the native IP
packet (v4 and v6).
The 20-bit field is currently unused.
0 15 16 19 20 23 24 31
+--------------------------------+--------+--------+----------------+
| Reserved |Reserved| IHL | Next header |
+--------------------------------+--------+--------+----------------+
Figure 2: GUT header
3.1. Sender operation
In implementation terms, the GUT process running on a host or router
(proxy) receives the native IP packet, the whole packet including the
IP header, grabs the bytes immediately after the IP static header,
adds a UDP and GUT header, and sends the packet to the destination
indicated in the received IP packet. Header checksums are
recalculated.
The source port in the UDP header MAY be chosen freely, although if
the native encapsulated protocol had a notion of port numbers, the
sender SHOULD choose the same source port (note that the source port
may already be used by another process, thus the processing may have
to choose another port number). The IP header indicates a UDP
transport, the GUT header is the first 4 bytes of the UDP payload.
The IP header length obviously gives the length of the whole GUT
packet including the encapsulated transport protocol packet.
The current value of GUT_P is 4887 (rule of thumb 1-800-GUTP)
The GUT daemon is not considered as an IP hop, thus, when the sender
builds the IP header, it MUST use the TTL from the native IP packet.
Similarly any ECN and DSCP bits are copied from the native IP packet
to the outgoing IP packet.
Manner & Varis Expires September 9, 2010 [Page 5]
Internet-Draft GUT March 2010
GUT adds 12 octets of headers (UDP+GUT) which may cause fragmentation
to happen. GUT is meant as transparent a functionality as possible.
Thus, in principle GUT relies on the network stack to do IP packet
fragmentation.
If the native IP packet had IP options, those are preserved within
the GUT encapsulation. Here the processing must store the original
IHL-field from the native IPv4 packet to be used on the responder
side for building the native IP packet properly.
It is possible, that the sender gets fragmented IP packets from the
network stack to be GUT-encapsulated. In such case, the GUT process
MUST reassemble the whole IP packet before adding the UDP and GUT
header. The subsequent packet is given back to the network stack for
transmission, and may be fragmented at that point to fit the MTU of
the link.
TODO: Discuss how PMTUD fits with GUT.
The initiator has to store state, the 5-tuple or 3-tuple (or any
information that enables tracking a particular flow), for each
initiated GUT encapsulation. This state is needed for properly
catching potential return packets of the native IP protocol from the
responder (e.g. DCCP, SCTP). This state can be made to expire after
a certain timeout, or an implementation can decide to monitor open
sockets in the operating system, and remove state of encapsulated
native protocols that have their socket closed.
3.2. Receiver operation
On the receiver side (responder and initiator), the GUT service
receives UDP packets, verifies the checksums, does further analysis
about whether it wants to process the packet further, and either
drops the packet or continues processing.
GUT must be able to receive packets with two distinct destination
port ranges:
GUT_P port: this port number is seen when the packet was sent by a
flow initiator.
Any other UDP port: the flow initiator has chosen a source port
number and if the encapsulated IP protocol included two-way
messaging (e.g. a handshake, acknowledgement packets, etc.), it
will receive return packets to this UDP port.
When the host receives packets to port GUT_P, i.e., it is the
destination of the flow, the responder, it MUST store the 5-tuple or
3-tuple (or any information that enables tracking a particular flow)
Manner & Varis Expires September 9, 2010 [Page 6]
Internet-Draft GUT March 2010
of the encapsulated IP packet flow. This state information is needed
to send back packets belonging to the same flow. An implementation
may optimize the overall resource consumption of the state in GUT by
omitting state information for flows where the source ports of the
native- and UDP transport protocols match.
After decapsulation of the 32-bit GUT header and the UDP header, the
GUT processing reconstructs the native IP packet by using the
received IP header fields but exchanges the encapsulated next header
and IHL fields found in the GUT header. Then the rebuilt packet is
injected into the network stack for further processing. Any
checksums are recalculated. Any IP options will now be visible to
the network stack.
A responder should never receive fragmented IP packets. A proper
implementation always gives full IP packets to the GUT process.
3.3. Example with one NAT-PT between the initiator and responder
The following figure describes how various protocol fields are mapped
on a two-way IP packet flow. The example shows a DCCP-transfer going
from A to B. The figure presents the content of IP packets as they
are sent out from a component on the path. Note that if the
encapsulated protocol does not have port numbers, the GUT processing
is even simpler.
Manner & Varis Expires September 9, 2010 [Page 7]
Internet-Draft GUT March 2010
[Source, IP A] [GUT@A] [NAT, ext IP C] [GUT@B] [Dest, IP B]
------------- Source A to destination B -------------------
1. [IP: A->B, DCCP]
2. [DCCP: E->F]
3. [IP: A->B, UDP]
4. [UDP: E->GUT]
5. [GUT-hdr, DCCP]
6. [DCCP: E->F]
7. [IP: C->B, UDP]
8. [UDP: P->GUT]
[GUT-hdr, DCCP]
...
9. [IP: C->B, DCCP]
10. [DCCP: E->F]
------------- Destination B to source A -------------------
11. [IP: B->C,DCCP]
12. [DCCP: F->E]
13. [IP: B->C, UDP]
14. [UDP: GUT->P ]
15. [GUT-hdr, DCCP]
16. [DCCP: F->E]
17. [IP: B->A, UDP]
18. [UDP: GUT->E]
...
19. [IP: B->A, DCCP]
20. [DCCP: F->E]
Figure 3: GUT encapsulation example
A few details from the figure above:
o Line 4: the GUT process takes GUT_P as the destination port, and
chooses a source port based on the DCCP header.
o Line 8: the NAT may choose a new source port P, instead of E, and
rewrite the UDP header.
o Line 10: before sending the packet out, the GUT process takes note
of the source IP and port numbers, and the encapsulated protocol.
o Line 11-12: the tunneled protocol has not seen the GUT
encapsulation, thus, it will use the native port numbers in the
reverse traffic.
Manner & Varis Expires September 9, 2010 [Page 8]
Internet-Draft GUT March 2010
o - Lines 13-16: the GUT process has earlier stored state about the
flow, knows now that the packet is for an existing stream, and can
direct the flow to the right destination port "P", instead of
sending it to GUT_P, as if the packet belonged to a new stream.
4. Deployment Considerations
The basic goal of GUT is to look like generic UDP messaging to any
middlebox on the path. If the native transport protocol has support
for congestion control, GUT encapsulated packets that are lost will
trigger the native transport to react.
As GUT-encapsulated traffic looks like an ordinary stream of UDP
packets, existing NAT traversal protocols and techniques work out of
the box. For example, a responder GUT-daemon can, when needed,
maintain the GUT_P open at the NAT using any suitable NAT-traversal
protocol.
GUT was originally designed to be used for host-to-host
communication. Yet, nothing actually prohibits to have a network
node that takes the IP packets coming from a host, and tunnels them
through GUT. Similarly, a network node on the receiving side of the
connection can decapsulate the packets before they actually hit the
receiving end-host, so essentially making a GUT-proxy service.
There is yet one critical issue to consider, namely when to
encapsulate a transport protocol in GUT, and when not. This can be
done automatically, e.g., when replies to a transport protocol Y's
connection initiation are not received within a given timeout. Using
GUT can also be a configuration parameter, say, e.g., the host always
encapsulates DCCP packets into GUT; this operation is fully
transparent to the inner transport protocol.
Note: the motivation and incremental deployment of a GUT-like scheme
needs more thought and work.
5. Encapsulation of protocols without port numbers
GUT is originally designed to counter the problems of deploying
relatively new transport protocols on existing Internet. Yet, GUT
can also be used to encapsulate any other protocol, e.g., RSVP or
HIP.
Note that some protocols may not involve port numbers, e.g., RSVP.
In such cases, GUT is free to choose a random port for the sender's
port number; the receiver's port is always GUT_P.
Manner & Varis Expires September 9, 2010 [Page 9]
Internet-Draft GUT March 2010
6. Security Considerations
In general GUT has the same security concerns as the IP protocol it
encapsulates. For example, if the encapsulated protocol can be
harmed by injecting false packets into the stream, GUT can not
prohibit this.
The main additional concern the GUT introduces is the increased state
needed to properly tunnel packets back-and-forth. Yet, here an
implementation SHOULD analyze the encapsulated IP protocol and drop
the packet, without storing state, if it does not match the
expectations. For example, if the host does not have a transport
port open at the indicated destination port, GUT SHOULD drop the
packet silently. Also, in case the native IP packet flow does not
have a notion of port numbers to enable more accurate matching of
pakcets, an implementation may consider storing more information
about the flow that just the 3-tuple. This has the downside that GUT
must be more aware of each individual native IP protocol - currently
GUT basically only needs to know if the native protocol has a notion
of port numbers or not; thus, a GUT implementation only needs special
treatment of native UDP, TCP, SCTP and DCCP packet flows.
Packets belonging to a GUT encapsulated flow will go through a
firewall processing twice, (1) once when the IP packet arrives,
either locally or from the network, and before it is given to GUT,
and (2) when GUT sends out the encapsulated IP protocol inside UDP.
GUT itself does not employ any security functions for content
protection. Yet, one could use any one-way mechanism, or purely rely
on the security functions of the inner payload. If security measures
are used on GUT, it should be a one-way scheme, which does not rely
on back-and-forth signalling; we don't want to force two-way
signaling within GUT, this may or may not happen due to the inner
protocol being tunneled.
7. IANA Considerations
This document requests IANA to allocate one value:
1. A new UDP port number GUT_P as referred to in the document.
8. Summary
Essentially this draft proposes to define a generic mechanism for
tunneling any IP payload over a UDP tunnel. The concrete steps to be
specified are:
Manner & Varis Expires September 9, 2010 [Page 10]
Internet-Draft GUT March 2010
1. Allocate a well-known port number for end-hosts to send UDP-
encapsulated traffic to. This is important because the sender would
need to know what port a receiver has open for GUT traffic. Also,
firewall administrators may want to choose if they allow UDP
tunneling to happen.
2. Define the encapsulation and decapsulation procedure so that the
receiver knows how to rebuild the original IP packet. The GUT
encapsulation is one such proposal.
The benefits are:
1. Existing IP protocols, with or without port information, work
without changes.
2. Deployment can be done on the end-host or a network proxy.
3. No changes are required for existing NAT and firewall devices.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
Authors' Addresses
Jukka Manner
Aalto University
P.O. Box 13000
Espoo FIN-00076 Aalto
Finland
Phone: +358 9 470 22481
Email: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Manner & Varis Expires September 9, 2010 [Page 11]
Internet-Draft GUT March 2010
Nuutti Varis
Aalto University
P.O. Box 13000
Espoo FIN-00076 Aalto
Finland
Email: nvaris@cc.hut.fi
Manner & Varis Expires September 9, 2010 [Page 12]