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

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

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 13 Feb 2007 11:45:23 -0600

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.

> 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
>  
> 
> > - In -00, if an endpoint registed with a SIP Contact or a SIPS 
> > Contact, the proxy
> >   as opposed to preserve the scheme used in the request. In other 
> > words, it
> >   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
> >   hop. Please review carefully this change, and the implications on 
> > the
> >   control. I'm not convinced that writing very detailed procedures 
> > makes much sense
> from SIPS 
> > to 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: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 13 Feb 2007 12:18:55 -0600

Francois Audet wrote:
> HTTPS by definition means TLS.

That has worked well so far when TLS was only used over TCP
for SIP (in HTTP, TCP is the only transport, so HTTPS auto-
magically implies TLS over TCP.)

I think what will probably cause a logjam is when TLS is used
with other transports (UDP and SCTP.)  Then, the preference of
a TLS transport can be specified in the URI using the "transport"
parameter with the sips scheme.

Alternatively, DNS NAPTR could be used as well.

I do not know to what extent, if any, we need to specify this
in draft-ietf-sips-01.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 13 Feb 2007 12:23:28 -0600

For what it's worth: TLS over SCTP is already defined, and there is a
Via field
for that. Not so for DTLS. 

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2007 10:19
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> Subject: Re: [Sip] draft-ietf-sip-sips-01.txt
> 
> Francois Audet wrote:
> > Hi John,
> > 
> > I think the short answer is that SIPS by definition means TLS. Just 
> > like HTTPS by definition means TLS.
> 
> with other transports (UDP and SCTP.)  Then, the preference 
> of a TLS transport can be specified in the URI using the "transport"