One document matched: draft-ietf-dccp-simul-open-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- bibliographical data, inclusion required -->
<!ENTITY rfc0793 PUBLIC "" "bib/reference.RFC.0793.xml">
<!ENTITY rfc2119 PUBLIC "" "bib/reference.RFC.2119.xml">
<!ENTITY rfc2663 PUBLIC "" "bib/reference.RFC.2663.xml">
<!ENTITY rfc3022 PUBLIC "" "bib/reference.RFC.3022.xml">
<!ENTITY rfc3235 PUBLIC "" "bib/reference.RFC.3235.xml">
<!ENTITY rfc3261 PUBLIC "" "bib/reference.RFC.3261.xml">
<!ENTITY rfc4340 PUBLIC "" "bib/reference.RFC.4340.xml">
]>
<rfc category="std" docName="draft-ietf-dccp-simul-open-04" ipr="full3978"
updates="4340">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes" ?>
<!--
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
-->
<front>
<title abbrev="DCCP Simultaneous-Open Technique">DCCP Simultaneous-Open
Technique to Facilitate NAT/Middlebox Traversal</title>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>Scotland</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk</uri>
</address>
</author>
<date day="4" month="Oct" year="2008" />
<area>Transport</area>
<workgroup>DCCP Working Group</workgroup>
<keyword>DCCP</keyword>
<keyword>NAT traversal</keyword>
<keyword>Middlebox Issues</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an update to the Datagram Congestion Control
Protocol (DCCP), a connection-oriented and datagram-based transport
protocol. The update adds support for the DCCP-Listen packet. This
assists DCCP applications to communicate through middleboxes (e.g. a
DCCP server behind a firewall, or Network Address Port Translators),
where establishing necessary middlebox state requires peering endpoints
to initiate communication in a near-simultaneous manner.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>DCCP <xref target="RFC4340"></xref> is both datagram-based and
connection-oriented. As such, it faces the same problems as TCP in
sending packets through devices that require all connections to be
initiated by a 'trusted' host. This is true of host-based firewalls, the
default policy on many firewalls, and (due to port overloading) Network
Address Port Translators, NAPTs <xref target="ID-Behave-DCCP"></xref>.
DCCP can not simply reuse traversal solutions that work for UDP. In
addition, the original specification of DCCP did not allow a server to
perform a simultaneous-open, an inherent characteristic of TCP that
greatly simplifies TCP Network Address Translator (NAT) traversal.</t>
<t>After discussing the problem space for DCCP, this document specifies
an update to the DCCP state machine to offer native DCCP support for
middlebox traversal. This reduces dependence on external aids such as
data relay servers ) <xref target="TURN"></xref> by explicitly
supporting a widely used principle known as 'hole punching'.</t>
<t>The method requires only a minor change to the standard DCCP
operational procedure. The use of a dedicated DCCP packet type ties
usage to a specific condition, ensuring the method is inter-operable
with hosts that do not implement this update, or disable it (see Section
4).</t>
<section anchor="intro1" title="Scope of this Document">
<t>This method is useful in scenarios when a DCCP server is located
behind a middlebox. It is relevant to both client/server and
peer-to-peer applications, such as VoIP, file sharing, or online
gaming and assists connections that utilise prior out-of-band
signaling (e.g. via a well-known rendezvous server (<xref
target="RFC3261"></xref>, <xref target="H.323"></xref>)) to notify
both endpoints of the connection parameters (<xref
target="RFC3235"></xref>, <xref target="NAT-APP"></xref>).</t>
</section>
<section title="DCCP NAT Traversal">
<t><!--> I've already said something specific about this section, but in general, I don't emerge from
reading this section with a clear feeling that I know the "Scope of the Problem to be Tackled".
This document specifically targets DCCP NAT traversal. However, due to the similarity of the
principles involved, the update may be of similar use to traversal of other types of middlebox,
such as firewalls.-->The behavioural requirements for NAT devices supporting
DCCP are described in <xref target="ID-Behave-DCCP"></xref>. A
"traditional NAT" <xref target="RFC3022"></xref>, that directly maps
an IP address to a different IP address does not require the
simultaneous open method described in this document.</t>
<t>The method is required when the DCCP server is positioned behind
one or more NAT devices in the path (i.e. hierarchies of nested NAT
devices are possible). This document refers to DCCP hosts located
behind one or more NAT devices as having "private" addresses, and to
DCCP hosts located in the global address realm as having "public"
addresses.</t>
<t>We consider DCCP NAT traversal for the following scenarios:</t>
<t><list style="numbers">
<t>Private client connects to public server.</t>
<t>Public server connects to private client.</t>
<t>Private client connects to private server.</t>
</list></t>
<t>A defining characteristic of traditional NAT devices <xref
target="RFC3022"></xref> is that private hosts can connect to external
hosts, but not vice versa. Hence the case (1) is possible using the
protocol defined in <xref target="RFC4340"></xref>. A pre-configured,
static NAT address map would allow outside hosts to connect to the
private network in cases (2) and (3).</t>
<t>This document describes a method to support cases (2) and (3) that
require NAT traversal techniques. A DCCP implementation conforming to
<xref target="RFC4340"></xref> and a NAT device conforming to <xref
target="ID-Behave-DCCP"></xref> would require a DCCP relay server to
perform NAT traversal for cases (2) and (3).</t>
<t>The document updates RFC 4340 to enable DCCP NAT traversal without
the aid of DCCP relay servers. This method requires the DCCP server to
discover the IP address and the DCCP port that correspond to the DCCP
Client. Such signalling may be performed out-of-band (e.g. using SDP
<xref target="RFC4566"></xref>).</t>
</section>
<section anchor="intro3" title="Structure of this Document">
<t>For background information on existing NAT traversal techniques,
please consult <xref target="BGND"></xref>.</t>
<t>The normative specification of the update is presented in <xref
target="SPEC"></xref>. An informative discussion of underlying design
decisions then follows, in <xref target="rationale"></xref>. Security
considerations are provided in <xref target="SECURITY"></xref> and
IANA considerations in the concluding <xref target="IANA"></xref>.</t>
</section>
</section>
<!-- introduction -->
<section anchor="SPEC" title="Procedure for Near-Simultaneous Open">
<t>This section is normative and specifies the simultaneous-open
technique for DCCP. It updates the connection-establishment procedures
of <xref target="RFC4340"></xref>.</t>
<section title="Conventions and Terminology">
<t>The document uses the terms and definitions provided in <xref
target="RFC4340"></xref>. Familiarity with this specification is
assumed. In particular, the following convention from (<xref
target="RFC4340"></xref>, 3.2) is used: <list style="empty">
<t>"Each DCCP connection runs between two hosts, which we often
name DCCP A and DCCP B. Each connection is actively initiated by
one of the hosts, which we call the client; the other, initially
passive host is called the server."</t>
</list></t>
<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 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="protocol_method" title="Protocol Method">
<t>The term "session" is used as defined in (<xref
target="RFC2663"></xref>, 2.3): DCCP sessions are uniquely identified
by the tuple of <source IP-address, source port, target IP-address,
target port>.</t>
<t>DCCP, in addition, introduces service codes, which can be used to
identify different services available via the same port <xref
target="Fai08"></xref>.</t>
<section title="Protocol Method for DCCP-Client Endpoints">
<t>This document updates <xref target="RFC4340"></xref>, by adding
the following rule for the reception of DCCP-Listen packets by
clients:</t>
<t>A client in any state MUST silently discard any received
DCCP-Listen packet.</t>
<!-- I think this should be removed
<t>If a client is awaiting the response to a DCCP-Request, it does not need to take specific action.
While in state REQUEST, it MUST use the protocol method defined in <xref target="RFC4340"/>.
This ensures that retransmissions of the Request will happen in the expected manner.</t>
-->
</section>
<section title="Processing by Routers and Middleboxes">
<t>DCCP-Listen packets do not require special treatment and should
thus be forwarded end-to-end across Internet paths, by routers and
middleboxes alike.</t>
<t>Middleboxes may utilise the connection information (address,
port, service code) to establish local forwarding state. The
DCCP-Listen packet carries the necessary information to uniquely
identify a DCCP session in combination with the source and
destination addresses (found in the enclosing IP-header), including
the DCCP Service Code value. The processing of the DCCP-Listen
packet by NAT devices is specified in <xref
target="ID-Behave-DCCP"></xref>.</t>
</section>
<section anchor="listen_packet" title="DCCP-Listen Packet Format">
<t>This document adds a new DCCP packet type, DCCP-Listen, whose
format is shown below.</t>
<figure anchor="listen_packet_format"
title="Format of a DCCP-Listen Packet">
<artwork><![CDATA[
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 | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |X| Reserved | Sequence Number High Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Low Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>The Source Port is the port on which the server is listening
for a connection from the IP address that appears as the
destination IP address in the packet.</t>
<t>The default value of 0 for the Allow Short Seqno feature MUST
be used, X MUST be set to 1, and DCCP-Listen packets with X=0
MUST be ignored. Since the use of short sequence numbers (<xref
target="RFC4340" />, 5.1) depends on the value of the Allow
Short Seqno feature (<xref target="RFC4340" />, 7.6.1) and since
DCCP-Listen packets are sent before a connection is established,
there is no way of negotiating the use of short sequence
numbers.</t>
<t>The sequence number of a DCCP-Listen packet is not related to
the DCCP sequence number for normal DCCP messages <xref
target="rationale" />. Thus, for DCCP-Listen packets:<list
style="symbols">
<t>DCCP servers should set both Sequence Number fields to
0.</t>
<t>DCCP clients MUST ignore the value of the Sequence Number
fields.</t>
<t>Middleboxes MUST NOT interpret sequence numbers on
DCCP-Listen packets.</t>
</list></t>
<t>The Service Code field contains the service code value for
which the server is listening for a connections(<xref
target="RFC4340" />, 8.1.2). This value MUST correspond to a
service code that the server is actually offering for
connections identified by the same source IP address and the
same Source Port as that of the DCCP-Listen packet. Since the
server may use multiple service codes, the specific value of the
Service Code field needs to be communicated out-of-band, from
client to server, prior to sending the DCCP-Listen packet, e.g.
described using the Session Description Protocol, SDP <xref
target="RFC4566" />.</t>
<t>At the time of writing, there are no known uses of the header
option (<xref target="RFC4340" /> , sec. 5.8) with a DCCP-Listen
packet. Clients MUST ignore all options in received DCCP-Listen
packets. Therefore, option values can not be negotiated using a
DCCP-Listen packet.</t>
<t>There is no payload data. Since DCCP-Listen packets are
issued before an actual connection is established, they MUST NOT
carry payload data. Endpoints MUST ignore any payload data
encountered in DCCP-Listen packets. In addition, DCCP clients
MUST ignore the value of the Sequence Number fields; and
middleboxes MUST NOT interpret the sequence numbers of
DCCP-Listen packets.</t>
<t>The following protocol fields are required to have specific
values:<list style="symbols">
<t>Data Offset MUST be zero (there is no payload).</t>
<t>CCVal MUST be zero (a connection has not been
established).</t>
<t>CsCov MUST be zero (there is no payload).</t>
<t>Type has the value 10 (assigned by IANA to denote a
DCCP-Listen packet).</t>
<t>X MUST be 1 (the Generic header must be used).</t>
</list></t>
</list>
</t>
<t>The remaining fields, including the "Res" and "Reserved" fields
are specified by <xref target="RFC4340" /> and its successors. The
interpretation of these fields is not modified by this document.</t>
<note title="Note to the RFC Editor:">
<t>This value assigned to the DCCP-Listen packet needs to be
confirmed by IANA when this document is published. Please then
remove this note.</t>
<t>==> End of note to the RFC Editor. <==</t>
</note>
</section>
</section>
<section title="Protocol Method for DCCP-Server Endpoints">
<t>This document updates <xref target="RFC4340"></xref> for the case
of a fully specified DCCP server endpoint. The update modifies the way
the server performs a passive-open.</t>
<t>Prior to connection setup, it is common for DCCP server endpoints
to not be fully specified: before the connection is established, a
server usually sets the target IP-address:port to wildcard values
(i.e. leaves these unspecified); the endpoint only becomes fully
specified after performing the handshake with an incoming connection.
For such cases, this document does not update <xref
target="RFC4340"></xref>, i.e. the server adheres to the existing
state transitions in the left half of <xref
target="state_diagram"></xref> (CLOSED => LISTEN =>
RESPOND).</t>
<t>A fully specified DCCP server endpoint permits exactly one client,
identified by target IP-address:port plus a single service code, to
set up the connection. Such a server SHOULD perform the actions and
state transitions shown in the right half of <xref
target="state_diagram"></xref>, and specified below.</t>
<figure anchor="state_diagram"
title="Updated state transition diagram for DCCP-Listen">
<artwork><![CDATA[
unspecified remote +--------+ fully specified remote
+---------------------| CLOSED |---------------------+
| +--------+ send DCCP-Listen |
| |
| |
v v
+--------+ timeout +---------+
| LISTEN |<------------------------------+-----------| INVITED |
+--------+ more than 2 retransmissions | +---------+
| | 1st / 2nd ^ |
| | retransm. | |
| +-------------+ |
| resend Listen |
| |
| |
| receive Request +---------+ receive Request |
+------------------->| RESPOND |<--------------------+
send Response +---------+ send Response
]]></artwork>
</figure>
<t>A fully specified server endpoint performs a passive-open from the
CLOSED state by inviting the remote client to connect. This is
performed by sending a single DCCP-Listen packet to the specified
remote IP-adress:port, using the format specified in <xref
target="listen_packet"></xref>. The server then transitions to the
INVITED state.</t>
<t>The INVITED state is, like LISTEN, a passive state, characterised
by waiting in the absence of an established connection. If the server
endpoint in state INVITED receives a DCCP-Request, it transitions to
RESPOND, where further processing resumes as specified in <xref
target="RFC4340"></xref>.</t>
<t>The server SHOULD repeat sending a DCCP-Listen packet while in the
INVITED state, at a 200 millisecond interval and up to at most 2
retransmissions (<xref target="rationale"></xref> discusses this
choice of time interval). If the server is still in the INVITED state
after a further period of 200ms following transmission of the third
DCCP-Listen packet, it SHOULD progress to LISTEN, and resume
processing as specified in <xref target="RFC4340"></xref>.<figure
anchor="retx" title="Retransmission of Listen Packet">
<artwork><![CDATA[ DCCP A DCCP B
------ NA NB ------
+----+ +-+ +-+ +-----------------+
| -->+--+-+----+-+--+--> SDP |
| | | | | | | | State = INVITED
| | | | | | | |
| |<-+-+----+-+--+<-- DCCP-Listen | Timer Starts
| | | | | | | | |
| | | | | | | | 1st Timer Expiry
| | | | | | | |
| |<-+-+----+++--+<-- DCCP-Listen | Timer Starts
| | | | | | | | |
| | | | | | | | 2nd Timer Expiry
| | | | | | | |
| |<-+-+----+-+--+<-- DCCP-Listen | Timer Starts
| | | | | | | | |
| | | | | | | | 3rd Timer Expiry
| | | | | | | |
| | | | | | | | State = LISTEN
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| -->+--+-+----+-+--+--> DCCP-Request |
| | | | | | | | State = RESPOND
| <--+--+-+----+-+--+<-- DCCP-Response|
+----+ +-+ +-+ +-----------------+
]]></artwork>
</figure></t>
<t>The diagram above shows the sequence of packets where the DCCP
server enters the INVITED state after reception of out-of-band
signaling (SDP). It considers the case when the server does not
receive a DCCP-Request within the first 600 ms (often the request
would be received within this interval). DCCP A is the client and DCCP
B is the server, and NA and NB are middlebox devices. Retransmission
is implemented using a timer. The timer is restarted with an interval
of 200ms when sending each DCCP-Listen packet. It is cancelled when
the server leaves the INVITED state. If the timer expires after the
first and second transmission, it triggers a retransmission of the
DCCP-Listen Packet. If it expires after sending the third DCCP-Listen
packet, the server leaves the INVITED state, to enter the LISTEN state
(where it passively waits for a DCCP-Request).</t>
<t>Fully specified server endpoints SHOULD treat ICMP error messages
received in response to a DCCP-Listen packet as "soft errors" that do
not cause a state transition. Reception of an ICMP error message as a
result of sending a DCCP-Listen packet does not necessarily indicate a
failure of the following connection request, and therefore should not
result in a server state change. This reaction to soft errors exploits
the valuable feature of the Internet that for many network failures,
the network can be dynamically reconstructed without any disruption of
the endpoints.</t>
<t>Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A
DCCP Server in state LISTEN MAY generate a DCCP-Reset packet (Code 7,
"Connection Refused") in response to a received DCCP-Listen packet.
This DCCP-Reset packet is an indication that two servers are
simultaneously awaiting connections on the same port.</t>
<t>Further details on the design rationale are discussed in <xref
target="rationale"></xref>.</t>
</section>
<!-- Protocol Method -->
<section title="Examples of Use">
<t>In the examples below, DCCP A is the client and DCCP B is the
server. A middlebox device (NAT/Firewall), NA is placed before DCCP A,
and another middlebox, NB, is placed before DCCP B. Both NA and NB use
a policy that permits DCCP packets to traverse the device for outgoing
links, but only permit incoming DCCP packets when a previous packet
has been sent out for the same connection.</t>
<t>In the figure below, DCCP A and DCCP B decide to communicate using
an out-of-band mechanism, whereupon the client and server are started.
DCCP A initiates a connection by sending a DCCP-Request. DCCP B
actively indicates its listening state by sending a DCCP-Listen
message. This fulfils the requirement of punching a hole in NB, so
that DCCP A can retransmit the DCCP-Request and connect through
it.</t>
<figure anchor="client_before_server"
title="Event sequence when the client is started before the server">
<artwork><![CDATA[
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
|DCCP-Request --> +--+-+---X| | | |
| |<-+-+----+-+--+<-- DCCP-Listen |
| | | | | | | |
|DCCP-Request --> +--+-+----+-+->| |
| |<-+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+->| |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+->| |
+------------------+ +-+ +-+ +-----------------+
]]></artwork>
</figure>
<t>The diagram below shows the reverse sequence of events, where the
server sends the DCCP-Listen before the client sends a
DCCP-Request:</t>
<figure anchor="server_before_client"
title="Event sequence when the server is started before the client">
<artwork><![CDATA[
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
| | | |X---+-+--+<-- DCCP-Listen |
|DCCP-Request --> +--+-+----+-+->| |
| | <+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+> | |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+> | |
+------------------+ +-+ +-+ +-----------------+
]]></artwork>
</figure>
</section>
<section title="Backwards Compatibility with RFC 4340">
<t>No changes are required if a DCCP Client conforming to this
document communicates with a DCCP Server conforming to <xref
target="RFC4340"></xref>.</t>
<t>If a client implements only <xref target="RFC4340"></xref>, an
incoming DCCP-Listen packet would be ignored due to step 1 in <xref
target="RFC4340"></xref>, 8.1, which at the same time also conforms to
the behaviour specified by this document.</t>
<t>This document further does not modify communication for any DCCP
server that implements a passive-open without fully binding the
addresses, ports and service codes to be used. The authors therefore
do not expect practical deployment problems with existing conformant
DCCP implementations.</t>
</section>
</section>
<!-- protocol approach -->
<section anchor="rationale" title="Discussion of Design Decisions">
<section title="Rationale for a New Packet Type">
<t>This is an informative section that reviews the rationale for the
design of this technique. The DCCP-Listen packet specified in <xref
target="listen_packet"></xref> has the same format as the DCCP-Request
packet (<xref target="RFC4340"></xref>, 5.1), the only difference is
in the value of the Type field. The usage, however, differs. The
DCCP-Listen packet serves as advisory message, not as part of the
actual connection setup: sequence numbers have no meaning, and no
payload may be present.</t>
<t>A DCCP-Request packet could in theory also have been used for the
same purpose. The following arguments were against this:</t>
<t>The first problem was that of semantic overloading: the
DCCP-Request defined in <xref target="RFC4340"></xref> serves a
well-defined purpose, being the initial packet of the 3-way handshake.
Additional use in the manner of a DCCP-Listen packet would have
required DCCP processors to have had two different processing paths:
one where a DCCP-Request was interpreted as part of the initial
handshake, and another where the same packet was interpreted as an
indicator message. This would complicate packet processing in hosts
and in particular stateful middleboxes (which may have restricted
computational resources).</t>
<t>The second problem is that a client receiving a DCCP-Request from a
server could generate a DCCP-Reset packet if it had not yet entered
the REQUEST state (step 7 in <xref target="RFC4340"></xref>, 8.5). The
method specified in this document lets client endpoints ignore
DCCP-Listen packets. Adding a similar rule for the DCCP-Request packet
would have been cumbersome: clients would not have been able to
distinguish between a Request meant to be an indicator message and a
genuinely erratic connection initiation.</t>
<t>The third problem is similar, and refers to a client receiving the
indication after having itself sent a (connection-initiation) Request.
Step 7 in section 8.5 of <xref target="RFC4340"></xref> requires the
client to reply to an "indicator message" Request from the server with
a DCCP-Sync. Since sequence numbers are ignored for this type of
message, additional and complex processing would become necessary:
either to ask the client not to respond to a DCCP-Request when the
request is of type "indicator message"; or ask middleboxes and servers
to ignore Sync packets generated in response to "indicator message"
DCCP-Requests. Furthermore, since no initial sequence numbers have
been negotiated at this stage, sending a DCCP-SyncAck would not be
meaningful.</t>
<t>The use of a separate packet type therefore allows simpler and
clearer processing.</t>
<section title="Use of sequence numbers">
<t>Although the DCCP-Listen Sequence Number fields are ignored, they
have been retained in the DCCP-Listen packet header to reuse the
generic header format from section 5.1 of <xref
target="RFC4340"></xref>.</t>
<t>DCCP assigns a random initial value to the sequence number when a
DCCP connection is established <xref target="RFC4340"></xref>.
Howeve, a sender is required to set this value to zero for a
DCCP-Listen packet. Both clients and middleboxes are also required
to ignore this value.</t>
<t>The rationale for ignoring the Sequence Number fields on
DCCP-Listen packets is that at the time the DCCP-Listen is
exchanged, the endpoints have not yet entered connection setup: the
DCCP-Listen packet is sent while the server is still in the
passive-open (INVITED) state, i.e. it has not yet allocated state,
other than binding to the client's IP-address:port and service
code.</t>
</section>
</section>
<section title="Generation of Listen Packets">
<t>Since DCCP-Listen packets solve a particular problem (NAT and/or
firewall traversal), the generation of DCCP-Listen packets on passive
sockets is tied to a condition (binding to an a priori known remote
address and service code) to ensure this does not interfere with the
general case of "normal" DCCP connections (where client addresses are
generally not known in advance).</t>
<t>In the TCP world, the analogue is a transition from LISTEN to
SYN_SENT by virtue of sending data: "A fully specified passive call
can be made active by the subsequent execution of a SEND" (<xref
target="RFC0793"></xref>, 3.8). Unlike TCP, this update does not
perform a role-change from passive to active. Like TCP, DCCP-Listen
packets are only sent by a DCCP-server when the endpoint is fully
specified (<xref target="protocol_method"></xref>).</t>
</section>
<section anchor="listen_repeats"
title="Repetition of DCCP-Listen Packets">
<t>Repetition is a necessary requirement, to increase robustness and
the chance of successful connection establishment when a DCCP-Listen
packet is lost due to congestion, link loss, or some other reason.</t>
<t>The decision to recommend a maximum number of 3 timeouts (2
repeated copies of the original DCCP-Listen packet) results from the
following considerations: The repeated copies need to be spaced
sufficiently far apart in time to avoid suffering from correlated
loss. The interval of 200 ms was chosen to accommodate a wide range of
wireless and wired network paths.</t>
<t>Another constraint is given by the retransmission interval for the
DCCP-Request (<xref target="RFC4340"></xref>, 8.1.1). To establish
state, intermediate systems need to receive a (retransmitted)
DCCP-Listen packet before the DCCP-Request times out (1 second). With
three timeouts, each spaced 200 milliseconds apart, the overall time
is still below one second. On the other hand, the sum of 600
milliseconds is sufficiently large to provide for longer one-way
delays, such as e.g. found on some wireless links.</t>
<t>The rationale behind transitioning to the LISTEN state after two
retransmissions is that other problems, independent of establishing
middlebox state, may occur (such as delay or loss of the initial
DCCP-Request). Any late or retransmitted DCCP-Request packets will
then still reach the server allowiing connection establishment to
successfully complete.</t>
</section>
</section>
<!-- discussion of issues -->
<section anchor="SECURITY" title="Security Considerations">
<t>The method specified in this document generates a DCCP-Listen packet
addressed to a specific DCCP client. This exposes the state of a DCCP
server that is in a passive listening state (i.e. waiting to accept a
connection from a known client).</t>
<t>The exposed information is not encrypted and therefore could be seen
on the network path to the DCCP client. An attacker on this return path
could observe a DCCP-Listen packet and then exploit this by spoofing a
packet (e.g. DCCP-Request, DCCP-Reset) with the IP addresses, DCCP
ports, and service code that correspond to the values to be used for the
connection. As in other on-path attacks, this could be used to inject
data into a connection or to deny a connection request. A similar
on-path attack is also possible for any DCCP connection, once the
session is initiated by the client (<xref target="RFC4340"></xref>,
Section 18).</t>
<t>The DCCP-Listen packet is only sent in response to explicit prior
out-of-band signaling from a DCCP client to the DCCP server (e.g. <xref
target="RFC4566"></xref>) information communicated via the Session
Initiation Protocol <xref target="RFC3261"></xref>), and will normally
directly precede a DCCP-Request sent by the client (which carries the
same information).</t>
<t>This update does not significantly increase the complexity or
vulnerability of a DCCP implementation that conforms to <xref
target="RFC4340"></xref>. A server SHOULD therefore by default permit
generation of DCCP-Listen packets. A server that wishes to prevent
disclosing this information MAY refrain from generating DCCP-Listen
packets, without impacting subsequent DCCP state transitions, but
possibly inhibiting middlebox traversal.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The IANA should register a new Packet Type, "DCCP-Listen", in the
IANA DCCP Packet Types Registry. The decimal value 10 has been assigned
to this types. This registry entry must reference this document.</t>
<t />
<note title="Note to the RFC Editor:">
<t>This value must be confirmed by IANA in the registry when this
document is published, please then remove this note.</t>
</note>
<note title="Acknowledgement">
<t>This update was originally co-authored by Dr Gerrit Renker,
University of Aberdeen, and the present author acknowledges his
insight in design of the protocol mechanism and in careful review of
the early revisions of the document text. Dan Wing assisted on issues
relating to the use of NAT and NAPT.</t>
</note>
</section>
<!-- END -->
</middle>
<back>
<references title="Normative References">
<!-- REFERENCES -->
&rfc2119;
&rfc4340;
</references>
<references title="Informative References">
&rfc0793;
&rfc2663;
&rfc3022;
&rfc3261;
&rfc3235;
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="Handley, M., Jacobson, V., and C. Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
</reference>
<reference anchor="Fai08">
<front>
<title>The DCCP Service Code</title>
<author initials="G" surname="Fairhurst"></author>
<date month="June" year="2008" />
</front>
<seriesInfo name="Work In Progress,"
value="draft-ietf-dccp-serv-codes-07" />
<format type="TXT" />
</reference>
<reference anchor="FSK05">
<front>
<title>Peer-to-Peer Communication Across Network Address
Translators</title>
<author initials="B" surname="Ford"></author>
<author initials="P" surname="Srisuresh"></author>
<author initials="D" surname="Kegel"></author>
<date year="2005" />
</front>
<seriesInfo name="Proceedings of USENIX-05," value="pages 179-192" />
<format type="TXT" />
</reference>
<reference anchor="NAT-APP">
<front>
<title>Application Design Guidelines for Traversal through Network
Address Translators</title>
<author initials="B" surname="Ford"></author>
<author initials="P" surname="Srisuresh"></author>
<author initials="D" surname="Kegel"></author>
<date month="March" year="2007" />
</front>
<seriesInfo name="Work In Progress," value="draft-ford-behave-app-05" />
<format type="TXT" />
</reference>
<reference anchor="GF05">
<front>
<title>Characterization and Measurement of TCP Traversal through
NATs and Firewalls</title>
<author initials="S" surname="Guha"></author>
<author initials="P" surname="Francis"></author>
<date year="2005" />
</front>
<seriesInfo name="Proceedings of Internet Measurement Conference (IMC-05),"
value="pages 199-211" />
<format type="TXT" />
</reference>
<reference anchor="GTF04">
<front>
<title>NUTSS: A SIP based approach to UDP and TCP
connectivity</title>
<author initials="S" surname="Guha"></author>
<author initials="Y" surname="Takeda"></author>
<author initials="P" surname="Francis"></author>
<date year="2004" />
</front>
<seriesInfo name="Proceedings of SIGCOMM-04 Workshops, Portland, OR,"
value="pages 43-48" />
<format type="TXT" />
</reference>
<reference anchor="GBF+07">
<front>
<title>NAT Behavioral Requirements for TCP</title>
<author initials="S" surname="Guha"></author>
<author initials="K" surname="Biswas"></author>
<author initials="B" surname="Ford"></author>
<author initials="S" surname="Sivakumar"></author>
<author initials="P" surname="Srisuresh"></author>
<date month="April" year="2007" />
</front>
<seriesInfo name="Work In Progress," value="draft-ietf-behave-tcp-07" />
<format type="TXT" />
</reference>
<reference anchor="Ros08">
<front>
<title>TCP Candidates with Interactive Connectivity Establishment
(ICE)</title>
<author initials="J" surname="Rosenberg">
<organization>Cisco</organization>
</author>
<date month="February" year="2008" />
</front>
<seriesInfo name="Work In Progress,"
value="draft-ietf-mmusic-ice-tcp-07" />
<format type="TXT" />
</reference>
<reference anchor="TURN">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)</title>
<author initials="J" surname="Rosenberg">
<organization>Cisco</organization>
</author>
<author initials="R" surname="Mahy">
<organization>Plantronics</organization>
</author>
<author initials="P" surname="Matthews">
<organization>Avaya</organization>
</author>
<date month="February" year="2008" />
</front>
<seriesInfo name="Work In Progress," value="draft-ietf-behave-turn-09" />
<format type="TXT" />
</reference>
<reference anchor="Epp05">
<front>
<title>TCP Connections for P2P Apps: A Software Approach to Solving
the NAT Problem</title>
<author initials="J-L" surname="Eppinger"></author>
<date month="January" year="2005" />
</front>
<seriesInfo name="Carnegie Mellon University/ISRI Technical Report"
value="CMU-ISRI-05-104" />
<format type="TXT" />
</reference>
<reference anchor="H.323">
<front>
<title>Packet-based Multimedia Communications Systems</title>
<author fullname="ITU-T">
<organization>ITU-T</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="Recommendation" value="H.323" />
<format type="TXT" />
</reference>
<reference anchor="ID-Behave-DCCP">
<front>
<title>Network Address Translation (NAT) Behavioral Requirements for
DCCP</title>
<author fullname="R. Denis-Courmont" surname="">
<organization></organization>
</author>
<date month="" year="2008" />
</front>
<seriesInfo name="Work in Progress"
value="draft-ietf-behave-dccp-02.txt" />
<format type="TXT" />
</reference>
</references>
<section anchor="BGND"
title="Discussion of Existing NAT Traversal Techniques">
<!-- Note-->
<t>This appendix provides a brief review of existing techniques to
establish connectivity across NAT devices, with the aim of providing
background information. This first considers TCP NAT traversal based on
simultaneous-open, and then discuss a second technique based on role
reversal. Further information can be found in <xref
target="GTF04"></xref> and <xref target="GF05"></xref>.</t>
<t>A central idea shared by these techniques is to make peer-to-peer
sessions look like "outbound" sessions on each NAT device. Often a
rendezvous server, located in the public address realm, is used to
enable clients to discover their NAT topology and the addresses of
peers.</t>
<t>The term 'hole punching' was coined in <xref target="FSK05"></xref>
and refers to creating soft state in a traditional NAT device, by
initiating an outbound connection. A well-behaved NAT can subsequently
exploit this to allow a reverse connection back to the host in the
private address realm.</t>
<t>UDP and TCP hole punching use nearly the same technique. The
adaptation of the basic UDP hole punching principle to TCP NAT traversal
was introduced in section 4 of <xref target="FSK05"></xref> and relies
on the simultaneous-open feature of TCP <xref target="RFC0793"></xref>.
A further difference between UDP and TCP lies in the way the clients
perform connectivity checks, after obtaining suitable address pairs for
connection establishment. Whereas in UDP a single socket is sufficient,
TCP clients require several sockets for the same address / port tuple:
<list style="symbols">
<t>a passive socket to listen for connectivity tests from peers
and</t>
<t>multiple active connections from the same address to test
reachability of other peers.</t>
</list></t>
<t>The SYN sent out by client A to its peer B creates soft state in A's
NAT. At the same time, B tries to connect to A: <list style="symbols">
<t>if the SYN from B has left B's NAT before the arrival of A's SYN,
both endpoints perform simultaneous-open (4-way handshake of
SYN/SYNACK);</t>
<t>otherwise A's SYN may not enter B's NAT, which leads to B
performing a normal open (SYN_SENT => ESTABLISHED) and A
performing a simultaneous-open (SYN_SENT => SYN_RCVD =>
ESTABLISHED).</t>
</list></t>
<t>In the latter case, it is necessary that the NAT does not interfere
with a RST segment (REQ-4 in <xref target="GBF+07"></xref>). The
simultaneous-open solution is convenient due to its simplicity, and is
thus a preferred mode of operation in the TCP extension for ICE (<xref
target="Ros08"></xref>, sec. 2).</t>
<section title="NAT traversal Based on a Simultaneous-Request">
<t>Among the various TCP NAT traversal approaches, the one using
simultaneous-open suggests itself as a candidate for DCCP due to its
simplicity <xref target="GF05"></xref>, <xref
target="NAT-APP"></xref>.</t>
<t>A characteristic of TCP simultaneous-open is that this erases the
clear distinction between client and server: both sides enter through
active (SYN_SENT) as well as passive (SYN_RCVD) states. . This
characteristic conflicts with the DCCP design decision to provide a
clear separation between client and server functions (<xref
target="RFC4340"></xref>, 4.6). Furthermore, several mechanisms
implicitly rely on clearly-defined client/server roles:</t>
<t><list style="symbols">
<t>Feature Negotiation: with few exceptions, almost all of DCCP's
negotiable features use the "server-priority" reconciliation rule
(<xref target="RFC4340"></xref>, 6.3.1), whereby peers exchange
their preference lists of feature values, and the server decides
the outcome.</t>
<t>Closing States: only servers may generate DCCP-CloseReq packets
(asking the peer to hold timewait state), while clients are only
permitted to send DCCP-Close or DCCP-Reset packets to terminate a
connection (<xref target="RFC4340"></xref>, 8.3).</t>
<t>Service Codes <xref target="Fai08"></xref>: servers may be
associated with multiple servi=ce codes, while clients must be
associated with exactly one (<xref target="RFC4340"></xref>,
8.1.2).</t>
<t>Init Cookies: may only be used by the server and on
DCCP-Response packets (<xref target="RFC4340"></xref>, 8.1.4).</t>
</list></t>
<t>The latter two points are not obstacles per se, but would have
hindered the transition from a passive to an active socket. In DCCP, a
DCCP-Request is only generated by a client. The assumption that "all
DCCP hosts may be clients", was dismissed, since it would require
undersirable changes to the state machine and would limit application
programming. As a consequence, the retro-fitting a TCP-style
simultaneous-open into DCCP to allow simulatenous exchange of
DCCP-Connect packets was not recommended.</t>
</section>
<section title="Role Reversal">
<t>Another simple TCP NAT traversal schemes uses role traversal (<xref
target="Epp05"></xref> and <xref target="GTF04"></xref>), where a peer
first opens an active connection for the single purpose of punching a
hole in the firewall; and then reverts to a listening socket,
accepting connections arriving via the new path.</t>
<t>This solution would have had several disadvantages if used with
DCCP. First, a DCCP server would be required to change its role to
temporarily become a 'client'. This would have required modification
to the state machine, in particular the trearment of service codes and
perhaps Init Cookies. Further, the method must follow feature
negotiation, since a host's choice of initial options can rely on its
role (i.e. if an endpoint knows it is the server, it can make a priori
assumptions about the preference lists of features it is negotiating
with the client, thereby enforcing a particular policy). Finally, the
server would have needed additional processing to ensure that the
connection arriving at the listening socket matches the previously
opened active connection.</t>
<t>This approach was therefore not recommend for DCCP.</t>
</section>
</section>
<!-- review -->
<section title="Change Log">
<!-- CHANGELOG -->
<t>Revision 00 was based on a previous individual submission
draft-fairhurst-dccp-behave-update-01 by the same authors.</t>
<t>Revision 01:</t>
<t>
<list style="symbols">
<t>introduced many format changes to improve readability</t>
<t>migrated background information into the Appendix</t>
<t>added <xref target="intro3" /> to summarize the document
structure</t>
<t>updated introductory paragraph of <xref target="SPEC" /> to
account for new structure</t>
<t>added captions to all figures</t>
<t>updated the specification in <xref target="SPEC" /> to (i) permit
options on DCCP-Listen packets; (ii) explain why the presence of
payload data is not useful; (iii) clarify that middleboxes must not
interpret sequence numbers on DCCP-Listen packets</t>
<t>clarified that the default value of the Allow Short Seqno feature
is to be used</t>
<t>added references to the service code draft <xref
target="Fai08" /></t>
<t>clarified the processing of DCCP-Listen packets by server
endpoints</t>
<t>corrected the reaction of a client implementing <xref
target="RFC4340" /> only - DCCP-Listen packets are treated as
unknown and hence do not generate a DCCP-Reset</t>
<t>swapped order of IANA / Security-Considerations sections</t>
<t>added a note in the Security Considerations section that servers
may refrain from generating DCCP-Listen packets</t>
</list>
</t>
<t>Revision 02:<list style="symbols">
<t>minor edits following WG feedback at IETF meeting</t>
<t>updated to reflect ID.Behave-DCCP</t>
<t>update to reflect comments from Colin Perkins</t>
<t>added a tentative IANA code point (as suggested at IETF-73)</t>
</list></t>
<t>
<list style="symbols">
<t>DRAFT -02</t>
<t>Edits following editorial corrections and suggestions from Tom
Phelan</t>
<t>Edits following comments from Dan Wing on role of NAT,
retransmision, and other issues.</t>
<t>Revised authors list</t>
<t>Reworded abstract, reworded appendices to clarify what was not
done</t>
<t>Checked spelling</t>
<t>Although this version includes significant changes to format and
text it does not seek to modify the intended procedure for a
server.</t>
<t />
<t>DRAFT - 03</t>
<t>Comments by Dan Wing</t>
</list>
<list style="symbols">
<t>DRAFT -04</t>
<t>Corrections by Dan Wing, and new diagram <xref target="retx" />
to and text to clarify the retransmission algorithm.</t>
</list>
</t>
<note title="Note to the RFC Editor:">
<t>Please remove this Change Log when done with the document.</t>
<t>
<!--API - Informative
This informative annexe provides an example of how an application can trigger the use of the simultaneous open technique described in this document.
A DCCP Server application may invoke the transmission of a DCCP-Listen packet by using an operating system set_socket_opt call that identifies the target IP-address. The application must have already associated a single valid service code.
There is no action required by a DCCP Client application when the DCCP processor receives a DCCP-Listen packet.
-->
</t>
</note>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 20:47:20 |