Subject: RE: [Sip] SIPS question

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 7 Nov 2002 14:01:06 -0500

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: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 04, 2002 6:08 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Monday, November 04, 2002 1:55 PM
> > To: Peterson, Jon
> > Cc: 'Anders Kristensen'; [email-masked]
> > 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 [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: Christer Holmberg <[email-masked]>
Date: Fri, 08 Nov 2002 08:36:30 +0200

Hi,

> procedures of [4] as if the input URI were a SIPS URI."

A couple of questions on this:

First, to make that "rule" above work in both directions, do we also need to
specify that when the session is initiated there must be a SIPS-URI also in the
From header, since the To and From values will be "switched" for requests sent
in the other direction? I guess it's not enough if the UAC inserts SIPS-URI in
the Contact header.

Second, my understanding of this is also that this would PREVENT the use of TLS
between specific nodes, let's say two proxies, in the path if the UAC did not
require TLS by inserting SIPS-URI in the To header. EVEN if one proxy, P1,
inserts a SIPS-URI Record-Route, a SIPS-URI Request-URI, and establish a TLS
connection with P2, when a request is sent in the other direction (P2-to-P1)
the To header SIP-URI would indicate that TLS shall not be used. Or, would the
change affect UAs (maybe only UACs?) only?

Regards,

Christer Holmberg
Ericsson Finland

---

From: [email-masked]
Date: Fri, 8 Nov 2002 09:09:38 +0200

this SIPS discussion reminds me about the dangers of rushing something
new and unimplemented into a standards specification at the last minute.
i have the feeling that the working group should start slowing down
introduction of new specifications and extensions before the existing
stuff has been widely implemented.

-- juha