Subject: [Sip] sip tcp connection

From: "jiang mingda" <[email-masked]>
Date: Wed, 18 Apr 2007 08:42:34 +0000

Hi Folks,
I have a question about sip over TCP. How many connections should be 
established between two sip servers/proxies? Shall I create only one tcp 
connection between them? If yes, there comes the  question, how much call 
rate could be supported on one tcp connection? If not , shall I create one 
connection per call? One connection per call will easily cause sip server 
overload.... Seems to multiple connections is a better choice, definitely 
this is very difficult for implementation.

Any exsting standards? I will really appreciate your comments.

Regards,
Richard

_________________________________________________________________
与世界各地的朋友进行交流，免费下载  Live Messenger; 
http://get.live.com/messenger/overview 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 18 Apr 2007 13:02:40 -0500

jiang mingda wrote:
> Hi Folks, I have a question about sip over TCP. How many connections
> should be established between two sip servers/proxies? Shall I create
> only one tcp connection between them?

You cannot use one connection for bi-directional requests because
of the security risk identified in Section 9 of connect-reuse
(http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-07).

> If yes, there comes the  question, how much call rate could be 
> supported on one tcp connection?

Generally speaking, it will be hard to quantify this to an
exact number.  It will depend on, among other things, your
OS, how it is configured, memory installed, CPU speed, your
role in the SIP ecosystem (proxy, UA, B2BUA) etc.

> If not , shall I create one connection per call? One connection per
> call will easily cause sip server overload.... Seems to multiple
> connections is a better choice, definitely this is very difficult for
> implementation.

Clearly one connection per call is not tenable.  You can get
away with two if you use connect-reuse and a pair of proxies.
You can get away with one if you use outbound between a proxy and
a UA.

See outbound
http://tools.ietf.org/html/draft-ietf-sip-outbound-08
and connect-reuse.
http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-07

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 18 Apr 2007 12:40:45 -0600

I've heard reference to this security issue in the past but have just gone
and read it for the first time, Section 9.3 right?  I'm not sure I
completely understand it.  Are you saying that another program can hijack
the connection once the legitimate SIP user is not present on the connection
anymore?  Would not the legitimate user have torn down the TCP connection
when it exited?  Wouldn't the TCP connection require authentication when it
was reestablished?  My apologies for my lack of understanding.

Thanks,
FM

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 18 Apr 2007 14:05:42 -0500

Frank W. Miller wrote:
> 
> I've heard reference to this security issue in the past but have just
> gone and read it for the first time, Section 9.3 right?  I'm not sure
> I completely understand it.  Are you saying that another program can
> hijack the connection once the legitimate SIP user is not present on
> the connection anymore?  

Yes.

> Would not the legitimate user have torn down the TCP connection 
> when it exited?  

Yes; thereby making the default port (5060) available for
other processes.

> Wouldn't the TCP connection require authentication when it was 
> reestablished?  

If it is between a UA and a registrar, it should.  If it is
between a UA and a default outbound proxy, it should.  But if
it is with another proxy, then there isn't any authentication.

- vijay

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 18 Apr 2007 14:47:38 -0600

Thanks for the reply.

If your answers are the case then I am confused.

There are three cases you can paint when the 5060 port is idle: 1) some
other network element tries to establish an inbound TCP connection to 5060
(for example) on my machine and 2) some bad program on my machine tries to
establish an outbound TCP connection to a legitimate SIP element, and 3)
some other network element tries to establish a connection (inbound or
outbound) with a bad program on my machine.

In the first case, there is no program listening on 5060 since the port is
free so the connection will not happen.

In the second case, you have established that the user must be authenticated
(except in the case of proxy-to-proxy) so that should presumably prevent bad
things from happening except in the one case.

In the third case, you probably have some kind of virus infestation or
something really bad since a bad program is cooperating with a "bad" network
element.

