One document matched: draft-ietf-dccp-simul-open-01.txt
Differences from draft-ietf-dccp-simul-open-00.txt
DCCP Working Group G. Fairhurst
Internet-Draft G. Renker
Updates: 4340 (if approved) University of Aberdeen
Intended status: Standards Track June 17, 2008
Expires: December 19, 2008
DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
draft-ietf-dccp-simul-open-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Fairhurst & Renker Expires December 19, 2008 [Page 1]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Abstract
This document specifies an update to the Datagram Congestion Control
Protocol (DCCP), a connection-oriented and datagram-based transport
protocol.
The update assists DCCP applications which need to communicate
through one or more middleboxes (e.g. Network Address Translators or
firewalls), where establishing necessary middlebox state requires
peering endpoints to initiate communication in a near-simultaneous
manner.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the Problem to be Tackled . . . . . . . . . . . . 4
1.3. Structure of this Document . . . . . . . . . . . . . . . . 4
2. Procedure for Near-Simultaneous Open . . . . . . . . . . . . . 5
2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
2.2. DCCP-Listen Packet Format . . . . . . . . . . . . . . . . 5
2.3. Protocol Method . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Protocol Method for DCCP-Server Endpoints . . . . . . 7
2.3.2. Protocol Method for DCCP-Client Endpoints . . . . . . 9
2.3.3. Processing by Routers and Middleboxes . . . . . . . . 9
2.4. Examples of Use . . . . . . . . . . . . . . . . . . . . . 9
2.5. Backwards Compatibility with RFC 4340 . . . . . . . . . . 10
3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 12
3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 12
3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 13
3.3. Repetition of Listen Packets . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Discussion of Existing NAT Traversal Techniques . . . 20
A.1. NAT traversal Based on Simultaneous-Open . . . . . . . . . 21
A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Fairhurst & Renker Expires December 19, 2008 [Page 2]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
1. Introduction
UDP Network Address Translator (NAT) traversal is well understood and
widely implemented. NAT traversal for connection-oriented protocols
(e.g. TCP) uses similar principles, but in some cases requires more
complex and expensive solutions, such as data relay servers [TURN].
DCCP [RFC4340] is both datagram-based and connection-oriented. As
such it faces faces the same problems as TCP NAT traversal, without
the ability to simply reuse traversal solutions which work for UDP.
An additional issue is that DCCP can not perform a simultaneous-open,
a TCP-inherent characteristic which greatly simplifies NAT traversal.
After discussing the problem space for DCCP, this document specifies
a DCCP extension to facilitate DCCP NAT traversal, by explicitly
supporting a widely used principle known as 'hole punching'. This
extension produces the same outward effect as an simultaneous-open,
but without internal changes to the standard DCCP operational
procedure. The extension uses a dedicated indicator message, whose
usage is tied to a specific condition, can thus be turned off, and is
inter-operable with non-extended hosts.
The object of this extension is DCCP native support for middlebox
traversal, reducing dependence on external aids such as data relay
servers.
1.1. Scope of this Document
This document is specifically targeted at NAT traversal. However,
due to the similarity of involved principles, the technique and
presented extension of DCCP may also be of similar use to the
traversal of other types of middlebox, such as firewalls.
The technique described by this document applies to scenarios where
one or both DCCP peers are located behind a middlebox.
The proposed extension is relevant to both client/server and peer-to-
peer applications, such as VoIP, file sharing, or online gaming. It
assists connections that utilise prior out-of-band signaling (e.g.
via a well-known rendezvous server ([RFC3261], [H.323])) to notify
both endpoints of the connection parameters ([RFC3235], [NAT-APP]).
For the scope of this document we assume traditional (outbound) types
of NAT as defined in [RFC2663] and further discussed in [RFC3022].
We understand NAT traversal as involving one or more NAT devices of
this type in the path (i.e. hierarchies of nested NAT devices are
possible). It is assumed that all NATs in the path between endpoints
are BEHAVE-compliant [NAT-APP].
Fairhurst & Renker Expires December 19, 2008 [Page 3]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
This document does not discuss specific behavioural requirements of
devices to support DCCP NAT traversal. These may be described by a
separate document. We further limit our assumptions regarding NAT
devices to a minimum of DCCP protocol support, in that layer-4
checksums are updated to account for changes in the pseudo-header.
1.2. Scope of the Problem to be Tackled
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.
We consider DCCP NAT traversal for the following scenarios:
1. Private client connects to public server.
2. Public server connects to private client.
3. Private client connects to private server.
A defining characteristic of traditional NAT devices [RFC3022] is
that private hosts can connect to external hosts, but not vice versa.
Hence the case (1) is always possible, whereas cases (2) and (3)
require NAT traversal techniques.
In this document we do not consider use of pre-configured, static NAT
address maps, which would also allow outside hosts to connect to the
private network in cases (2) and (3).
A DCCP implementation conforming to [RFC4340] requires a relay server
to perform NAT traversal. The extension specified by this document
enables DCCP NAT traversal without the aid of relay servers.
1.3. Structure of this Document
For background information on existing NAT traversal techniques,
please consult Appendix A.
The normative specification of the extension is presented in the next
section. An informative discussion of underlying design decisions
then follows in Section 3. Security considerations are provided in
Section 4 and IANA considerations in the concluding Section 5.
Fairhurst & Renker Expires December 19, 2008 [Page 4]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
2. Procedure for Near-Simultaneous Open
This section is normative and specifies the simultaneous-open
technique for DCCP.
The presented extension updates the connection-establishment
procedures of [RFC4340].
2.1. Conventions and Terminology
The document uses the terms and definitions provided in [RFC4340].
Familiarity with this specification is assumed. In particular, the
following convention from ([RFC4340], 3.2) is used:
"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."
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].
2.2. DCCP-Listen Packet Format
This document updates DCCP by adding a new packet type, DCCP-Listen,
whose format is shown below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DCCP-Listen Packet Format
DCCP-Listen Packets MAY include header options ([RFC4340], sec. 5.8).
Note however that, at the time of this writing, there are no known
uses of header options for the DCCP-Listen packet.
Fairhurst & Renker Expires December 19, 2008 [Page 5]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Since DCCP-Listen packets are issued before an actual connection is
established, they SHALL NOT carry payload data, and endpoints MUST
ignore any payload data encountered on DCCP-Listen packets.
Servers SHOULD set both Sequence Number fields to 0; clients MUST
ignore the value of the Sequence Number fields; and middleboxes MUST
NOT interpret sequence numbers on DCCP-Listen packets.
Furthermore, the following protocol fields MUST all be set to zero:
CCVal (a connection has not been established),
CsCov (there is no payload).
The "Res" and "Reserved" fields are specified by [RFC4340] and its
successors. The interpretation of these fields is not modified by
this document.
The Type field has the value XX-IANA-assigned-XX, which indicates
that this is a DCCP-Listen packet.
Fairhurst & Renker Expires December 19, 2008 [Page 6]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Note to the RFC Editor:
Please replace XX-IANA-assigned-XX in the above paragraph with the
value assigned in the registry and remove this note.
==> End of note to the RFC Editor. <==
Since the use of short sequence numbers ([RFC4340], 5.1) depends on
the value of the Allow Short Seqno feature ([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. Consequently, the default value of 0 for the Allow Short
Seqno feature ([RFC4340], 6.4) SHALL be used, X MUST be set to 1, and
DCCP-Listen packets with X=0 MUST be ignored.
The Service Code field contains the service code ([RFC4340], 8.1.2)
that the client peer wants to use for this connection. 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 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. using SDP).
2.3. Protocol Method
We use the term "session" as defined in ([RFC2663], 2.3): DCCP
sessions are uniquely identified by the tuple of <source IP-address,
source port, target IP-address, target port>.
DCCP, in addition, introduces service codes which can be used to
identify different services available via the same port [Fai08].
We call the five-tuple <source IP-address, source port, service code,
target IP-address, target port> a fully specified DCCP connection,
and refer to an endpoint that has been assigned all five parameters
as a "fully specified endpoint". DCCP-Listen packets are only sent
for the specific case of fully specified DCCP-server endpoints.
2.3.1. Protocol Method for DCCP-Server Endpoints
This document updates [RFC4340] for the case of fully specified DCCP-
server endpoints. The update is normative and applies to the way the
server performs passive-open.
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
Fairhurst & Renker Expires December 19, 2008 [Page 7]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
(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 [RFC4340], i.e. the
server adheres to the existing state transitions in the left half of
Figure 2 (CLOSED => LISTEN => RESPOND).
A fully specified DCCP-server endpoint permits exactly one client,
identified by target IP-address:port plus service code, to set up the
connection. Such a server SHOULD perform the actions and state
transitions shown in the right half of Figure 2, and specified below.
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
Figure 2: Updated state transition diagram for DCCP-Listen
A fully-specified server endpoint performs passive-open from CLOSED
by inviting the remote client to connect. This is done by sending a
single DCCP-Listen packet to the specified remote IP-adress:port,
using the format specified in Section 2.2. The server then
transitions to INVITED.
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 [RFC4340].
The server SHOULD repeat sending a DCCP-Listen packet while in state
INVITED, at a 200 millisecond interval and up to at most 2
repetitions (Section 3 discusses this choice of timer interval). The
retransmission timer is restarted with the same 200ms interval after
the second retransmission. When, upon the next timeout, the server
Fairhurst & Renker Expires December 19, 2008 [Page 8]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
is still in the INVITED state, it SHOULD progress to LISTEN, and
resume processing as per [RFC4340].
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.
Server endpoints SHOULD in general ignore any incoming DCCP-Listen
packets. As an exception to this rule, a DCCP-Server in state LISTEN
MAY generate a Reset (Code 7, "Connection Refused") in response to a
DCCP-Listen packet.
Further details on the rationale are discussed in Section 3.
2.3.2. Protocol Method for DCCP-Client Endpoints
This document updates [RFC4340], by adding the following normative
rule for the reception of DCCP-Listen packets by clients.
Clients MUST silently discard any received DCCP-Listen packets,
regardless of their current state.
2.3.3. Processing by Routers and Middleboxes
DCCP-Listen packets do not require special treatment and should thus
be forwarded end-to-end across Internet paths, by routers and
middleboxes alike.
Middleboxes may utilise the connection information (address, port,
service code) to establish local forwarding state. This has been the
main motivation for adding the Service Code field: in combination
with the source and destination addresses (found in the enclosing IP-
header), the DCCP-Listen packet carries all necessary information to
uniquely identify a DCCP session.
2.4. Examples of Use
In the examples below, DCCP A is the client and DCCP B is the server.
NAT/Firewall device NA is placed before DCCP A, and NAT/Firewall
device 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.
DCCP A and DCCP B decide to communicate using some out-of-band
mechanism, whereupon the client and server are started. DCCP A
initiates a connection by sending a DCCP-Request. DCCP B actively
Fairhurst & Renker Expires December 19, 2008 [Page 9]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
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.
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
|DCCP-Request --> +--+-+---X| | | |
| |<-+-+----+-+--+<-- DCCP-Listen |
| | | | | | | |
|DCCP-Request --> +--+-+----+-+->| |
| |<-+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+->| |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+->| |
+------------------+ +-+ +-+ +-----------------+
Figure 3: Event sequence when the client is started before the server
The diagram below shows the reverse sequence of events, where the
server sends the DCCP-Listen before the client sends a DCCP-Request:
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
| | | |X---+-+--+<-- DCCP-Listen |
|DCCP-Request --> +--+-+----+-+->| |
| | <+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+> | |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+> | |
+------------------+ +-+ +-+ +-----------------+
Figure 4: Event sequence when the server is started before the client
2.5. Backwards Compatibility with RFC 4340
There are no changes if a client conforming to this document
communicates with a server conforming to [RFC4340].
If a client implements only [RFC4340], incoming DCCP-Listen packets
would be ignored due to step 1 in [RFC4340], 8.1, which at the same
time also conforms to the behaviour specified by this document.
Fairhurst & Renker Expires December 19, 2008 [Page 10]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
This document further does not modify communication for any 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.
Fairhurst & Renker Expires December 19, 2008 [Page 11]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
3. Discussion of Design Decisions
3.1. Rationale for a New Packet Type
The DCCP-Listen packet specified in Section 2.2 has the same format
as the DCCP-Request packet ([RFC4340], 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.
It is important to point out that a DCCP-Request packet could in
theory also be used for the same purpose. The following arguments
were against this.
The first problem is that of semantic overloading: the Request is
defined in [RFC4340] to serve a well-defined purpose, being the
initial packet of the 3-way handshake. Additionally using it in the
manner of a DCCP-Listen packet would require DCCP processors to have
two different processing paths: one where a Request is interpreted as
part of the initial handshake, and another where the same packet is
interpreted as indicator message. This complicates packet processing
in hosts and in particular stateful middleboxes (which may have
restricted computational resources).
The second problem is that a client receiving a DCCP-Request from a
server could generate a Reset if it has not yet entered the REQUEST
state (step 7 in [RFC4340], 8.5). This document lets client
endpoints ignore DCCP-Listen packets. Adding a similar rule for the
Request packet is more cumbersome: clients can not distinguish
between a Request meant to be an indicator message and a genuinely
erratic connection initiation.
The third problem is similar and refers to a client receiving the
DCCP-Listen after having itself sent a (connection-initiation)
Request. Step 7 in section 8.5 of [RFC4340] requires the client to
reply to an "indicator message" Request from the server with a Sync.
Since sequence numbers are ignored for this type of message,
additional and complex processing becomes necessary: either to ask
the client not to respond to a Request when the Request is of type
"indicator message"; or ask middleboxes and servers to ignore Sync
packets generated in response to "indicator message" Requests.
Furthermore, since no initial sequence numbers have been negotiated
at this stage, sending a SyncAck would not be meaningful.
Using a separate packet type allows simpler and clearer processing.
Fairhurst & Renker Expires December 19, 2008 [Page 12]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
The rationale for ignoring the Sequence Number fields on DCCP-Listen
packets is that endpoints have not yet entered connection setup: the
Listen packet is sent out 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.
Although the DCCP-Listen Sequence Number fields are ignored, they
have been retained to reuse the generic header format from section
5.1 of [RFC4340].
3.2. Generation of Listen Packets
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), so as to not interfere with the general
case of "normal" DCCP connections (where client addresses are
generally not known in advance).
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" ([RFC0793],
3.8).
Unlike TCP, this proposal does not perform a role-change from passive
to active.
Like TCP, we require that DCCP-Listen packets are only sent by a
DCCP-server when the endpoint is fully specified (Section 2.3).
3.3. Repetition of Listen Packets
Repetition is a necessary requirement, to increase robustness and the
chance of successful connection establishment: in case a Listen
packet is lost due to congestion, link loss or some other reason.
Recommending a maximum number of 3 timeouts (2 repetitions) is due to
the following considerations. The repeated copies need to be spaced
sufficiently far apart in time to avoid suffering from correlated
loss. The interval of 200ms has been chosen to accommodate a wide
range of wireless and wired network paths.
Another constraint is given by the retransmission interval for the
DCCP-Request ([RFC4340], 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
Fairhurst & Renker Expires December 19, 2008 [Page 13]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
sufficiently large to provide for longer one-way delays, such as e.g.
found on some wireless links.
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, so that connection establishment
completes successfully.
Fairhurst & Renker Expires December 19, 2008 [Page 14]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
4. Security Considerations
The method specified in this document exposes the state of a DCCP
server that has been explicitly pre-configured to accept a connection
from a known client. Establishing this state requires prior out-of-
band signalling between the client and server (e.g. via the Session
Initiation Protocol [RFC3261]).
The technique generates a packet addressed to the expected client.
This increases the vulnerability of the DCCP server, by revealing
which ports are in a passive listening state (the information is not
encrypted and therefore could be seen on the path to the client
through the network).
Servers that do not wish to disclose this information may refrain
from generating DCCP-Listen packets, without impacting subsequent
DCCP state transitions.
This document requires endpoint nodes to ignore reception of DCCP-
Listen packets (in any state other than LISTEN).
We do not believe these changes significantly increase the complexity
or vulnerability of a DCCP implementation that conforms to [RFC4340].
Fairhurst & Renker Expires December 19, 2008 [Page 15]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
5. IANA Considerations
This document requires IANA action by allocation of a new Packet Type
from the IANA DCCP Packet Types Registry. The name of the Packet
Type is the "DCCP-Listen" packet, and its type field is set to XX-
IANA-assigned-XX.
The Registry entry is to reference this document.
Fairhurst & Renker Expires December 19, 2008 [Page 16]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Note to the RFC Editor:
Please replace XX-IANA-assigned-XX throughout this document with the
value assigned in the registry and remove this note.
Fairhurst & Renker Expires December 19, 2008 [Page 17]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
6.2. Informative References
[Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software
Approach to Solving the NAT Problem", Carnegie Mellon
University/ISRI Technical Report CMU-ISRI-05-104,
January 2005.
[FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators",
Proceedings of USENIX-05, pages 179-192, 2005.
[Fai08] Fairhurst, G., "The DCCP Service Code", Work In
Progress, draft-ietf-dccp-serv-codes-06, June 2008.
[GBF+07] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", Work In
Progress, draft-ietf-behave-tcp-07, April 2007.
[GF05] Guha, S. and P. Francis, "Characterization and Measurement
of TCP Traversal through NATs and Firewalls", Proceedings
of Internet Measurement Conference (IMC-05), pages 199-
211, 2005.
[GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based
approach to UDP and TCP connectivity", Proceedings of
SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004.
[H.323] ITU-T, "Packet-based Multimedia Communications Systems",
Recommendation H.323, July 2003.
[NAT-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design
Guidelines for Traversal through Network Address
Translators", Work In Progress, draft-ford-behave-app-05,
March 2007.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
Fairhurst & Renker Expires December 19, 2008 [Page 18]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[Ros08] Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)", Work In
Progress, draft-ietf-mmusic-ice-tcp-06, February 2008.
[TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Work In
Progress, draft-ietf-behave-turn-07, February 2008.
Fairhurst & Renker Expires December 19, 2008 [Page 19]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Appendix A. Discussion of Existing NAT Traversal Techniques
This Appendix is a brief review of existing techniques to establish
connectivity across NAT devices, with the aim of providing background
information.
We first consider TCP NAT traversal based on simultaneous-open, and
then discuss a second technique based on role reversal. Further
information can be found in [GTF04] and [GF05].
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.
The term 'hole punching' was coined in [FSK05] 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.
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 [FSK05] and relies on the
simultaneous-open feature of TCP [RFC0793]. 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:
o a passive socket to listen for connectivity tests from peers and
o multiple active connections from the same address to test
reachability of other peers.
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:
o 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);
o 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).
Fairhurst & Renker Expires December 19, 2008 [Page 20]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
In the latter case it is necessary that the NAT does not interfere
with a RST segment (REQ-4 in [GBF+07]). The simultaneous-open
solution is convenient due to its simplicity, and is thus a preferred
mode of operation in the TCP extension for ICE ([Ros08], sec. 2).
A.1. NAT traversal Based on Simultaneous-Open
Among the various TCP NAT traversal approaches, simultaneous-open
suggests itself due to its simplicity [GF05], [NAT-APP].
A characteristic of simultaneous-open is that the clear distinction
between client and server is erased: both sides enter through active
(SYN_SENT) as well as passive (SYN_RCVD) states. This characteristic
is in conflict with several ideas underlying DCCP, as a clear
separation between client and server has been one of the initial
design decisions ([RFC4340], 4.6). Furthermore, several mechanisms
implicitly rely on clearly-defined client/server roles:
o Feature Negotiation: with few exceptions, almost all of DCCP's
negotiable features use the "server-priority" reconciliation rule
([RFC4340], 6.3.1), whereby peers exchange their preference lists
of feature values, and the server decides the outcome.
o Closing States: only servers may generate CloseReq packets (asking
the peer to hold timewait state), while clients are only permitted
to send Close or Reset packets to terminate a connection
([RFC4340], 8.3).
o Service Codes: servers may be associated with multiple service
codes, while clients must be associated with exactly one
([RFC4340], 8.1.2).
o Init Cookies: may only be used by the server and on DCCP-Response
packets ([RFC4340], 8.1.4).
The latter two points are not obstacles per se, but hinder the
transition from a passive to an active socket. The assumption that
"all DCCP hosts are clients", on the other hand, must be dismissed
since it limits application programming. As a consequence, retro-
fitting simultaneous-open into DCCP does not seem a very sensible
idea.
A.2. Role Reversal
After the simultaneous-open, one of the simplest TCP NAT traversal
schemes involves role traversal ([Epp05] and [GTF04]), 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,
Fairhurst & Renker Expires December 19, 2008 [Page 21]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
accepting connections arriving via the new path.
This solution has several disadvantages for DCCP. First, a DCCP
server would be required to change its role temporarily to 'client'.
This requires modification of settings, in particular service codes
and perhaps Init Cookies.
Further, the the server must not yet have started feature
negotiation, since its choice of initial options may 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).
Lastly, the server needs additional processing to ensure that the
connection coming through the listening socket matches the one for
which it previously opened an active connection.
We therefore do not recommend this approach for DCCP.
Fairhurst & Renker Expires December 19, 2008 [Page 22]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Appendix B. Change Log
Revision 00 retrieved from previous individual submission
draft-fairhurst-dccp-behave-update-01 by the same authors.
Revision 01:
o introduced many format changes to improve readability
o migrated background information into the Appendix
o added Section 1.3 to summarize the document structure
o updated introductory paragraph of Section 2 to account for new
structure
o added captions to all figures
o updated the specification in Section 2 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
o clarified that the default value of the Allow Short Seqno feature
is to be used
o added references to the service code draft [Fai08]
o clarified the processing of DCCP-Listen packets by server
endpoints
o corrected the reaction of a client implementing [RFC4340] only -
DCCP-Listen packets are treated as unknown and hence do not
generate a Reset
o swapped order of IANA / Security-Considerations sections
o added a note in the Security Considerations section that servers
may refrain from generating DCCP-Listen packets
Fairhurst & Renker Expires December 19, 2008 [Page 23]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Note to the RFC Editor:
Please remove this Change Log when done with the document.
Fairhurst & Renker Expires December 19, 2008 [Page 24]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Authors' Addresses
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Gerrit Renker
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
Email: gerrit@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Fairhurst & Renker Expires December 19, 2008 [Page 25]
Internet-Draft DCCP Simultaneous-Open Technique June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Fairhurst & Renker Expires December 19, 2008 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-22 21:56:19 |