Subject: [Sip] Process question on fixing record-route

From: Dean Willis <[email-masked]>
Date: Mon, 23 Apr 2007 13:56:06 -0500

In Prague we recorded a consensus on documenting the various fixes to  
record-route as described in:

http://www.ietf.org/internet-drafts/draft-froment-sip-record-route- 
fix-00.txt

While we agreed to undertake this effort, we left open the discussion  
of how to achieve it.

Two proposals were made:

1) Recast the solution as a BCP

2) Move this into the "Essential Corrections" process for RFC 3261  
bugfixing.

I currently lean towards number 2, but we should discuss it.

--
Dean

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Mon, 23 Apr 2007 13:59:57 -0500

I think this should go down the 1) path. This is a recommended use of  
mechanisms that exist, not a change of any normative text.

RjS

On Apr 23, 2007, at 1:56 PM, Dean Willis wrote:

>
> In Prague we recorded a consensus on documenting the various fixes  
> to record-route as described in:
>
> While we agreed to undertake this effort, we left open the  
> discussion of how to achieve it.
>
> Two proposals were made:
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Apr 2007 15:21:30 -0500

On Apr 23, 2007, at 1:59 PM, Robert Sparks wrote:

> I think this should go down the 1) path. This is a recommended use  
> of mechanisms that exist, not a change of any normative text.
>

So we can fix [BUG664], [BUG734], and [BUG735] with a BCP?

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Mon, 23 Apr 2007 15:42:14 -0500

664 - Yes - we are making a behavior explicit that obviates the need  
to do rewriting, and the clause that talks about rewriting starts out  
"If the URI placed in the Record-Route header field needs to be  
rewritten"

724 - Yes - this bug is asking for a clarification, not an essential  
change to normative text. (The essence of the bug is to capture that  
proxies should record route any time the transport details change  
between coming in and going out).

735 - Not covered by the draft in question. That's a sips: question -  
This one _will _ require normative changes to the spec, but will come  
around only after we make more progress on the sips discussion. And  
depending on how that comes out, it may or may not fall into the  
category of an _essential_ correction.

RjS

---

From: Thomas Froment <[email-masked]>
Date: Tue, 24 Apr 2007 10:44:08 +0200

It seems that, the document can end with some modifications not 
requiring to change any *must* statement, so if i understood well what 
Robert said, it is still possible to change a *should* (i.e. "you can 
bypass it only if you have a very good reason"...) in a "bcp" (best 
practice having to justify what this very good reason IS...).

Before going to version -01, I would like to poll the working group on 
the following open issues:

1) Do we want to *deprecate* record-route rewriting or just recommend 
double R-R but let R-R rewriting as a valid alternative?

When I wrote the first version of the draft, I decided to let the two 
possibilities open, but some people told me there was probably a 
consensus for deprecating.
Is rewriting a valid technique given the fact that end-to-end protection 
of the route set can not be supported by the protocol when authorizing this?

So, maybe we can start a poll here, who is in favor of deprecating, who 
is opposed and why?

2) About transport switching, as it is described yet, one of the 
observed proxy implementation behaviour is to make double R-R, puting 
the transport parameter
(for instance, if we have a proxy switching from TCP to UDP, and using 
numeric IP addresses), and thus, ignoring the SHOULD 
statement:[RFC3261], item 4 of section 16.6, "The URI placed in the 
Record-Route header field value MUST be a SIP or SIPS URI. [...] The URI 
SHOULD NOT contain the transport parameter unless the proxy has 
knowledge(such as in a private network) that the next downstream element 
that will be in the path of subsequent requests supports that transport".

