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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Nov 2000 10:02:36 -0500

There are a couple of mitigating factors.

One is that the big firewall vendors are starting to
commit to supporting SIP. No names, sorry, NDA issues!

Another is that commercial SIP firewall "side cars" are appearing.

I had an enlightening conversation with my internal security folks
about the relative merits of "in the firewall" and "in parallel with
the regular firewall" approaches.  They seemed content with the argument
that a parallel approach would be best if traffic volume of RTP was
high, but "in the existing firewall" was best otherwise.

I remember arguing for what we called an "interim AH" security scheme
in Megaco, because at the time, the embedded OSs did not support
IPSEC, and it was pretty hard to add it unless you had source code
(since the AH header goes between IP and anything else).  We used
a header in the Megaco payload.  By the time the protocol came out,
the OSs had been upgraded, so that most now have IPSEC, if not from
the vendor, then a 3rd party.  I wonder if we would have the same
result here.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 12:23 AM
> To: 'Howard Hart'; Henning G. Schulzrinne
> Cc: Jonathan Rosenberg; [email-masked]'
> Subject: RE: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt
> 
> 
> I think this all has to be taken within the context that the 
> entfw draft is
> NOT meant to be a long term solution. It is a short term 
> hack, nothing more.
> As such, I am not really worried about potential HTTPS 
> caching proxies (if
> even possible) that might arise one or two years from now. 
> 
> The draft aims really to solve a chicken-and-egg problem. No 
> enterprise IT
> admin is going to let SIP (let alone UDP based RTP) in or out of the
> firewall until there is overwhelming demand and strong 
> reasons for them to
> do so. These incentives come when enough internal users are 
> using services
> and deriving business value from them. Unfortunately, that 
> won't ever happen
> since the firewalls block SIP/RTP. So you see the problem. 
> Through what is,
> in the best case, an ugly hack, we can get some usage going within
> enterprises, and then the demand can grow, and then IT 
> departments will
> change policies so that users can stop doing horrible things 
> like port 443
> tunneling, and rather use SIP the original way it was 
> designed to be used.
> 
> -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: Howard Hart [mailto:[email-masked]]
> > Sent: Tuesday, November 28, 2000 3:09 PM
> > To: Henning G. Schulzrinne
> > Cc: Jonathan Rosenberg; [email-masked]'
> > Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt
> > 
> > 
> > Hi Henning,
> > 
> >    See responses below:
> > 
> > "Henning G. Schulzrinne" wrote:
> > 
> > > Howard Hart wrote:
> > > >
> > > > 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.
> > >
> > > 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.)
> > 
> > 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.
> > 
> > >
> > >
> > > >
> > > >     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
> > >
> > > 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.
> > 
> > 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.
> > 
> > >
> > >
> > > > 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....
> > >
> > > 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.
> > 
> > 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.
> > 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 30 Nov 2000 18:46:08 +0100

> commit to supporting SIP. No names, sorry, NDA issues!

For example, Cisco claims to have SIP support in their
latest PIX firewalls 5.2:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/pixrn521.htm#xtocid2350933

FYI: The "in parallel with the regular firewall" topic
will be discussed at the MidCom BOF

Jiri

-- 
Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
		    tel:+49-30-34637271
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

---

From: "Tom Tang" <[email-masked]>
Date: Thu, 30 Nov 2000 10:08:04 -0800

Jiri :

   Can you elaborate on what operations they support for SIP ?
 I looked through that link and on the Cisco website, but
 nada. Thanks.

 - Tom

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jiri Kuthan
Sent: Thursday, November 30, 2000 9:46 AM
To: Rosen, Brian
Cc: 'Jonathan Rosenberg'; 'Howard Hart'; Henning G. Schulzrinne;
[email-masked]'
Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt

For example, Cisco claims to have SIP support in their
latest PIX firewalls 5.2:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/pixrn521.h
tm#xtocid2350933

Jiri