So, the only real issue here is that proxy-to-proxy TCP connections *may* be
hijacked by some bad program on the initiator's proxy device?  How realistic
is this?  I mean, proxies are likely to have the 5060 port open all the time
anyway and even if they reboot or something, how many proxies are there that
aren't going to be under pretty tight security to prevent a bad program from
appearing?  Is this enough to disallow the use of a bidirectional TCP
connection in all cases?

Speaking as a UA implementer (which I often do ;) ) maintaining a single TCP
connection with my first proxy hop is easier to implement so why be so
draconian because of one case?  It seems like you should address the one
case if it's a problem rather than just shutting down the general mechanism
for everybody.

Thanks, 
FM

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 1:06 PM
To: Frank W. Miller
Cc: [email-masked]
Subject: Re: [Sip] sip tcp connection

Yes.

- vijay

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 17:41:08 -0500

> was reestablished?  My apologies for my lack of understanding.

There's a couple of ways of looking at it. The one that concerns me  
most is what might be called "TCP Hijacking".

http://www.iss.net/security_center/advice/Exploits/TCP/ 
session_hijacking/default.htm

The idea is that if you authenticate (say, via digest) at the start  
of a TCP session, then anybody "on the wire" can easily take over the  
session and continue to use it without having to re-authenticate.

TLS pretty much prevents this attack.

Just for fun, I seem to recall back in the days of coaxial ethernet  
once seeing an app that would hijack an NFS session to start  
returning bogus data to the client. It was great fun to divert  
somebody to what appeared to be an empty NFS filesystem where they  
expected to find their dissertation research.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 25 Apr 2007 14:00:27 -0400

I was also surprised and confused as to why TCP-reuse had been pulled out of
connect-reuse.

I am not clear why any argument which includes "a middle-man can hijack it"
should mean a mechanism cannot be allowed in a draft. (unless the
mechanism's purpose is to be a security mechanism, which this one isn't)

UDP already has the noted weaknesses, only worse. 

If you're not using an authenticated transport, then you're not using an
authenticated transport.  If the threat of hijacking makes an application
mechanism unacceptable for a given transport then there are a lot of sip
drafts/RFCs that need to be changed to only allow DTLS/TLS, starting with
3261.  

I would also argue that hijacking (whether from a middle-man or on the same
host) is more likely between a UA and its proxy, and since Outbound
implicitly supports a connect-reuse model for TCP without requiring TLS,
then the ship has already sailed on that. (though you could argue the
instance-id and reg-id provide some more auth info, but its still cleartext)

So all we're talking about is proxy-to-proxy or proxy-to-registrar, etc.
Without connect-reuse, you need to send requests out a TCP connection you
created to the far end.  But how do you know it's the far-end you think it
is?  You don't.  Without TLS or something similar you can't.  Even if you
use digest auth, it only verifies to the far end who you are, not the other
way around (and I don't know of proxies that do digest for themselves to
other proxies, nor how they could).  So the draft (and sip in principle) is
already susceptible to TCP hijacking in many forms.

The only interesting scenario I can see in this regard is when a proxy has a
legitimate active socket listener on 5060, for its legitimate proxy process.
Then a rogue application on the same proxy creates a new tcp connection to
the far-end using an ephemeral local port, and sends some SIP request to the
far-end with an alias in the via claiming it represents the local proxy.
While that's an interesting case, it hardly scratches the surface of issues
that could occur with a rogue application on a proxy host.

For this issue to make TCP-connect-reuse be dropped from the draft really
seems silly.  The security concerns should just be listed, as they are for
all mechanisms, left up to local policy to decide whether to accept or not,
and leave it at that.

-hadriel
p.s. not that I'm a big proponent of TCP connect-reuse in general mind you,
but we have providers who demand it, and right now we have to let the
operator configure it manually without any way to verify the far-end can
really do it.  It would be nice if the signaling could reinforce it.

> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 6:41 PM
> To: Frank W. Miller
> Cc: [email-masked]; 'jiang mingda'