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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 Aug 2006 14:25:05 -0500

Folks:

On behalf of my co-authors, I have just submitted the latest
revision (-06) to draft-ietf-sip-connect-reuse.

This version should (hopefully) get the draft out of the WGLC
state.  It addresses the concerns and comments raised during
the WGLC period, including support for name-based virtual
servers across TCP and TLS.  The text has been also redone for
readability.  More attention is paid to TCP connection reuse
than was the case with the previous versions.

Until the archive is updated with the new version, you can get
a copy from:

http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-06.html
http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-06.txt

Please go through the draft and advise regarding comments you
may have.

As the co-author holding the editor's pen, I believe that the
draft is ready to proceed further.  I will wait to hear from
the chairs about the next steps for this particular document.

Thank you.

- 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)

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 21 Aug 2006 22:53:48 +0200

Vijay,

Regarding virtual servers - it is not that an instant message would end up 
in the wrong mailbox, but a secure connection for domain X would get reused 
as a connection to domain Y. This has been called "totally broken" by Cullen

1) I wonder, how broken is it really? Could there be cases where the virtual 
domain operator may decide to allow this (ie local policy)? Couldn't it be 
'SHOULD' strength?
2) Since TCP does not provide much security anyway, is there really harm in 
sharing TCP connections across virtual domains?

Regards,

Jeroen

----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: "SIP LIST" <[email-masked]>
Sent: Monday, August 21, 2006 9:25 PM
Subject: [Sip] Updated revision of 
connect-reuse(draft-ietf-sip-connect-reuse-06)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Aug 2006 16:27:12 -0500

Jeroen van Bemmel wrote:
> Vijay,
> 
> Regarding virtual servers - it is not that an instant message would end 
> up in the wrong mailbox, but a secure connection for domain X would get 
> reused as a connection to domain Y. This has been called "totally 
> broken" by Cullen
> 
> 1) I wonder, how broken is it really? Could there be cases where the 
> virtual domain operator may decide to allow this (ie local policy)? 
> Couldn't it be 'SHOULD' strength?

I would think that the behavior that is expected when
virtual domains are not used should be equal to the behavior
that is exhibited when virtual domains are used.  If two
domains are hosted on two separate hosts, then there isn't
any chance that a connection for domain A on host A' gets
used for sending a request to domain B on host B'.
Consequently, it seems appropriate that if two domains
are hosted on the same physical host, this property of
separation be maintained.  Specifying a SHOULD strength
is a recipe for problems, IMHO.

> 2) Since TCP does not provide much security anyway, is there really harm 
> in sharing TCP connections across virtual domains?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Aug 2006 10:42:50 -0400

This is shaping up - much more comprehensible than earlier versions. But 
there still seem to be some loose ends to clean up. Here are notes I 
made while reading through this version.

	Paul

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.

Section 8.1

    The implications of placing an "alias" parameter in the topmost Via
    header of a request must be understood by the client.  Specifically,
    this means that the client MUST keep the connection open for as long
    as the resources on the host operating system allow it to, and that
    it MUST accept requests over this connection -- as opposed to a
    default listening port -- from its downstream peer.  And furthermore,

The condition "as opposed to a default listening port" is wrong, and 
contradicted later in the text. I think you mean to say "in addition to 
the default listening port".

    TCP connections, obviously, cannot be authenticated in a similar
    manner as TLS connections; nor can an identity be derived by
    inspecting fields of a certificate.  For TCP connections, clients
    MUST use as the destination identity the URI used as input to the
    RFC3263 server resolution process.

This seems obsolete, since reuse is no longer supported for TCP.

Section 9.2: (nit)

    this case, the alias table MUST not be updated.

I think that should be

    this case, the alias table MUST NOT be updated.

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.

(But then apparently any discussion of TCP connection reuse should be 
out of scope anyway.)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 23 Aug 2006 11:20:27 -0500

Paul Kyzivat wrote:
> This is shaping up - much more comprehensible than earlier versions.
> But there still seem to be some loose ends to clean up.

Paul: Thanks for your time in reading -06.  I am also glad
that you found it much more easier to follow than earlier
revisions; we put in a fair amount of edits for clarity in
this version.

More inline.

> 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?

> contradicted later in the text. I think you mean to say "in addition
> to the default listening port".

Yes; corrected.

> this case, the alias table MUST NOT be updated.

Yes; corrected.  Thanks.

> 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.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Aug 2006 14:12:19 -0400

> TCP connection for each domain.  But maybe this is overkill.

There won't be any requests in the backwards direction. There will be a 
separate connection for each direction. That is the key difference from 
the TLS approach.

	Paul