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

[Thomas Froment <[e-mail]>]

Hi,
answers inlines...
Jonathan Rosenberg a écrit :
> 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.
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?
>
> 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.
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

>>   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.
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?
>>   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.
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 ;-)....)

>> 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?
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" ;-)..
>> 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 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


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip