Subject: [SIP] I-D ACTION:draft-byerly-sip-hide-route-00.txt

From: [email-masked]
Date: Wed, 11 Oct 2000 06:31:46 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIP Record-Route/Route Hiding
	Author(s)	: B. Byerly, D. Daiker, S. Bhatnagar
	Filename	: draft-byerly-sip-hide-route-00.txt
	Pages		: 12
	Date		: 10-Oct-00
	
This document describes a proposed extension to SIP.
This document proposes a mechansim to encrypt/hide Record-Route and
Route entries in or to support confidentiality of SIP proxy
routing information.  The functionality of the Record-Route and
Route headers are preserved.
The introduction of this extension allows a set of
trusted SIP proxies to cooperatively hide the route that
SIP PDUs transit from untrusted proxies and user agents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-byerly-sip-hide-route-00.txt

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-byerly-sip-hide-route-00.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-byerly-sip-hide-route-00.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.

---

From: Neil Deason <[email-masked]>
Date: Wed, 11 Oct 2000 15:37:19 +0100

There was a recent discussion on the list about Via 
hiding - the general feeling then was that it should 
be removed as it didn't really deliver and wasn't being 
implemented.

This change was duly made in bis 02 and is documented 
in Section I. (Which I think should be titled Changes 
made in Version 02 not 01??).

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

> SIP PDUs transit from untrusted proxies and user agents.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Bryan Byerly <[email-masked]>
Date: Wed, 11 Oct 2000 11:12:55 -0400

> be removed as it didn't really deliver and wasn't being

I know of at least one vendor that has implemented Via header hiding.  :-)

It was my understanding from the discussion that the Via header hiding functionality
was being removed (as a compliance) from the SIP bis draft.  So, that makes Via
header hiding optional for those that do not wish to implement it.  It doesn't
preclude others from implementing it.

It would seem appropriate for Via header hiding to now be placed in a separate
Internet-Draft for those that wish to use it.

Jonathan/Henning,
Is a Via header hiding draft in the works?  Do you need volunteers to perform the
extraction of Via into an I-D?

thanks for your help,
Bryan

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Oct 2000 11:16:26 -0400

Bryan Byerly wrote:

> extraction of Via into an I-D?

The reason that Via header hiding was removed is that some of us
(including me) see it as a flawed mechanism. I can't prevent others from
implementing anything, but I don't think I want to contribute to an I-D
that prolongs its agony and further complicates the protocol, for
extremely marginal gain in mostly feel-good security.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Oct 2000 09:47:13 -0700

Henning,

I recall that the two main criticisms of Via hiding were a) complexity, so
make it an optional draft; and b) that there was no similar mechanism for
other sensitive headers like Router/Record-Route, so here is a suitable
mechanism.

DCS, and similar architectures, will need this kind of functionality.  IMO
it is better to make the mechanism generic, than to write more proprietary
extensions.  If you'd like, someone can bundle Via hiding with this draft
into a header-hiding "package"?

Can you propose an alternate mechanism which satisfies the same requirements?

thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Oct 2000 12:48:04 -0400

> Can you propose an alternate mechanism which satisfies the same requirements?

In the earlier discussion, I listed a whole lot of headers and other
information, of which Route is only the most obvious. The only real
solution that I can think of is back-to-back "anonymizer" UAs. This also
makes the trust model far more explicit. Also, in almost all cases, you
care far more about where your voice/video IP packets come from. Unless
you hide those, hiding the Route or Via seems pointless to me (and very
hard to explain to users).

Thus, I don't think the mechanism proposed for Route does anything but
add more complexity and the feel-good perception of security.