Subject: Re: [Sip] Updated revision of connect-reuse (draft-ietf-sip-connect-reuse-06)

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Sep 2006 23:17:28 -0400

>
>> Section 2
>> The connect reuse mechanism described in this document is defined  
>> only for Transport Layer Security (TLS) transports.
>> The doc seems to be schizophrenic about this. It continues to talk
>> about connection reuse of TCP connections, but using different
>> connections in each direction. Not clear if that is intended as a
>> true part of the specification, as some non-normative text about a
>> usage that is already defined elsewhere, or simply as obsolete text
>> that hasn't been removed.
>
> You are right about the schizophrenic nature of TCP connection
> reuse.  Earlier versions mainly wanted to do TLS reuse; but I
> think that it is important to provide TCP connection reuse
> as well, but because of the security problems associated
> with doing TCP connection reuse a la TLS, it is best to open
> up a connection in each direction.
>
> It'll be great to provide normative behavior for TCP connection
> reuse in this document, especially now as the use of TCP
> in SIP increases.  If we do not provide any guidance, then
> implementations will have at least two different sets of
> behaviors:
>   1) Reuse the TCP connection in the backwards direction, a la
>      TLS.  This pitfalls of doing so are listed in Section 9.3.
>   2) Open up two connections for reuse, as this draft
>      recommends.
>
> For interoperability, it'll be good to have one behavior and
> it'll be even better if this information is maintained in one
> document (as opposed to having a connection reuse document
> for TLS and another for TCP).
>
> What do others in the WG think?
>
>

I sort of thought that this document was going to cover TCP as well.  
However, I don't see how any solution other than 2 above could work.  
A solution that allowed an attacker to connect to cisco, claim they  
were lucent, then intercept every call that cisco makes to lucent  
sounds like something that would certainly warrant a CERT advisory. I  
sort of doubt the WG would come to the conclusion that the dubious  
gains that this mechanisms offers of reducing two connection to one  
would ever be worth the security tradeoff of making it trivial for  
off path attackers to highjack calls of their choosing.

>
>> Section 10.2  (Virtual Servers and TCP Connections)
>> I don't follow this at all. I see absolutely no reason why the  
>> same connection should not be used for atlanta.example.com and  
>> chicago.example.com if the resolve to the same address.
>
> Hmmm...Jeroen also made the same comment.  So maybe I need to
> re-look at that section.  I was trying to partition the
> namespace for the server hosting the virtual domains such that
> requests in the backwards direction would result in a distinct
> TCP connection for each domain.  But maybe this is overkill.
> Any other opinions?
>
> Thanks much for your time on this.

With TLS, I think we have discussed this in the past and with TCP It  
won't matter if we end up with the solution 2 from above.

_______________________________________________
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: Thu, 14 Sep 2006 16:51:34 -0500

Complete context for this response is at:
   http://www1.ietf.org/mail-archive/web/sip/current/msg16284.html
   Only portions from Cullen's response quoted below.

> I sort of thought that this document was going to cover TCP as well.  

Cullen: Good; thanks.  I think that'll be very helpful to implementors.

> won't matter if we end up with the solution 2 from above.

2 it is.  I will rev up the draft.

Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)