Actually, double RR with transport parameter is ok as long as the 
dowstream element support that transport. It is, in the most general 
case, always the case
as long as proxy is using one on the transport mandated in RFC3261 (UDP, 
TCP).
The problem occurs of course if the proxy is switching, for instance, 
from TCP to SCTP, then, if the next SIP element supports that transport, 
it is still dangerous:
let's assume this is a proxy which is NOT record-route, then, when a 
subsequent request arrives, the second SIP element may be asked to route 
the request
using a Route with transport=SCTP parameter it does not support.
What to do in that case? I suggest to recommend to double -RR WITH 
transport parameter *only* if transport is a mandatory transport (UDP or 
TCP, possibly TLS, but should be replaced by sips in a near future, so 
let's forget the TLS transport), OR if proxy has knowledge that *any* 
subsequent element do support that transport.

Any thoughts?

-
Thomas

Dean Willis wrote:
> http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt 
>
>
>

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 24 Apr 2007 17:25:05 +0300

> double R-R but let R-R rewriting as a valid alternative?

can you clarify what you mean by r-r rewriting?  if i recall correctly,
according to rfc 3261 r-r headers are added during dialog initiating
request and after that route set does not change, i.e., proxies only
need to r-r initial request.

 > The URI 

my proxy may be talking to a proxy of another organization using tls no
matter if uri scheme in requests is sip or sips.  if request comes in
over udp and goes out over tls, should my proxy double r-r and add
transport=tls or what?

-- juha

---

From: Thomas Froment <[email-masked]>
Date: Tue, 24 Apr 2007 16:44:30 +0200

> need to r-r initial request.
Yes, RR-rewriting is described in section 3.2 of 
http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt,
and drawbacks outlined in section 4...
Basically, the R-R has to be modified in the 200 OK response so that the 
Route set seen by the caller will be different than the Route set seen 
by the callee...
> over udp and goes out over tls, should my proxy double r-r and add
So, I voluntarily omitted to discuss the "transport=TLS" use case since 
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt already 
take care of it,
so "sips:" scheme should be used and double RR is also to be recommended 
when transiting from "sip:" to "sips:", it is described in the sip/sips 
document.

By the way, another question comes to my mind, should we ask Francois 
Audet to reference this record-route document in its "double RR" section?

The open issue I described here was: "do we recommend to double R-R 
*and* put the transport parameter on RR header in some circumstances?" 
(which is a different
wording than current text which says "SHOULD NOT put any transport 
parameter etc...".

-
Thomas

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 24 Apr 2007 17:51:36 +0300

> and drawbacks outlined in section 4...

so you are going to make a change to rfc3261 just like that?  if so,
what is the motivation for it?

 > Route set seen by the caller will be different than the Route set seen 

why?

 > when transiting from "sip:" to "sips:", it is described in the sip/sips 

what you describe in above has nothing to do with my example where
request comes in to proxy over udp using sip uri scheme and my proxy has
an agreement with the next hop proxy that tls is used for all
communication between the two proxies.  of course my proxy cannot go and
change uri scheme to sips.  so please tell me exactly what my proxy has
to do regarding record routing.

-- juha

---

From: Thomas Froment <[email-masked]>
Date: Tue, 24 Apr 2007 17:14:36 +0200

Juha Heinanen wrote:
> what is the motivation for it? [...]
So, please read the the draft, I cannot reword it with a smaller number 
of words in the mailing list...
> communication between the two proxies. 
> so please tell me exactly what my proxy has to do regarding record routing.
>   
from sip/sips document: "[RFC3261]/26.2.2 makes it clear that the use of 
the "transport=tls"  URI transport parameter in SIPS or SIP URIs has 
been deprecated.
So, normative change recommended by this document is the following:
" 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."

To be compatible with that statement, in your use case,
I think you should use double RR, on the UDP side, use a RR header with 
transport=UDP or NO transport parameter (that was my question: do we 
allow to put
this transport parameter in some circumstances?),
on the TLS side, do not use any transport parameter, but use the sips 
scheme on RR.
Does it answer your question?

Thomas

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 24 Apr 2007 18:30:58 +0300

> of words in the mailing list...

there is so many sip working group drafts that it is impossible for
someone who also needs to do some real work to read them all.  i just
got worried when i noticed that some changes to rfc3261 were proposed.
looks like a complicated issue, if it the reasons cannot be states in a
couple of sentences.

 > Does it answer your question?

yes, you answered my question, but the answer is totally unacceptable.
i repeat, there is no way my proxy can go and change uri scheme from sip
to sips, since my proxy has no way to know that tls is supported on the
following hops and, if not, the request that started as sip will fail.

-- juha