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

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Sep 2006 15:54:06 -0500

Thanks for your input. Very valuable.

See below. 

> ________________________________
> 
> 	From: Tina TSOU [mailto:[email-masked]] 
> 	Sent: Tuesday, September 05, 2006 3:23 AM
> 	To: [email-masked]
> 	Subject: [Sip] doubts about 
> draft-audet-sip-sips-guidelines-03.txt
> 	
> 	
> 	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? 

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.

> 	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?

I'm not sure I understand your comments, but what I do no is that I
probably need to look at the implications of the path header in more 
details.

> 	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.

Correct. I will clarify.
 
> 
> 	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).

Good point. I'll add.

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

The intent is to remove this whole Appendix in a next version. I haven't
heard
anybody arguing that the "explicit" registration mechanism should be
used.
If it stays like this, it will be gone in the next revision.

> 	
> 	B. R.
> 	Tina 
> 	Messengers: 
> 	MSN: [email-masked] 
> <mailto:[email-masked]>    Yahoo: tina_tsou    Skype: 
> tinaTSOU    Jabber: [email-masked] <mailto:[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: Michael Thomas <[email-masked]>
Date: Tue, 05 Sep 2006 14:27:06 -0700

>last hop. It has been proposed by many that the "last-hop exception

[litany of unnatural acts elided]

I find all of this just a wee bit absurd. Either make SIPS require TLS 
everywhere,
or make it require "adequate" (fsvo "adequate") security everywhere. Making
special cases for the "last hop" (which I will note probably has nothing 
to do
with the "last hop" for SIP, but instead the last hop from a service 
provider to
some CPE) seems like a pretty dumb idea frankly and speaks volumes of what
a mess this really is.

          Mike

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Sep 2006 17:48:22 -0500

And I'm not going to disagree...

Many have argued for deprecating the last-hop exception altogether.

That would require a substantive change to RFC 3261. But it would indeed
make it
less absurb. 

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 2:27 PM
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> Subject: Re: [Sip] doubts about draft-audet-sip-sips-guidelines-03.txt
> 
> Francois Audet wrote:
> 
> >the last hop. It has been proposed by many that the 
> "last-hop exception 
> >rule"
> >be deprecated.
> >  
> >
> 
> I find all of this just a wee bit absurd. Either make SIPS 
> require TLS everywhere, or make it require "adequate" (fsvo 
> "adequate") security everywhere. Making special cases for the 
> "last hop" (which I will note probably has nothing to do with 
> the "last hop" for SIP, but instead the last hop from a 
> service provider to some CPE) seems like a pretty dumb idea 
> frankly and speaks volumes of what a mess this really is.
> 
>           Mike
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 06 Sep 2006 11:46:52 +0800

Dear Francois,
Thank you very much for your reply.
See [Tina: ...] as following.

B. R.
Tina

----- Original Message ----- 
From: "Francois Audet" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 06, 2006 4:54 AM
Subject: RE: [Sip] doubts about draft-audet-sip-sips-guidelines-03.txt

See below. 

[Tina: Same as this, is it possible that a Proxy can use double RR to avoid the TLS overload for outside dialog SIPS request? Proxy can add two RR, one is SIPS to connect downstream UA or Proxy, the other is SIP to reuse the IPSec link.
 
BTW, Probably Double RR can be mentioned as an option behavior in the last hop proxy to avoid RR rewrite.]

It means the following:

I'm not sure I understand your comments, but what I do no is that I
probably need to look at the implications of the path header in more 
details.
[Tina: Sorry the doubt is not stated properly. The doubt is:
 
If a Proxy in-between the UA and the registrar inserts Path header, but the URI in Path is SIP other than SIPS even the Req-URI in REGISTER is SIPS, so the registrar will reject it by 403, but in this response there will be no information about the reason of this rejection is because illegal Path. So is more info required to be added?
 
One more: Should UA check the Service-Route header to verify each URI should be SIPS? If not, what UA will do?]

Correct. I will clarify.

Good point. I'll add.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Sep 2006 13:03:12 -0500

> [Tina: Same as this, is it possible that a Proxy can use 
> double RR to avoid the TLS overload for outside dialog SIPS 
> request? Proxy can add two RR, one is SIPS to connect 
> downstream UA or Proxy, the other is SIP to reuse the IPSec link.
>  
> BTW, Probably Double RR can be mentioned as an option 
> behavior in the last hop proxy to avoid RR rewrite.]

I don't believe you need to put two Record-Route entry to achieve
what you want.

My reading of RFC 3261 sections 16.6 and 16.7 is that you
would insert a Record-Route with sip for the outgoing request,
but that for the response, you would replace it with sips.

Like this:

UA a                  Proxy                 UA b

  ====REQUEST/TLS=======>----REQUEST/non-TLS--->
                             Record-Route=sip

  <===Response/TLS======<----Response/non-TLS---
      Record-Route=sips      Record-Route=sip

Let me know if this addresses your concern, or if I misunderstood
your point.

> If a Proxy in-between the UA and the registrar inserts Path 
> header, but the URI in Path is SIP other than SIPS even the 
> Req-URI in REGISTER is SIPS, so the registrar will reject it 
> by 403, but in this response there will be no information 
> about the reason of this rejection is because illegal Path. 
> So is more info required to be added?

I don't have an answer to this. I think this is an open issue.

> One more: Should UA check the Service-Route header to verify 
> each URI should be SIPS? If not, what UA will do?]

Funny you should ask.... I was thinking about exactly this yesterday.

I think we have 3 choices:

1 - We state that the UA MUST verify that the Service route is all SIP.

2 - We don't, which would then throw a wrench into the end-to-end 
    TLS idea. Effectively, it would allow for doing not only "last-hop"
    exceptions, but also "first-hop exceptions" or "hop-X exceptions". 
    To me, this is one more reasons why the last-hop exception is such
    a slippery slope.

3- We don't, and we let the enforcement be done at the proxies
themselves.
   This may be difficult to troubleshoot when a wrong Route entry is
encountered.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 07 Sep 2006 11:57:33 +0800

See [Tina1: ...]

B. R.
Tina
----- Original Message ----- 
From: "Francois Audet" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 07, 2006 2:03 AM
Subject: RE: [Sip] doubts about draft-audet-sip-sips-guidelines-03.txt

Like this:

UA a                  Proxy                 UA b

[Tina1: Double RR is used to avoid the rewrite in response.
 
Please refer the SIP Bug Item 664
 
Double record-routing, described in:
http://www.ietf.org/mail-archive/working-groups/sip/current/msg06589.html
 
is an alternative to rewriting the record-route header in responses. it has many benefits as pointed out in the mail, and is completely backwards compatible with 3261. Bis should probably discuss this technique and offer it as an option. This would affect some existing text that mandates rewriting the record-route in the response.]

3- We don't, and we let the enforcement be done at the proxies
themselves.
   This may be difficult to troubleshoot when a wrong Route entry is
encountered.
[Tina1: Funny you also thought about it:P I think if TLS is a MUST for SIPS, option 1 should be taken.]

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Sep 2006 13:24:54 -0500

Dean Willis please make sure you read this email...
There is a question for you.

> Sent: Wednesday, September 06, 2006 8:58 PM
> To: [email-masked]; Audet, Francois (SC100:3055)
> is an alternative to rewriting the record-route header in 
> responses. it has many benefits as pointed out in the mail, 
> and is completely backwards compatible with 3261. Bis should 
> probably discuss this technique and offer it as an option. 
> This would affect some existing text that mandates rewriting 
> the record-route in the response.]

Yes, I hadn't seen this email from Dean date Oct 14, 2002...
It's good that you are paying attention!

It does seem that the same would apply here. Very similar to the
IPv6-IPv4 transitions solution too as per 
http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-03.

