[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] SIPS question
I'm not sure I favor removal of this 8.1.2 text entirely. After some
reflection, I think what we're looking for is a rule that reflects the use
of SIPS in the destination address-of-record to which a request is sent (in
a dialog, this is largely applicable only to the initial request), not the
Request-URI. If we're concerned about the destination address-of-record of
the initial request, we should probably be talking about the To header
field.
So, as a correction (to the text in 8.1.2 anyway) I might suggest something
like:
"Independent of which URI is used as the input to the procedures of [4], if
the To header field specifies a SIPS resource, the UAC MUST follow the
procedures of [4] as if the input URI were a SIPS URI."
Squinting at the flows for a moment, I don't see this giving rise to the
sort of concerns that Christer raised about the Contact header and
retargeting (when the SIPS URI is used in Route/Contact headers), but it
still provides the hBh-all-the-way property that SIPS was designed for.
A similar correction could be made to the informative text in 26.2.2. Any
thoughts about this? Any other text that would need to be amended?
Jon Peterson
NeuStar, Inc.
> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Monday, November 04, 2002 6:08 AM
> To: christer.holmberg@lmf.ericsson.se; jon.peterson@neustar.biz
> Cc: akristensen@dynamicsoft.com; sip@ietf.org
> Subject: RE: [Sip] SIPS question
>
>
> Removing this restriction seems to fix the problem, I think.
>
> "Independent
> of which URI is used as input to the procedures of [4], if the
> Request-URI specifies a SIPS resource, the UAC MUST follow the
> procedures of [4] as if the input URI were a SIPS URI."
>
> But also, would mandating that: if a REGISTER has a sips-uri
> contact, the To-header must contain a sips-uri work? and visa versa?
>
> eg: UA2 registers with sips-uri in both To-header and
> contact-header (sips in both or neither, but not mixed).
>
> In this case, UA2 home proxy will reject the request with 404
> if UA1 sends a request with sip-uri. UA2 can also reject the
> request directly if it doesn't want to accept requests not using TLS.
>
> Regards,
> Hisham
>
> > -----Original Message-----
> > From: ext Christer Holmberg
> [mailto:christer.holmberg@lmf.ericsson.se]
> > Sent: Monday, November 04, 2002 1:55 PM
> > To: Peterson, Jon
> > Cc: 'Anders Kristensen'; sip@ietf.org
> > Subject: Re: [Sip] SIPS question
> >
> >
> >
> > Hi,
> >
> > > >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.
> > >
> > > The design of SIPS used as the 'remote target', as the AoR of the
> > > destination, necessitates that this first hop go over TLS.
> > Look, as I said,
> > > outbound proxies are proxy servers, proxy servers MUST
> > support TLS, and
> > > entities that support TLS MUST support SIPS. Converting
> > this Route header to
> > > a TLS route is plausible and allowed by the spec.
> >
> > Yes, but the problem is again if the UAC doesn't support TLS.
> > Assume the UAC
> > gets the Request-URI SIPS-URI from some "external source"
> > (ENUM, data base,
> > whatever...), but since it uses an outbound proxy, using a
> > predefined Route with
> > SIP-URI, it doesn't care about the Request-URI SIPS-URI.
> >
> > I don't know if that scenario is "allowed" or not, but my
> > point was that the
> > problem would be the same as for mid-session requests.
> >
> > > We considered both transport parameters (transport=tls was
> > obsoleted in
> > > favor of SIPS, as I'm sure you recall) and
> > Require/Supported option tags in
> > > our deliberations about SIPS. The point is that we wanted
> a resource
> > > identifier that indicates directly that it should be
> > contacted securely.
> >
> > Another option would be that the URI in the TO header, which
> > IS end-to-end,
> > would be used to indicate if to use TLS or not. That would
> > not allow that TLS is
> > used between specific hops only, though.
> >
> > Now, however, TLS would be used for the mid-session requests
> > EVEN if the record
> > routing proxies insert SIP-URI in the Record-Route headers,
> > and/or the UAC
> > inserts SIP-URI in the Contact header, since the TO header
> > URI would not change.
> >
> > Now TLS would always be used for the whole session, and not
> > only for the INVITE,
> > but I assume that is how most people intend to use it anyway. Or?
> >
> > But, I still think the easiest fix would be to change the
> > text as proposed
> > earlier. Then, we may have to write something about the
> > outbound proxy scenario
> > - or use Jonathan's proposal to use TLS only if the previous
> > hop used TLS
> > (assuming we want to use TLS end-to-end ONLY, that is).
> >
> > 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