Subject: Re: [Sip] some comments on draft-ietf-sip-sips

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 12 Apr 2007 13:51:46 +1000

I agree with Jonathan, Robert and Francois. I have a couple of
comments that I would like the draft to discuss:

- If the caller endpoint only supports sip and the callee endpoint has
only registered with a sips URI. How would the caller endpoint be
informed? We talk about redirecting all the way back to the calling
end with a 3xx response. How would the UA handle that? should the 3xx
response be changed to 4xx at the UAC core? what error code would that
be?

- a proxy that usually terminates a 3xx response can no longer do that
if the original R-URI was sip and the contact in 3xx is a sips, and
visa versa.

Thanks,
Hisham

On 30/03/07, Francois Audet <[email-masked]> wrote:
> Thanks Robert.
>
> Exactly my toughts as well. I think it would mean that the draft should
> include some language about prefereing TLS transport anyhow (it was my
> intention to add that in).
>
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> > Sent: Thursday, March 29, 2007 07:14
> > To: Jonathan Rosenberg
> > Cc: IETF SIP List
> > Subject: Re: [Sip] some comments on draft-ietf-sip-sips
> >
> > I also think disallowing upgrades is the better course.
> >
> > I still have misgivings about how likely an implementation is
> > to do the "right thing" WRT informing its user when it
> > receives an INVITE over TLS with a sips: RURI, but a sip: URI
> > in the To: header. If it makes the mistake of presenting this
> > as a "secure" invitation, the UAS's user may make a very
> > wrong choice in answering the call (and possibly compound the
> > error later with REFERs in that dialog).
> >
> > If we do allow an upgrade retarget, we are sanctioning a
> > downgrade in the reverse direction for subsequent requests in
> > the dialog that gets established. Thus the only "right thing"
> > for the above implementation to do is to present this call as
> > a normal sip: call.
> >
> > So the only benefit of allowing an upgrade I see is that some
> > part of the signaling happens over TLS. But that can be
> > achieved by preferring hop-by-hop TLS anyhow. In a flow
> > through the networks we anticipate, retargetting anywhere but
> > the (near) last hop will occur because of configuration,
> > usually under the control of the operator of the retargetting element.
> > That same level of configuration effort can go into properly
> > populating DNS to cause TLS to be used. The retargetting due
> > to registrations at the (near) last hop is likely to be
> > mooted by outbound.
> >
> > It appears to greatly simplify things if this kind of upgrade
> > can't happen and we rely on redirection all the way to the endpoint.
> >
> > RjS
> >
> > On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote:
> >
> > > In a separate thread, we've been discussing whether we can
> > make this
> > > draft normative and finally go about 'fixing' the things that make
> > > SIPS broken. Besides the last hop exception problem, there
> > is another
> > > bit which is very problematic:
> > >
> > >>  The presence of a SIPS Request-URI does not necessarily indicate
> > >> that
> > >>    the request was sent securely on each hop.  As described in
> > >>    [RFC3261]/26.4.4, a proxy may legitimately retarget a
> > request from
> > >>    SIP to SIPS.  Therefore, a UAS MUST NOT assume on the
> > basis of the
> > >>    Request-URI alone that SIPS was used for the entire
> > request path.
> > >
> > >
> > > Retargeting from sips to sip is a lot like the last hop exception
> > > rule, and it really ruins the ability for the UAS to verify
> > the main
> > > security property provided by SIPS. Instead of the ad-hoc
> > algorithms
> > > suggested as ways to actually verify this, can we change this rule?
> > > Proxy MUST NOT retarget a sips URI to sip. I think I've
> > suggested tihs
> > > in the past that I think we need to outright forbid up and
> > downgrades.
> > >
> > > Section 4.2 - does this evaporate if we can make this change to not
> > > change sip to sips?
> > >
> > > Indeed I think this document becomes oodles simpler when we
> > eliminate
> > > these two exceptions. I think the doc is still pretty complicated
> > > since there are so many exceptions and variations. I want it to be,
> > > you ar eeither sips, in which case EVERYTHING is sips, or
> > you are sip,
> > > in which case NOTHING is sips. Really easy that way, and it
> > gives us
> > > the security property we need.
> > >
> > >>  The USC registers either a SIPS or a SIP AOR.  From a routing
> > >>    perspective, it does not matter which one is used for
> > registration
> > >> as
> > >>    they identify the same resource.
> > >>    If all the Contacts are SIPS, a SIPS AOR MUST also be
> > used by the
> > >>    UAC.  If at least one of the Contacts is SIP or is
> > neither SIP nor
> > >>    SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST
> > also be used
> > >> by
> > >>    the UAC.
> > >
> > > isn't this a contradiction? The first paragraph says that
> > it doesn't
> > > matter whether you use sip or sips. Then the next says why
> > you pick a
> > > sip or sips aor.
> > >
> > > Also I tihnk the text should be restructured a bit to say
> > that, a UA
> > > can operate in one of three modes - sips only, sip only or
> > either. And
> > > then based on that, how do you set each of the parameters in the
> > > REGISTER (To, from, contact, r-uri). The current text is
> > inverted and
> > > you have to work backwards in some places to sort it out.
> > >
> > > I don't really see why the AOR in the To is relevant at all
> > (sip vs.
> > > sips).
> > >
> > >>  A registrar MUST only accept a binding to a SIPS Contact
> > if all the
> > >>    appropriate URIs are of the SIPS scheme: i.e., the Request-URI,
> > >> the
> > >>    AOR (i.e., To header), the From header, the Contacts
> > and all the
> > >> Path
> > >>    headers.  If the URIs are not of the proper SIPS scheme, it must
> > >>    reject the REGISTER with a 403 "Forbidden".
> > >
> > > I don't see why the To and From are relevant. Indeed I think a sips
> > > contact can be accepted as long as the r-uri was sips. For
> > path, its
> > > really a double check since they should have been sips
> > based on other
> > > rules, should probably make that clear.
> > >
> > >>   SIPS in a Dialog
> > >>    There MUST be only one Contact in any request resulting in the
> > >>    establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER).
> > >
> > > This is a basic 3261 requirement having nothing to do with
> > sips; might
> > > want to merely state this as fact.
> > >
> > >> As mandated by [RFC3261]/8.1.1.8, in a request, if the
> > Request-URI or
> > >>    top Route header field value contains a SIPS URI, the Contact
> > >> header
> > >>    field MUST contain a SIPS URI as well.  Furthermore, as
> > mandated
> > >> by
> > >>    [RFC3261]/12.1.1, if the request that initiated the dialog
> > >> contained
> > >>    a SIPS URI in the Request-URI or in the top Record-Route header
> > >> field
> > >>    value, if there was any, or the Contact header field if
> > there was
> > >> no
> > >>    Record-Route header f
> > >
> > > There are three statemenets in the or condition. However,
> > if the first
> > > is true, and we eliminate the last hop exception and retarget
> > > exception, unless there is a protocol error the others will be true
> > > too. This is one of many places where sips is just way
> > simpler if we
> > > do that.
> > >
> > >> be careful about what to use in the Contact (in case
> > Record-Route is
> > >>    not used for this hop).  If the Contact was a SIPS URI,
> > it would
> > >> mean
> > >>    that it would only accept mid-dialog requests that are
> > over secure
> > >>    transport end-to-end.  Since the Request-URI is in this
> > case a SIP
> > >>    URI, it is quite possible that the UA sending a request to that
> > >> URI
> > >>    may not be able to send requests to SIPS URIs.  It is therefore
> > >>    RECOMMENDED that in this case, the Contact be a SIP
> > URI, even if
> > >> the
> > >>    request is sent over a secure transport (e.g., the
> > first hop could
> > >> be
> > >>    re-using a TLS connection to the proxy as would be the case with
> > >>    [I-D.ietf-sip-outbound]).
> > >
> > > why is this just RECOMMENDED and not MUST?
> > >
> > >> When a target refresh occurs within a dialog (e.g., re-INVITE,
> > >>    UPDATE), unless there is a need to change it, the UAC SHOULD
> > >> include
> > >>    a Contact header with a SIPS URI if the original request used a
> > >> SIPS
> > >>    Request-URI.
> > >
> > > why not MUST?
> > >
> > >>  Sessions, dialogs and transactions may be "derived" from existings
> > >>    ones.
> > >>    As a general principle, derived dialogs and transactions SHOULD
> > >> NOT
> > >>    result in an effective downgrading of SIPS to SIP, without the
> > >>    explicit authorization of the entities involved.
> > >
> > > unless you formally define 'derived' this is a meaningless
> > > requirement.
> > >
> > >>  However, for backward compatibility, if a "transport=tls"
> > parameter
> > >>    is received, it should be interpreted as per the following
> > >>    guidelines:
> > >>    o  [RFC3261]/16.7 states the transport parameter (e.g.,
> > with tcp
> > >> or
> > >>       udp) SHOULD NOT be used in Record-Route unless it
> > has knowledge
> > >>       that the next upstream element that will be in the path of
> > >>       subsequent supports this transport.  Generally, it is
> > >> recommended
> > >>       that the transport parameter never be used in a Record-Route,
> > >>       Route or Path header.  Since the transport=tls URI parameter
> > >> has
> > >>       been deprecated, it MUST NOT be used in Route,
> > Record-Route or
> > >>       Path headers, and MUST be ignored.
> > >>    o  In a Contact in a dialog, it MAY be interpreted as a
> > request to
> > >>       send incoming mid-dialog requests using TLS.  Note that this
> > >> would
> > >>       only have a significance if [I-D.ietf-sip-outbound]
> > and Record-
> > >>       Route are not used, and if that URI is nevertheless
> > reachable
> > >> with
> > >>       TLS which is extremely unlikely.  If it was the case that it
> > >> was
> > >>       reachable with TLS, say because there is an active TLS
> > >> connection,
> > >
> > > the first paragraph says that what follows will be what to
> > do if you
> > > receive transport=tls, but the first bullet is about sending it. In
> > > that paragraph you say its 'recommneded' not to be used in
> > RR, Route
> > > or Path, and then next sentence is MUST NOT. So which is it?
> > >
> > > If this is normative do we need to carry forward text on
> > transport=tls
> > > beyond saying don't send and ignore on receive?
> > >
> > >
> > > Thanks,
> > > Jonathan R.
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > > Cisco Fellow                                   Parsippany, NJ
> > > 07054-2711
> > > Cisco Systems
> > > [email-masked]                              FAX:   (973) 952-5050
> > > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > > http://www.cisco.com
> > >
> > > _______________________________________________
> > > 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
> >
>
> _______________________________________________
> 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: "Francois Audet" <[email-masked]>
Date: Wed, 11 Apr 2007 23:09:51 -0500