Dean, was there any action (the "path forward") resulting from that 
email from you? Was the double-record route idea as an alternative
to response-altering by proxy (as per RFC 3261) formalized anywhere?

I can certainly recommend the double record-route in the SIPS document,
but it seems that it applies everywhere, not just to the infamous 
last-hop exception (e.g., IPv6 transistion and multi-homed proxies).

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Sep 2006 13:28:31 -0500

> [Tina1: Funny you also thought about it:P I think if TLS is a 
> MUST for SIPS, option 1 should be taken.]

I think I agree.

And the proxies would obviously check it too.

---

From: Dean Willis <[email-masked]>
Date: Thu, 7 Sep 2006 13:46:40 -0500

On Sep 7, 2006, at 1:24 PM, Francois Audet wrote:

>> . . .

> to response-altering by proxy (as per RFC 3261) formalized anywhere?

RFC 3608 contains the following:

    Instead of following the procedure in [3], proxies used with
    Service-Route that are inserting Record-Route or Path header field
    values SHOULD record not one but two route values when processing  
the
    request.  The first value recorded indicates the receiving  
interface,
    and the second indicates the sending interface.  When processing the
    response, no modification of the recorded route is required.  This
    optimization provides for fully invertible routes that can be
    effectively used in construction of service routes.

I believe Jonathan was hoping to do some further cleanup in route- 
construct.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Sep 2006 13:58:55 -0500

Thanks.

RFC 3608 limits this procedure to when service routes are used,
which shouldn't be the case. The "do double record-route instead
of response mangling as per 16.7/RFC3261" rule should apply everywhere.

The idea of fuirther cleaning-up in Jonathan's Route-Contruct draft
is appealing...

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, September 07, 2006 11:47 AM
> Cc: Tina TSOU; [email-masked]
> responses. 
> >> it has many benefits as pointed out in the mail, and is completely 
> >> backwards compatible with 3261. Bis should probably discuss this 
> >> technique and offer it as an option.
> >> This would affect some existing text that mandates rewriting the 
> >> record-route in the response.]
> >
> > email from you? Was the double-record route idea as an 
> alternative to 
> > response-altering by proxy (as per RFC 3261) formalized anywhere?
> >
> 
> 
>     values SHOULD record not one but two route values when 
> processing the
>     request.  The first value recorded indicates the 
> receiving interface,
> I believe Jonathan was hoping to do some further cleanup in 
> route- construct.
> 
> 
> --
> Dean
> 
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Sep 2006 14:26:03 -0500

> of response mangling as per 16.7/RFC3261" rule should apply everywhere.

There is more history here:

   1) See also RFC 3486 and its use of double R-R ((Section 6);
   2) Back in the Vancouver IETF (Nov '05) there was a thread on
   sipping-v6-transition about double R-Rs
   (http://www1.ietf.org/mail-archive/web/sipping/current/msg09938.html).
   The conclusion I later arrived at, and this is reflected in
   sipping-v6-transition-03 and the upcoming -04, is to use double
   R-R.

Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: Dean Willis <[email-masked]>
Date: Thu, 7 Sep 2006 16:02:55 -0500

> of response mangling as per 16.7/RFC3261" rule should apply  

I concur, never having liked response-mangling much. However,  
updating 3261 was somewhat out-of-scope for 3608.

I believe I have seen other drafts (RFCs?)  reference DRR "as  
described in RFC 3608".

> The idea of fuirther cleaning-up in Jonathan's Route-Contruct draft

Indeed. The problem is one of deciding which bits should be cleaned,  
and which should be left to age like Stilton . . .

--
Dean

---

From: Tina TSOU <[email-masked]>
Date: Fri, 08 Sep 2006 15:38:59 +0800

Thanks a lot. It is clearer now:)
Waiting for the aged Stilton ...

B. R.
Tina

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 8 Sep 2006 13:04:59 -0500

> I believe I have seen other drafts (RFCs?)  reference DRR "as 

That's exactly what I will do for sips-guidelines.