< draft-ietf-sip-nat-01.txt		draft-ietf-sip-nat-02.txt >
	Internet Engineering Task Force SIP WG		Internet Engineering Task Force SIP WG
	Internet Draft J.Rosenberg,J.Weinberger,H.Schulzrinne		Internet Draft J. Rosenberg
	draft-ietf-sip-nat-01.txt dynamicsoft,Columbia U.		dynamicsoft
	November 21, 2001		J. Weinberger
	Expires: May 2002		dynamicsoft
			H. Schulzrinne
			Columbia U.
			draft-ietf-sip-nat-02.txt
			July 1, 2002
			Expires: January 2003
	SIP Extensions for NAT Traversal		An Extension to the Session Initiation Protocol (SIP)
			for Symmetric Response Routing
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 40 ¶
	material or to cite them other than as "work in progress".		material or to cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	To view the list Internet-Draft Shadow Directories, see		To view the list Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	In this draft, we discuss how SIP can traverse existing, non-SIP		The Session Initiation Protocol (SIP) operates over UDP and TCP. When
	aware NATs. Our approach is to make SIP "NAT friendly" with two minor		used with UDP, responses to requests are returned to the source
	extensions. The first allows for responses to UDP requests to go back		address the request came from, but from the port written into the
	to the source port of the request. The second allows a registrar to		topmost Via header of the request. This behavior is not desirable in
	use the source IP address and port instead of the Contact in a REGIS-		many cases, most notably, when the client is behind a NAT. This
	TER.		extension defines a new parameter for the Via header, called rport,
			that allows a client to request that the server send the response
			back to the source IP address and port where the request came from.
			Table of Contents
			1 Introduction ........................................ 3
			2 Terminology ......................................... 3
			3 Client Behavior ..................................... 3
			4 Server Behavior ..................................... 4
			5 Syntax .............................................. 4
			6 Example ............................................. 5
			7 Security Considerations ............................. 6
			8 IANA Considerations ................................. 6
			9 Acknowledgements .................................... 6
			10 Author's Addresses .................................. 7
			11 Normative References ................................ 7
			12 Informative References .............................. 7
	1 Introduction		1 Introduction
	The problem of getting applications through NATs has received a lot		The Session Initiation Protocol (SIP) [1] operates over UDP and TCP.
	of attention [1]. Getting SIP [2] through NATs is particularly trou-		When used with UDP, responses to requests are returned to the source
	blesome. There are several ways to solve the problem. One of these is		address the request came from, but from the port written into the
	to embed an ALG in all NATs. However, this has not happened. The top		topmost Via header of the request. This behavior is not desirable in
	commercial NAT products continue to be SIP-unaware. Even if SIP ALG		many cases, most notably, when the client is behind a NAT. In that
	support were added tomorrow, there is still a huge installed based of		case, the response will not properly traverse the NAT, since it will
	NATs that do not understand SIP. As a result, there is going to be a		not match the binding established with the request.
	long period of time during which users will be behind NATs that are
	ignorant of SIP, probably at least two to three years. The SIP com-
	munity cannot wait for ubiquituous deployment of SIP aware NATs.
	Another solution is to ubiquitously deploy IPv6, in the expectation		Related to this, there is currently no way in SIP for a client to
	that this will eliminate the need for NATs. Whether this expectation		learn, from a response to its request, the source port that the
	is realistic or not is one question, but the timeframes for such		server saw in the request. Currently, SIP does provide the client
	deployment are long.		with the source IP address that the server saw in the request. This
			information is conveyed in the received parameter in the topmost Via
			header of the response. This information has proved useful for basic
			NAT traversal, debugging purposes, and support of multi-homed hosts.
			However, it is incomplete without the port information.
	Yet another solution is to use midcom [3], with a user agent or proxy		This extension defines a new parameter for the Via header, called
	controlling the firewall. This solution is, architecturally, much		rport, that allows a client to request that the server send the
	better than usage of ALGs, but will take even longer to ubiquitously		response back to the source IP address and port where the request
	deploy.		came from. The rport parameter is analagous to the received
			parameter, except rport contains a port number, not the IP address.
	Therefore, the approach taken is to make SIP "NAT Friendly" through		2 Terminology
	some backwards compatible extensions. These extensions generally
	operate by informing a server to ignore an IP address present in the
	SIP message, and instead use the source IP address and port. This
	follows the recommendations of [4].
	Of course, the harder problem is the traversal of the media streams		In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
	through NAT. That problem is covered separately.		"SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
			"OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
			indicate requirement levels for compliant SIP implementations.
	2 Reference Architecture		3 Client Behavior
	Consider the standard SIP "trapezoid" of Figure 1. The client UA 1,		The client behavior specified here affects the transport processing
	is behind a NAT, NAT 1. It sends all requests to local outbound proxy		defined in Section 18.1 of SIP [1].
	1. Those requests are forwarded to terminating proxy 2, which then
	sends them to the called party, UA 2, who is also behind a NAT.
	Getting SIP through in this configuration involves two parts. The		A client compliant to this specification (clients include UACs and
	first is getting the request from UA 1 to Proxy 1, and the response		proxies) MAY include an rport parameter in the top Via header of
	back. The second is getting the INVITE from Proxy 2 to UA 2, and the		requests it generates. This parameter MUST have no value; it serves
	response back. The solution for the first problem is "Via Received		as a flag to indicate to the server that this extension is supported
	Ports". This solution follows the usage of the received parameter in		and requested for the transaction.
	the Via header (which handles IP addresses), but for ports. The solu-
	tion for the second problem is the new Translate header, which allows
	a client to tell a registrar to ignore the Contact header, and
	instead register an address obtained from the IP address and port
	from the REGISTER request.
	The sections below describe these extensions in more detail.		When the client sends the request, if the request is sent using UDP,
			the client MUST be prepared to receive the response on the same
			socket the request was sent on. Specifically, it MUST be prepared to
			receive the response on the same IP address and port present in the
			source IP address and source port of the request. For backwards
			compatibility, the client MUST still be prepared to receive a
			response on the port indicated in the sent-by field of the topmost
			Via, as specified in Section 18.1.1 of SIP [1].
	3 Via Ports		In the case where there is a NAT between the client and server, in
	+-------+ +-------+		order for the response to always be received, the NAT binding must
	| | | |		remain in existence for the duration of the transaction. Most UDP NAT
	| Proxy |------------- | Proxy |		bindings appear to have a timeout of about one minute. Therefore,
	| 1 | | 2 |		non-INVITE transactions will have no problem. For INVITE
	| | | |		transactions, the client may need to retransmit its INVITE every 20
	/ +-------+ +-------+		seconds or so, even after receiving a provisional response, in order
	/ \		to keep the binding open to receive the final response.
	/ \
	+------------------+ +------------------------+
	.....+------------------+... ..+------------------------+..
	. / NAT 1 . . NAT 2 \ .
	. / . . \ .
	. / . . \ .
	. +-------+ . . +-------+ .
	. | | . . | | .
	. | | . . | | .
	. | UA 1 | . . | UA 2 | .
	. | | . . | | .
	. +-------+ . . +-------+ .
	. Domain A . . Domain B .
	............................ ..............................
	Figure 1: Reference Configuration		OPEN ISSUE: This is awful. Perhaps a further sign that the
			only real answer is TCP? Or, perhaps this belongs in
			sipping-nat-scenarios, not here.
	The first problem with SIP traversal through NATs is sending a		4 Server Behavior
	request from a client behind a NAT to a server on the outside (UA 1
	to proxy 1).
	SIP specifies that for UDP, the response is sent to the port number		The server behavior specified here affects the transport processing
	in the Via header and the IP address the request came from. However,		defined in Section 18.2 of SIP [1].
	due to NAT, the port number in the Via header will be wrong. This
	means that the response will not be sent to the proper location. How-
	ever, with TCP, responses are sent over the connection the INVITE
	arrived on. This means that a response sent over the TCP connection
	will be received properly by a caller behind a NAT. Therefore, one
	solution for traversal of requests from inside to outside is to use
	persistent TCP connections. However, many VoIP endpoints do not sup-
	port TCP, so a UDP based solution is desirable.
	Our approach is to define a new Via header parameter, called the		When a server compliant to this specification (which can be a proxy
	response port, encoded as "rport". This parameter is inserted by		or UAS) receives a request, it examines the topmost Via header. If
	clients (which can be proxies or UACs) when they wish for the		this Via header contains an rport parameter with no value, it MUST
	response to be sent to the IP address and port the request was sent		insert the port the request was received from as the value of this
	from. The parameter is inserted with no value to flag this feature.		parameter. This is analagous to the way in which a server will insert
	When received at a server which understands this extension, the		the receieved parameter with the source IP address the request was
	server (which can be a proxy or UAS) MUST insert the port the request		received from. In fact, the server MUST insert a received parameter
	was received from as the value of this parameter. If the Via maddr		containing the source IP address that the request came from, even if
	parameter is not present, that port MUST be used to send the		it is identical to the value of the sent-by field. Note that this
	response, instead of the port in the sent-by field. If the maddr Via		processing takes place independent of the transport protocol.
	parameter is present, the rport parameter is ignored for sending the
	response, and the procedures defined in [2] are used.
	response-port = ``rport'' [``='' 1*DIGIT]		When a server attempts to send a response over an unreliable unicast
			transport, such as UDP, and there is no Via maddr parameter present,
			but there is both a received parameter and an rport parameter, the
			response MUST be sent to the IP address listed in the received
			parameter, and the port in the rport parameter. This effectively adds
			a new processing step between bullets two and three in Section 18.2.2
			of SIP [1].
	A client inserting the rport into the Via header MUST wait for		5 Syntax
	responses on the socket the request is sent on, and MUST also list,
	in the sent-by field, the local port of that socket the request was		The syntax for the rport parameter is:
	sent from. The latter is mandatory for backwards compatibility.
			response-port = "rport" [EQUAL 1*DIGIT]
			This extends the existing definition of the Via header parameters, so
			that its BNF now looks like:
			via-params = via-ttl / via-maddr
			/ via-received / via-branch
			/ response-port / via-extension
			6 Example
	Consider an example. A client sends an INVITE which looks like:		Consider an example. A client sends an INVITE which looks like:
	INVITE sip:user@domain SIP/2.0		INVITE sip:user@domain SIP/2.0
	Via: SIP/2.0/UDP 10.1.1.1:4540;rport		Via: SIP/2.0/UDP 10.1.1.1:4540;rport
	This INVITE is sent with a source port of 4540 and source IP of		This INVITE is sent with a source port of 4540 and source IP address
	10.1.1.1. The request is natted, so that the source IP appears as		of 10.1.1.1. The request is natted, so that the source IP appears as
	68.44.20.1 and the source port as 9988. This is received at a proxy.		68.44.20.1 and the source port as 9988. This is received at a proxy.
	The proxy forwards the request, but not before appending a value to		The proxy forwards the request, but not before appending a value to
	the rport parameter in the proxied request:		the rport parameter in the proxied request:
	INVITE sip:user@domain2 SIP/2.0		INVITE sip:user@domain2 SIP/2.0
	Via: SIP/2.0/UDP proxy.domain.com		Via: SIP/2.0/UDP proxy.domain.com
	Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988		Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
	This request generates a response, which arrives at the proxy:		This request generates a response, which arrives at the proxy:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP proxy.domain.com		Via: SIP/2.0/UDP proxy.domain.com
	Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988		Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
	The proxy strips its top Via, and then examines the next one. It con-		The proxy strips its top Via, and then examines the next one. It
	tains both a received param, and an rport. The result is that the		contains both a received param, and an rport. The result is that the
	follow response is sent to IP address 68.44.20.1, port 9988:		following response is sent to IP address 68.44.20.1, port 9988:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988		Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
	The NAT rewrites the destination address of this packet back to IP		The NAT rewrites the destination address of this packet back to IP
	10.1.1.1, port 4540, and is received by the client.		10.1.1.1, port 4540, and is received by the client.
	This works fine when the server supports this extension, so long as		7 Security Considerations
	there are no nats between the client and server. Consider a server
	that does not understand it. In this case, it will ignore the rport
	parameter, and send the following response to IP 10.1.1.1, port 4540:
	SIP/2.0 200 OK
	Via: SIP/2.0/UDP 10.1.1.1:4540;rport
	As specified by SIP, this response is sent to the source IP of the
	request, and the port in the Via header. Since the client is listen-
	ing on 4540, the response is received correctly.
	In the case where the server does not support the extension, but
	there is a nat between the client and the server, the response is
	sent to the source IP and port in the Via, which will be dropped by
	the nat. This is the same behavior exhibited by SIP today. As a
	result, our extension is backwards compatible, in the sense that it
	always works at least as well as baseline SIP. When both sides
	support it, and there is a nat in the middle, traversal works
	correctly.
	For the response to always be received, the NAT binding must remain
	in existence for the duration of the transaction. Most UDP NAT bind-
	ings appear to have a timeout of one minute. Therefore, non-INVITE
	transactions will have no problem. For INVITE transactions, the
	client may need to retransmit its INVITE every 20 seconds or so, even
	after receiving a provisional response, in order to keep the binding
	open to receive the final response.
	Because of the increased network traffic generated to keep the UDP
	bindings active, it is RECOMMENDED that TCP be used instead, as it
	generates much less data.
	4 Contact Translation
	The received port parameter will allow requests initiated from inside
	the NAT (and their responses), to work. However, getting requests
	from a proxy outside the NAT, to a host inside, is a different story.
	The problem has to do with registrations. In Figure 1, the callee, UA
	2, will receive requests at that UA because it had previously sent a
	REGISTER request to the registrar, which is co-located with proxy 2.
	This registration contains a Contact header which lists the address
	where the incoming requests should be sent to. However, in the case
	of NAT, this address will be wrong. It will contain a domain name or
	IP address that is within the private space of domain B. Thus, the
	REGISTER might look like:
	REGISTER sip:B.com SIP/2.0
	From: sip:ua2B.com
	To: sip:ua2B.com
	Contact: sip:ua2@10.0.1.100
	This address is not reachable by the proxy.
	To solve this problem, we need two things. First, we need a per-
	sistent "connection" to be established from UA 2 to proxy 2.
	Secondly, we need a way for incoming requests destined for UA 2 to be
	routed over this connection.
	To address this first problem, clients have to send REGISTER requests
	over a TCP or TLS connection, or use UDP along with the response port
	parameter in the Via header. If TCP is used, this connection is kept
	open indefinitely. We further recommend that the proxy/registrar hold
	this connection in a table, where the table is indexed by the remote
	side of the transport connection. For UDP, the client holds on to the
	socket, and uses it for REGISTER refreshes and to receive incoming
	calls. The server also holds on to the "connection". In the case of
	UDP, that means that server stores the local IP/port that the request
	was received on, and indexes it by the source IP and port the request
	was sent from. When the proxy wishes to send a packet to some server
	at IP address M, port N, transport O, it looks up the tuple (M,N,O)
	in the table to see if a connection already exists, and then uses it.
	The NAT bindings are kept fresh through REGISTER refreshes (see Sec-
	tion 4.1).
	Now, a connection is available for contacting the user. However, this
	connection must be associated with sip:ua2@B.com. Unfortunately, it
	is not. Calls for sip:ua2@B.com are translated to sip:ua2@10.0.1.100,
	which does not correspond to the remote side connection used to send
	the REGISTER, as seen by the proxy. Thats because of NAT, which will
	make the remote side appear to be a publically routable address.
	To handle this problem, the proxy could, in principal, record the IP
	address and port from the remote side of the connection used to send
	a REGISTER. Then, it can create a Contact entry of the form
	sip:bob@[ip-addr]:[port], where [ip-addr] and [port] are the IP
	address and port of the remote side of the connection. However, this
	is assuming that the registration is for the purposes of connecting
	the address in the To field with the machine the connection is coming
	from. That may not be the intent of the registration. The registra-
	tion may be used to set up a call forwarding service, for example.
	As a result, it is our proposal that clients be allowed to explicitly
	ask a proxy to create a Contact entry corresponding to the machine a
	REGISTER is sent from. To do that, the UA inserts a Translate header
	into the request. This header contains the URL (which MUST be one of
	the Contact URLs) that is to be translated, along with a parameter
	that indicates the type of NAT the client is behind.
	translate-header = ``Translate'' ``:'' ``<'' addr-spec ``>''
	[``;'' ``nat'' ``='' nat-types]
	nat-types = ``sym'' | ``cone''
	If a registrar receives a REGISTER request with a translate header,
	it MUST find the matching Contact header (using standard URL matching
	rules [2]) in the REGISTER request, and MUST replace the host value
	with the IP address in the received parameter of the bottom-most Via,
	if present, else the host from the Via sent-by field. The port of the
	Contact MUST be replaced with the rport parameter from the bottom-
	most Via, if present, else the value from the sent-by field, if
	present, else 5060. This is the actual Contact stored in the regis-
	tration database, and returned to the client in the response. Using
	the bottom-most Via to obtain the source IP and source port of the
	client allows for the case where the registrar and the outbound proxy
	are not co-located.
	If no matching Contact was found in the REGISTER, the Translate
	header is ignored.
	The nat-type parameter is an optional parameter that tells the regis-
	trar what type of NAT the client is behind. This information is very
	helpful for some faul tolerance and scalability scenarios, described
	below. The means by which the client can determine which type of nat
	it is behind are outside the scope of this specification.
	Any 2xx response to a request that contained a Translate header, and
	resulted in a translation (because there was a matching Contact),
	MUST include a Translate header in the response. This header MUST
	contain the translated URL. Of course, the same URL will also appear
	amongst the Contacts in the 2xx. The Translate header in the 2xx is
	needed so that a UAC can determine the value of the translated Con-
	tact when there are more than one registered contacts.
	Consider once more the architecture of Figure 1. The callee has an IP
	address of 10.0.1.100. It sends a REGISTER from port 2234 to port
	5060 on the proxy. This connection goes through the NAT, and the
	source address is rewritten to 77.2.3.88, and the source port to
	2937. The registration looks like:
	REGISTER sip:ua2@Y.com SIP/2.0
	From: sip:ua2@Y.com
	To: sip:ua2@Y.com
	Via: SIP/2.0/UDP 10.0.1.100;rport
	Translate: sip:ua2@10.0.1.100:2234
	Contact: sip:ua2@10.0.1.100:2234
	The proxy Y then stores the socket the request was received on into a
	table, indexed by the source port:
	(77.2.3.88,2397,UDP) -> [reference to UDP socket]
	It fills in the rport parameter, and adds the received parameter, to
	the top Via. It also translates the Contact header to
	sip:ua2@77.2.3.88:2397, and stores that in the registration database.
	It then responds to the REGISTER:
	SIP/2.0 200 OK
	From: sip:ua2@Y.com
	To: sip:ua2@Y.com
	Via: SIP/2.0/UDP 10.0.1.100;rport=2397;received=77.2.3.88
	Translate: sip:ua2@77.2.3.88:2397
	Contact: sip:ua2@77.2.3.88:2397
	This response is sent to 77.2.3.88:2397 because of the rport. The NAT
	translates this to 10.0.1.00:2234, which is then received by the
	client.
	Now, when an INVITE arrives for sip:ua2@Y.com, it is looked up in the
	registration database. The contact is extracted, and the proxy tries
	to send the request to that address. To do so, it checks its connec-
	tion table to an open connection to the IP address, port and tran-
	sport where the request is destined. In this case, such a connection
	is available, and the request is forwarded over it. Because it is
	over a connection with an existing NAT binding, it is properly routed
	through the NAT. The response from the callee is also routed over the
	same connection.
	If the UA is behind a symmetric NAT, the proxy that the user is con-
	nected to needs to record route incoming and outgoing INVITE
	requests.
	4.1 Refresh Interval
	Since the connection used for the registrations is held persistently
	in order to receive incoming calls, the NAT binding must be main-
	tained. To avoid timeout, data must traverse the NAT over that con-
	nection with some minimum period. When UDP is used, registrations
	will need to be refreshed at least once every minute. The clients
	SHOULD include an Expires header or parameter with this value. For
	TCP, a longer interval can be used. 10 minutes is RECOMMENDED.
	To test whether the interval is short enough, proxy servers MAY
	attempt to send OPTIONS requests to the client shortly before the
	registration expires. If the OPTIONS requests generates no response
	at all, the server SHOULD lower the value of the Expires header in
	the next registration. Servers SHOULD cache and reuse the largest
	successful refresh interval that they discover for a given Contact
	value.
	4.2 Routing to the Ingress Proxy
	A complication arises when a domain supports multiple proxy servers.
	Consider the scenario shown in Figure 2
	A user joe in domain.com is behind a NAT. In DNS, domain.com contains
	an SRV entry that points to three servers, 1.domain.com, 2.domain.com
	and 3.domain.com. When the user registers, they will resolve
	domain.com to one of these. Assume its 1.domain.com. As a result of
	this, the connection state is stored proxy 1.
	In the case of TCP, this connection state is important. Unless calls
	for joe@domain.com arrive to proxy 1, they won't be routable to the
	UA. In the case of UDP, whether it is important or not depends on the
	type of NAT the user is behind. One type of NAT, which we call "sym-
	metric", treats UDP much like TCP. When A sends a request from inside
	to B on the outside, UDP messages back to A must come from B, with a
	source port equal to the destination port of messages from A to B. In
	the other case, which we call "cone", which is described in [5], UDP
	messages back to A can have any source port and IP address.
	If the user is behind a NAT that operates in cone mode, any of the
	proxies in the proxy farm will be able to reach the customer through
	the NAT. All will send requests to the public IP address and port
	binding created by the NAT, but with different source IP addresses
	and ports. Since source addressing doesn't matter, things work well.
	In this case, the proxy need not even store connection state as
	described in Section 4.
	If the user is behind a NAT that operates in symmetric mode, calls to
	the user must come in through the proxy that the user registered to.
	In order to enable this, we recommend that the location server data-
	base store not only the contact, but the proxy that the user con-
	nected to. When a call comes in for that user, the proxy receiving
	the INVITE looks up the user in the database. The database entry
	indicates the proxy the user is connected to (call this the connected
	proxy). If the connected proxy is not the proxy which received the
	INVITE, the proxy that received the INVITE uses a route header to
	force the call through the connected proxy. In the case where joe
	registered at proxy1, and the incoming INVITE arrived at proxy 2, the
	request sent by proxy 2 would look like:
	INVITE sip:proxy1.domain.com SIP/2.0
	--
	// \\
	/ \
	| DB |
	| |
	\ /
	\\ //
	--
	+-----+ +-----+ +-----+
	| | | | | | domain.com
	|Proxy| |Proxy| |Proxy|
	| 1 | | 2 | | 3 |
	+-----+ +-----+ +-----+
	+-------------------------+
	| NAT |
	+-------------------------+
	+-----+
	| |
	|UA |
	| |
	+-----+
	Figure 2: Multiple Proxy Configuration
	Route: sip:joe@22.1.20.3:3038
	This request will first go to proxy1, and from there, over the exist-
	ing connection to joe.
	An alternate approach, instead of Route headers, is to simply have
	the proxy which received the request forward it to the one that the
	user registered with, without modifying the request URI. This will
	cause the receiving proxy to perform the location server lookup a
	second time, which is inefficient. However, it does not rely on the
	usage of pre-loaded routes.
	The differing proxy behaviors for symmetric and cone NATs explains
	the presence of the nat-type attribute in the Translate header.
	Assuming the client can determine which type it is behind it can sim-
	ply inform the proxy, allowing it to take the proper action.
	4.3 INVITE Usage
	The 200 OK response to the REGISTER request contains the SIP URL that
	the registrar placed into the database. This address has the impor-
	tant property that it is routable to the client from the proxy on the
	public side of the NAT. As a result, the client needs to place this
	URL as the Contact header in its INVITE requests and 2xx responses to
	INVITE, so that it can be reached from the proxy on the outside.
	5 Security Considerations
	Arguably, the usage of receive ports and the Translate header improve
	security. In normal SIP usage, a rogue UA or proxy can send registra-
	tions that contain Contacts that point to a different phone. Or, they
	can send an INVITE with a Via header that contains the echo port, or
	some other port, on the machine. These can be used to launch attacks.
	The receive port and Translate header insure that only the entity
	that sent the requet, is the one to receive further messages.
	6 Acknowledgements
	The authors would like to thank Rohan Mahy for his comments and con-
	tributions to this work.
	7 Changes since draft-ietf-sip-nat-00
	o Described resolution of conflict between rport and maddr
	parameter.
	o Specified that the registrar use the bottom-most Via rport and
	received parameter to obtain the source IP and port.
	o Specified that the Translate header needs to appear in 2xx		Since this extension merely adds source port information to the
	REGISTER responses.		source address information already present in SIP, it does not appear
			to add any additional security considerations.
	8 Changes since draft-rosenberg-sip-entfw-02		8 IANA Considerations
	o Split entfw into three. This is piece 1, which covers the pure		There are no IANA Considerations associated with this specification.
	SIP extensions.
	o Changed syntax of Translate header. Allow any URL type, and		9 Acknowledgements
	require usage of angle brackets to distinguish URL from header
	parameters.
	o Clarified that record-routing of INVITE at the proxy is not		The authors would like to thank Rohan Mahy for his comments and
	needed if UDP is used and the client is behind a full cone		contributions to this work.
	NAT.
	Full Copyright Statement		Full Copyright Statement
	Copyright (c) The Internet Society (2001). All Rights Reserved.		Copyright (c) The Internet Society (2002). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this docu-		included on all such copies and derivative works. However, this
	ment itself may not be modified in any way, such as by removing the		document itself may not be modified in any way, such as by removing
	copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of develop-		Internet organizations, except as needed for the purpose of
	ing Internet standards in which case the procedures for copyrights		developing Internet standards in which case the procedures for
	defined in the Internet Standards process must be followed, or as		copyrights defined in the Internet Standards process must be
	required to translate it into languages other than English.		followed, or as required to translate it into languages other than
			English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			10 Author's Addresses
	9 Author's Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	First Floor		First Floor
	East Hanover, NJ 07936		East Hanover, NJ 07936
	email: jdrosen@dynamicsoft.com		email: jdrosen@dynamicsoft.com
	Joel Weinberger		Joel Weinberger
	dynamicsoft		dynamicsoft
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	skipping to change at page 14, line 25 ¶		skipping to change at page 7, line 30 ¶
	East Hanover, NJ 07936		East Hanover, NJ 07936
	email: jweinberger@dynamicsoft.com		email: jweinberger@dynamicsoft.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	M/S 0401		M/S 0401
	1214 Amsterdam Ave.		1214 Amsterdam Ave.
	New York, NY 10027-7003		New York, NY 10027-7003
	email: schulzrinne@cs.columbia.edu		email: schulzrinne@cs.columbia.edu
	10 Bibliography		11 Normative References
	[1] M. Holdrege and P. Srisuresh, "Protocol complications with the IP		[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
	network address translator (NAT)," Internet Draft, Internet Engineer-		protocol," Internet Draft, Internet Engineering Task Force, Feb.
	ing Task Force, Oct. 2000. Work in progress.		2002. Work in progress.
	[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:		[2] S. Bradner, "Key words for use in RFCs to indicate requirement
	session initiation protocol," Request for Comments 2543, Internet		levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
	Engineering Task Force, Mar. 1999.
	[3] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan,		12 Informative References
	"Middlebox communication architecture and framework," Internet Draft,
	Internet Engineering Task Force, Oct. 2001. Work in progress.
	[4] D. Senie, "NAT friendly application design guidelines," Internet		Full Copyright Statement
	Draft, Internet Engineering Task Force, Mar. 2001. Work in progress.
	[5] J. Rosenberg, R. Mahy, and C. Huitema, "Traversal using nat relay		Copyright (c) The Internet Society (2002). All Rights Reserved.
	(turn)," Internet Draft, Internet Engineering Task Force, Nov. 2001.
	Work in progress.		This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS 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.
End of changes. 37 change blocks.
	461 lines changed or deleted		154 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/