Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes

From: "BONNAERENS Ben" <[email-masked]>
Date: Wed, 5 Aug 2009 16:23:02 +0200

Hi,
version -08 of record-route fix has just been submitted.

Change log:
- Changed its status from BCP to PS,
- Take into account IESG reviews and subsequent comments on the mailing
lists, 
they were summarized in Robert Sparks's document (rrf.txt), 
so it has been integrated in version -08 with minor refactoring from the
authors (me and Ben).

The thoughest part was related to the SIP/SIPS question raised by Cullen
(http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-route-fix/c
omment/98624/),
so here is the text that was added in version -08 to answer this
question:
"Thus, if the transport protocol changed between its
   incoming and outgoing sides, the proxy SHOULD use the double
   Record-Route technique and SHOULD add a transport parameter to each
   of the Record-Route URIs it inserts. With the exception that if TLS
is
   used as the transport protocol on either side of the proxy, the URI
   chosen to place in the Record-Route header field value reflecting the
   interface using TLS will need to leverage the [RFC3263] mechanisms to
   indicate that TLS must be used rather attempting to use the
deprecated
   "transport=tls" URI parameter. See [RFC3261] Section 26.2.2 and
   [I-D.ietf-sip-sips] Section 3.1.4 for more discussion."

Brds,
Thomas & Ben

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 06 Aug 2009 08:36:54 +0100

Well, I know what this means, but will your average reader understand
it? I think we are trying to say something along the lines that if the
transport protocol changes you SHOULD use the double Record-Route
technique, where the differences in transport protocol are reflected in
different values of the transport parameter (udp/tcp/sctp) and/or
different values of the URI scheme (sip/sips). Correct?

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of BONNAERENS Ben
> Sent: 05 August 2009 15:23
> To: [email-masked]
> Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> 
> Hi,
> _______________________________________________
> Sip mailing list  https://www.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: "BONNAERENS Ben" <[email-masked]>
Date: Fri, 7 Aug 2009 15:57:19 +0200

Hello John,

> Well, I know what this means, but will your average reader 
> understand it? I think we are trying to say something along 
> the lines that if the transport protocol changes you SHOULD 
> use the double Record-Route technique, where the differences 
> in transport protocol are reflected in different values of 
> the transport parameter (udp/tcp/sctp) and/or different 
> values of the URI scheme (sip/sips). Correct?

Your phrasing could lead to the understanding that we suggest that 
only a sips URI can be used to identify the TLS interface which is not
correct.
As the current text suggests, can the TLS interface be identified by any
URI
(sip or sips ; excluding the deprecated transport=tls parameter) that 
resolves via RFC3263 procedures to the TLS transport.

IMHO leaves your suggested phrasing more room for ambiguity
compared to the current text.

Best regards & thanks,

Ben.  

> From: Elwell, John [mailto:[email-masked]] 
> Sent: donderdag 6 augustus 2009 9:37
> To: BONNAERENS Ben; [email-masked]
> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> 
> Well, I know what this means, but will your average reader 
> understand it? I think we are trying to say something along 
> the lines that if the transport protocol changes you SHOULD 
> use the double Record-Route technique, where the differences 
> in transport protocol are reflected in different values of 
> the transport parameter (udp/tcp/sctp) and/or different 
> values of the URI scheme (sip/sips). Correct?
> 
> John
> 
> Behalf Of 
> > BONNAERENS Ben
> > - Take into account IESG reviews and subsequent comments on the 
> > mailing lists, they were summarized in Robert Sparks's document 
> > (rrf.txt), so it has been integrated in version -08 with minor 
> > refactoring from the authors (me and Ben).
> > 
> >    chosen to place in the Record-Route header field value 
> reflecting 
> > the
> >    interface using TLS will need to leverage the [RFC3263] 
> mechanisms 
> > to
> > 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: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 09:43:57 +0100

In that case, I obviously misunderstood the text in the current draft.
What exactly is the meaning of "will need to leverage the [RFC3263]
mechanisms"?

John

> From: BONNAERENS Ben [mailto:[email-masked]] 
> Sent: 07 August 2009 14:57
> To: Elwell, John; [email-masked]

---

From: Tomasz Zieleniewski <[email-masked]>
Date: Tue, 11 Aug 2009 13:01:36 +0200

Hello Ben,

Can we say in other words that proxy in such case should
indicate used TLS transport by inserting the sips URI in the
Record-Route header instead of using transport=tls parameter.

Kind regards,
- Tomasz Zieleniewski

2009/8/7 BONNAERENS Ben <[email-masked]>

---

From: "BONNAERENS Ben" <[email-masked]>
Date: Tue, 11 Aug 2009 13:43:47 +0200

Hello John,

What we are trying to say is that the URI, identifying the TLS
interface, placed 
in the Record-Route header must, after executing the RFC3263 DNS
procedureson it, 
result in the TLS transport being selected.

This can be a sips URI or a sip URI (so called "best effort TLS" in
[I-D.ietf-sip-sips] chapter 3.1.3) 
but we suggest to not use the deprecated "transport=tls" parameter.

Best regards &Thanks,

Ben 

RFC3263 Chapter 4.1
"   First, a client resolving a SIPS URI MUST discard any services that
   do not contain "SIPS" as the protocol in the service field.  The
   converse is not true, however.  A client resolving a SIP URI SHOULD
   retain records with "SIPS" as the protocol, if the client supports
   TLS."  

> Behalf Of Elwell, John
> Sent: dinsdag 11 augustus 2009 10:44
> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> 
> What exactly is the meaning of "will need to leverage the 
> [RFC3263] mechanisms"?
> 
> John
> 
> > > understand it? I think we are trying to say something along the 
> > > lines that if the transport protocol changes you SHOULD use the 
> > > double Record-Route technique, where the differences in transport 
> > > protocol are reflected in different values of the transport 
> > > parameter (udp/tcp/sctp) and/or different values of the 
> URI scheme 
> > > (sip/sips). Correct?
> > 
> > As the current text suggests, can the TLS interface be 
> identified by 
> > any URI (sip or sips ; excluding the deprecated transport=tls 
> > parameter) that resolves via RFC3263 procedures to the TLS 
> transport.
> > 
> > > understand it? I think we are trying to say something along the 
> > > lines that if the transport protocol changes you SHOULD use the 
> > > double Record-Route technique, where the differences in transport 
> > > protocol are reflected in different values of the transport 
> > > parameter (udp/tcp/sctp) and/or different values of the 
> URI scheme 
> > > (sip/sips). Correct?
> > > 
> > > John
> > > 
> > > > The thoughest part was related to the SIP/SIPS question 
> raised by 
> > > > Cullen
> [email-masked] for questions on current sip

---

From: "BONNAERENS Ben" <[email-masked]>
Date: Tue, 11 Aug 2009 13:54:56 +0200

Hello Tomasz,
 
It can be a sips URI but it is not restricted to sips.
 
For example a SIP URI resolving to the TLS transport after executing the
RFC3263 procedures on it is possible.
 
Best regards & thanks,
Ben.
 
RFC3263 Chapter 4.1
 
[I-D.ietf-sip-sips] Section 3.1.3 ~ "best effort TLS"

________________________________

	From: Tomasz Zieleniewski [mailto:[email-masked]] 
	Sent: dinsdag 11 augustus 2009 13:02
	To: BONNAERENS Ben
	Cc: Elwell, John; [email-masked]
	Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes

	Hello Ben,

	Kind regards,
	- Tomasz Zieleniewski

		Hello John,

		> values of the URI scheme (sip/sips). Correct?

		Your phrasing could lead to the understanding that we
suggest that
		only a sips URI can be used to identify the TLS
interface which is not
		correct.
		As the current text suggests, can the TLS interface be
identified by any
		URI
		(sip or sips ; excluding the deprecated transport=tls
parameter) that
		resolves via RFC3263 procedures to the TLS transport.
		
		IMHO leaves your suggested phrasing more room for
ambiguity
		compared to the current text.
		
		Best regards & thanks,
		
		Ben.

		> From: Elwell, John
[mailto:[email-masked]]
		> > The thoughest part was related to the SIP/SIPS
question raised by
		> > Cullen
(http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r
		> > oute-fix/c
		> >    of the Record-Route URIs it inserts. With the
exception
		> that if TLS
		> > is
		> >    used as the transport protocol on either side of
the
		> proxy, the URI
		> > Sip mailing list
https://www.ietf.org/mailman/listinfo/sip
		_______________________________________________
		Sip mailing list
https://www.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: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 13:21:10 +0100

> Sent: 11 August 2009 12:44
> To: Elwell, John
> Cc: [email-masked]; Thomas Froment
[JRE] So if you want to ensure TLS, either you use a sips URI or you
populate your DNS records such that a sip URI always resolves to TLS
transport - correct?
If so, I think the average reader would have a hard time deducing this
from the present text.

John

---

From: Robert Sparks <[email-masked]>
Date: Tue, 11 Aug 2009 20:35:00 -0500

John -

Would this substitution address your concern?

      When TLS is used on the transport on either side of the proxy  
the URI
      chosen to place in the Record-Route header field value  
reflecting the
      interface using TLS will need to use a sips: URI or ensure that  
a sip:
      URI resolves (per the procedures of [RFC3263]) to using TLS rather
      than attempting to use the deprecated  "transport=tls" URI  
parameter.
      See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4
      for more discussion

RjS

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 Aug 2009 07:41:52 +0100

Robert,

Yes, that would be a lot better.

Thanks.

John

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: 12 August 2009 02:35
> To: Elwell, John
> Cc: BONNAERENS Ben; [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Aug 2009 14:42:42 -0500

>     See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4

That makes my head hurt!

Compound sentences should make sense even with clauses redacted.

Let's play some games with this mind twister:

First I'll try to scope the sub-clauses:

> (When TLS is used (on the transport (on either side of the proxy)))  
> the URI (chosen to place (in the Record-Route header field value  
> (reflecting the interface using TLS))) will need to use a sips: URI  
> or ensure that a sip: URI resolves (per the procedures of [RFC3263])  
> to using TLS (rather than attempting to use the deprecated   
> "transport=tls" URI parameter).
>

One reduction to see if it makes sense:

> When TLS is used the URI chosen to place in the Record-Route header  
> field value will need to use a sips: URI or ensure that a sip: URI  
> resolves (per the procedures of [RFC3263]) to using TLS rather than  
> attempting to use the deprecated  "transport=tls" URI parameter.

Let's pull some smaller pieces out of this:

> When TLS is used the URI chosen to place in the Record-Route header  
> field value will need to use a sips: URI.

"chosen to place" is clumsy. Let's substitute "placed", add a comma  
for the subordination,  and see if it gets better.

> When TLS is used, the URI placed in the Record-Route header field  
> value will need to use a sips: URI.

What does it mean for a URI to use a URI? I think perhaps it needs to  
BE a SIPS URI.

Rewritten:

> When TLS is used, the URI placed in the Record-Route header field  
> value will need to be a sips: URI.

Now lets look at the other half of that clause:

> When TLS is used, the URI placed in the Record-Route header field  
> value will need to ensure that a sip: URI resolves (per the  
> procedures of [RFC3263]) to using TLS rather than attempting to use  
> the deprecated  "transport=tls" URI parameter.

How does a URI ensure that a ensure something about a URI?

Maybe you mean:

> When TLS is used, the URI placed in the Record-Route header field  
> value MUST resolve (per the procedures of [RFC3263]) to using TLS  
> rather than attempting to use the deprecated  "transport=tls" URI  
> parameter.

I'm still stumbling over "resolve to using TLS rather than attempting  
to use the deprecated  "transport=tls" URI parameter." So let's just  
lop off the sentence from "rather than . . ." and move that out.

What's wrong with

> When TLS is used, the URI placed in the Record-Route header field  
> value MUST resolve (per the procedures of [RFC3263]) to using TLS .

Is "resolve to using TLS" the same thing as "resolve using TLS"? I  
think they're subtly different, but the complexity still scares me. I  
think we're trying to say that the application of RFC 3263 procedures  
to the URI must result in a next-hop that is reachable only by TLS.

So let's try a rewrite based on these assumptions. How about this:

> When TLS is used, the URI placed in the Record-Route header field  
> MUST encode a next-hop that will be reached using TLS. There are two  
> ways for this to work. The first way is for the URI placed in the  
> Record-Route to be a sips: URI. The second is for the URI placed in  
> the Record-Route to be constructed such that application of  RFC  
> 3263 resolution procedures
> to that URI produces a result reachable only using TLS. Proxies  
> compliant with this specification MUST NOT use a "transport=tls"  
> parameter on the URI placed in the Record-Route because the  
> "transport=tls" usage was deprecated by RFC 3261.

Does that mean the same thing to you as the original megasentence did?

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Wed, 12 Aug 2009 15:15:19 -0500

I skipped straight to the end (will come back and read how you got  
there later).
But yes, I think the rewrite you have at the end says the the same  
thing.

RjS
On Aug 12, 2009, at 2:42 PM, Dean Willis wrote:

>> or ensure that a sip: URI resolves (per the procedures of  
>> [RFC3263]) to using TLS (rather than attempting to use the  
>> deprecated  "transport=tls" URI parameter).
>>
>
> What does it mean for a URI to use a URI? I think perhaps it needs  
> to BE a SIPS URI.
>
> Rewritten:
>
> I'm still stumbling over "resolve to using TLS rather than  
> attempting to use the deprecated  "transport=tls" URI parameter." So  
> let's just lop off the sentence from "rather than . . ." and move  
> that out.
>
> What's wrong with
>
> think they're subtly different, but the complexity still scares me.  
> I think we're trying to say that the application of RFC 3263  
> procedures to the URI must result in a next-hop that is reachable  
> only by TLS.
>
>> MUST encode a next-hop that will be reached using TLS. There are  
>> two ways for this to work. The first way is for the URI placed in  
>> the Record-Route to be a sips: URI. The second is for the URI  
>> placed in the Record-Route to be constructed such that application  
>> of  RFC 3263 resolution procedures

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Aug 2009 15:17:05 -0500

On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote:

>    When TLS is used on the transport on either side of the proxy the  
> URI
>    interface using TLS will need to use a sips: URI or ensure that a  
> sip:

That makes my head hurt!

What's wrong with

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Aug 2009 11:42:51 +0100

OK for me too. 

John

> Sent: 12 August 2009 21:15
> To: Dean Willis
> Cc: Elwell, John; [email-masked]; BONNAERENS Ben

---

From: "BONNAERENS Ben" <[email-masked]>
Date: Thu, 13 Aug 2009 13:46:59 +0200

Hello Dean,

Sorry to make your head hurt ;-)

To me the -09 sentence was clear but I do think you have a point on the
compound sentences.

Still I would like to comment on the "only" in following sentence of the
text you proposed:
"The second is for the URI placed in the Record-Route to be constructed
such that application of  RFC  
3263 resolution procedures to that URI produces a result reachable only
using TLS."

Why should that URI _only_ be reachable via TLS?
The DNS for that URI can be populated with NAPTR records
for multiple transports with TLS as preferred I assume.

I would also replace "sips: URI" by "SIPS URI" to be consistent across
the document.

Resulting in following updated text:
"When TLS is used on the transport on either side of the proxy,
the URI placed in the Record-Route header field  MUST encode 
a next-hop that will be reached using TLS. There are two  
ways for this to work. The first way is for the URI placed in the  
Record-Route to be a SIPS URI.The second is for the URI placed in  
the Record-Route to be constructed such that application of  
[RFC3263] resolution procedures to that URI results in TLS being
selected. 
Proxies compliant with this specification MUST NOT use a "transport=tls"

parameter on the URI placed in the Record-Route because the  
"transport=tls" usage was deprecated by RFC 3261."

Can we agree on this text?

Best regards & Thanks,

Ben.

> From: Dean Willis [mailto:[email-masked]] 
> Sent: woensdag 12 augustus 2009 22:17
> To: Robert Sparks
> > (reflecting the interface using TLS))) will need to use a 
> sips: URI or 
> > ensure that a sip: URI resolves (per the procedures of [RFC3263])
> attempting

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Aug 2009 16:12:13 -0500

> for multiple transports with TLS as preferred I assume.

Dunno WHY it should say that; that's what I thought I read in the  
compound sentence I was trying to straighten out.

Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e  
TLS even more strongly than did 3261 for original sips URIs. So if a  
URI used in a record-route resolves both TLS and non-TLS, there's a  
possibility that the return stroke might not use TLS, thereby breaking  
the e2e TLS requirement. But your proposed wording change seems to  
have the same effect.

> I would also replace "sips: URI" by "SIPS URI" to be consistent across

That makes sense; I  responded in the wording I thought Robert had  
used. But consistency with the document would be preferred.  Your  
usage is also consistent with draft-ietf-sip-sips.

> Can we agree on this text?

Looks OK to me.

--
Dean

---

From: Gilad Shaham <[email-masked]>
Date: Fri, 14 Aug 2009 15:28:53 +0100

Hi Ben,

I have also read the draft and everything was clear to me and seemed
easy to read until I reached 6.1 and 6.2.

One suggestion I have to make the text more readable is to separate the
problem description from the solution. Meaning today it's:

1. Problem 1 & actions
2. Problem 2 & actions
3. Problem 3 & actions

I'm proposing to change it to
l. Problem 1
2. Problem 2
3. Problem 3

Describe each problem/scenario without describing the solution and give
examples if needed.

Following that provide all the recommended actions.

Implementers should have an easy way to see and understand all the
changes they require to conform to the RFC. For example, In RFC 4320
it's easy to follow through because it describes the changes very simply
(the problems are described in more detail in RFC 4321). I'm not
suggesting changing this draft into 2 RFCs, just asking to focus on the
problems and then focus on the actions.

In any case maybe there's a different solution for this and maybe it's
just me, but I fear that if the text would not be clear enough then many
vendors would have a hard time assessing the effort needed to implement
it and thus the adoption rate of this spec would be affected.

Final note - section 7 has a summary that may or may not provide all
necessary actions, but I simply had a lot to go through in section 6
that I almost never reached section 7.

Thanks,
Gilad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Friday, August 14, 2009 12:12 AM
To: BONNAERENS Ben
Cc: [email-masked]
Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes

Looks OK to me.

--
Dean

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 14 Aug 2009 16:31:48 +0200

13 aug 2009 kl. 23.12 skrev Dean Willis:
> possibility that the return stroke might not use TLS, thereby  
> breaking the e2e TLS requirement. But your proposed wording change  
> seems to have the same effect.
>

I did not read the draft as SIPS requiring e2e TLS. We still use  
proxys and have clear communication within the proxy. E2E to me is UAC  
-> UAS with encryption ALL the way and no middleman.

Did I misunderstand?

/O

---

From: Robert Sparks <[email-masked]>
Date: Fri, 14 Aug 2009 10:44:49 -0500

Hi Gilad -

This document is already very far along the process, we are doing fine- 
tuning based on IESG review
and while I truly appreciate insight that will make a document more  
readable, it would not be appropriate
to restructure the text at this time.

I hope more reviewers of future documents show the same kind of  
concern for the implementer you
exhibit here.

RjS

---

From: Dean Willis <[email-masked]>
Date: Sun, 16 Aug 2009 21:32:07 -0500

On Aug 14, 2009, at 9:31 AM, Olle E. Johansson wrote:

>> Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires  
>> e2e TLS even more strongly than did 3261 for original sips URIs. So  
>> if a URI used in a record-route resolves both TLS and non-TLS,  
>> there's a possibility that the return stroke might not use TLS,  
>> thereby breaking the e2e TLS requirement. But your proposed wording  
>> change seems to have the same effect.
>>
>
>
> proxys and have clear communication within the proxy. E2E to me is  
> UAC -> UAS with encryption ALL the way and no middleman.
>
> Did I misunderstand?

It kind of  on what you mean by "end to end". Draft-ietf-sip-sips  
requires that TLS be used on every hop whenever a SIPS  URI is used,  
whereas RFC 3261 allowed an exemption for the "last hop". In the  
language of the discussion at the time, this was considered "end to  
end TLS" even though it wasn't "UA to UA TLS".

Under 3261, one could legitimately double record route at a proxy  
performing contact routing with a first route entry having a SIPS URI  
and a second having a SIP URI.

With draft-ietf-sip-sips, that behavior is forbidden if the result  
would be to fail to use TLS on the route-segment indicated with a SIPS  
URI.

The record-route-fix document is essentially promoting a very special  
exception by noting that it is possible to construct a SIP URI such  
that resolution of the SIP URI using the procedures of RFC 3263 would  
guarantee that TLS is used, even though the URI itself is SIP instead  
of SIPS.

Consequently, the working I suggested was intended to convey the idea  
that the "special SIP URI" MUST resolve only to TLS and MUST NOT  
resolve to a hop that would not use TLS, since the only case in which  
we RFC 3261 would have allowed us to not use TLS was deprecated by  
draft-ietf-sip-sips.

--
Dean