> On Fri, Apr 05, 2002 at 12:37:01PM -0600, Glover George wrote: > > Am I right in understanding this logic behind doing connection tracking? > > The first protocol involved that needs to be messed with is SIP. Does > > I've been spending quite some time digging into SIP and thinking about > possible solutiosn for conntrack/NAT support for this protocol. It's not > as easy as you think. In certain fields of the SIP header, a hostname > instead of an IP can be used. So how do you create an expectation for > a hostname? Somebody would have to resolve the hostname into an IP > address and then cause an expectation for this IP address. Stuff like > that can't be done from within the kernel, so you'd need some support > for an asynchronous DNS resolver in userspace. >
I've sniffed the initial transactions and MSN transmits what it thinks each location's ip is during the communications through the .Net servers. I haven't been able to look at the first SIP packets because the remote location can't send it's SIP Invite because my location is sending the 192.168.xx address to the other server. > Furthermore, what about encrypted or authenticated SIP/SDP? You loose. > > Please try to read the available documentation. There is a Master thesis > on how to NAT SIP/SDP, which proposes a specific way of implementation. But here, and maybe correctly, you're looking at an overall solution. My motivation, however off it may be, is to get the traditional Messenger stuff working using the .Net servers. The Windows Messenger docs say that encryption is only use when in conjunction with an SIP Proxy service (Yes, I have been reading the available documentation!). But I'd also like you to send me the links to this extra documentation you've found. Thanks. > > The 'official' IETF approach on how to NAT SIP/SDP is that you have to > run some SIP proxy, which communicates the to-be-opened port and NAT > mappings > over some protocol (formerly FCP, firewall configuration protocol) to the > firewall. And how is the SIP proxy any safer that allowing it through the server? They're both going to relay the same information back to the inside machine, and if the SIP Proxy isn't watching for Trojan horses, what's to say it won't get through anyway? The fact is some OS's ARE indeed insecure, but we don't always have that choice now do we. Like I said before it's easy to write this off as just too insecure. But since when has the open source community said we don't want to provide choices? I don't know about all of you, but I really don't care if my infamous OS is open to attacks through these ports. What's the alternative? Having to pull it out from behind the firewall completely leaving EVERY port open to compromise? The prevailing attitude should be if people want to use it, give them as much adequate warning about the service as possible, but give them the choice! If they don't take the time to create a site-specific security policy, should they really be screwing with a firewall in the first place?
