To be clear, that text in 26.2.2 is not normative, it is merely descriptive.
The functional behavior of SIPS is specified elsewhere in the document;
changing the wording of 26.2.2 does not change anything's behavior.
I maintain that the problem normative text in 8.1.2 (end of 1st paragraph)
was most likely written without sufficient consideration of loose routing. I
can assure you that we were quite mindful of your culprit 2) below, and
considered it a desirable case (in which TLS rightfully MUST be employed by
the UAC to contact the first hop). We weren't really mindful of 1)... but
again, throughout this discussion it has been a little unclear why a UA
would specify a URI in the Contact address in responses that differs from
the Contact address it sends when it registers (we call both of those things
by the same name for a reason); this has been something of a corner case.
I agree that it would be unfortunate to throw away loose routing for SIPS
entirely - when I suggested this was the simplest fix, I meant simplest from
a specification perspective. I know the text in 8.1.2 is bad, arguably
26.2.2 needs to be changed, but I haven't been able to go through the whole
spec (as well as RFC3263) and hunt for similar text... mandating strict
routing provides a one-sentence band-aid. In the long run, though, I agree
it would be better to fix all the places where there is language contrary to
lr.
Finally, speaking to a point that has occasionally been brought up in this
thread, RFC3261-compliant proxies MUST support SIPS. By RFC3261, proxies
MUST support TLS, and TLS implementations MUST support SIPS. At a
specification level, it isn't clear to me that we need to worry about
ascertaining proxy support for SIPS any more than we worry about proxy
support for TCP. I don't think this part of the behavior is broken, anyway.
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
Sent: Friday, November 01, 2002 12:51 PM
To: Peterson, Jon
Cc: 'Christer Holmberg'; Arunachalam Venkatraman; sip@ietf.org
Subject: Re: [Sip] SIPS question
Wouldn't it be unfortunate if we were to downgrade an otherwise
all-loose routing signaling path to strict routing because of the
situation discussed here.
I agree with Christer that the problem lies with the text of section
26.2.2 which requires that the UAC use TLS even though it's not routing
the request based on the R-URI but to the top Route. It seems that
26.2.2 didn't anticipate that 1) the scheme of the R-URI of a subequent
request can be sips even though it was sip for the original request, and
2) initial requests with a sips R-URI but a preloaded Route whose top
URI is a sip URI. This last case could be common, for example, in cases
where a service route has a sip URI top entry.
Is there a problem in clarifying section 26.2.2 to say that request is
sent using a transport of the top Route if there is one, or else to the
R-URI? It seems more natural to use the properties of the next-hop URI
that the request is in fact being sent to.
It is clearly also the case, as Jon points out, that the UAS should be
at least discouraged from using a sips Contact when the top R-R isn't
sips (or it somehow *knows* that that proxy does in fact support sips).
If the original request has a Record-Route header, I don't think it
should matter whether or not the UAC happens to support sips or not - as
long as the upstream record-routing proxy does, that should be enough, no?
Anders
Peterson, Jon wrote:
I think the problem with much of the language that has been
cited from
RFC3261 in this thread is that we expected SIPS to be
strict-routed. I don't
think any of these problems with intermediaries and
retargeting arise if
strict routing is used. Unfortunately, both loose routing
and SIPS arose
relatively late in the game for RFC3261, and we may not
have fully studied
their interaction.
A few other notes about this thread:
While I agree that HTTP R-U's cannot be retargeted to HTTPS, I think
retargeting SIP to SIPS is attractive and workable,
provided strict routing
is used (or language is introduced to bring SIPS into
parity with loose
routing). It is desirable to be able to secure as much of
the communications
path as possible.
The recipient of a request should be able to ascertain
whether or not the
request was retargeted to SIPS by checking to see if the To
header field
uses the SIPS scheme.
Finally, when we were working on the design of SIPS, we
noted that there
were a class of problems that resulted from specifying
transport=tls (or any
optional transport, including =tcp and =sctp) in
Contact/Record-Route header
fields. Hence there is language in bis that says things like:
The [Record-Route] URI SHOULD NOT
contain the transport parameter unless the proxy
has knowledge
(such as in a private network) that the next
downstream element
that will be in the path of subsequent requests
supports that
transport.
Similar language should probably be introduced for SIPS,
and the Contact
header.
Anyway, for the time being, I suspect that the simplest bug
fix is to say
that whenever a route set or remote target for a dialog
contains a SIPS URI,
requests must be strict routed.
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
Sent: Thursday, October 31, 2002 10:13 PM
To: Arunachalam Venkatraman
Cc: sip@ietf.org
Subject: Re: [Sip] SIPS question
Hi Arunachalam,
If there are no record routing proxies in the path, your
second "rule" may
work just fine.
However, I am not sure your first "rule" would work when
there are record
routing proxies. Like Hisham said, if UA2 has registered
itself with P1 using
SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST
insert SIPS-URI in
the Contact header, which again means that UA1 may end up in
a situation where
the Request-URI for the next request is SIPS-URI, and
according to the spec it
MUST now use TLS for that request - even if it doesn't
support TLS, and even
if it's not going to use the Request-URI to route the message
in the first
place.
Now, changing the text in the spec MAY help: the change would
be that the UAC
does not make any transport based decissions based on the
Request-URI, but on
the URI it actually uses to route the request (which of
course MAY be the
Request-URI, but also the top Route).
I also think part of the basic problem is the fact that the
URI may change
from SIP to SIPS in the signalling path. I don't think that
is true for
HTTP/HTTPS, is it?
Thanks for your comments!
Regards,
Christer Holmberg
Ericsson Finland
Arunachalam Venkatraman wrote:
Christer
Interesting issue.
How about this for a solution ---
The UAS sends a SIPS URI in its Contact only if one of the
following is
true-
1. The top Route in its Route Set is a SIPS URI
2. If no Route set has been established, the Contact in the
request is a
SIPS-URI.
In all other cases, it sends a SIP-URI in its Contact.
Will this work?
Venkat
-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
Christer Holmberg
Sent: Thursday, October 31, 2002 6:43 AM
To: hisham.khartabil@nokia.com
Cc: jon.peterson@neustar.biz; sip@ietf.org
Subject: Re: [Sip] SIPS question
Hi,
Hi,
I guess UA2 should have registered with P1 using
a sips-uri
in the contact-header. P1 doesn't care about the
contact-header sent in the 200 OK. UA2 contact-header is
telling UA1 (not P1) to contact it using TLS.
No, but the Contact header value will be used in requests
during the session, as part of the route set or Request-URI
(depending on if loose routing is used etc)
What I meant to say is that if UA2 had registered with P1
using a sips-uri in the contact-header, then when P1 is
routing the INVITE, it will put sips-uri in the record-route
header since the request uri (retrieved from the registrar)
is a sips-uri.
Since P1 contacted UA2 using sips, the 200 ok must contain
a contact-header with sips-uri.
Ok. So, in this case UA1 will receive a Record-Route with
SIPS-URI. So, the next time UA1 sends a request the SIPS-URI
indicates it shall use TLS - which UA1 may not even support.
No, P1 will modify the record-route header in the
response and will make
it a sip-uri.
And, since UA1 used SIP-URI in its own Contact header, P1
shall use UDP (or TCP) to forward requests received from UA2,
so now we would have the separate-transport-in-each-direction
problem between UA1 and P1, wouldn't we?
UA1 will have a different route-set that UA2.
True.
However, EVEN if UA2 has registered itself with P1 using
SIPS-URI, and P1
uses TLS to
contact it, UA1 will still receive a Contact header with
SIPS-URI, and
according to the
RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it
would have to
use TLS for the
other requests, even if it doesn't support TLS, and even if
the requests
aren't even sent
to UA2 (UA1 send them to P1, which record-routed).
Regards,
Christer Holmberg
Ericsson Finland
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip