Subject: [SIP] Poorman's SIP through firewall.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 20 Jul 2000 19:53:42 -0700

Yet another SIP firewall proposal:

It provides a way to get past a dumb/non-SIP or RTP aware firewalls where
there are no RTP proxies or firewall control features. This would be the
sort of mechanism used by a PC SIP client on a corporate network to reach
the outside world with no assistance from an unsympathetic network
adminstrator <grin>.

It uses RTP over TCP. This will require adding a new "rtp over tcp" profile
for SDP - I have heard other people talking about this for DTMF transport so
I'm sure it will eventually happen. 
[Sure, everyone knows that tcp is not optimal for real-time traffic but it
is used successfully by a lot of existing internet multimedia applications.]

So how does it work ? Simple. It requires no changes to SIP and has needs no
special handling of the firewall case.

Firstly the User-Agents establish a SIP session using TCP to get through the
firewall (a static firewall port map to a SIP proxy would be required for
UA's to call into the firewall). The SIP signalling through a firewall has
always been possible but the tricky part has been punching the media
through.

_Both_ UA's attempt to open a TCP connection to the address list in each of
the m= lines in the SDP body (eg, m=audio 5000 RTP_TCP/AVP 18) - this is
done regardless of whether the m= line is sendonly, recvonly or sendrecv.
Now one or both TCP connections may succeed. The UA's send their media on
the first TCP connection that successfully connects and should receive media
on either the inbound or outbound TCP connection. For robustness the source
port of the TCP connection should come from a different port than the local
port specified in the SDP body (otherwise you could have two TCP sessions
between the same port pair).

In the case of the firewall penetration only one of the two TCP connection
attempts will succeed (the one going from inside to outside the firewall)
but since each connection provides a bidirectional pipe then two way media
flow can be achieved.

Can anyone see any problems with this idea ?

Security issues: 
- interior addresses will be placed in the SDP session (I don't think that's
a major security breach is it?)
- you are forced to accept media connections from unknown IP addresses. I
don't see this as a real problem for internet users - if you want real
security use a proper SIP ALG firewall proxy.

Robert.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Jul 2000 00:58:17 -0400

> Can anyone see any problems with this idea ?

1. still doesn't work with nat
2. doesn't work if both users are behind firewalls (both TCP connections
will fail)
3. many firewalls won't let tcp out on dynamic ports; only fixed ones
like 80, and then often just from a proxy
4. latency will really suck

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: Howard Hart <[email-masked]>
Date: Fri, 21 Jul 2000 09:25:24 -0700

Or you could just park yourself on the standard RealAudio TCP/UDP ports. You'd be
amazed at how many sites have this particular hole in place due pressure from the
user population or executive suite, plus most Firewall vendors support it as an
option out of the box. TCP port 7070 (or just use 80) and incoming/outgoing UDP
ports 6970-7170.

Howard Hart
ipDialog, Inc.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jul 2000 02:31:46 -0400

I know in practice this kind of thing is done a lot, but its a very bad
slippery slope.

The problem is that once your firewall administrators find out you are
sending stuff they don't want through the firewall on other open ports,
they buy smarter firewalls that do packet inspection to be sure its the
right protocol. Then, application writers tunnel their protocols over
the protocol thats allowed through, and it works again. Then, firewall
vendors put fixes for that, and we're back to square one. Its happened a
lot already for http. In fact, the IESG has an I-D on this subject:

http://search.ietf.org/internet-drafts/draft-moore-using-http-00.txt

Long term, we need solutions that allow network servers for specific
applications (like SIP servers) to cooperate with firewalls to implement
the overall network policy. This is the idea behind foglamps:

http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 23 Jul 2000 13:54:07 -0700 (PDT)

> http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt

   And when the e-2-e applications encrypt the
   application payloads?

   This entire thing strikes me as entirely
   unsolvable: two colluding parties can always
   defeat a net.marm. I saw an article on how
   people were transmitting covert messages using
   unused/mungable parts of IP and TCP headers.
   The possibilities seem limitless.

		     Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Jul 2000 00:27:24 -0400

>    And when the e-2-e applications encrypt the

Sorry, can't hear you. What? Hellooooo? Heloooooooo?

Firewalls and NATs, simply put, do not fit well into the end to end
architecture. So, if you build security based on e2e models, its no big
surprise nats and firewalls screw things up.

So, its a tradeoff. Want security - get few features and services from
network devices that (for good or bad) want to munge and look at your
packets. 

If I could make these devices go away, I would. But they are here, and I
need to live with them.

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 25 Jul 2000 13:52:39 +0200

>    And when the e-2-e applications encrypt the

I do not think that what you are speaking about is a strictly technical
issue.  It is difficult to use firewalls and e2e encryption in 
the same way like it is difficult for a custom officer to do his 
job if he cannot inspect your luggage. If an administrator does 
deploy a firewall, it is not very likely he will allow arbitrary 
encrypted  traffic to get through it. If encryption is needed in 
firewall-ed networks to create VPNs, firewall-2-e seems to be the 
appropriate scenario rather than e-2-e.

>    The possibilities seem limitless.

Firewalls can hardly prevent communication of two
colluding parties. Their main value is they minimize
number of places vulnarable to external attacks.

Jiri