Yes, good suggestion. > -----Original Message----- > From: Hisham Khartabil [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 20:52 > To: Audet, Francois (SC100:3055) > Cc: Robert Sparks; Jonathan Rosenberg; IETF SIP List > Subject: Re: [Sip] some comments on draft-ietf-sip-sips > > 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 PROTECTED]> 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 PROTECTED] > > > 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 PROTECTED] 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 PROTECTED] for questions on > current sip Use > > > > [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use > > > [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use > > [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
