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.So, I assume the following sentence should be removed "In other words, there is no IP level route between U1 and U2;".
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.
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:
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.
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
These two points were raised by Dean in a mailing list discussion, Oct. 4th 2002: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.
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 ;-)....)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.
fixing it..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?
I agree with this main objection, and that it should be re-organized now, will taken into account these recommendations in version -02,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.
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip