Subject: Re: [Sip] Question on SIPS and Contact URI

From: "Samuel Osorio Calvo" <[email-masked]>
Date: Wed, 06 Apr 2005 13:53:04 +0200

When the caller starts a dialog with a SIPS URI, it forces that all proxies in the path use TLS and since TLS is a mandatory feature for SIP proxies, the request MUST have followed a TLS path.
However, RFC 3261 does not mandates anything about the last hop (UA-->outbound proxy  OR  egress proxy-->remote UA). Thus, the final proxy, applying local policies, might send the SIPS request using another transport mechanism to the UA because RFC 3261 does not mandates UAs to support TLS.

Hence, as far as I know, the UA not supporting TLS will use the standard SIP forwarding mechanisms (Via, Route, Contact, ...)  and will probably insert sips: URI in the subsequent replies and request. These messages will be taken by the proxy, which will use TLS where applicable:
Something like:

Dialog initiating request:
UA1---???--->outbound proxy--TLS-->P1----TLS--->P2----TLS--->Egress proxy--????--->UA2

reply & within dialog messages:
UA2---???--->Egress proxy---TLS-->outbound proxy----???--->UA1
(P1 and P2 have not inserted Record-Route headers).

??? will be fixed by local policy and UA supported features, it can be UDP, TCP, SCTP,.........

Hope it helps and please correct me if I am not right,

Samuel Osorio.

Unclassified.
>>> Miguel Garcia <[email-masked]> 04/06/05 12:23PM >>>
The first proxy not supporting TLS? Hmmm... I thought that RFC 3261 
mandates proxies to support TLS (besides UDP and TCP), so the case would 
not exist.

/Miguel

Elwell, John wrote:

> I cannot find anything that specifies how a SIP UA should behave when it
> receives a SIPS URI in a Contact header during a dialog (target refresh) or
> during dialog establishment if the transport is not TLS. The implication is
> that all future requests to that contact must be sent using TLS, even though
> TLS has not been used up to now for this dialog. Is that correct? What would
> a UA do that does not support TLS? What if the first proxy that has
> record-routed does not support TLS? One solution might be to convert the URI
> to a SIP URI for sending future requests.
> 
> John
> 
> 
> _______________________________________________
> 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
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked] 
Nokia Research Center      Helsinki, Finland

_______________________________________________
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

_______________________________________________
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: "Dale Worley" <[email-masked]>
Date: Wed, 6 Apr 2005 09:51:03 -0400

> However, RFC 3261 does not mandates anything about the last
> hop (UA-->outbound proxy  OR  egress proxy-->remote UA).
> Thus, the final proxy, applying local policies, might send
> the SIPS request using another transport mechanism to the UA
> because RFC 3261 does not mandates UAs to support TLS.

Strictly speaking, section 4 says "A call made to a SIPS URI guarantees that
... TLS .. is used to carry all SIP messages from the caller to the domain
of the callee.  From there, the request is sent securely to the callee, but
with security mechanisms that depend on the policy of the domain of the
callee."

Once a dialog is established, requests within the dialog are handled
differently than requests outside of a dialog, in regard to their
request-URIs and routing.

Section 12.2.1.1 says "A request within a dialog is constructed by using
many of the components of the state stored as part of the dialog. ... The
UAC uses the remote target and route set to build the Request-URI and Route
header field of the request.  [much detail to support RFC 2543 follows]"

The request within a dialog is routed using the stored route set of the
dialog.  It is loaded into the Route: headers, which control how the request
is routed.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2005 10:47:24 -0400

Dale has it right. A corollary to this is that using a sips uri in the 
Contact at most guarantees that the sips requirements will be followed 
in routing from the last proxy in the route header. This isn't 
especially helpful in general.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 6 Apr 2005 11:03:02 -0400

> From: Paul Kyzivat
>
> A corollary to this is that using a sips
> uri in the

It doesn't even guarantee that, since the last several routers might all be
inside the destination domain.  What it does guarantee is that any segments
of the path that aren't done with TLS are done under the policy control of
proxies that are administered by the destination domain, and that
administration is presumably as concerned as anyone with the security of the
contents of the dialog.

Dale