Subject: RE: [Sip] draft-ietf-sip-sips-01.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 Feb 2007 18:03:19 +0000

Francois,

Yes, I know that RFC 3261 states that SIPS means TLS, but do we need to
document the reasons for that?

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 13 February 2007 17:45
> To: Elwell, John; [email-masked]
> Subject: RE: [Sip] draft-ietf-sip-sips-01.txt
> 
> Hi John,
> 
> I think the short answer is that SIPS by definition means 
> TLS. Just like
> HTTPS by 
> definition means TLS.
> 
> It's not a judgment of the value of TLS versus IPsec. It's just the
> definition
> of the term.
> 
> So if one wants to use IPsec, there is no SIPS to worry about (which
> makes
> implementation easier on that front). 
> 
> If the group believes that I should mention something about it, I'll
> gladly 
> add some wording about it in the spec.
>  
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Tuesday, February 13, 2007 03:18
> > To: Audet, Francois (SC100:3055); [email-masked]
> > Subject: RE: [Sip] draft-ietf-sip-sips-01.txt
> > 
> > Would there be any benefit in mentioning why it is specified 
> > that (with the exception of the last hop) a SIPS request must 
> > be forwarded over TLS rather than IPSEC? I can't find 
> > anything in RFC 3261. I don't have enough expertise in this 
> > area to propose particular words, but IPSEC seems to be 
> > getting deployed quite a lot (e.g., with IMS) and an IETF 
> > opinion on its appropriateness for transporting SIPS requests 
> > might be useful.
> > 
> > John
> >  
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[email-masked]]
> > > Sent: 09 February 2007 22:43
> > > To: [email-masked]
> > > Subject: [Sip] draft-ietf-sip-sips-01.txt
> > > 
> > > I want to draw attention to the up-issue of the sips draft.
> > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-01.txt
> > > 
> > > Here is a summary of the main changes changes:
> > > 
> > > - More clarification on using TLS with SIP instead of SIPS. 
> > > Added a call
> > >   flow 9.3 to illustrate it.
> > > 
> > > - In -00, if an endpoint registed with a SIP Contact or a SIPS 
> > > Contact, the proxy
> > >   would forward incoming request to that UAS using the 
> > scheme of the 
> > > contact
> > >   as opposed to preserve the scheme used in the request. In other 
> > > words, it
> > >   "upgraded" or "downgraded" the scheme based on what was used in 
> > > Registration in
> > >   the Contact. That introduced a whole bunch of issues with 
> > mid-dialog 
> > > requests. For
> > >   example, if an Endpoint registered with a SIPS contact, 
> > an incoming 
> > > request
> > >   sent using a SIP Request-URI would be upgraded to SIPS by the 
> > > terminating proxy.
> > >   Upon accepting the request, the UAS would then have to 
> use a SIPS 
> > > contact (as per
> > >   RFC 3261) which would most likely not be understood by the
> > >   other side, and would create problem with sending mid-dialog 
> > > requests such
> > >   as ACK. In -01, the proxy is expected to leave the Request-URI 
> > > scheme intact when
> > >   delivering the request. This will fix the problem 
> described above.
> > > Also, it
> > >   correctly indicates to the UAS that the request was NOT 
> > sent using 
> > > SIPS on every
> > >   hop. Please review carefully this change, and the 
> implications on 
> > > the
> > >   call flows in section 9 to ensure that it is correct. 
> This change 
> > > fixes
> > >   lots of problems with -00.
> > > 
> > > - When a request is rejected, a 403 Forbidden is used 
> > instead of 416 
> > > "Unrecognized
> > >   URI scheme". The rationale is that RFC 3261 says that 
> > when you get a 
> > > 416, you
> > >   should retry with SIP URI scheme which would then loop. 
> > If anybody 
> > > believes a
> > >   different error response should be used, please speak up.
> > > 
> > > - I cleaned up the description of loose routing 
> > implications of sips.
> > > The -00 draft
> > >   was saying that SIPS meant TLS for loose routes, but the
> > > -01 explains
> > > that it really
> > >   means, well, SIPS.
> > > 
> > > - Corrected a bunch of mistakes in the call flows.
> > > 
> > > The To-be-done section contains a bunch of open issues.
> > > 
> > > - One open issue regards how to deal with SIP URIs in 
> REFER and 3rd 
> > > party call
> > >   control. I'm not convinced that writing very detailed 
> procedures 
> > > makes much sense
> > >   as it could get overly complicated. Somehow, I think we 
> need some 
> > > high-level
> > >   statement about not allowing "derived connections" (such as one 
> > > obtained when
> > >   REFER or 3rd-party call control) to effectively downgrade 
> > from SIPS 
> > > to SIP.
> > >   Anyboy has any toughts on the issue?
> > > 
> > > - The other open issue is about GRUU.  How should the UAC 
> > react if the 
> > > returned
> > >   GRUU is SIP but	the To was SIPS? How should the UAC react if the
> > > returned 
> > >   GRUU is SIPS but the To was SIP? Any ideas? (Maybe we can 
> > be a bit 
> > > more
> > >   prescriptive here).
> > > 
> > > 
> > > A detailed diff can be found at:
> > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://t
> > > ools.ietf.
> > > org/id/draft-ietf-sip-sips-00.txt&url2=http://tools.ietf.org/i
> > > d/draft-ie
> > > tf-sip-sips-01.txt
> > > 
> > > 
> > > _______________________________________________
> > > 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