Subject: RE: [SIP] SIP through Firewalls Revisited

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 4 Mar 2001 21:19:59 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, March 04, 2001 8:55 AM
> To: [email-masked]
> Subject: [SIP] SIP through Firewalls Revisited
> 
> 
> I saw the Feb 22 edition of "Getting SIP through Firewalls and NATs"
> (draft-rosenberg-sip-firewalls.txt), with interesting updates on
> draft-rosenberg-sip-entfw-001.txt.

Just for clarification; these address very different probles. The first,
draft-rosenberg-sip-firewalls, gives details on how to build a SIP ALG for
NAT. The second, which is far more time critical, deals with how to get SIP
through NATs and firewalls when there is no ALG involved at all. Expect an
update on this document to be posted shortly, with a new approach which now
allows RTP over UDP to work....

> 
> With respect to the "Non-Solution 1", section 7,  page 27, 
> you mention the
> possibility that firewall implementors will learn "to block 
> messages based
> on their content" once they learn that we are doing this sort 
> of thing.
> Quite right. For example, firewalls nowadays can check the 
> protocol to see
> that it is really HTTP.
> 
> But just to be contrary, let me suggest if we want to implement this
> non-proposal, with all its problems, and both sides of the 
> SIP transaction
> are cooperating, we could make the first token of the initial line
> "HTTP/1.0" rather than "SIP/2.0".

Its like a game of cat and mouse. First we do that, and then firewalls get
smarter, and look for mandatory headers, method names, and so on. I wouldn't
be surprised if a firewall blocked anything except GET, HEAD, POST. We very
quickly arrive at http tunneling.

-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: Henning Schulzrinne <[email-masked]>
Date: Sun, 04 Mar 2001 21:27:37 -0500

> quickly arrive at http tunneling.

One also shouldn't forget that defeating a firewall can yield two
reactions:

+: firewall admin bought the cheapest code she could find, is glad that
she doesn't have to upgrade the firewall to support this strange SIP
stuff, and otherwise doesn't care.

-: firewall admin is annoyed with people that try to circumvent rules
that only allow certain traffic types, and reports you to your boss, who
doesn't know about the technical details, but certainly knows about
company rules. You're asked to clean out your desk.

After all, we're not circumventing some inconvenient fact of nature, but
rather, in some cases, restrictions put into place for whatever
(misguided) reasons. Intentional cheating is not likely to be looked
upon favorably in those cases.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 05 Mar 2001 07:04:10 -0600

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Henning Schulzrinne
> Sent: Sunday, March 04, 2001 8:28 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [SIP] SIP through Firewalls Revisited
>
>
>
This is true. I am not an advocate of work arounds or tunneling mechanisms,
but, since we are trying to place SIP into the mainstream, perhaps if we
supplement TLS with an accountability mechanism built in (to appease the
security administrators) which identifies the tunneled protocol we can
continue with this as a work around, or maybe even as a permanent solution.

The main benefit that I see with using TLS is that we can provide a form of
confidentiality, though weak, we can at least offer a minmum form of privacy
to the client itself.

Correctly implemented, and as TLS and Internet authentication mechanisms
develop this may prove to be the best possible way to achieving a KISS
solution.

IMHO
Chris