Subject: RE: [SIP] NATs and firewalls: yet another approach?

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 1 Mar 2001 02:16:30 -0500

Comments at end.

> -----Original Message-----
> From: Alberto Cuda [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 9:20 AM
> To: [email-masked]
> Subject: [SIP] NATs and firewalls: yet another approach?
> 
> 
> Hi, 
> I was looking for a workaround for the NAT/firewall
> problem concerning RTP flows when the UA *knows* it
> is not capable of creating a "good" SDP description.
> In particular I was wondering if there's a way 
> to avoid the deployment of a B2BUA and stick with a 
> vanilla proxy. So the question is: what if UAs 
> could "declare" in an header the address they'll need, 
> in order to let SIP proxies allocate an address and 
> return it to the sender? For instance, if "[email-masked]" 
> wants to call "[email-masked]" the message flow could be:
> 
> [email-masked]    proxy.a.com        
>       |                 |                
>       |-------M1------->|                
>       |<------M2--------|                
>       |-------M3------->|                 
> 
> M1:
> INVITE sip:[email-masked] SIP/2.0
> ...
> Address-Request: 10.0.0.1:24445;transport=udp
> ...
> c=IN IP4 10.0.0.1
> ...
> 
> M2:
> SIP/2.0 4xx Address Needs Translation
> ...
> Address-Request:
> 100.0.0.1:24445;transport=udp;map=163.162.3.19:1029;expires=3600
> ...
> 
> M3:
> INVITE sip:[email-masked] SIP/2.0
> ...
> Address-Request: 10.0.0.1:24445;transport=udp;map=163.162.3.19:1029
> ...
> c=IN IP4 163.162.3.19
> ...
> 
> And so on. Of course this requires also a new request method 
> to let the callee allocate its address[es] (it can't do it within
> the INVITE transaction, because it can't receive a response from
> the proxy). This new method could also be useful to reallocate the 
> same addresses or if this operation requires some kind of
> authentication. 
> 
> This SIP-extension should work even if the message body is 
> not SDP, and
> has
> no side effects when one of the two peers does not understand it.
> It works when there are one or more NATs and/or firewalls (if an RTP
> proxy
> is also deployed): it looks too good to be true. What I'm missing?

How does the proxy know the IP address? There won't be a NAT binding for it
in the NAT. So, the proxy needs to create the binding. Once it does that, it
has to manage the lifecycle of the binding, which means it now needs to
become call stateful. So, you're pretty much doing whats in
draft-rosenberg-sip-firewalls-00.txt, but trying to control a NAT with which
you may not have a relationship (enterprise traversal). Not likely to work.

I'll note that the solution in draft-rosenberg-sip-entfw-00.txt does not
require a B2BUA. It can work with a transaction stateful proxy.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 02 Mar 2001 16:26:35 +0100

Jonathan Rosenberg wrote:
[...]
> the proxy needs to create the binding. Once it does that, it
> become call stateful. 

Perhaps not necessarily -- one may use session timers w/re-invites and 
translate them to FW/NAT binding timers.

Jiri

-- 
Jiri Kuthan         sip:[email-masked]
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

---

From: Alberto Cuda <[email-masked]>
Date: Fri, 02 Mar 2001 17:01:16 +0100

> translate them to FW/NAT binding timers.

This is what I had in mind. More precisely, I was thinking of an 
"expires" parameter, set by the server:
> Address-Request: \
Clients can keep the binding alive by (re-)sending that method 
I introduced in my previous email. 

What I'm trying to find is the most simple/general way to allow
connections without depending on a specific version of a specific
session descriptor. Yet there are so many possible architectures 
that it isn't so easy predict if this is feasible without actually
implementing it, so I think I'll try this extension with our UA 
and proxy: if the results will be interesting, I'll post them here.

	Cheers.
		Alberto.

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 03 Mar 2001 20:19:15 +0100

Please note the only point I made previously was a SIP proxy could
keep FW/NAT rules alive without having to be call-stateful.

The particular scenario you are suggesting seems quite difficult to
deploy as it requires changes to applications both in end-devices and
network. You still need to bind SIP proxies to FW/NAT somehow.

I personally expect embedded ALGs to be the earliest solutions to
the FW/NAT problem and midcom solutions later.

Jiri