One document matched: draft-manner-tsvwg-gut-01.xml
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY ecn PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml'>
<!ENTITY dccp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml'>
<!ENTITY sctp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'> ]>
<!-- trust200902 -->
<!-- full3978 -->
<rfc category="exp" ipr="trust200902" docName="draft-manner-tsvwg-gut-01.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev='GUT'> Generic UDP Tunnelling (GUT) </title>
<author initials='J.' surname="Manner" fullname='Jukka Manner'>
<organization abbrev='Aalto University'>Aalto University</organization>
<address>
<postal>
<street>P.O. Box 13000</street>
<city>Espoo</city> <code>FIN-00076 Aalto</code>
<country>Finland</country>
</postal>
<phone>+358 9 470 22481</phone>
<email>jukka.manner@tkk.fi</email>
<uri>http://www.netlab.tkk.fi/~jmanner/</uri>
</address>
</author>
<author initials='N.' surname="Varis" fullname='Nuutti Varis'>
<organization abbrev='Aalto University'>Aalto University</organization>
<address>
<postal>
<street>P.O. Box 13000</street>
<city>Espoo</city> <code>FIN-00076 Aalto</code>
<country>Finland</country>
</postal>
<email>nvaris@cc.hut.fi</email>
</address>
</author>
<date month="March" year="2010" />
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>
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 <xref target="RFC2119" />.
</t>
<t> In addition, we use the following terms:</t>
<t>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.</t>
<t>Initiator: the node that has sent the first packet belonging to an exchange by
the native protocol.</t>
<t>Responder: the node that received the first packet of the native protocol.</t>
</section>
<section title="Introduction">
<t>
New IP paylods, e.g., transport layer technologies, such as SCTP <xref
target="RFC4960" /> and DCCP <xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
In other words, this specification, i.e, GUT, only defines
</t>
<t>
<list>
<t>The encapsulation of the native IP payload,</t>
<t>The GUT header structure and content, and </t>
<t>The state machine on the initiator and responder sides.</t>
</list>
</t>
<t>
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).
</t>
</section>
<section title="Basic operation">
<t>
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. <xref
target="f:stack" /> shows the encapsulation.
</t>
<figure anchor="f:stack" title="GUT encapsulation"> <artwork><![CDATA[
+------------------+ +------------------+
| | ------> | |
| | | |
| 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 |
| |
+------------------+
]]></artwork> </figure>
<t>
The GUT header is 32 bits and carries two pieces of information that enable
reconstructing the native IP packet.
</t>
<t>1. The IPv4 Header Length (IHL, 4 bits) field from the native IPv4 packet.</t>
<t>2. The IP protocol number (next header, 8 bits) of the native IP packet (v4 and v6).</t>
<t>
The 20-bit field is currently unused.
</t>
<figure anchor="f:header" title="GUT header"> <artwork><![CDATA[
0 15 16 19 20 23 24 31
+--------------------------------+--------+--------+----------------+
| Reserved |Reserved| IHL | Next header |
+--------------------------------+--------+--------+----------------+
]]></artwork> </figure>
<section title="Sender operation">
<t>
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.
</t>
<t>
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.
</t>
<t>
The current value of GUT_P is 4887 (rule of thumb 1-800-GUTP)
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
TODO: Discuss how PMTUD fits with GUT.
</t>
<t>
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.
</t>
</section>
<section title="Receiver operation">
<t>
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.
</t>
<t>
GUT must be able to receive packets with two distinct destination port ranges:
</t>
<t>
<list>
<t>GUT_P port: this port number is seen when the packet was sent by a flow
initiator.</t>
<t>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.</t>
</list>
</t>
<t>
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) 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.
</t>
<t>
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.
</t>
<t>
A responder should never receive fragmented IP packets. A proper implementation
always gives full IP packets to the GUT process. </t>
</section>
<section title="Example with one NAT-PT between the initiator and responder">
<t>
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.
</t>
<figure anchor="f:example" title="GUT encapsulation example"> <artwork><![CDATA[
[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]
]]></artwork>
</figure>
<t>
A few details from the figure above:
</t>
<t>
<list style="symbols">
<t>
Line 4: the GUT process takes GUT_P as the destination port, and chooses
a source port based on the DCCP header.
</t>
<t>
Line 8: the NAT may choose a new source port P, instead of E, and rewrite
the UDP header.
</t>
<t>
Line 10: before sending the packet out, the GUT process takes note of the
source IP and port numbers, and the encapsulated protocol.
</t>
<t>
Line 11-12: the tunneled protocol has not seen the GUT encapsulation, thus,
it will use the native port numbers in the reverse traffic.
</t>
<t>
- 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.
</t>
</list>
</t>
</section>
</section>
<section title="Deployment Considerations">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Note: the motivation and incremental deployment of a GUT-like scheme needs more
thought and work.
</t>
</section>
<section title="Encapsulation of protocols without port numbers">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="IANA Considerations">
<t>
This document requests IANA to allocate one value:
</t>
<t> 1. A new UDP port number GUT_P as referred to in the document. </t>
</section>
<section title="Summary">
<t>
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:
</t>
<t>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. </t>
<t>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.</t>
<t>
The benefits are:
</t>
<t>
<list style="numbers">
<t>Existing IP protocols, with or without port information, work without
changes. </t>
<t>Deployment can be done on the end-host or a network proxy.</t>
<t>No changes are required for existing NAT and firewall devices.</t>
</list>
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
</references>
<references title='Informative References'>
&dccp;
&sctp;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:47 |