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

From: John Lazzaro <[email-masked]>
Date: Tue, 13 Feb 2001 20:06:36 -0800

"Christopher A. Martin" writes
[...]

> 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.

But how do enterprises make that decision? It happens because
"Sparky the change agent" downloads an application demo, gets enthused,
and starts a process of building consensus in an organization
around the idea. 

Sparky needs subterfuge to get that application working, though, if a
firewall or NAT stands in the way.  Enter draft-rosenberg-sip-ent and
other such tricks.

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

The real goal of SIP solutions to work around firewalls and NATs is to
let sparky do the demo to her manager's manager, who will reorder the
priorities of the 10 items on the overworked network administrator's
list of things to do, and put "finding a new firewall vendor who
supports SIP" at the top.

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

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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Wed, 14 Feb 2001 09:29:01 -0600

Comments are inline,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> John Lazzaro
> Sent: Tuesday, February 13, 2001 10:07 PM
> To: [email-masked]
> Subject: [midcom] RE: [SIP] NAT, SOCKS 5 proxies, win proxies
>
>
>
>
Actually this may happen in smaller organizations, but in the larger
disciplined organizations IT personnel attend seminars, meet with vendors
and attempt to stay on top of current technology. This also applies to the
telecommunications departments. And lets not forget the vendor sales people
that want to pawn their latest and greatest, they wont let the above
individuals forget that theres a new toy in town either.

> firewall or NAT stands in the way.  Enter draft-rosenberg-sip-ent and
For the smaller organizations, where sparky works, if sparky is authorized
to download and install programs for testing then sparky should not have a
problem connecting it the unprotected side of the firewall and showing off
the new gadget. If sparky is not authorized then management most likely
wouldnt hear about this cool new toy.

In addition, if sparky performs subterfuge on my network, and risks damage
to the business operations, then sparky can go look for another job.

> supports SIP" at the top.
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.

Now for testing and prioritiization, if sparky is authorized, and the
firewall admin does not wish to make the rules to permit this traffic,
hopefully the light will turn on in sparky's head to makes sparky realize
that this could be tested on the open network (the unprotected side of the
firewall. Then management can see the demo and determine priorities all day
long. Thats a lot of "if's" and "and's", but since we're writing a story
here let me embellish a little.

;^>

Chris