Subject: [midcom] FW: [SIP] NAT, SOCKS 5 proxies, win proxies

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 13 Feb 2001 10:47:57 -0600

The folowing thread was actually on the SIP working group mail-list I
responded to it there but I thought that we should discuss this in our
forum. Another one will follow.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Christopher A.
Martin
Sent: Friday, February 09, 2001 11:46 PM
To: 'Jonathan Rosenberg'; 'John Lazzaro'; [email-masked]
Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies

Jonathan,
I believe that workarounds for firewall inadequacies is no better than
removing the firewall.

The issue of trust compounds the already insecure nature of SIP without
adding a possible avenue of attack from an untrusted public source, through
the use of SSL or TLS. by at least creating the functionality at or on the
firewall one could at least have a fighting chance.

Also as we know vulnerabilities exist, but also can be created by unsound
architectures. Already SSL has been determined to be flawed in a lab
environment, causing a systme vulnerability that may allow access to the
server running it. TLS is supposed to fix alot of the downside to SSL, as
well as become the standards based form of SSL, but does it also have the
vulnerability?

In the draft you state

"The other alternative, embedding a SIP ALG within enterprise NATs and
firewalls, has not happened. The top commercial firewall and NAT products
continue to be SIP-unaware. Even if SIP ALG support were added immediately,
there is still a huge installed based of firewalls and NATs that do not
understand SIP."

As an assumption on my part I would like to go out on a limb and state that
just as SIP is evolving, and growing in support, so will the firewall
vendors in implementing the solution.

I also believe that if an enterprise has made the decision to implement SIP,
whether to save money or take advantage of the new functionality offered at
such a scale, they have already signaled that they are willing to do what it
takes to support SIP.

If the existing firewall technology cannot accomodate the business
requirement to implement SIP, the enterprise will most likely find a vendor
that can.

As we know a couple of vendors have already begun to support SIP
functionality, and others are following suit.

But I've rambled my personal agenda long enough, on to the task at hand.
Lets make the standards based methodology needed to propagate SIP to the
world through NAT, short lived though it may be. :^)

Christopher A. Martin
SR. Security Integration Engineer
IP Communications Engineering, WorldCom
972-729-4569

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Thursday, February 08, 2001 9:22 PM
> To: 'John Lazzaro'; [email-masked]
> Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies
>
>
> All solutions for nat and firewall traversal that assume no enterprise
> support are ugly. I have proposed one solution:
>
> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-ent
> fw-00.txt
>
> which relies on a B2BUA outside of the firewall, coupled with
> SIP over TLS.
>
> -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
>
>
> > -----Original Message-----
> > From: John Lazzaro [mailto:[email-masked]]
> > Sent: Thursday, February 08, 2001 8:00 PM
> > To: [email-masked]
> > Subject: Re: [SIP] NAT, SOCKS 5 proxies, win proxies
> >
> >
> >
> > [email-masked] writes:
> > > a) SIP and RTP should be able to work from a single UDP port.
> >
> > This basic idea can work -- sooner or later I hope to write up
> > a SIP B2BUA I've implemented for multi-party conference
> > initialization that takes this route, mostly following the
> > "Activision" techniques described in the recent "Protocol
> > Complications with NAT" RFC. The ugliest aspect of this is
> > that unless you also want to multiplex RTP and RTCP on the
> > same UDP port, you need to have parallel SIP sessions going
> > on two ports, on for the RTP port and one for the RTCP port.
> > In my SDP-specific implementation for the B2BUA, the NAT
> > information specified in the Activision algorithm gets
> > embedded in SDP fmt lines by the SIP conference server,
> > which is another ugly aspect ... although I believe that
> > if the received tag for Via was a hostport, you might be able
> > to legally embed this NAT information in the SIP itself.
> >
> > However, I think there's a big difference between "it can
> > be made to work" and "everyone should do it" -- using the
> > OS to do multiplexing is a pretty key concept in ALF, and
> > when you ignore it all sorts of bad things result.
> > One that immediately comes to mind -- you can't connect()
> > the socket on the client if you're using the Activision
> > algorithm in the multi-party case, since you're using the
> > same socket to send RTP to several parties, as well as
> > the SIP conference B2BUA. The result is, you can't get
> > ICMP feedback to tell if you're UDP packets aren't being
> > listened to, and need to use timeouts exclusively ...
> >
> > --------------------------------------------------------------
> > -----------
> > John Lazzaro -- Research Specialist -- CS Division -- EECS --
> > UC Berkeley
> > lazzaro [at] cs [dot] berkeley [dot] edu
> www.cs.berkeley.edu/~lazzaro
> --------------------------------------------------------------
> -----------
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer'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 sip-implementors" in the body.
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer'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 sip-implementors" in the body.
>

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer'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 sip-implementors" in the body.

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: John Lazzaro <[email-masked]>
Date: Wed, 14 Feb 2001 10:35:36 -0800

"Christopher A. Martin" <[email-masked]> writes:
> Thank you, that was my point! The firewall vendor needs to accomodate SIP
> not the other way around. This thread was trying to find a solution by
> modifying SIP and/or RTP to accomodate the firewall.

For the record, I think we need both, and my own interest is
the latter -- to combine the Activision technique described in RFC 3027
and also in:

http://www.alumni.caltech.edu/~dank/peer-nat.html

with SIP, for getting UDP RTP and SIP through NAT's. 

It's not clear to me that this sort of technique has a place in midcom --
I'm still paging through the 20 different types of middeboxes in 
draft-carpenter-midtax-00.txt to see if it fits anywhere :-). But
since its a UDP approach to draft-rosenberg-sip-ent's TCP approach,
it does seem to be a valid potential topic for the SIP WG, although
given the incredible workload of SIP WG, it certainly isn't a priority ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------