Subject: [Sip] doubts about draft-audet-sip-sips-guidelines-03.txt

From: Tina TSOU <[email-masked]>
Date: Tue, 05 Sep 2006 18:23:27 +0800

Hi all,
I had some doubts about sip-sips-guidelines draft as following. It will be appreciated if someone would like to reply it.

1. Does SIPS always require TLS? In IMS case, if I-CSCF of different operators already have an IPSec link, is it mandatory to establish another TLS link above IPSec? 

2. For this statement,

<Quote>
OPEN ISSUE:  What error code should be returned if not?  Should it be 403 "Forbidden"?
</Quote>

If the Proxy inbetween had inserted a SIP URI in Path header, how the UA can find this if only a 403 is been received?

3. For section 6 paragraph 1 the following statement,

<Quote>
This poses a very significant problem if Record-Route is not used in that if the remote end does not support SIPS, it will not be able to send a mid-dialog request to the client.
</Quote>

I had a doubt that if the remote end doesn't support SIPS, then there must be one Proxy will RR as the RFC3261 16.6 bullet 4 (the text had been quoted in the following for reference). And the problem mentioned in the above statement will not exist.

RFC3261 16.6 bullet 4
<Quote>
Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field.  In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post         processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI.
</Quote>

4. Appendix A, Open issue 1, Perhaps using Notify to intimate is not a good idea as there may be no implicit subscription because of subscription suppression (draft-ietf-sip-refer-with-norefersub).

5. Appendix B: Is the procedure defined in main document "explicit registration"? But this phrase cannot be found in main document.

B. R.
Tina 
Messengers: 
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]
_______________________________________________
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: "Samir Srivastava" <[email-masked]>
Date: Wed, 13 Sep 2006 14:23:15 -0500

Hi,

Can we avoid double encryption between two SIP addressable entities?

If IPSEC tunnel is between two *SIP un-addressable* entities, then SIP
application layer does not bother. 

This is penalty of tight coupling of TLS with SIPS. It is secure routing
requirement, and should be done with Proxy-Require with clear definition
of secure protocol etc. After 3261 (SIPS), we found new URI property
(GRUU) and now we are defining GRUU with SIPS. When we discover new URI
properties in future then we will keep defining its behavior for SIPS
(more texts/cycles/complications etc) .

Thx
Samir

<< Removed unrelated stuff >>
  
> >
> >
> > 	1. Does SIPS always require TLS? In IMS case, if I-CSCF
> > of different operators already have an IPSec link, is it
> > mandatory to establish another TLS link above IPSec?
> 
> This is what is described in Section 3 of the draft, but I probably
> need to discuss the last-hop exception rule in more details,
especially
> how it relates to Record-Route.
> 
> The answer is that SIPS always require TLS for all hops until you
reach
> the
> last hop. It has been proposed by many that the "last-hop exception
> rule"
> be deprecated.
> 
> To answer your question in terms of when you send a request outside of
> an existing dialog, you are correct that (except for the last hop),
> you DO have to use TLS for reaching SIPS resources. If you are using
> IPsec
> as per your example, this will indeed mean TLS over an IPsec link.
That
> is
> correct.
> 
> The last hop exception has some interesting side effects however when
> used
> inside a dialog.
> 
> If the last hop doesn't use TLS, the last Record-Route entry would be
a
> SIP URI instead of SIPS URI.
> 
> Therefore, within that dialog, the last hop would be allowed to send
> requests where the request-URI itself is sips but where the
Record-route
> is SIP, and therefore that request would not be sent over TLS. In
other
> words,
> a terminal would be able to accept over TCP/UDP a request to SIPS
> addressed to
> itself, and send mid-dialog requests to a remote target using a SIPS
> Request-URI
> but using UDP or TCP as per the Record-Route entry.
> 
> What does it mean for architectures that prefer to use IPsec instead
of
> TLS?
> 
> It means the following:
> 
> - You probably do not want to use SIPS URIs for those devices in the
> IPsec
>   network (phones, etc.).
> 
> - If Record-Route is used, those devices will be able to reuse the
same
> TCP or
>   UDP connection for sending mid-dialog requests even if the
Request-URI
> is SIPS.
> 
> - However, if the device is sendind requests outside of a dialog (like
> an INVITE for
>   example), to a SIPS URI, it HAS to use TLS (and therefore TLS over
> IPsec in your
>   example).
> 
> - Therefore, if you do NOT want to do TLS over IPsec in this case, it
> means that
>   you can not reach SIPS resources. You will be able to receive
requests
> from
>   entities using SIPS as contacts (with Record-route), but you will
not
> be able
>   to make requests to SIPS. If a resource supports both SIP and SIPS,
it
> would
>   still be reachable using SIP since they are routed the same way.
> 
> 
> I will include much more text on this in the next revision.
> 
>