[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] SIPS question

To: "Peterson, Jon" <jon.peterson@neustar.biz>
Subject: Re: [Sip] SIPS question
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Date: Sat, 02 Nov 2002 18:28:13 +0200
Cc: "'Anders Kristensen'" <akristensen@dynamicsoft.com>, sip@ietf.org
List-help: <mailto:sip-request@ietf.org?subject=help>
List-id: Session Initiation Protocol <sip.ietf.org>
List-post: <mailto:sip@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=unsubscribe>
References: <15A2739B7DAA624D8091C65981D7DA815EB364@stntexch2.va.neustar.com>
Sender: sip-admin@ietf.org
Hi,

First, I keep mentioning chapter 26.2.2, but as Hisham said, the same thing is
basically said also (maybe even more clear) in chapter 8.1.2.

Then:

I DO agree with Jon that it should be possible to use TLS only between specific
hosts in the path.

I DO NOT, however, like the proposal that we should allow this only for strict
routing, since the RFC basically recommends not to use strict routing in the
first place... So, I agree with Anders that we need a generic solution which
works also for loose routing.

So, I think the easiest, and also best, solution is to change the text about the
Request-URI - to say that the if-to-use-TLS decission should be made based the
URI actually used for the message routing, which again MAY be the Request-URI,
but also the top Route.

Or, is there something else which would be messed up with such a change?

Also, it's not only about mid-session requests, even if that may be so in most
cases. Assume the Request-URI for the initial INVITE is SIPS-URI, but the UAC
uses an outbound proxy, ie using a pre-configured Route with SIP-URI.

Also, what if one wants to use TEL-URL (or whatever non-SIP-URI?) Then one could
argue that we will have to define TELS-URL etc... We shall remember that SIP
DOES allow the use of multiple URI schemes, which again is different from HTTP.
So, MAYBE we would need a more generic solution, ie using another mechanism to
indicate the use of TLS (eg using the transport parameter, and/or a Require
header option tag). But, that's another discussion :)

Regards,

Christer Holmberg
Ericsson Finland











"Peterson, Jon" wrote:

> 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

_______________________________________________
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
References:
- RE: [Sip] SIPS question
  - From: Peterson, Jon
Prev by Date: Re: [Sip] INVITE without SDP body.
Next by Date: Re: [Sip] SIPS question
Previous by thread: RE: [Sip] SIPS question
Next by thread: Re: [Sip] SIPS question
Index(es):
- Date
- Thread