One document matched: draft-matthews-p2psip-dsip-nat-traversal-00.txt
P2PSIP Working Group E. Cooper
Internet-Draft P. Matthews
Intended status: Standards Track Avaya
Expires: August 29, 2007 D. Bryan
B. Lowekamp
SIPeerior Technologies and
College of William and Mary
February 25, 2007
NAT Traversal for dSIP
draft-matthews-p2psip-dsip-nat-traversal-00
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 August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document shows how the algorithm for resource registration and
lookup in a SIP-based peer-to-peer system can be implemented in the
presence of NATs. More precisely, this document show how this
algorithm can be generalized into a method of routing arbitrary SIP
Cooper, et al. Expires August 29, 2007 [Page 1]
Internet-Draft NAT Traversal for dSIP February 2007
requests through overlays, and how this approach can be used to set
up new connections between peers to use for additional SIP signaling.
The document uses SIP to signal new dSIP connections, and uses
Interactive Connectivity Establishment (ICE) to allow these
connections to be established through NATs.
Requirements Language
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview and Key Concepts . . . . . . . . . . . . . . . . . . 5
2.1. Overview of the New Procedures . . . . . . . . . . . . . . 5
2.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Connection Table . . . . . . . . . . . . . . . . . . . . . 7
2.4. Comparison of Iterative and Recursive Routing with NAT
Traversal . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Iterative Routing . . . . . . . . . . . . . . . . . . 8
2.4.2. Recursive Routing . . . . . . . . . . . . . . . . . . 9
2.4.3. Relative Costs . . . . . . . . . . . . . . . . . . . . 9
3. Establishing and Maintaining dSIP Connections . . . . . . . . 9
4. Routing a SIP Request through the Overlay . . . . . . . . . . 10
4.1. Sending using Direct Routing . . . . . . . . . . . . . . . 11
4.2. Sending using either Recursive or Iterative Routing . . . 11
4.2.1. Forming and Sending the Request . . . . . . . . . . . 11
4.2.2. Handling the Request at a Receiving Peer . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Routing a REGISTER Request using Recursive Routing . . . . 13
5.2. Setting up a dSIP Connection using Recursive Routing . . . 14
5.3. Routing a REGISTER Request using Iterative Routing . . . . 15
6. Possible Enhancement . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
Cooper, et al. Expires August 29, 2007 [Page 2]
Internet-Draft NAT Traversal for dSIP February 2007
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Cooper, et al. Expires August 29, 2007 [Page 3]
Internet-Draft NAT Traversal for dSIP February 2007
1. Introduction
Network Address Translators (NATs) are a fact of life on the modern
Internet. Some measurements have indicated that almost 74% of web-
browsing clients on the global Internet are behind NATs [Illuminati].
NATs cause problems for peer-to-peer systems because they make it
difficult for two peers to communicate freely. First of all, the
nature of address translation means that the local IP address of a
peer Y behind a NAT is often not the address that another peer X
needs to use to reach peer Y. Second, NATs typically provide a
security function whereby the NAT in front of peer Y will typically
block a packet sent by X to Y unless Y has recently sent a packet to
X.
Many peer-to-peer systems work around this problem by dividing peers
into two groups: those behind NATs (often called "ordinary peers")
and those not behind NATs (often called "super peers"). These
systems then establish a peer-to-peer relationship between super
peers, while establishing a master-slave relationship between each
ordinary peer and a super peer.
This approach works well if a large percentage of peers are not
behind NATs. However, in some of the use-cases [P2PSIP-Use-Cases]
identified for P2PSIP, the percentage of peers not behind NATs may be
very small. For example, a P2PSIP system in a "Managed, Private
Network Environment" may consist of a number of peers, each one of
which is behind its own NAT. In these cases, the ordinary peer /
super peer approach scales poorly or breaks down entirely.
Another approach is to treat all peers as equal and establish long-
lived connections between peers through the intervening NATs. In
this approach, there is a partial mesh of connections between peers,
which is used for routing messages flowing between peers. If peer X
wants to send a message to peer Y, it can either send the message
directly (if it has a direct connection), or send it indirectly
through one or more intermediate peers. Alternatively, X can set up
a new connection directly to Y, then send its message along that new
connection.
For dSIP systems [dSIP-Base], this second approach works well because
dSIP already has the notion of connections between peers. And if the
set of connections forms a structured partial mesh, as it does when
Chord is used as the lookup algorithm [dSIP-Chord], this approach
provides a very efficient way to organize peers such that every peer
contributes equally to the routing and lookup functions of the
overlay.
Cooper, et al. Expires August 29, 2007 [Page 4]
Internet-Draft NAT Traversal for dSIP February 2007
This document describes how to add NAT Traversal to dSIP using this
approach of establishing a partial mesh of long-lived connections
between peers. It describes how to set up a dSIP connection between
two peers, and how to route SIP requests and responses through the
resulting partial mesh of connections.
For more discussion on the problems that NATs cause for peer-to-peer
systems and the various approaches to NAT Traversal for P2PSIP, see
[BEHAVE-P2P-State], [NATs-and-Overlays] and [DHT-for-Communications].
2. Overview and Key Concepts
This section provides a non-normative description of the procedures
and data structures required to perform NAT traversal between P2PSIP
peers. Normative text is found in subsequent sections. This section
first describes the new procedures at a high-level and then discusses
certain aspects of interest.
2.1. Overview of the New Procedures
This document defines two procedures:
o A procedure for setting up a new dSIP connection between two
peers; and
o A procedure for routing an arbitrary SIP request through a dSIP
overlay.
These two procedures are mutually recursive: setting up a dSIP
connection requires the ability to route an INVITE request through
the overlay, and routing a request can require new connections to be
set up (depending on the routing method used).
Consider the case of a peer X in the overlay. Peer X is maintaining
a table of current dSIP connections to other peers. Peer X now
wishes to establish a new dSIP connection with peer Y. This
connection may be intended as a long-term connection in the overlay
as dictated by the DHT algorithm [dSIP-Base], or it may be a
connection needed for some short-term purpose.
Peer X sets up a new dSIP connection using SIP signaling. The
standard SIP and SDP mechanisms for signaling a connection are used,
with two exceptions. The first exception is that the SDP offer and
answer does not specify RTP as the media stream, but instead
specifies dSIP. How this is done is described in detail in
Section 3. The second exception is that the INVITE, and indeed all
SIP requests, are not routed as described in [RFC3263] but are
Cooper, et al. Expires August 29, 2007 [Page 5]
Internet-Draft NAT Traversal for dSIP February 2007
instead routed as described in this document.
A typical message exchange to establish a dSIP connection proceeds as
follows. First, peer X creates an INVITE request. The SDP body of
the INVITE specifies that the new connection will be a dSIP
connection. The SDP body also contains ICE candidates so the
connection can be established through intervening NATs. Peer X then
sends the INVITE to peer Y, using the routing procedure described
below. Peer Y responds with a 200 OK, which is then ACKed by peer X.
Peer X and Y then use ICE to determine the candidate pair for the
connection. At this point, the connection is established.
For short-term connections, nothing more needs to be done. However,
for long-term connections, one endpoint (typically peer X) will send
a new INVITE with a Replaces header down the new connection to
establish a new dialog for the connection that involves only the two
endpoints and not any other peers. If this was not done, and if one
of those peers subsequently left the overlay, then the signaling path
for the connection would be broken. (This idea was borrowed from
[Bootstrap] - see that document for more discussion on why peers want
to do this).
When peer X sends the INVITE, or indeed any SIP request, to peer Y,
it has three choices for how to route the request: direct routing,
recursive routing, or iterative routing.
Direct routing is simply sending the request directly to peer Y
without establishing a dSIP connection to Y first. This may or may
not work, depending on the address that X has for Y and the filtering
permissions installed in any intervening NATs.
Recursive routing is sending the request to a peer U to which X
already has a dSIP connection, and requesting that U proxy the
request onward towards Y. Peer U may or may not have a direct
connection to peer Y; if it does not, it will need to send the
request to another peer V which in turn proxies it onward until peer
Y is reached. When proxying the request onward, each peer forwards
the request to the peer in its connection table that is "closest" to
the destination peer Y. This "closest" function is defined by the DHT
algorithm used by the overlay. For example, in a DHT based on Chord,
each peer U forward the request to the peer V in its connection table
whose peer-ID is closest but not greater than peer Y's peer-ID.
Iterative routing is sending the request to a peer U and requesting
that peer U reply with 302 Moved Temporarily specifying a closer peer
V. In the presence of NATs, this technique is rather complex because
peer X usually does not have a dSIP connection to V. So peer X must
first set up a temporary dSIP connection to V and then send the
Cooper, et al. Expires August 29, 2007 [Page 6]
Internet-Draft NAT Traversal for dSIP February 2007
request to V. (Setting up the temporary dSIP connection to V is done
by sending the INVITE for the connection to peer U and requesting
that it proxy it onward to peer V).
We discuss the pros and cons of iterative vs. recursive routing in
Section 2.4.
2.2. ICE
A variety of NAT traversal techniques have been created for Internet
communications. Some involve changes in network devices and some are
strictly endpoint-based mechanisms. The recommended technique
[Sipping-NAT-Traversal] for SIP systems is Internet Connectivity
Establishment [ICE]. ICE is a technique for performing "NAT-hole-
punching" [BEHAVE-P2P-State].
ICE is an especially attractive technique because it does not require
the configuration of network devices and allows end-to-end encryption
to be used. ICE has the added benefit of working in complex network
topologies that may include multiple NATs.
ICE-enabled peers collect a number of addresses that might be useful
for communicating with other peers. These addresses, referred to as
candidates, commonly include the address of the peer's network
interface as well as the publicly reachable address of the NAT the
peer is behind (discovered via STUN [STUN-bis]). These candidates
are exchanged with remote peers via an existing communication
channel. Each peer then combines its own candidates with the remote
candidates to create an ordered list of candidate pairs. The pairs
are then tested in order until a working network path is discovered.
Given the uncertainty surrounding NAT behavior it is difficult to
predict how often "NAT-hole-punching" can be successfully used for
TCP and UDP transports, but [NAT-Character] estimates an 88% success
rate for TCP and a 100% success rate for UDP when certain common
types of NAT devices are present.
2.3. Connection Table
In addition to the routing table entries required by the DHT
algorithm, the connection table described in [dSIP-Base] contains
additional connections. These additional connections arise because a
peer has connections that it originates to other peers (in its
routing table), connections that other peers originate to it (in
their routing table), and temporarily connections made to perform
resource registrations and queries. Since connections are bi-
directional, we do not distinguish between these two types of
connections when routing requests. For example, Chord specifies that
Cooper, et al. Expires August 29, 2007 [Page 7]
Internet-Draft NAT Traversal for dSIP February 2007
each peer stores routing table entries to other peers in the first
half of the ring starting from itself [dSIP-Chord]. In practice,
however, the connection table will provide connections to peers
distributed across the entire ring. Keep-alive traffic must be sent
on all the entries in the connection table to ensure that NATs
between the peers will not discard the overlay traffic.
2.4. Comparison of Iterative and Recursive Routing with NAT Traversal
[dSIP-Base] describes two techniques for routing SIP requests in a
P2PSIP network: iterative and recursive. While that document
discusses some of their costs and benefits in terms of reliability
and security against various DoS attacks, the added cost of NAT
traversal affects each differently. Both approaches require ICE
connectivity checks to occur whenever an dSIP connection between
peers is added to the overlay. But the two techniques differ in the
amount of work to route a request.
2.4.1. Iterative Routing
In the iterative technique, a request from peer X may be sent to peer
U. If peer U is the final destination, it will respond immediately,
but normally peer U will respond with the address of another peer, V,
that is closer to the destination. Having received a response that
contains the address of peer V, peer X re-issues the request directly
to peer V. This process of iterative redirection continues until
eventually the peer that is the final destination is reached. Under
the iterative routing method, peer X is responsible for transmitting
each request to a sequence of new targets. The first target (peer U)
is selected from peer X's connection table, so a dSIP connection will
already exist and the query can be expected to traverse any
intervening NATs with no difficulty. However, it is very likely that
peer X will not have an existing dSIP connection to the second
target, peer V. The same holds true for any subsequent targets.
As mentioned above, ICE requires an existing (usually indirect)
communication channel to exchange candidate addresses and establish a
new (direct) channel. In order for peer X to successfully transmit a
SIP request to peer V, it must enlist the help of peer U (which has
established dSIP connections to both X and V). For this to work,
peer U must proxy the INVITE for the new dSIP connection on to peer
V. Peer U must not respond to the INVITE with a 302 as it did for the
original SIP request. Therefore, dSIP connection establishment
dictates that even if the overlay is using iterative routing for
requests, it must support two-hop proxying (recursive routing) for
INVITEs that set up dSIP connections. Assuming that U is willing to
proxy the INVITE, X and V can perform ICE connectivity checks to
create a new dSIP connection. Peer X is then free to use the new
Cooper, et al. Expires August 29, 2007 [Page 8]
Internet-Draft NAT Traversal for dSIP February 2007
dSIP connection to deliver its query to peer V. This entire process
can then repeat until a dSIP connection has been established to the
target of the request. Clearly the efficiency and effectiveness of
the iterative routing technique are greatly affected by the presence
of NATs.
2.4.2. Recursive Routing
Under the recursive routing technique, once peer X sends a request to
peer U, peer U will proxy the request to peer V. Since peer V is
selected by peer U from its own connection table, peer U already has
a dSIP connection with peer V, and the proxied request will traverse
any NATs between Y and Z with no problems. No new dSIP connections
need be established. In fact, every hop along the path of the
request is selected from the proxying peer's connection table, so the
request will only traverse existing dSIP connections.
2.4.3. Relative Costs
When the costs of setting up new dSIP connections are considered, the
recursive routing technique remains low-cost, while the iterative
technique grows in cost as the number of temporary dSIP connections
that must be established increases. On the other hand, iterative
routing reduces the risk of amplification attacks and allows the
originating peer to identify where a message failure occurs, whereas
recursive routing gives the originating peer less control and
awareness of how failures occur.
Because iterative and recursive routing both have advantages in
different situations, and because in a heavily-NATed network, even
when using iterative routing a significant amount of two-hop
recursive routing is needed for each new dSIP connection, it is
possible for both techniques to be used within the same operation to
balance the costs and benefits of the two techniques.
3. Establishing and Maintaining dSIP Connections
This section and its subsections present a normative description on
how to set up a dSIP control connection in the presence of NATs. The
description here modifies the procedures given in [dSIP-Base] and the
procedures specified there should be followed where they are not
otherwise overridden by this document.
At the start of this procedure, peer X wishes to set up a dSIP
control connection to peer Y. This procedure assumes that X has a URI
for peer Y that is in the form specified in [dSIP-Base].
Cooper, et al. Expires August 29, 2007 [Page 9]
Internet-Draft NAT Traversal for dSIP February 2007
How X obtains this URI is not specified here. The REGISTER query
operation in [dSIP-Base] provides one way. The DHT chosen for the
overlay may provide other ways. See also the discussion in
Section 6
The details of this procedure are almost identical to the details of
the procedure for setting of a control connection between a joining
peer and an admitting peer specified in [Bootstrap]. Rather than
repeating that procedure, we simply describe the necessary
modifications.
Peer X begins by constructing a SIP INVITE message. The To: header
is set to the URI of peer Y, and the From: and Contact: headers are
set to the URI of peer X. Both URIs MUST be constructed according to
the rules of [dSIP-Base] and include the "peerid" parameter.
The SDP offer and answer are constructed as specified in section 6.4
of [Bootstrap], except that, in the "m" line, the "media" parameter
is set to "application" and the "fmt" parameter set to "sip". This
specifies that the Peer Protocol for the new connection will be SIP.
The INVITE request is then routed to peer Y using direct, iterative,
or recursive routing using the procedures defined in Section 4.
When peer Y responds with a 2xx, the two endpoints follow the
procedures specified in sections 6.5 and 6.5 of [Bootstrap]. As a
result of these procedures, a SIP connection is established between
peers X and Y, with the dialog for the connection running over the
connection itself.
Keep-alives must be run on the control connection to maintain it in
the presence of NATs. To do this, control connections SHOULD use the
STUN Binding Indication method described in ICE [ICE]. These
procedures require STUN [STUN-bis] and SIP [RFC3261] to be
multiplexed on the same connection: at the far end, the two types of
packets can be distinguished because the STUN packets contain the
magic cookie 0x2112A442, and these characters cannot occur in a SIP
packet at this location.
If the two peers at each end of a connection can somehow learn that
there are no NATs between them, then the keep-alives MAY be run at a
rate lower than that recommended in [ICE]. The procedures for making
that determination are not specified here.
4. Routing a SIP Request through the Overlay
This section and its subsections present a normative description on
Cooper, et al. Expires August 29, 2007 [Page 10]
Internet-Draft NAT Traversal for dSIP February 2007
how to route a SIP request through the P2PSIP overlay. The
description here modifies the procedures given in [dSIP-Base] and the
procedures specified there should be followed where they are not
otherwise overridden by this document.
At the start of this procedure, peer X has a SIP request which it
wishes to send to peer Y. This procedure assumes that X has a URI for
peer Y that is in the form specified in [dSIP-Base].
How X obtains this URI is not specified here, and depends on the
context in which the request is generated.
Peer X MAY elect to use direct routing, iterative routing, or
recursive routing when sending the request.
4.1. Sending using Direct Routing
If peer X has an IP address for peer Y, peer X MAY elect to send the
request directly to peer Y, using standard SIP techniques.
Peer X might obtain an IP address in a variety of ways. The URI
for peer Y may include an IP address, or peer X may obtain
information about peer Y through DHT-specific mechanisms.
If peer X knows the port and transport protocol associated with the
address, it SHOULD use those values. Otherwise, it is RECOMMENDED
that it use port 5060 and the UDP protocol respectively.
If peer X sends the request directly to Y using UDP, then it is
RECOMMENDED that peer X assume the send attempt has failed if it does
not receive a reply within a short period (one or two expirations of
Timer A). If peer X uses TCP to send the request, then it is
RECOMMENDED that peer X assume the send attempt has failed if it is
unable to establish a TCP connection within a short period (perhaps
2*T1). If the send attempt fails, then the peer SHOULD try to send
the request through the Overlay using either recursive or iterative
routing.
4.2. Sending using either Recursive or Iterative Routing
4.2.1. Forming and Sending the Request
Peer X SHOULD indicate the requested routing method by adding either
"proxy" (for recursive routing) or "redirect" (for iterative routing)
to a Request-Disposition header [RFC3841] in the request.
Peer X then chooses the peer U in its connection table that is
"closest" to peer Y. If there is no such peer U, then peer X SHOULD
Cooper, et al. Expires August 29, 2007 [Page 11]
Internet-Draft NAT Traversal for dSIP February 2007
treat the request as having failed.
The definition of "closest" depends on the DHT algorithm used by
the overlay. For example, in a system based on Chord (for
example, [dSIP-Chord]), "closest" means the peer whose peer-ID is
the closest in the ring when going in the direction of ascending
peer-ID.
Peer X then sends the request on its connection to U.
If peer X receives a reply of 302 Moved Temporarily specifying some
other peer W, then peer X SHOULD follow the procedures specified in
Section 3 to set up a dSIP connection to peer W if it does not
already have such a connection. Peer X MUST use recursive routing
(and not iterative routing) when establishing the connection. Peer X
MAY omit sending an INVITE with a Replaces header [RFC3891] - this
may be appropriate if peer X views this new connection as temporary
and plans to tear down the connection after a short while.
Once the connection to peer W is established, peer X SHOULD try the
request again, using whatever routing method it wishes.
4.2.2. Handling the Request at a Receiving Peer
When peer U receives the request, it decides whether the request is
addressed to it, or whether it should proxy the request onward.
If peer U is not the final destination for the request, peer U acts
as a SIP proxy for the request as specified in section 16 of
[RFC3261]. When forwarding the request, looks for the peer V it its
connection table that is "closest" to the destination peer Y.
If a peer V is found, the handling depends on the requested handling
("proxy" or "redirect") indicated in the Request-Disposition header
of the request.
If the requested handling is "proxy", the peer MUST proxy the request
on to V. Peer U MUST add a Record-Route header [RFC3261] to the
request and SHOULD add a "rport" parameter [RFC3581].
Adding the Record-Route header ensures that subsequent requests in
the dialog (if any) take the same route. In particular, this
ensures that the ACK in an INVITE transaction will be routed
through the overlay and not sent directly.
If the requested handling is "redirect", the peer SHOULD reply with a
302 Moved Temporarily specifying peer V.
Cooper, et al. Expires August 29, 2007 [Page 12]
Internet-Draft NAT Traversal for dSIP February 2007
If no handling is specified, the handling of the request is
undefined.
If there is no such peer V, then peer U MUST treat the proxy attempt
as having failed and reply appropriately.
The handling of a request addressed to peer U follows normal SIP
processing rules [RFC3261]. In particular, any response is routed
back along the path of the request.
5. Examples
In this section, we give three examples that illustrate the
procedures defined above.
5.1. Routing a REGISTER Request using Recursive Routing
This first example shows the recursive routing of a SIP request
message. In this particular case, the request is a REGISTER message.
In dSIP, REGISTER messages are used to store and retrieve information
in the overlay. In this example, peer X does a recursive lookup of
information associated with a user M. The hash of M's resource-id
falls within the range of ids owned by peer Y, so M's information is
stored with Y. Peer X, which wishes to retrieve this information,
creates a REGISTER message which is addressed to M, and sends it into
the overlay via peer U with a Request-Disposition header containing
"proxy". Peer U proxies this request on to peer V, which it turn
proxies it on to peer Y, which replies with a 200 OK containing
information about user M.
In the figure, "REGISTER(To:M,R-D:proxy)" indicates a REGISTER
message with a To header containing "M" and a Request-Disposition
header containing "proxy". Not shown in the figure is the adding of
Record-Route headers by peers U and V as they proxy the request.
Cooper, et al. Expires August 29, 2007 [Page 13]
Internet-Draft NAT Traversal for dSIP February 2007
Peer X Peer U Peer V Peer Y
| | | |
| REGISTER(To:M,R-D:proxy) | |
|--------------------->| | |
| |----------------->| |
| | |--------------------->|
| | | 200 OK |
| | |<---------------------|
| |<-----------------| |
|<---------------------| | |
| | | |
Figure 1: Routing a REGISTER Request using Recursive Routing
5.2. Setting up a dSIP Connection using Recursive Routing
In this example, assume peer X wishes to set up a dSIP connection to
peer Y. Peer X has a URI for peer Y, but cannot send directly to peer
Y due to intervening NATs. However, there is an indirect route to Y
via peers U and V.
Peer X sends an INVITE request to peer Y via peer U with a Request-
Disposition of "proxy". Peer U proxies this onward to peer V, adding
a Record-Route header as it does so. Similarly, peer V proxies the
request on to peer Y. Peer Y replies with a 200 OK. Peer X then
responds with an ACK, which is proxied through peers U and V because
of the Record-Route.
Peers X and Y then perform one or more ICE ([ICE] and [ICE-TCP])
connectivity checks. These are shown as happening after the INVITE
transaction, but in practice they would usually happen in parallel.
Once the connectivity checks finish, the controlling agent (assumed
to be peer X in this example) sends an INVITE with a Replaces header
directly to Y to replace the dialog that goes via U and V with a new
dialog that runs along the direct dSIP connection. The Replaces
header causes the controlled agent (assumed to be Y) to send a BYE
for the old dialog.
To compress the example, we show final BYE transaction with a single
arrow labeled "BYE/200".
Cooper, et al. Expires August 29, 2007 [Page 14]
Internet-Draft NAT Traversal for dSIP February 2007
Peer X Peer U Peer V Peer Y
| | | |
| INVITE(To:Y,R-D:proxy) | |
|--------------------->| | |
| |----------------->| |
| | |--------------------->|
| | | 200 OK |
| | |<---------------------|
| |<-----------------| |
|<---------------------| | |
| ACK | | |
|--------------------->| | |
| |----------------->| |
| | |--------------------->|
| | | |
| ICE connectivity checks |
|<-------------------------------------------------------------->|
| | | |
| Direct dSIP connection established |
|================================================================|
| | | |
| INVITE (Replaces) | | |
|--------------------------------------------------------------->|
| | | 200 OK |
|<---------------------------------------------------------------|
| ACK | | |
|--------------------------------------------------------------->|
| | | |
| | | BYE / 200 OK |
|<---------------------|<-----------------|<---------------------|
| | | |
Figure 1: Setting Up a dSIP Connection using Recursive Routing
5.3. Routing a REGISTER Request using Iterative Routing
In this example, we revisit the situation of the first example, and
show how it can be done using iterative routing. As before, peer X
want to retrieve information about a user M, who information is
stored with peer Y.
In the figure below, peer X sends an REGISTER query request addressed
to user M via peer U with a Request-Disposition of "redirect". Peer
U responds back to peer X with a 302 Moved Temporarily, specifying
that peer X should try peer V.
Peer X does not have a dSIP connection to peer V, and the various
Cooper, et al. Expires August 29, 2007 [Page 15]
Internet-Draft NAT Traversal for dSIP February 2007
NATs in the network prevent peer X from just sending the REGISTER
request directly to V. Thus, when doing iterative routing, the next
step is for peer X to set up a temporary dSIP connection to peer V.
To do this, peer X send an INVITE to peer V via peer U with a
Request-Disposition of "proxy". This INVITE is proxied by U to V,
which responses with a 200 OK. Peers X and Y then do ICE
connectivity checks and set up a direct dSIP connection between
themselves. Since this is just a temporary dSIP connection, peer X
does not bother with replacing the indirect dialog with a direct
dialog (as shown in the previous example).
Peer X then resends the original REGISTER (addressed to M), this time
sending it via the direct dSIP connection to V. This causes peer V to
respond with a 302 that specifies peer Y.
Once again, peer X needs to set up a temporary dSIP connection
(assuming it does not already have one with peer Y and that
intervening NATs prevent sending without a connection). Peer X does
this by sending an INVITE addressed to Y along its temporary
connection to V, which proxies it onto to Y. As before, X and Y run
ICE connectivity checks and establish a dSIP connection.
At this point, peer X once again resends the original REGISTER
request, this time along the direct connection to Y. Peer Y responds
with a 200 OK containing the desired information.
Finally, peer X tears down it two temporary dSIP connections to Y and
V (in the reverse order that they were set up).
Peer X Peer U Peer V Peer Y
| | | |
| REGISTER(To:M,R-D:redirect) | |
|--------------------->| | |
| 302(Contact:V) | | |
|<---------------------| | |
| | | |
| | | |
| INVITE(To:M,R-D:proxy) | |
|--------------------->| INVITE(To:M,R-D:proxy) |
| |----------------->| |
| | 200 | |
| 200 |<-----------------| |
|<---------------------| | |
| ACK | | |
|--------------------->| ACK | |
| |----------------->| |
| | | |
Cooper, et al. Expires August 29, 2007 [Page 16]
Internet-Draft NAT Traversal for dSIP February 2007
| ICE connectivity checks | |
|<--------------------------------------->| |
| dSIP connection to V established | |
|=========================================| |
| | | |
| | | |
| REGISTER(To:M,R-D:redirect) | |
|---------------------------------------->| |
| | 302(Contact:Y) | |
|<----------------------------------------| |
| | | |
| | | |
| INVITE(To:Y,R-D:proxy)/200/ACK | INVITE(To:Y)/200/ACK |
|---------------------------------------->|--------------------->|
| | | |
| ICE connectivity checks |
|<-------------------------------------------------------------->|
| | | |
| dSIP connection to Y established |
|================================================================|
| | | |
| | | |
| REGISTER(To:M,R-D:redirect) | |
|--------------------------------------------------------------->|
| | | 200 |
|<---------------------------------------------------------------|
| | | |
| | | |
| BYE/200 | | BYE/200 |
|---------------------------------------->|--------------------->|
| BYE/200 | | |
|--------------------->|----------------->| |
| | | |
Figure 3: Routing a REGISTER Request using Iterative Routing
6. Possible Enhancement
As currently specified, a peer X must know the exact peer-ID of the
peer it wishes to establish a dSIP connection with before starting
the procedure described in Section 3.
However, to build and maintain its routing table, peer X wants to set
up a connection for each routing table entry. The range of peer-IDs
that can be used for each routing table entry is dependent on the DHT
used. (For example, if the Chord DHT is used, peer X would try to
Cooper, et al. Expires August 29, 2007 [Page 17]
Internet-Draft NAT Traversal for dSIP February 2007
set up a connection to the first peer in the range 2^i .. 2^(i+1),
for various values of "i"). To update a routing table entry as
currently specified, peer X must first send a Peer Query for a
peer-ID in the range of peer-IDs associated with each routing table
entry. This query will fail, but the failure response will contain
the peer-ID of the first peer in this range. At that point, peer X
has the exact peer-ID it needs and can use the procedure described in
Section 3.
Future versions of this specification may extend the procedures here
to allow this operation to be done with one SIP transaction rather
than two.
7. Security Considerations
Security considerations will be discussed in a future version of this
document.
8. IANA Considerations
IANA considerations will be discussed in a future version of this
document.
9. Acknowledgments
A team of people have worked on the various drafts related to the
dSIP protocol and extensions thereof. The team consists of: David
Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp,
Philip Matthews, and Marcia Zangrilli.
Special thanks to Alan Johnston, who suggested (originally in the
context of [Bootstrap]), the use of the Request-Disposition and
Replaces headers.
10. References
10.1. Normative References
[Bootstrap]
Cooper, E., Johnston, A., and P. Matthews, "Bootstrap
Mechanisms for P2PSIP", Internet
Draft draft-matthews-p2psip-bootstrap-mechanisms (Work in
Progress).
Cooper, et al. Expires August 29, 2007 [Page 18]
Internet-Draft NAT Traversal for dSIP February 2007
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Internet
Draft draft-ietf-mmusic-ice (Work in Progress).
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)", Internet
Draft draft-ietf-mmusic-ice-tcp (Work in Progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric Response
Routing", RFC 3581, August 2003.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[dSIP-Base]
Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P
Approach to SIP Registration and Resource Location",
Internet Draft draft-bryan-p2psip-dsip-00 (Work in
Progress), February 2007.
10.2. Informative References
[BEHAVE-P2P-State]
Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "State of Peer-to-Peer(P2P) Communication
Across Network Address Translators(NATs)", Internet
Draft draft-ietf-behave-p2p-state (Work in Progress).
[DHT-for-Communications]
Bryan, D., Zangrilli, M., and B. Lowekamp, "Challenges of
DHT Design for a Public Communications System", William
and Mary Technical Report WM-CS-2006-03, June 2006.
Cooper, et al. Expires August 29, 2007 [Page 19]
Internet-Draft NAT Traversal for dSIP February 2007
Copy available at
http://www.cs.wm.edu/~bryan/pubs/wm-cs-2006-03.pdf
[Illuminati]
Cadaco, M. and M. Freedman, "Illuminati - Opportunistic
Network and Web Measurement",
http://illuminati.coralcdn.org/stats/, February 2007.
[NAT-Character]
Guha, S. and P. Francis, "Characterization and Measurement
of TCP Traversal through NATs and Firewalls", Proceedings
of Internet Measurement Conference (IMC), October 2005.
Copy available at
http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/
[NATs-and-Overlays]
Cooper, E. and P. Matthews, "The Effect of NATs on P2PSIP
Overlay Architecture", Internet
Draft draft-matthews-p2psip-nats-and-overlays (work in
progress), February 2007.
[P2PSIP-Use-Cases]
Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer-
to-Peer Session Initiation Protocol (P2P SIP)", Internet
Draft draft-bryan-sipping-p2p-usecases (work in progress),
November 2005.
Copy available at www.p2psip.org/ietf.php
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[STUN-bis]
Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, "Simple
Traversal Underneath Network Address Translators (NAT)
(STUN)", Internet Draft draft-ietf-behave-rfc3489bis (Work
in Progress).
[Sipping-NAT-Traversal]
Boulton, C., Ed., Rosenberg, J., and G. Camarillo, "Best
Current Practices for NAT Traversal for SIP", Internet
Draft draft-ietf-sipping-nat-scenarios (Work in Progress).
[dSIP-Chord]
Zangrilli, M. and D. Bryan, "A Chord-based DHT for
Resource Lookup in P2PSIP", Internet
Cooper, et al. Expires August 29, 2007 [Page 20]
Internet-Draft NAT Traversal for dSIP February 2007
Draft draft-zangrilli-p2psip-dsip-dhtchord (Work in
Progress), February 2007.
Authors' Addresses
Eric Cooper
Avaya
1135 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x228
Email: ecooper@avaya.com
Philip Matthews
Avaya
100 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x224
Email: philip_matthews@magma.ca
David A. Bryan
SIPeerior Technologies and College of William and Mary
3000 Easter Circle
Williamsburg, Virginia 23188
USA
Phone: +1 757 565 0101
Email: dbryan@sipeerior.com
Bruce Lowekamp
SIPeerior Technologies and College of William and Mary
3000 Easter Circle
Williamsburg, Virginia 23188
USA
Phone: +1 757 565 0101
Email: lowekamp@sipeerior.com
Cooper, et al. Expires August 29, 2007 [Page 21]
Internet-Draft NAT Traversal for dSIP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Cooper, et al. Expires August 29, 2007 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 04:15:45 |