Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-05.txt

From: [email-masked]
Date: Wed, 08 Mar 2006 02:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Connection Reuse in the Session Initiation Protocol (SIP)
	Author(s)	: R. Mahy, et al.
	Filename	: draft-ietf-sip-connect-reuse-05.txt
	Pages		: 16
	Date		: 2006-3-7
	
When SIP entities use a connection oriented protocol to send a
request, they typically originate their connections from an ephemeral
port.  The SIP protocol includes mechanisms which insure that
responses to a request, and new requests sent in the original
direction reuse an existing connection.  However, new requests sent
in the opposite direction are unlikely to reuse the existing
connection.  This frequently causes a pair of SIP entities to use one
connection for requests sent in each direction, and can result in
potential scaling and performance problems.  This document proposes
requirements and a mechanism which address this deficiency in
environments where the connection could be opened in either
direction.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-connect-reuse-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-connect-reuse-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
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: Wed, 8 Mar 2006 21:33:09 +0100

Hi,

A suggestion: Instead of installing the alias at the time a request with a 
top Via containing 'alias' is received, what about doing it the moment a 
101-2xx response is forwarded back upstream?

I think this would avoid some of the attacks described in section 9.3. The 
reason to include 1xx responses, is that e.g. an UPDATE sent during early 
dialog would be able to use the aliased connection.

Also, for security reasons perhaps the types of requests that may carry an 
alias should be restricted. For example, a CANCEL may not be challenged, so 
it would not be wise to allow it to establish an alias. Same for ACK, and 
what about OPTIONS?

Regards,

Jeroen

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 09 Mar 2006 10:19:19 -0600

Jeroen van Bemmel wrote:
> Hi,
> 
> A suggestion: Instead of installing the alias at the time a request with 
> a top Via containing 'alias' is received, what about doing it the moment 
> a 101-2xx response is forwarded back upstream?

I believe that could be an implementation detail, but as far as I
can tell, this is simply delaying the alias binding.  And I am not
quite sure how this delay alleviates the security attacks since
these attacks are launched from the sender's host.

> Also, for security reasons perhaps the types of requests that may carry 
> an alias should be restricted. For example, a CANCEL may not be 
> challenged, so it would not be wise to allow it to establish an alias. 
> Same for ACK, and what about OPTIONS?

But a CANCEL or ACK sent over TLS will still go through the normal
cert authentication, so at least over TLS I don't see why
CANCEL and ACK ought to be restricted.  The question of whether
the receiving end should establish an alias for OPTIONS or MESSAGE
is fair.  I think it should be okay for TLS transports, but would
like to hear what others think.

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