Subject: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2000 14:05:33 -0500

I wanted to draw attention to the following draft which we have submitted.
It tackles, and provides what we believe to be at least a workable solution,
to the problem of SIP traversal through enterprise firewalls and NATs when
there is no ALG at all associated with, or inside of, the firewall. 

Thanks,
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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 22, 2000 6:13 AM
To: IETF-Announce
Cc: [email-masked]
Subject: I-D ACTION:draft-rosenberg-sip-entfw-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: SIP Traversal through Residential and Enterprise
NATs 
                          and Firewalls
	Author(s)	: J. Rosenberg, H. Schulzrinne
	Filename	: draft-rosenberg-sip-entfw-00.txt
	Pages		: 15
	Date		: 21-Nov-00
	
In this draft, we discuss how SIP can traverse enterprise and
residential firewalls and NATs. This environment is challenging
because we assume here that the end user has little or no control
over the firewall or NAT, and that the firewall or NAT is completely
ignorant of SIP

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rosenberg-sip-entfw-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rosenberg-sip-entfw-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Wed, 22 Nov 2000 14:05:37 -0500

---

From: Howard Hart <[email-masked]>
Date: Mon, 27 Nov 2000 10:41:32 -0800

Jonathan and Henning,

   I think this is a great shot at tunneling SIP and RTP through Firewalls,
though you may want to add the following caveats to section 6:

    1) Wrt corporate tunneling, high-bandwidth voice traffic has a distinct
network signature vs. (relatively) low-bandwidth Web traffic. If you blast
voice traffic, encrypted or unencrypted over Web ports, it's going to stick out
like a sore thumb even using the crudest network monitoring tools. ISS and the
other network intrusion detection packages may even flag it as a Netbus,
BackOrifice, or  Distributed Denial of Service attack signature. Most network
administrators will shut the originating host/port down immediately and ask
questions later.

    2) The Internet backbone itself has been heavily optimized (some might say
almost too optimized) for port 80 traffic, and is moving in that direction (as
much as is feasible) for port 443/HTTPS. Increasingly, ISPs are using Web
caching engines to limit this traffic across their backbones. Case in point--I
used Checkpoint's encrypted VPN product in a previous company to connect an
overseas location to our site (encrypted payloads, port numbers stay the same).
Our remote site wanted to access our internal Web server. Unfortunately, one of
the intermediate ISPs was using a Web caching product, which resulted in the
caching engine intercepting, then attempting to originate an (unauthorized)
port 80 access to our internal Web server on the remote end's behalf, with the
expected (non)result. The answer from the ISP was, of course, "well it works
fine for all our normal customers--EOM". I think you'd see some very
interesting  side effects if you applied a tunneled RTP stream to this or other
kinds of caching servers on port 80.
Granted, 443/SSL-caching is a much more difficult problem, equating to a
man-in-the- middle attack--maybe even unsolvable, but given the monetary
inceptive is huge to come up with a solution here too, partial or otherwise....

Howard Hart
ipDialog, Inc.

Jonathan Rosenberg wrote:

>   ------------------------------------------------------------------------
>
> Subject:
>   ------------------------------------------------------------------------
>
>    ATT04220.txtName: ATT04220.txt
>                Type: Plain Text (text/plain)
>
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 28 Nov 2000 09:52:42 -0500

> administrators will shut the originating host/port down immediately and ask

I'm not sure whether that's a problem, as voice bandwidth is generally
much lower than web retrievals. (As low as 8 kb/s vs. a few hundred
kilo*bytes*/second on my desktop to many web servers. If I download a
piece of software, it will easily consume as much bandwidth as a phone
call: 3 minute call = 180 seconds = 180 kBytes, which is smaller than
many individual web pages.)

> almost too optimized) for port 80 traffic, and is moving in that direction (as

This is bogus, except for the web caching that some ISPs (but,
fortunately, by no means all ISPs) do. Routers don't know about port 80.

> inceptive is huge to come up with a solution here too, partial or otherwise....

Much of 443 traffic is inherently uncacheable, as it is for things like
forms responses from web orders. I doubt that even the looniest ISP
would want to return your airline booking confirmation page or bank
balance to me. Also, unless the cache has the certificate of the origin
server, intercept is just not possible. I doubt that Citibank, say,
would hand out their private key to random ISPs.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Howard Hart <[email-masked]>
Date: Tue, 28 Nov 2000 12:08:39 -0800

Hi Henning,

   See responses below:

> many individual web pages.)

If the average Web page retrieval required 100+ kbytes/second, I don't think the
average user on their 28.8 baud, 3-5 kbytes/second (w/VJ compression) modem would do
much web surfing :-), but I get your point. My contention is divergence from Web
traffic signatures will be highly dependent on a number of cumulative factors, from
your locally provisioned bandwidth, to your usage patterns, to the number of times
you access the same server, to the sensitivity of your intrusion detection package,
to how long you stay on the phone, etc. If you throw in sustained, encrypted RTP
packet rate signatures at 25-50 pps over several minutes with the added burden that
only a small percentage of Web traffic is encrypted/port 443, it will probably
trigger the alarms, but your mileage will vary depending on the level of paranoia at
your local site.

> fortunately, by no means all ISPs) do. Routers don't know about port 80.

Agreed, my wording was poor. More accurately, ISPs are deploying web caching engines
at their edges to eliminate/optimize redundant HTTP/port 80 traffic over their
backbones, especially when they're being used for transit vs. direct access to Web
servers within their networks.

> would hand out their private key to random ISPs.

True, and as I stated above, maybe unsolvable, but for a sample of where pieces of
this might come into play later on, check out
http://www.f5.com/f5products/bigip/ecommerce, one of the more popular Web
load-balancers. The advantage here is you offload encryption and key negotiation
from individual servers in a large server farm and place the burden in hardware on
the load-balancer. The question then becomes an ISP/SysAdmin policy issue as to
whether you can locate your remote tunneling Proxy in front of or behind the
load-balancer, and what's the impact when the load-balancer assumes all traffic on
port 443 is HTTP only.

NOTE: This is obviously NOT an issue for your scheme today. Just something to
consider or maybe even take advantage of in the future.

Howard Hart
ipDialog, Inc.