Subject: [Sip] draft-audet-sip-sips-guidelines-00.txt: use of transport=tls

From: "Francois Audet" <[email-masked]>
Date: Mon, 17 Apr 2006 15:46:27 -0500

Hi Paul,

Thanks for your comments. I'm starting to digest them.

Rather than copy the whole list of comments, I'll deal with
individual comments separately.

OPEN ISSUE: use of "transport=tls".

> >    RFC 3261 makes it clear that the use of the "transport=tls" URI
> >    transport parameter in SIPS or SIP URIs has been deprecated.
> >    However, it has not been eliminated from the ABNF in 
> >    section 25 of RFC 3261.
> 
> That isn't so clear to me. It seems to clearly ban this 
> parameter in a 
> SIPS URI, but I don't see the words as banning it in a SIP URI.
> 
> The value in using it, as mentioned above, is that it means a TLS hop 
> can be used for either insecure requests, but that the URI 
> could also be 
> upgraded to SIPS in order that it be permissible in a 
> transaction that 
> is using SIPS. This seems necessary to avoid two separate connections 
> when using -outbound- for nat traversal.

I believe that we have a different opinion of how this should work.

My understanding is that transport=tls is deprecated, and it works the
following way:

- If a UA wants to indicate to the registrar that it supports both sip 
  and sips, and TCP and TLS, then it sends the following:
	- AOR (To field) == sip 
	- 2 contacts are included: sips and sip (with q value for
prefence)
  That explicitely lists both a sips and sip contact (as described in
section
  4.2 of my draft).

I believe that what you are proposing is instead that to indicate
support for
both TCP and TLS transport, one should do:
	- AOR (To field) == sip
	- 1 contact: sip with transport=tls.

With my proposal, one does not need a "new option tag". The idea is 
that sip AOR is always "upgradable" to sips (but not the other way
around),
and that the Contact list in the registration ALWAYS include all the
possible
contacts, including both sip and sips if both are supported.

In other words, the concept of "upgrading" from sip to sips is only 
applicable to AORs (not to Contacts or other fields). Seems to me to 
be clearer. It also avoids the sctp problem. I also believes that it
doesn't have the problem or requiring 2 connections for sip-outbound.
You would send the REGISTER using TLS in this case, but you would be
prepared to receive incoming requests on this connection using either
TLS or TCP.

Am I misunderstanding what you are proposing?

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Apr 2006 17:25:04 -0400

> I believe that we have a different opinion of how this should work.

Note that I am not at all confident that I am on firm ground with what I 
am suggesting. In a way it is hopeful thinking. More below.

> 	- 1 contact: sip with transport=tls.

More or less. As long as the R-URI is sips, its not clear to me it 
matters whether the To uri is sip or sips.

> applicable to AORs (not to Contacts or other fields).

My thinking was that sips can only be used with e2e hop by hop security. 
But a TLS connection can be used either as one hop of an e2e hop by hop 
secure session, or as part of a session that has insecure hops and so is 
ineligible for sips. A proxy would be able to upgrade a sip uri with 
transport=tls to sips when it knew all other hops are secured.

> Seems to me to 
> be clearer. It also avoids the sctp problem.

I don't know about clearer. There are probably other solutions to the 
sctp problem.

> I also believes that it

That is a big issue to me. I'm not sure I follow.

> prepared to receive incoming requests on this connection using either

So when using sip, the messages over the connection would not be 
encrypted, but when using sips they would?

Can you do that with TLS? I'm no expert, but I thought once you 
establish a connection, it starts out TCP but if you do the TLS 
handshake then it is all TLS from then on.

*If* you can register these two contacts, one sip and one sips, and they 
can share the same connection, then I am *less* concerned. I still 
suspect it will present complexities and problems.

Maybe Cullen will be able to comment on the impact to outbound.

> Am I misunderstanding what you are proposing?

No, you seem to get it.

	Paul

---

From: Klaus Darilion <[email-masked]>
Date: Thu, 20 Apr 2006 18:21:53 +0200

> OPEN ISSUE: use of "transport=tls".

Hi!

Although RFC3261 states that this parameter is depreciated, I do not 
understand why. Can you please explain it to me?

Consider the following example:
UserA   ProxyA   ProxyB  UserB

User A sends a request to its proxyA. Then, the request should be 
forwarded to proxyB via TLS, but there is no need for the whole chain to 
  be TLS.

Thus, I would asume that userA sends:

INVITE sip:userB@proxyB;transport=tls

But if this parameter is depreciated, how else can I force TLS on a 
certain hop?

Thanks
Klaus