Subject: [Sip] How is the NAT/Firewall solution status right now?

From: "Patrick Lam" <[email-masked]>
Date: Thu, 10 Apr 2003 16:27:10 +0800

Dear all:

I lost track of this a little while ago.  How is the status for NAT/Firewall
solution for SIP currently?  

Is MIDCOM still the best one right now?

Actually, why does the SIP community not like the idea of opening a
particular public address (at the firewall) for an ALG, and let all the
traffic (heading any port) through to it?  I have asked many security
experts, it seems like as long as I close the corresponding sockets on the
ALG after the RTP sessions, allowing traffic to flow through the firewall
(toward the closed socket) should not cause much threat.  

What is the current best solution for the NAT/firewall problem right now?

Thanks.

Patrick Lam

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Apr 2003 00:46:11 -0400

inline.

Patrick Lam wrote:
> Dear all:
> 
> I lost track of this a little while ago.  How is the status for
> NAT/Firewall solution for SIP currently?  

There are many solutions. draft-ietf-sipping-nat-scenarios describes 
some of them. The net/net from that draft is that its all a big mess, 
with differing solutions in differing cases. TO deal with that, I have 
recently proposed a unifying mechanism called ICE:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt

> Is MIDCOM still the best one right now?

MIDCOM is still unspecified. But, if/when it arrives, it won't cover 
many cases. It has the fundamental problem that it requires the agent to 
know the precise location of the firewalls/nats on the media path. This 
is pretty much a show-stopper in a lot of topologies. For example, in 
the case where you have a nat in your house, which your PC can control 
with midcom, there still may be a nat on the cable provider network, 
which you will not know about. Protocols like STUN and TURN (both of 
which are used by ICE) don't have this kind of limitation.

The long term right-answer is based on nsis, when all of the 
firewalls/nats support it. But thats a long ways off.

> experts, it seems like as long as I close the corresponding sockets on
> the ALG after the RTP sessions, allowing traffic to flow through the
> firewall (toward the closed socket) should not cause much threat.  

It is not unreasonable, and there are products on the market that 
basically work like this. This kind of approach has the benefit compared 
to midcom of not requiring firewall changes per se. However, it does 
require the deployment of some kind of box which will act as a media 
relay. That increases overall cost and introduces requirements for more 
bandwidth in the DMZ to handle the relay. This relay can be a b2bua or a 
TURN server or equivalent.

Note that, with ICE, the traffic through this relay can be substantially 
reduced, using it only for calls that actually end up going to endpoints 
outside the firewall.

> What is the current best solution for the NAT/firewall problem right

Well, if you want my biased opinion, it is STUN and TURN in conjunction 
with ICE. I owe the wg a draft that describes how this optimally handles 
all of the cases in draft-ietf-sipping-nat-scenarios with a single 
client-side mechanism.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip