Subject: [Sip] comments on draft-ietf-sip-record-route-fix-01

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 02 Dec 2007 23:25:08 -0500

Firstly, I am still of the opinion that this is NOT an essential 
correction to SIP, but rather a BCP. Clearly the record-route mechanism 
in RFC3261 itself still works and works fine for the cases where it is 
applicable. Documenting double-record routing makes sense, but I do not 
believe it should replace what is in RFC3261 or obsolete it. There is no 
reason to do it, and its unrealistic to think that everyone who is doing 
rr-rewriting will go an change their implementation because IETF decided 
to deprecate something that works.

Section 3.1: this is an unrealistic use case. If this were the actual 
network, no media would be able to flow in the resulting session.

Section 3.2: the indented text seems to include both the original 
rfc3261 text and commentary on it; I think only the orginal text should 
be indented.

> often been noticed that letting [RFC3261] with the Record-Route
>    rewriting as the only technique described in core specification is
>    dangerous, due to the fact that rewriting has some heavy drawbacks.

this is hyperbole, and not supported by the two points which follow:

>   1) Callee cannot sign the route set, because it gets edited by the
>       proxy in the response.  Consequently, end-to-end protection of the
>       route set can not be supported by the protocol.  The openness and
>       the end-to-end principles are broken (!)...

sign the route set?? This has never been possible. Even S/MIME doesn't 
support that:

    Header fields that can be legitimately modified by proxy servers are:
    Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
    Authorization.  If these header fields are not intact end-to-end,
    implementations SHOULD NOT consider this a breach of security

I don't know what real attack or real problem you are talking about here.

>   2) Proxy must implement special "multi-homed" stateful logic.  On
>       the request phase, it goes through output interface calculation
>       and writes the output interface into the route.  It must then
>       inspect all responses, grep for an input interface, and
>       selectively edit them to reference the correct output interface:
>       this is a CPU drag.

it is true that there is additional CPU cost. However, that is hardly 
"dangerous". And, I suspect, in most cases, not a very big CPU burden.

I'm not opposed to double record-routing; I am taking objection to the 
vilification of what is in RFC 3261.

> Thus, on the request processing side: item 4 of section 16.6 of
>       [RFC3261], it SHOULD be noticed that the URI MAY contain the

I don't know what it means to SHOULD notice something. Why is this text 
indented?

> This technique has many benefits, and is completely backwards
>    compatible with [RFC3261].  It consists in putting as the first
>    value, the Route of receiving interface, including schemes and/or URI
>    parameters, and, as second value, the Route of the sending interface.
>    When processing the response, no modification of the recorded route
>    is required.

s/Route/URI

Section 5 has odd indenting.

The document is hard to follow; it intermixes restatements of RFC3261 
sections along with other normative text which is not defined as a 
restateemnt of rfc3261.

I think it would be a clearer document, in fact, if it were not an 
essential correction and instead a clear description of how to double 
record-route and when to do it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
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: Thomas Froment <[email-masked]>
Date: Mon, 03 Dec 2007 14:29:06 +0100

Hi,
answers inlines...
Jonathan Rosenberg a écrit :
> correction to SIP, but rather a BCP. Clearly the record-route 
> mechanism in RFC3261 itself still works and works fine for the cases 
> where it is applicable. Documenting double-record routing makes sense, 
> but I do not believe it should replace what is in RFC3261 or obsolete 
> it. There is no reason to do it, and its unrealistic to think that 
> everyone who is doing rr-rewriting will go an change their 
> implementation because IETF decided to deprecate something that works.
>
So, I assume the following sentence should be removed "In other words, 
there is no IP level route between U1 and U2;".
The multi-home proxy still exist, do you agree?
> rfc3261 text and commentary on it; I think only the orginal text 
> should be indented.
Ok, I will try to clarify this.. Indeed, it was mixed from the first 
version of the document because it is inspired by the sipit.net 
descriptions:

http://bugs.sipit.net/show_bug.cgi?id=664
http://bugs.sipit.net/show_bug.cgi?id=734
http://bugs.sipit.net/show_bug.cgi?id=735

> I don't know what real attack or real problem you are talking about here.
These two points were raised by Dean in a mailing list discussion,  Oct. 
4th 2002:
http://www1.ietf.org/mail-archive/web/sip/current/msg06589.html

It is just wrong?
> vilification of what is in RFC 3261.
In fact, my initial version was not so oriented *against* the rewriting, 
but some people encouraged me to be more "radical"... (I can give the 
names ;-)....)

> I don't know what it means to SHOULD notice something. Why is this 
> text indented?
fixing it..
 This part aims at summarizing parts of the RFC being impacted by the 
draft, I will probably make a dedicated section for that, and remove the 
"SHOULD notice" ;-)..
> sections along with other normative text which is not defined as a 
I agree with this main objection, and that it should be re-organized 
now, will taken into account these recommendations in version -02,

Still need to decide now if it should be a BCP or an RFC 3261 essential 
correction process document...
Thansk a lot,
Thomas

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 Dec 2007 10:02:27 -0600

On Dec 2, 2007, at 10:25 PM, Jonathan Rosenberg wrote:

>
> Section 3.1: this is an unrealistic use case. If this were the  
> actual network, no media would be able to flow in the resulting  
> session.
>

well, MESSAGE methods and presence and probably MSRP would flow. Do  
you mean to say SIP isn't useful for that sort of application?

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Dec 2007 17:23:10 -0500

Dean, according to the picture, there is NO IP CONNECTIVITY between 
endpoints. Only a SIP proxy connects them. Nothing will work.

-Jonathan R.

Dean Willis wrote:
> well, MESSAGE methods and presence and probably MSRP would flow. Do you 
> mean to say SIP isn't useful for that sort of application?
> 
> -- 
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 5 Dec 2007 17:59:19 -0600

MESSAGE requires only a SIP proxy to span this. MSRP could easily  
have a parallel set of relays. This was actually a fairly typical  
enterprise network (at least through the mid 1990s), where there is  
no IP connectivity between the corp net and the Internet. All cross- 
net connectivity is provided by per-protocol proxies. I built up 50  
or more enterprise networks with exactly this property.

SIP is useful without media. You ever use Micosoft's IM client?

--
dean

On Dec 5, 2007, at 4:23 PM, Jonathan Rosenberg wrote:

>> well, MESSAGE methods and presence and probably MSRP would flow.  
>> Do you mean to say SIP isn't useful for that sort of application?
>>