Yes, good suggestion. 

> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2007 20:52
> To: Audet, Francois (SC100:3055)
> Cc: Robert Sparks; Jonathan Rosenberg; IETF SIP List
> I agree with Jonathan, Robert and Francois. I have a couple 
> of comments that I would like the draft to discuss:
> 
> - If the caller endpoint only supports sip and the callee 
> endpoint has only registered with a sips URI. How would the 
> caller endpoint be informed? We talk about redirecting all 
> the way back to the calling end with a 3xx response. How 
> would the UA handle that? should the 3xx response be changed 
> to 4xx at the UAC core? what error code would that be?
> 
> - a proxy that usually terminates a 3xx response can no 
> longer do that if the original R-URI was sip and the contact 
> in 3xx is a sips, and visa versa.
> 
> Thanks,
> Hisham
> 
> > Exactly my toughts as well. I think it would mean that the draft 
> > should include some language about prefereing TLS transport 
> anyhow (it 
> > was my intention to add that in).
> >
> > > I still have misgivings about how likely an 
> implementation is to do 
> > > the "right thing" WRT informing its user when it receives 
> an INVITE 
> > > over TLS with a sips: RURI, but a sip: URI in the To: 
> header. If it 
> > > makes the mistake of presenting this as a "secure" 
> invitation, the 
> > > UAS's user may make a very wrong choice in answering the 
> call (and 
> > > possibly compound the error later with REFERs in that dialog).
> > >
> downgrade 
> > > in the reverse direction for subsequent requests in the 
> dialog that 
> > > gets established. Thus the only "right thing"
> > > for the above implementation to do is to present this call as a 
> > > normal sip: call.
> > >
> > > So the only benefit of allowing an upgrade I see is that 
> some part 
> > > of the signaling happens over TLS. But that can be achieved by 
> > > preferring hop-by-hop TLS anyhow. In a flow through the 
> networks we 
> > > anticipate, retargetting anywhere but the (near) last hop 
> will occur 
> > > because of configuration, usually under the control of 
> the operator 
> > > of the retargetting element.
> > > populating DNS to cause TLS to be used. The retargetting due to 
> > > registrations at the (near) last hop is likely to be mooted by 
> > > outbound.
> > >
> > > It appears to greatly simplify things if this kind of 
> upgrade can't 
> > > happen and we rely on redirection all the way to the endpoint.
> > >
> > > RjS
> > >
> > > > Section 4.2 - does this evaporate if we can make this change to 
> > > > not change sip to sips?
> > > >
> > > > since there are so many exceptions and variations. I want it to 
> > > > be, you ar eeither sips, in which case EVERYTHING is sips, or
> > > you are sip,
> > > >>    appropriate URIs are of the SIPS scheme: i.e., the 
> > > >> Request-URI, the
> > > > I don't see why the To and From are relevant. Indeed I think a 
> > > > sips contact can be accepted as long as the r-uri was sips. For
> > > path, its
> > > >>    a SIPS URI in the Request-URI or in the top Record-Route 
> > > >> header field
> > > > exception, unless there is a protocol error the others will be 
> > > > true too. This is one of many places where sips is just way
> > > simpler if we
> > > > do that.
> > > >
> > > >>    URI, it is quite possible that the UA sending a request to 
> > > >> that URI
> > > >>    a Contact header with a SIPS URI if the original 
> request used 
> > > >> a SIPS
> > > >>    Request-URI.
> > > >
> > > > why not MUST?
> > > >
> > > >>    As a general principle, derived dialogs and transactions 
> > > >> SHOULD NOT
> > > >>       Route or Path header.  Since the transport=tls URI 
> > > >> parameter has
> > > >>       send incoming mid-dialog requests using TLS.  Note that 
> > > >> this would
> > > >>       TLS which is extremely unlikely.  If it was the 
> case that 
> > > >> it was
> > > > receive transport=tls, but the first bullet is about 
> sending it. 
> > > > In that paragraph you say its 'recommneded' not to be used in
> > > RR, Route