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. > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 18, 2007 6:41 PM > To: Frank W. Miller > Cc: [email protected]; 'jiang mingda' > Subject: Re: [Sip] sip tcp connection > > > On Apr 18, 2007, at 1:40 PM, 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? 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. > > > > 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
